Page List

Search on the blog

2021年9月14日火曜日

class SRE implements DevOps

SREに関する講座「class SRE implements DevOps」を視聴した。
 

簡単なメモを残しておく。

What's the Difference Between DevOps and SRE?
  • DevOpsはDeveloperとOperatorの障壁を取り除くための指針
    • Developerは新しい機能を早くリリースしたい
    • Operatorはシステムが安定して動くように新しい機能をリリースしたくない
  • SREはDevOpsの実装の1つ
SLIs, SLOs, SLAs, oh my!
  • プロダクトごとに求められる availability は異なる
  • availability の定義もプロダクトによって異なる
  • SLI(Service Level Indicators) 過去5分間の95-percentile latencyが300ms未
  • SLO(Service Level Objectives) 年間を通してSLIが99.9%正常である
  • SLA(Service Level Agreements) 年間を通してSLIが99.5%未満しか正常でなかったらカスタマーに返金する
Risk and Error Budgets
  • Error Budget = どのくらいの unavailability を許容できるか
  • Error Budget が無くなったら、新しい機能のリリースはやめて信頼性の向上にフォーカスする
  • Error Budget でアクシデント/リスクを数値化することで、アクシデントは起こって当然だと認識できる
Toil and Toil Budgets
  • Overhead: Email, ミーティング、通勤
  • Toil: プロダクションサービスの運用に関わるタスクのうち、繰り返し手動で行われる自動化可能なもの
    • 障害対応もToil
    • 障害対応を自動化するツールを書くのはToilではない
    • すべてのToilが悪いというわけではない(新人が手動でシステムをいじって理解を深めるなど)
Now SRE Everyone Else with CRE! 
  • APIを公開しているサービスはコンシューマにSLOを共有するべき
  • Customer Reliability Engineering = Google Cloudでアプリケーションを作っているユーザのSRE実現をサポート
Managing Risks as a Site Reliability Engineer
  • Risk Analysis = 考えられる障害のダウンタイム、影響範囲、頻度などを使ってSLOを達成できるかどうか調べる
  • Risk Analysis を行うことで SLO 達成のために排除すべきリスクが分かる
  • Risk Analysis を行うことで、現実的な Error Budget が分かる
Actionable Alerting for Site Reliability Engineers
  • アクション可能で無い雑音のアラートはOFFにする
  • SLOを使って実際にユーザに問題が発生している場合にアラートを出すようにする
    • fast burn alert: 短期間のError Budget の消費量が異常 -> アラート、緊急対応
    • slow burn alert: 長期間のError Budget の消費量が異常 -> チケット、業務時間内での対応
Observability of Distributed Systems
  • structured logging: ユーザ情報が入った reqeust logs, サーバの debug logs
  • metrics: クエリの数、レイテンシーの分布、CPUロードなど
  • traces: 実行フローのタイミングや依存関係
  • 失敗している処理の共通点(リージョン、コードのバージョンなど)を見つけることで原因を特定しやすくなる
Incident Management
  • インシデント対応のときは明確なロールと責任を定義する
  • 計画と実行を一人で行うのは難しいので分業が必要
    • Incident Commander(IC): 戦略的な意思決定とロールのアサインを行
    • Operation Lead: システムの理解と変更に責任を持つ
  • 必要に応じて、ICはコミュニケーション機能やロジスティック機能(食べ物を買ってきたり、部屋の環境を整えたりする)を他の人に移譲することができる
Postmortems and Retrospectives
  • ICがドラフトを作るが、すべてのロールの人が必要な情報を追記していく
  • Blameless culture を持つことが大事
  • Distributed System は様々な要素が絡み合って動作するので、root cause だけではなくすべての要素について記述する

0 件のコメント:

コメントを投稿