簡単なメモを残しておく。
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 だけではなくすべての要素について記述する