【書評】SRE・運用保守

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

概要

• システムの信頼性を担保するために、ソフトウェアエンジニアによって運用保守(監視障害対応)業務の標準化、継続化、自動化を行ったGoogleの組織的実践例
• 冒頭でSREという言葉自体は表現として曖昧である断りが書かれている
• また、SREはDevOpsをGoogleで拡張したプラクティスとも捉えることができると注意書きがある（具体的な方法論は本書熟読推奨）
• IPAでいうRASISに該当する
• システムの信頼性・クラウドサービスごとの可用性・運用コストの3点が主な焦点となる

背景・課題

• 一般にソフトウェアの運用よりもを誕生させるための議論が多い
• しかし実際は誕生後の運用の方がコストとして40%~90%になりうるという推定研究結果がある（＝創業よりも守勢の方が難しい）
• また従来、ソフトウェア開発エンジニアとシステムアドミニストレーターとが別の職種として分かれていた

解決方針

• プロダクト開発チームと別に、運用のためのSREチームを発足
• 新たにソフトウェアエンジニアに運用業務を任せるようにし、開発業務時間50%運用業務時間50%にする
• 50%を超えた運用業務はプロダクト開発チームに差し戻す（これにより運用業務手作業時間の増加を防ぐ）
• 50%の開発業務では、ソフトウェア定義設計開発運用保守全般の標準化、自動化を図る

他業界との比較

4つの観点での考察

1. 準備とディザスタテスト
2. ポストモーテムの文化（個人と問題の分離）
3. 自動化と運用のオーバーヘッドの低減
4. 構造化された合理的な判断

結論

• 他業界と比較するとSREは、発生しうる障害の様々な影響への未然防止よりも変更を加える速度・適応速度への要求が高い
• （ただし障害の影響がとても大きい場合保守的なアプローチが妥当
• SREは他の業界で培われた原則を採用し、規模、複雑性、速度、信頼性のバランスをもたらすために作られた組織的取り組み

付録：

Google参考資料

https://lp.cloudplatformonline.com/rs/808-GJW-314/images/App_Modernization_Session_03.pdf

cloud.google.com

AWS運用保守サービス

classmethod.jp

GCP運用保守サービス

cloud-ace.jp