自分の理解を深めるためにまとめてみました。

1章イントロダクション

Dev（開発）とOps（運用）を分離することによるOps観点でのメリデメ

メリット

業界的にナレッジが蓄積されており、学習＆真似がしやすい。
人材確保しやすい。

デメリット

マニュアルでの運用がベースとなるため、サービスの規模に比例してチームの規模が大きくなってしまう。
開発と運用でバックグラウンドが異なるために衝突しやすい。
開発はスピードを素早くリリースしたいという目標に対して、運用は極力問題が起こさないようにしたいという開発とは逆行する目標となってしまう。

上記デメリットに対するGoogleのアプローチ

ソフトウェアエンジニアにサービスを運用させることで、自動化をすすめた。GoogleのSREの大半はソフトウェアエンジニアリング＋一連の技術的スキル（主要なものとしてUNIXシステムの理解＆ネットワーク（L1～L3））を持っている。さらに全てのSREに共通するのは、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適正。自動化にリソースを割かせるために運用業務は全業務時間の50％以下に抑えるようにしている。そのためにはまずは時間の計測から。そしてもし運用業務が50％以上になっているのであれば人員追加を行う。SREチームと開発チームとの間で人的交換が可能となり、エンジニアのスキルアップという副次的効果もある。課題としては人材採用が難しい。というのもコーディング＋技術の両方を有する人材はかなり少ないからである。また、リリースの調整が必要なことからマネジメント層の理解/協力が必須。

SREの信条

継続的な学習

実戦からの経験を得ながら改善するためには障害の発生度合いが大事。障害が多すぎるのは当然良くないが、少なすぎると時間だけが無駄に過ぎてしまい学習することができない。改善のための事後検証（ポストモーテム）は必須である。

SLOの考え方

100%の信頼性は目指すべきできはなく、サービスの内容を鑑みて99%なのか99.9%なのか99.99%なのかを決める。100%から信頼性を引いた値をエラーバジェットとして捉え、エラーバジェットをどのように使うかが重要。理想的にはローンチに関することにバジェット（予算）を使用できるとよい。

モニタリング

設定した閾値を超えたらアラートメールを飛ばし、それを受け取った人間がリカバリを行うという旧来のフローはよろしくないので、極力人間を介さずにリカバリできるような仕組みを構築し、やむを得ず人間の判断が必要な場合だけ通知するフローにする。

緊急対応

MTTF（平均故障時間）とMTTR（平均修復時間）ではMTTRの方が重要。その場の判断でスーパーエンジニアが神がかり的なテクニックで復旧することよりも、事前に手順書を作っておき有事の際は手順書を使って復旧することのほうがよい。その手順書を使って事前に障害復旧のシミュレーションをしておくとさらによい。

変更管理

少しずつリリースしていき、何か問題が発生したらすぐに検知できるようにし、必要に応じてミスの無い切り戻しができることを目指す。

キャパシティプランニング

問題が起こる前に、自然的/突発的な需要を加味してキャパシティの計画を行う。

プロビジョニング（リソース増強）

コスト面を考えるとプロビジョニングは素早くかつ必要な場合のみ行うべき。

効率とパフォーマンス

コストとパフォーマンスのバランスを意識してリソースを調整する必要がある。

（2章に続く）

1章 イントロダクション