SRE サイトリライアビリティエンジニアリング

 昨日読了。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

大著。SREという新しい概念の理論的紹介と、Googleでの膨大な実践例。

運用エンジニアの新たな概念であるSRE。SREの作業時間は、エンジニアリング、トイル、オーバーヘッドからなる。エンジニアリングはソフトウェア開発や（単発の）システム設定やドキュメント作成であり、トイルを自動化するのが目的。トイルはサービス運用の実作業であり定形作業やインシデント対応。オーバーヘッドは会議や教育など。

SREは、エンジニアリングの比率を50%以上にすることが目標。そのためには、12時間のシフト中のインシデント対応の最頻値は0件で、たかだか2件以内とする。エンジニアリングの比率を維持することで、自動化によるシステム能力に比例しない人員での運用が可能になるとともに、運用エンジニアのスキル・キャリア・モチベーションの維持拡大が可能になる。成熟度が向上するとインシデントがほとんど発生しなくなるため、定期的なディザスタテスト（DiRT = Disaster and Recovery Testing）が必要。

開発チームとSREチームとの間は緊張が生まれる。開発チームは機能提供のスピード（＝変更すること）、SREチームはシステムの安定性（＝変更しないこと）を求める。SLOをもとにエラーバジェットを形成することで、同じ方向を向くことができる。クォーターごとのエラーバジェットが残っいれば変更可能、残り少なければ変更不可。SREチームは50%ルールを破るアプリケーションに対して、開発チームに一部の運用を差し戻しすることができる。

SREによるソフトウェアエンジニアリング。自らがニーズを把握して、自らの仲間が利用者である。Auxonというインテントベースのリソース割当てツールがGoogleでの成功例。SREが生み出したものからGoogleの対外サービスになったものもある。

用語: トイル、ポストモーテム、カスケード障害、カナリアリリース、ディザスタテスト