MEGUMI SHIMABUKURO はじめに
SRE 本、かなり分厚い本なので長い間積んだままにしていたのですが、初学者におすすめの章があると聞いてあらためて読んでみました。
サイトリライアビリティエンジニアリングとはなんぞや？の基本がわかるとてもいい本で、最近社内で取り組んでる SRE 活動への理解が深まる内容でした。SRE の基本を知りたい人におすすめの一冊です。
初学者におすすめしている章は以下の通りになります。
- 1章 イントロダクション
- 3章 リスクの受容
- 4章 サービスレベル目標
- 5章 トイルの撲滅
以下、感想とメモ書きです。
1章 イントロダクション
Q. サイトリライアビリティエンジニアリングとは何ですか？
- ソフトウェアエンジニアに運用チームの設計を依頼したときに出来上がるもの
- 人手による管理を自動化するソフトウェアを設計し実装すること
Q. サイトリライアビリティエンジニアリングの責任範囲について教えてください
- パフォーマンス
- 効率性
- 変更管理
- モニタリング
- 緊急対応
- キャパシティプランニング
Q. DevOpsとサイトリライアビリティエンジニアリングの違いは何ですか？
- サイトリライアビリティエンジニアリングは、DevOpsに独自の拡張を加えたプラックティス
- DevOpsは、サイトリライアビリティエンジニアリングの中核的な方針を組織や個人向けに一般化したもの
- 📝 DevOpsの方が抽象度高めの概念っぽい
Q. エラーバジェットとは何ですか？
- エラーになっても許容される値
- サービスの可用性のターゲットを1から引いた値
- 例. サービスの可用性が99.99%の場合、0.01%は利用できない場合があるということ。逆に言えば、0.01%のエラーは許容されるということ。これをエラーバジェットという。
Q. エラーバジェットが重要な理由について教えてください
- サイトリライアビリティエンジニアリングと最速で昨日リリースすることの競合を解決するために重要な指標
- プロダクト開発チームとSREチームは構造上対立がある。プロダクトチームは新機能リリースに対してインセンティブがあるが、SREチームはサイトの安定に対してインセンティブがあり、それぞれの目的に競合が発生する。
- エラーバジェットを導入することで、SREチームはある程度エラーを許容できるようになり、開発チームはそのエラーバジェットを使うことで昨日のリリース速度を最大化できる。
Q. 効果的なモニタリングの出力には３つの種類があります。それは何ですか？
- アラート
- チケット
- ロギング
👨🏻 感想
サイトリライアビリティエンジニアリングとは何なのか、全体像がわかりやすかったです。
3章 リスクの受容
Q. 必要以上に信頼性を高めないのはなぜですか？
- 信頼性を高めること以外の改善を行うチャンスを失うから
- 信頼性とコストの関係は比例では済まない。繰り返し信頼性を高めていくと、ある回は前回のコストの100倍ぐらいかかることがある。
Q. サービスの可用性の計算方法を教えてください。
- リクエスト成功率で可用性を定義する
- 可用性 = 成功したリクエスト数 / 総リクエスト数
- 例. 1日の可用性が99.99%、1日の理消すと数が250万リクエストの場合、エラーを回数は250回までは許容される。
Q. なぜリクエスト成功率で可用性を定義するのですか？
- リクエスト成功率以外では稼働率が可用性を定義する指標と考えられるが、グローバルに分散したシステムだと、あまり意味を持たないため
- 可用性 = 稼働時間 /（稼働時間 + 停止時間）
Q. 可用性のターゲットレベルを考える時に考慮すべき事項は何ですか？
- ユーザーが期待するサービスのレベル
- サービスが直接的に収入につながっているか
- サービスが有料なのか無料なのか
- 市場に競合がある場合、その競合が提供してるサービスレベル
- toC向けのサービスなのか、toB向けなのか
Q. サービスの可用性ターゲットを決定するときにどんなことを問いかけますか？
- 可用性を１桁改善するようにシステムの構築と運用を行った場合、収入はどのように増加するか
- この追加の収入は、信頼性をそのレベルにまで高まるためのコストに見合うか
Q. 信頼性と収入との関係がシンプルな関数で表せない場合はどうしたらいいですか？
- インターネットサービスプロバイダのバックグランドエラー率を考えることが有効
- エンドユーザーの観点からサービスのエラー率をバックグラウンドエラー率よりも低くできるなら、サービスのエラーはインターネットの接続のノイズに紛れることになる。
Q. サービスリスク許容度を検討する際に可用性以外のメトリクスにはどんなものがありますか？
- 例えばレイテンシー。スピードが重要な要件になる場合がある。
Q. エラーバジェットを形成するやり方を教えてください。
- プロダクトマネージャーがSLOを規定する。四半期内に期待されるサービスの稼働時間を設定する
- 実際の稼働時間は、中立な第三者であるモニタリングシステムによって計測される。
- この２つの値の差が、その四半期内の「損失可能な信頼性」という「予算」の残分となる。
- 計測された稼働時間がSLOを超えている、言い換えればエラーバジェットがまだ残っているなら新しいリリースをプッシュできる。
Q. エラーバジェットを定義するメリットについて教えてください。
- プロダクト開発者とサイトリライアビリティエンジニアリングに共通のインセンティブを提供する。
👨🏻 感想
エラーバジェットを使うとサイトリライアビリティエンジニアリングとプロダクト開発の優先度を検討しやすそうだと思いました。
プロダクト開発と運用タスクの優先度は悩むことが多いので、うまく実践できるととても有益そうですね。
4章 サービスレベル目標
Q. SLIとは何ですか？
- 提供されるサービスレベルの性質に関して慎重に定義された計測値
📝 SLI = （良いイベント / 有効なイベント）× 100%
Q. SLOとは何ですか？
- サービスレベル目標の略
- SLIで計測されるサービスレベルのターゲット値、あるいはターゲット値の範囲
Q. SLAとは何ですか？
- サービスレベルアグリーメントの略
- SLAはユーザーとの間で結ぶ明示的、あるいは暗黙的の契約。SLOを満たした場合（or 満たしてない場合）に関する規定の定義
Q. SLAとSLOの違いをはっきりさせる方法はを教えてください。
- 「SLOが満たされなかった時にどうなりますか？」 と尋ねたときに明確な規定がなければ、それはSLOです
Q. 重要なSLI を見極める方法を教えてください。
- ユーザーがシステムに求めていることを理解する
- 📝 CUJの作成がSLIを定義する第一歩。ユーザーの行動を洗い出して、その中で本当にユーザーが必要なもの、もし動かなかったらユーザーがサービスに対して不満足になってしまうものをCUJとして定義する
参考:【SRE NEXT 2022】SLO決定のためのArt of SLO / 山口 能迪
Q. SLIを決めるときの観点からみたサービス障害の分類を教えてください。
- ユーザーとやり取りするサーバーシステム
- ストレージシステム
- ビッグデータシステム
- 正確性
Q. ユーザーとやり取りをするサーバーシステム（リクエスト・レスポンス）に関する障害の場合、どのような SLI を取ればいいですか？
- 可用性：処理に成功した正常なリクエストの数の比率
- レイテンシ：リクエストに対して、レスポンスを返すまでにかかった時間
- スループット：処理に成功した正常なリクエストの数の比率
Q. SLO 選択時の議論を生産的なものにするために役立つことについて教えてください。
- 現在のパフォーマンスに基づいてターゲットを選択してはならない
- シンプルさを保つ
- 「絶対」は避ける
- 最小限にとどめる
- 最初から完璧でなくてもよい
Q. システム管理のサイクルについて教えてください。
- システムのSLIモニタリングと計測を行う
- SLOに対してSLIを比較し、アクションが必要かを判断する
- アクションが必要なら、ターゲットを満たすために実現しなければならないことを明らかにする
- 行動に移す
👨🏻 感想
SLIの計算式自体は一般的なものがありそうですが、どの部分を見るかはユーザーがサービスに求めていることを理解しないと見極めれなそうだと思いました。
ユーザー理解のためにはCUJが必要だと思うので、SLIやSLOを整理していくためには、まずはCUJから取り組んでいくのが良さそうですね。普段作ってるサービスでも作ってみたいです。
5章 トイルの撲滅
Q. トイルとは何ですか？
- プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つもののこと。
Q. トイルかどうか判断する観点について教えてください。
次の説明が１つ以上当てはまるならトイルの可能性が高い。
- 手作業であること
- 繰り返されること
- 自動化できること
- 戦術的であること
- 長期的な価値を持たないこと
- サービスの成長に対して比例してスケールするタスクであること
Q. トイルが少ない方がいい理由を教えてください。
- トイルは、ほっとくと拡大していき全員の時間を100%埋め尽くしてしまう傾向があるから。エンジニアリングの作業により、サービスのサイズとサイトリライアビリティのタスク量は比例しないようにしたいから。
Q. SREのエンジニアリングの作業とはどんな活動ですか？
- ソフトウェアエンジニアリング
- システムエンジニアリング
- トイル
- オーバーヘッド
Q. トイルは常に悪なのですか？
- 常に悪ではない。量が少ない場合は、あまり問題ない。
- トイルが有害になるのは、大量に処理しなければならなくなった時。
Q. トイルが悪である理由を教えてくだい。
- キャリアの停滞
- トイルの使う時間が増えることでキャリアアップの邪魔になる
- モラルの低下
- あまり多すぎると不満が発生する
Q. トイルに時間を使いすぎるとどんなダメージが生じますか？
- 混乱の発生
- 進歩速度の低下
- 習慣づけ
- 摩擦の発生
- 信義違反
👨🏻 感想
トイルは常に悪というわけではないですが、基本的には改善していきたいですね。見極めながら対応していきたいです。