The Site Reliability Workbook 書評
毎週コツコツ輪読してようやく2ヶ月前くらいに読み終わったので雑にまとめておく。(まとめとこ、と思ってから2ヶ月も放置していたということ...)
https://landing.google.com/sre/workbook/toc/
Chapterまとめ
1. How SRE Relates to DevOps(オススメ度: ★★★★☆)
DevOps/SREの概要。基本的な内容なので1冊目を読み込んでいて完全に理解してるよという人は飛ばしてしまっても良いかも。でも、大事なことなのでおさらいしておくのも良さそう。
Summary:
- devとopsが分離していると知識のサイロ化やコラボレーションの不足が発生する
- 予防より迅速なリカバリに重点を置く
- リスクの低い小さな変更
- 自動テスト
- 変更管理はツールに依存している
- DevOpsの支持者はツールより組織文化に重点を置いている
- 客観的な話し合いのためにも計測は必要
- DevOpsは哲学、作業アプローチ(インタフェース)でSREはいくつかの実装(クラス)
- オペレーションはソフトウェアの問題
- MTTRを減少させることで開発速度が向上する
Part I Foundations
2. Implementing SLOs(オススメ度: ★★★★★)
SLI/SLO策定時に考えるべきことが書いてある章。 SLO設定で難しいのが設定後の調整だと思うが、そのあたりの方法もまとめてあってとても良い。是非読むべき章。
Summary:
- SLI specification
- ユーザにとって重要と考えられる指標
- 100ms以内にページがロードされるとか
- SLI implementation:
- 計測方法
- ログから取得するとか、ブラウザ側(javascript)で取得するとか
- 方法毎にquality, coverage, costが異なるので適したものを選ぶ
- 最初の試みは正しくないかもしれないので、フィードバックループで修正していく
- SLI/SLO例
- Number of successful HTTP requests / total HTTP requests (success rate)
- Number of gRPC calls that completed successfully in < 100 ms / total gRPC requests
- Number of search results that used the entire corpus / total number of search results, including those that degraded gracefully
- Number of “stock check count” requests from product searches that used stock data fresher than 10 minutes / total number of stock check requests
- 偽陽性のときはimplementation確認 or SLO緩和
- SLI implementation変更 -> 計測をユーザに近づける(サーバ -> LB -> Clientとか) or キャプチャのカバレッジを上げる
- 生ログを調査するためにしばらく失陥のあるバージョンを実行しておくこともあり
3. SLO Engineering Case Studies(オススメ度: ★★★★☆)
GCPに移行した企業とGoogle CREの奮闘事例集。 SLIとするMetricsの収集、格納方法や、それをどのように共有しているかなどが参考になる。また実際のSLOの設定値なども公開してくれている。
Summary:
- Evernote事例
- Home Depot
- FiRE Academy: トレーニングプログラム
- VALET
- Volume (traffic), Availability, Latency, Error, Tickets の略称
- SLOを会社で広めるためのキャッチーな呼び方
- レイテンシは 95th and/or 99th percentile を見てる
- SLOレポートを上級者に提出
- 指標はマネージャの年次パフォーマンスレビューで使われる
- Metricsの収集方法: frontend -> BigQuery, Stackdriver
- 自動レポート/アラート
- 毎日、毎週、および毎月でトレンドをチェックしている
- SLOと監視ツールの閾値は異なる(統合できていないとのこと)
- SLOレビューは毎週、毎月
- 800のサービスのSLOを追跡し、月に約50の新しいサービスがVALET
- コールツリーを作成
- Home DepotのSLOの設定例
- 99.5%:店員や新サービスのMVPで使用されていないアプリケーション
- 99.9%:ホームデポの大部分の非販売システムに適している
- 99.95%:販売システム(または販売システムをサポートするサービス)
- 99.99%:共同インフラサービス
4. Monitoring(オススメ度: ★★★★☆)
モニタリングを設計するときの話。 "コンテンツを使用している人々にとって意味のあるダッシュボードを作成するのが重要" というのは当たり前ではあるけど、サービス側の理解が乏しいSRE側でそれを作るのはなかなか難しいもの。Dev側に自由にいじれるようにしてもらう、というのがいいのかなと思ったりした。
Summary:
- データの鮮度とデータの検索速度
- データをあつめてグラフ出力とかは時間がかかるのでNO
- Metricsはcounterを推奨
- 生のMetricsをオフライン分析用に別のシステムに記録することをお勧め
- コンテンツを使用している人々にとって意味のあるダッシュボードを作成するのが重要
- ランタイムイントロスペクション
- ログの処理にCloud Dataflow、アドホックにBigQuery、ダッシュボードについてはData Studio
- 設定もVCSで管理する
- モニタリングに使うツール群: Prometheus / InfluxDB / Alertmanager / Grafana
5. Alerting on SLOs(オススメ度: ★★★★★)
問題の検知方法などがまとめられた章。 単純に短期のSLI Metricsの集計値がSLOを超えただけでアラートを投げるとオオカミ少年化することが多くなってしまう。不要なアラートを少なくするための対処法が色々とまとめられている。AlertManagerについては詳細な設定例もあるので設定の際には参考になると思う。
Summary:
- precision: エラー検知したものが本当にエラーだった確率、高いほどいい
- recall: 網羅率、エラーがあってもOK、どれだけエラーを取りこぼしていないか、高いほどいい
- Burn rate alert
- どの程度SLOを消費しているかによってアラートを出し分ける
- ある程度放置しても良いものはTicket化しPagerとは扱わない
- burn rate 1 = このままだと月のerror budgetを完全に使い切る状態
- サービス個別ではなくクラス毎に設定値を分けておくという方法もある
6. Eliminationg Toil(オススメ度: ★★★☆☆)
Toilを削減する取り組みが記載されている章。 例はデータセンターのハードウェア故障についての例がフローチャートなどで説明されていて分かりやすい。ただ、クラウドプロバイダーに頼りまくっている環境の場合はあまり参考にならないかも知れない。
e.g)
- 1回ミスは再起動で対処し、詳細調査は実施しない
- ほとんどの障害は再起動で治るものが多いため、調査に時間をかけずに一律再起動にしている
- 2回ミスならハード交換とか
Toilの計算には利害関係者も含める必要があるというのは常に頭においておいたほうがいいとは思った。権限を委譲して他チームにオフロードすると、タイマーで計測する自分の作業時間は減っても、作業量全体では減るわけではないので、逆にマイナスに働くこともありそうではある。
7. Simplicity(オススメ度: ★★★☆☆)
Simplicity大事、だけど "Simple is not easy" だよ、という話...だったっけ?
Summary:
- Borgから乗り換えようとしていたOmegaのコンセプトはKubernetesに
- 糞コードを一番潰したものに Zombie Code Slayer の称号が与えられる
Part II Practices
8. On-Call(オススメ度: ★★★★☆)
あたふたすることしかできないので "対処法がわからんアラートは投げるな" というのはとてもわかる。これはアラート無闇に設定するなというよりはちゃんと対処法をまとめておけということだとは思う(更に言えば対処の必要がない状態がベスト)。これが徹底していると、新メンバー参画時の負担も相当減りそうではある。 対処法が用意できない障害ってなかなかない気もしたが、クラウドプロバイダー側の大規模障害とかは基本的にお手上げになる気はする。
Summary:
- Rollback出来ない変更は避ける
- アラートを追加したら1週間くらい本番環境でテストする
- Playbookを書いてからアラート設定するっていうのは確かに
- On-call当番は2人で1週間、12時間で割るとか
- 予定があったら一時的にスワップしたりする
- Operation:Project の作業割合は 1:1が基準, 1:2が理想
- オンコール当番が入れ替わるときに引き継ぎする
- ユーザーへの影響軽減がPrimary、その後に対応を実施する
対処例:
などが書いてあった気がする
9. Incident Response(オススメ度: ★★★☆☆)
インシデント対応のあれこれ。
プロセスやロールを細かく決めておくことでスムーズなインシデント対応ができるようになるよという話。ただ、対応に慣れていないと焦ってしまってプロセスを無視した動きをしてしまいそう(特に新規参画者とか)。最初はとりあえずICが誰かだけ決めて3Cを実施してもらう、くらいでもいいのかもしれない。
主なプロセス
- Incident Command System(ICS)
- PagerDutyのIncident Responseプロセス
- Incident Management At Google(IMAG)
3つのC
- Coordinate: Coordinate response effort.
- Communicate: Communicate between incident responders, within the organization, and to the outside world.
- Controll: Maintain control over the incident response.
Summary:
- 開発者が対応できる日にだけROする
- インシデントは早期に宣言すべき
- 影響範囲を最小限に留める
- 原因がわかるまでROはしない
- SREは war room (戦略的決定をする部屋) に集まって相談
10. Postmortem Culture:Leaming from Failure(オススメ度: ★★★★☆)
postmortemの章。 Googleで発生したプロキシ、キャッシュの障害の話が例として紹介されている。
Summary:
- 用語解説などはBackground/Glossaryセクションに記載
- 影響の数値化:問題の期間だけでは不十分
- 根本原因とトリガーの記載
- 回復作業セクションの記載
- 人間の行動を変えるのではなく自動化プロセスを変える
- アクションアイテムでは改善といった曖昧な言葉は使わず、成功判断が明確に行えるものを記載する
- アクションアイテムにちゃんとチケット化し誰かをアサインする
- 個人的な主観は含めない、心理的安全性を損なうようなことは言わない
- そんなことより検証可能なデータを乗せるべき
- 1週間以内に記載
- 迅速なほど正確になる、間が空くほど想像でギャップを埋めてしまう
- 長いチャットのやり取りなんかはリンクを貼るだけにして読みやすくする
- ゲーミフィケーション: 最もアクションアイテムをCloseしたものにはご褒美 とか
11. Managing Load(オススメ度: ★★★☆☆)
負荷の管理の話。 リクエストが急増したトラブルの事例の紹介。
Summary:
- DNSが一番簡単だけど効果的ではない
- クライアント側の期限切れ設定を上手く制御することは難しい
- 単一VIPを指定すると、一番近いノードにデータグラムをルーティングする
- Border Gateway Protocol(BGP)経由
- BGPルート再計算が発生すると接続がリセットされることがある
- consistent hash, exponential backoff の話とか
- オートスケーリング
- 有効なノードの平均CPU使用率でやらないと駄目
- 追加されていても働いてないインスタンスを計算に入れると上手くオートスケーリングが発生しなくなる
- オートヒーリング
- 正常になるまで十分な期間待つ
- スケールアップはすぐやるけどスケールダウンはしばらく待つ
- オートヒーリングを無効化するkillスイッチはあったほうがいい
12. Introducing Non-Abstract Large System Design(オススメ度: ★★★★☆)
略してNALSDというらしい。 マルチDCの同期問題を解決するための構成を検討する過程が紹介されている。懸念点を段階的に潰していき、抽象的な構成から具体的な構成にしていく方法がとても参考になる。
- Is it possible?
- Can we build it without “magic”?
- Can we do better?
- Is it as simple as we can reasonably make it?
- Is it feasible?
- Does it fit within our practical constraints (budget, time, etc.)?
- Is it resilient?
- Will it survive occasional but inevitable disruptions?
13. Data Processing Pipelines(オススメ度: ★★★☆☆)
データ処理パイプラインの話。 分析用途でなら少しくらいデータが欠落してもいいかも知れないけど、Spotifyのように会計に絡んでくるシステムだと設計が大変そうだと思った。
Summary:
- SLIとなり得るMetricsの参考
- Yで処理されたデータのX%
- 最も古いデータはYより古くない
- パイプラインジョブはY以内に正常に完了
- 後方視的分析
- あとで評価して何%間違っているかとか
- 優先順位の高い処理が先に処理されるようにする
- E2E評価
- ステージとしての評価だけではなく全体での評価も必要
- 依存関係
- 依存しすぎない、外部に依存する場合は最悪を考える
- データフローダイアグラム書いておく
- 各ポイントにはデバック情報/手順書へのリンクをしておく
- 処理が冪等なら複数パイプラインで並列実行してもいい
- Spotifyのケーススタディ
14. Configuration Design and Best Practices(オススメ度: ★★★☆☆)
各ソフトウェアの設定についての話。
理想は勝手に状況を認識して構成を変更する世界? 確かにデフォルト設定はそうなっているとありがたいと思う。必要なときだけ明示的に指定する感じが良さそう。
Summary:
- インフラ視点:調整できる箇所が多いほうがユーザの要望は汲み取りやすい
- ユーザ視点:設定が少ないほうがいい
- out-of-boxで使えたほうが楽
- 動的なデフォルト値がおすすめ
- worker数 = core数 とか
- 意味検証
- 有効に作用する設定になっているか検証
- ありえないRAM要求していないかとか
- 構文検証
- DSL: 強調表示
- linter
- 自動構文フォーマッター
- 徐々に展開していくのが大事
- pod単位で徐々に
- 何かあったらすぐロールバック
- 誤った場合に制御できなくなるようなケースでは自動でロールバックするようにしておくと良さそう
15. Configuration Specifics(オススメ度: ★★★☆☆)
configuration languageの話。
HCLとかそういう類。
便利だけど制御構文のようなものを入れすぎると最終的な結果を想像しづらくなりそうではある。構成を評価するタイミングは早めが良さそうだなと思った。実行時評価はちょっとリスキー。
- 設定を理解しやすく維持する
- 個別設定はなくなるけど毎回設定変更は必要になる
- 組織が大規模になると大変
- 設定ファイルよりアプリ側で自動で設定するほうが有効な場合もある
- k8sには設定言語は付属していない、yamlオンリー
- jsonnetの使い方などの紹介
- yamlではjsonでは表現できない設定も書けるけど、k8sは内部的にはjsonでデータを持つので使えない
- バージョニング: 古いバージョンを維持しながら上げていく
- ソース管理: エディタプラグインでスタイルを強制する
16. Canarying Releases(オススメ度: ★★★☆☆)
カナリアリリースの切り戻し判断に用いるMetricsの話や、本番と近い負荷をかけるための方法の紹介など。
Summary:
- カナリア評価は12メトリクス以下
- e.g.) CPU usage, memory footprint, HTTP return codes (200s, 300s, etc.), latency of response, correctness
- Blue/Green Deployment
- Artificial Load Generation
- Traffic Teeing: mirrorモジュール
Part III Processes
17. Identifying and Recovering from Overload(オススメ度: ★★★☆☆)
チームの半数がやめて過負荷になったのをどうやって切り抜けたかという話。 実際の作業負荷+精神的な負荷がある(わかる)。Toilしんどい(文字のまんま)。
18. SRE Engagement Model(オススメ度: ★★★☆☆)
どのようにDevと関わっていくかという話。 Devに関与しだすフェーズによってどのような差があるのかの説明などがされている。
Summary:
- 密なコミュニケーションが大事
- SLOはGA前に定める
- dev側もオンコール担当に一人くらい含める
19. SRE: Reaching Beyond Your Walls(オススメ度: ★★★☆☆)
SRE文化をどのように広めていくかの話? 顧客と一緒にSREを推進する場合、どのようなステップを踏むとよいかということが書かれている。割と初歩的な内容なので、なぜ今ここで?という気持ちに少しなった。
Summary:
- trustは主観、reliableは客観
- ユーザーがいないサービスは無価値
- 信頼性はユーザーが決める
- "どのようなときに信用を失うか" を考える
20. SRE Team Lifecycles(オススメ度: ★★★☆☆)
SRE組織をどのように発展させていくかという話。 どうすべきかは組織規模や地理的条件によって異なるから上手いことやれよという感じ。
Summary:
- SLOはユーザーエクスペリエンスの保護のため
- 信頼性を高める作業、エラー予算の使用を少なくするための作業
- SLOの合意はリーダーの合意が必要
- SREいなくてもSLOの設定には価値がある
- 最初のSRE
- 最初の配置パターン
- Dev team
- Ops team
- Horizontal role
- 強い権限をSREで集中管理にしたい場合はdev側には組み込まない方が良い、あとから無くすのは困難
- Tuckman's stages of group development
- The Forming, Storming, Norming, Performing model の略称、チームビルディングモデル
- LCEチーム
- SREチームを評価するシニアSREチーム
- 主な評価軸: pager load, error budget usage, project completion, bug closure rates
- Dev:SREの割合は 5:1 ~ 50:1 くらいで、最頻値は 10:1 らしい
21. Organizational Change Management in SRE(オススメ度: ★★☆☆☆)
組織変革のススメ方などの話。
新しいツールに切り替えますよってときにどう進めていくかという話。
何か(組織構造や共通基盤など)を変更する場合は、なぜ変えるのか、どうしてそれに変えるのかといったことを共有しながら進めることが大事なんだろうなということを思ったりした。
様々なモデルが紹介されていたが、抽象的すぎてあまり参考にはならなかったかも...。
まとめ
実際の事例が多く記載されている章がとても参考になった。 個人的には 2, 4, 5, 8 ,10 章がおすすめ。