今更ながら「SRE サイトリライアビリティエンジニアリング」を読んだ❗️
出版された2017年にすぐ購入してパラパラとは読んだけど，当時の僕の経験値だと深くまで理解できなかったり，590ページという厚さに圧倒されたりもして，書評記事を書けず積読してしまっていた📕 最近 Site Reliability Engineering (SRE) の導入を考える機会があったりして，本書を一冊すべて読むことにした．ちなみに本書は朝活としてコツコツ読んでいて，3週間（朝活をした日だと17日間）で読んだ．
今では SRE 事例をよく聞くようになったし，実際に SRE を担当してる友人もいるほどには普及してる感じだけど，それでも僕が支援している現場だとまだまだそういうレベルに達していないこともあって「アプリケーションとインフラのサイロ化」という状態ですら全然ある．本書で学んだことをすべて導入できるとは思えないけど，真似できるところやマインドセットから築いていくこともできそうで，そういうアプローチを学べたのは良かった👌
また本書のタイトルに SRE と付いているから自分は読む必要がなさそうだ〜と敬遠してしまう人もいそうだけど，インフラ（もしくは信頼性に取り組むこと）を他人事に感じて欲しくなく，どういうポジションだったとしてもサービスの信頼性に対する意識はチームでの共通認識として高めていくのが重要だと思う．全員気持ちは SRE！的な〜 ＼( 'ω')／
目次
- 第Ⅰ部 : イントロダクション
- 1章 : イントロダクション
- 2章 : SRE の観点から見た Google のプロダクション環境
- 第Ⅱ部 : 原則
- 3章 : リスクの受容
- 4章 : サービスレベル目標
- 5章 : トイルの撲滅
- 6章 : 分散システムのモニタリング
- 7章 : Google における自動化の進化
- 8章 : リリースエンジニアリング
- 9章 : 単純さ
- 第Ⅲ部 : 実践
- 10章 : 時系列データからの実践的なアラート
- 11章 : オンコール対応
- 12章 : 効果的なトラブルシューティング
- 13章 : 緊急対応
- 14章 : インシデント管理
- 15章 : ポストモーテムの文化 : 失敗からの学び
- 16章 : サービス障害の追跡
- 17章 : 信頼性のためのテスト
- 18章 : SRE におけるソフトウェアエンジニアリング
- 19章 : フロントエンドにおけるロードバランシング
- 20章 : データセンターでのロードバランシング
- 21章 : 過負荷への対応
- 22章 : カスケード障害への対応
- 23章 : クリティカルな状態の管理 :信頼性のための分散合意
- 24章 : cron による分散定期スケジューリング
- 25章 : データ処理のパイプライン
- 26章 : データの完全性 : What You Read Is What You Wrote
- 27章 : 大規模なプロダクトのローンチにおける信頼性
- 第Ⅳ部 : 管理
- 28章 : SRE の成長を加速する方法 : 新人からオンコール担当、そしてその先へ
- 29章 : 割り込みへの対処
- 30章 : SRE の投入による運用過負荷からのリカバリ
- 31章 : SRE におけるコミュニケーションとコラボレーション
- 32章 : 進化する SRE のエンゲージメントモデル
- 第Ⅴ部 : まとめ
- 33章 : 他の業界からの教訓
- 34章 : まとめ
- 付録 A : 可用性の一覧
- 付録 B : プロダクションサービスのためのベストプラクティス
- 付録 C : インシデント状況ドキュメントの例
- 付録 D : ポストモーテムの例
- 付録 E : ローンチ調整チェックリスト
- 付録 F : プロダクションミーティングの議事録の例
サービスレベル目標
4章「サービスレベル目標」では SLI (Service Level Indicators) / SLO (Service Level Objectives) の考え方や具体的な例が載っていて良かった．リクエストのエラー率やレイテンシーを SLI に設定する例はよく聞くけど，例えば一括処理（バッチ処理）のような場合は処理できた件数を SLI にする例なども参考になった👌
ちなみに今は「SLO サービスレベル目標」を読んでいて，ユーザー体験を重視したより実践的な SLI / SLO の視点を学べていて，次に読む一冊として正解だったと思う．
トイル
5章「トイルの撲滅」では SRE を単なる運用担当にしないようにトイル（運用業務）を作業時間の 50% 以下に抑えるような話で良かった．必ずしも手作業の全てが悪ではないとは思うけど，どういった作業がトイルなのかを見極めながら進めていくのが良さそうという気付きになった💡
- 手作業であること
- 繰り返されること
- 自動化できること
- 戦術的であること
- 長期的な価値を持たないこと
- サービスの成長に対して O(n) であること
障害対応
14章「インシデント管理」では，最初に Mary というオンコールエンジニアを中心にとあるインシデント対応をしたら状況がさらに悪化したという物語が載っていて良かった（反面教師的な意味で💨）．
原因としてはそれぞれの登場人物が自分のやるべきことを自分の考えだけで実行してしまったことで，具体的には以下のようにまとまっていた．障害対応に慣れている人ならこうはならなそうだけど，SRE に限らず，障害対応に慣れていないと視野が狭くなってしまって誰しも起きてしまう可能性のあるアンチパターンで，それがうまくまとまっていた🚨
- 技術的な問題への極端な集中
- 貧弱なコミュニケーション
- 勝手な動き
あと「付録 C」の「インシデント状況ドキュメント」は使える❗️特に "終了基準" と "TODO" と "タイムライン" は重要だ〜 ＼( 'ω')／
SRE 本を読んでるんだけど「14章: インシデント管理」良いねぇ💡SRE に限らず障害対応のときはこういうことを意識しましょ〜というべスプラとアンチパターンがうまく表現されてるhttps://t.co/kc95KF6tlo
— カック (@kakakakakku) 2023年8月15日
データの完全性／可用性
26章「データの完全性 : What You Read Is What You Wrote」は "データの完全性" や "データの可用性" という観点からデータを取り扱うプラクティスがまとまっていて良かった．バックアップとアーカイブの違いという話も載っている．そもそも目の前のバックアップを使って今すぐリストアできる？と言われたら自信を持って Yes と言えるだろうか...🌀
そして "ゴミ箱" と "論理削除" と "遅延削除" というプラクティスもさっそく検討できそうで良かった💡
コラボレーション
31章「SRE におけるコミュニケーションとコラボレーション」に載っていた「プロダクションミーティング」という会議体はとても効果的に感じられて今すぐ実践できそうだった．SRE 主導で以下のようなアジェンダを説明できれば，関係者全員で認識を深められるし，サービス運用の改善を「サービス目線で」行えるようになる．SRE の持つ専門性をサービスに還元しつつ，単に信頼性に関するタスクを SRE に丸投げしているような状態も避けられそう．
- プロダクション環境において予定されている変更
- メトリクス
- 障害
- ページされたイベント
- ページされなかったイベント
- これまでのアクションアイテム
また SRE がいなく，アプリケーションとインフラがサイロ化しているような現場の改善にも「プロダクションミーティング」は活用できると思った．アプリケーション側がインフラの知識がないために作業をインフラ側に依頼してるけど，ミーティングをすると進捗管理（完了したのか進行中なのか）しかされていないような現場も実際に見たことがあって，そういう状態を打破する（手を取り合う）きっかけにも使えると思った．
SRE 本「31章: SRE におけるコミュニケーションとコラボレーション」に載ってる「プロダクションミーティング」という会議体は良いねぇ💡SRE 以前の問題だけど開発とインフラがサイロ化してて作業の丸投げのようになってる現場でもサービス目線で知識共有をするきっかけになるhttps://t.co/nfXEHLemyl
— カック (@kakakakakku) 2023年8月30日
まとめ
やっと「SRE サイトリライアビリティエンジニアリング」を読めた❗️SRE に限らずサービスを開発・運用しているなら知っておくべきプラクティスも紹介されてたし，Google の規模だからこそな事例もあったけど，楽しく読めた．もう読み始めてるけど次は「SLO サービスレベル目標」を読むぞー💪
英語なら無料で読める
SRE 本は英語なら無料で読める📕 一部のアップデートはウェブに公開されている ＼( 'ω')／
