SRE : Site Reliability Engineering
Googleが提唱・実践しているシステム管理とサービス運用の方法論
1.1 サービス管理へのシステム管理者のアプローチ
従来のDevOps : 「開発」「運用」で分かれる
- Dev
- 好きなものを好きなときにローンチしたい
- Ops
- 一度動いたシステムは一切変更したくない
対立しがち
1.2 サービス管理へのGoogleのアプローチ（SRE）
Googleはソフトウェアエンジニアを採用して、いままでシスアドが手作業で行ってきた作業を遂行するシステムを構築するようにした。
→ ソフトウェアエンジニアが運用チームの設計
- 手作業でタスクをこなすことにすぐに飽きてしまう
- 代替するソフトウェアを書くスキルセットを持つエンジニアチーム
すべてのSREに共通するのは、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適正。
常にエンジニアリングをしないと、運用の負荷が増大し続ける
SREに対して、チケット、オンコール、手作業といった「運用」業務の合計を50%以下にするように上限を設けた。
1.3 SREの信条(責任を持つ領域)
- サービスの可用性
- レイテンシ
- パフォーマンス
- 効率性
- 変更管理
- モニタリング
- 緊急対応
- キャパシティプランニング
1.3.1 エンジニアリングへの継続的な注力の保証
- 運用50%
- 残りはコーディングを伴うプロジェクト作業
目標
- 運用負荷のオーバーフローが起こらない
- プロダクトが過大な運用負荷を生じさせない
SREと開発者がお互いに目標を支持する
50%をオーバーするようであれば、50%以下になるまで開発サイドにも手伝ってもらう。
ページャー（アラートのこと）が無くても、インシデントについてポストモーテムを書くべき
- モニタリングの欠陥
- 問題を明らかにする
1.3.2 SLOを下回ることなく、変更の速度の最大化を追求する
エラーバジェット（予算）
信頼性の目標を100%にするのは間違っているという考え。
ユーザとサービスの間には数多くのシステムが存在するため可用性が下がる。
100%にするための苦労が見合わない
信頼性の目標をどう考慮するか
- ユーザが満足する可用性のレベル
- 可用性に満足できないユーザへの代替策
- 可用性のレベルを変更した場合にプロダクトの利用に変化が起こるか
可用性のターゲットを決める
100% - 可用性 = エラーバジェット（予算）
- 開発:ローンチのリスクに使う
- SRE:エラーバジェットを節約
→ 素早いローンチに向けた最適化
エラーバジェットを使うことでSREの目標は
「サービス障害を0にすること」ではなく「機能のリリース速度を最大化するためにエラーバジェットを使うこと」になる。
サービス障害は悪いことではなく、予想済みの部分。これをコントロールする。
1.3.3 モニタリング
システムの健全性と可用性を追跡。
アラートメールは効果的ではない。
- 人間がメールを読み、何らかの対応アクションの必要性を判断しなければならないようなシステムは、根本的に欠点を抱えている
- ソフトウェアが解釈を行い、人間はアクションを行う必要があるときのみ通知を受けるべき。
モニタリングの出力
- アラート 即座にアクションを行う
- チケット 即座である必要はない
- ロギング 人間が見る必要はないもの
1.3.4 緊急対応
信頼性
- 平均故障時間(mean time to failure)
- 平均修復時間(mean time to repair)
予めオンコール手順書を作って練習することでMTTRを短縮
1.3.5 変更管理
サービス障害の70%はシステムの変更によって生じている。
- 漸進的なロールアウトの実装
- 高速かつ正確な問題の検出
- 問題が生じた際の安全なロールバック
これらを自動化することで、リリースの速度と安全性が高まる
1.3.6 需要の予測とキャパシティプランニング
- 自然な成長
- 突発的な成長
ステップ
- 自然な需要の正確な予測。リードタイムも考慮
- 突発的な需要の発生源を織り込む
- リソースとサービスのキャパシティ把握のための定期的な負荷テスト
1.3.7 プロビジョニング
必要に応じてリソースを提供できるように準備しておくこと。
変更管理とキャパシティプランニングの組み合わせ。
すばやくかつ必要な場合のみ行う。
1.3.8 効率とパフォーマンス
リソースは需要（負荷）、キャパシティ、利用率の関数
レスポンス速度のキャパシティのターゲットを満たすようにプロビジョニングを行う。
パフォーマンスを改善するためにモニタリングと改修に努め、キャパシティを追加して効率を改善する。