【書籍メモ】SRE サイトリライアビリティエンジニアリング
前提
SRE関連の用語
非機能関連の用語
1章
SRE チームは、サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負います
インシデントに対してポストモーデムを行う
生じたことの詳細、イベントのすべての根本原因、問題の解決策、次回はより良く対処できるようにするためのアクションの割り当て
信頼性の決め方
プロダクトの利用方法を踏まえて考えたとき、ユーザーが満足する可用性のレベルはどの程度か。
プロダクトの可用性に満足できなかったユーザーにとって、どのような代替策があるか。
可用性のレベルを変更したとして、ユーザーのプロダクトの利用の仕方に何が起こるか。
手順書があるとよい、ない場合と比べて緊急対応のMTTRが3倍改善された
変更管理のベスト
順を追ったロールアウト
高速で正確な問題の把握
安全なロールバック
キャパシティプランニング
自然な需要
突発的な需要
定期的な負荷テスト
2章
Googleのデータセンターの説明
3章
リスクの需要
ユーザは信頼性が99.9%だろうが99.999%だろうがわからない
むしろ100%を目指すと機能開発が滞る
停止時間はどれくらいが許容される?
リクエスト成功率から可用性を考える
可用性 = 成功したリクエスト数 ÷ 総リクエスト数
可用性のターゲットレベル
ユーザが期待するサービス
収入につながるか
サービスが有料か無料か
競合サービスのレベル
toC?toB?
ユーザがCである場合、機能開発が望まれる。可用性は低めに設定
可用性を上げた場合、コストに見合うのか?
ユーザに応じて複数の性能のインフラを用意する
SQSのstandard/FIFOみたいな?
SLOを設定し、稼働時間がSLOを超えている場合にリリースが可能となる
4章 SLO
SLO/SLI/SLA
SLIはサービスレベルの指標を表す
レイテンシや可用性など、数字でだせるもの
提供するシステムによって、重要なSLIは異なる
例:ユーザとやりとりするシステムは可用性、レイテンシ、スループットを考慮する
指標の収集にはクライアント側の考慮を忘れずに
一般的な指標はテンプレート化しておく
SLOはミニマムスタートで、必要に応じて厳しくしていく
SLOの対応のため、バッファを設定する。また過剰な達成を避ける
5章 トイル
トイルがどんなものかを判断し、減らす
トイルが少ない場合は悪と決めつけることはできない
6章 モニタリング
モニタリングシステムにより
何が壊れたのか
何が原因なのか
障害が起こったときに対応するために、以下を比べる必要がある。普段から意識しておこう
普段の速度
障害の際の速度
4大シグナル
レイテンシ
トラフィック
エラー
サチュレーション
手一杯になっていないか、またはその予測
平均のレイテンシ(もしくはその率)でモニタリング設定をするのは危険
レイテンシでグループしたリクエストカウントで判断する方法が紹介されている
燃え尽き症候群を避けよう
7章
良い自動化を進めることで、自分だけでなくメンバーに良い影響をもたらす
障害は避けられないものと考えて自動化を行う
自動化もいいけど、まずは適切な設計をしようね
8章
リリースプロセスの定義は初期の段階から始める
9章
コードは単純こそよい。複雑に思えたら差し戻し
第Ⅲ部
サービスの信頼性の階層