SRE本
ktoyodGoogleのSREチームは運用業務の合計を50%以下にするよう上限が設けられている
ktoyodSREはソフトウェアエンジニアが運用チームを設計した結果できるもの
ktoyodポストモーテム
サービス運用時のシステム障害やデータの損失など、インシデントについてまとめた文書
ktoyodページャー
ポケベルのこと。この文脈ではアラートと同義と考えて良さそう。
ktoyodモニタリングにおいては、アラートの領域のどの部分をとっても人間の解釈が必要であってはならない。
ソフトウェアが解釈を行い、人間はアクションを行わなければならないときにのみ通知を受けるようになっているべき
ktoyodアラート: 即座に対応
チケット: 即座じゃなくてもいい
ロギング: 診断もしくはフォレンジックのために記録されるもの
ktoyodモニタリングの用途
- 深刻な問題のためのアラート
- 挙動の比較。ソフトウェアのアップデートによってサーバーは高速化されたか
- 時間の経過に伴うリソース消費の増加の検証。キャパシティプランニングに欠かせない
ktoyodトイル: 日常的に繰り返される運用上の作業であり、永続的な価値を生み出さず、サービスの成長に比例してスケールするもの
ktoyod過度の信頼性はコストに跳ね返るし安定性を最大化しようとすれば新しい機能の開発やユーザーへのプロダクトの提供速度が制限される。
バランスが大事
ktoyodコスト
- 冗長なマシン/コンピュートリソースのコスト
- 機会のコスト: 安定性にエンジニアリングリソースを割くことで新しいことを行う機会が減る/失われる
ktoyodグローバルに分散されたサービスでは世界中のどこかでは稼働中になっているので、稼働時間で可用性を測るのではなくリクエストの成功率という観点から可用性を定義している。
可用性 = (成功したリクエスト数) / (総リクエスト数)
ktoyodバッチだとしても、処理に成功したレコード数と失敗したレコード数という観点で定義されたリクエスト成功率を使えば有益な可用性のメトリクスを計算できる。
ktoyodエラーバジェットはSLO（四半期内に期待されるサービスの稼働時間）から算出され、一つの四半期内でサービスの信頼性がどの程度損なわれても許容できるかを示す明確で客観的なメトリクス。
プロダクトの開発速度を求めるプロダクト開発者と、信頼性を求めるSREがこのメトリクスを共有することでプロダクトのリスクについて共通の結論に辿り着くことができる。
ktoyodSLI: サービスレベル指標。多くのサービスではリクエストのレイテンシを考慮する。（それ以外だとエラー率やシステムスループット。）また、可用性や耐久性も重要。
ktoyodSLO: サービスレベル目標。SLIで計測されるサービスレベルのターゲット価、あるいはターゲット値の範囲。
ktoyodSLA: サービスレベルアグリーメント。ユーザーとの間で結ぶ明示的、あるいは暗黙の契約であり、その中にSLOを満たした場合（あるいは満たせなかった場合）に関する規定が含まれる。
ktoyodSLO設定の際、安全マージン（顧客に見せるSLOと内部的なSLO）を確保すること、過剰達成を避けること（ユーザーは実績から評価する）に注意する
ktoyodトイルとは、
- プロダクションサービスを動作させることに関係する作業で、
- 手作業で繰り返し行われ、
- 自動化することが可能であり、
- 戦術的で長期的な価値を持たず、
- 作業量がサービスの成長に比例する
といった傾向を持つもの
ktoyodGoogle の SRE 組織では、トイルを作業時間の50%以下に抑えるという目標が掲げられており、最低でも50%は将来のトイルを削減するか、サービスの機能を追加するエンジニアリングプロジェクトの作業に費やす。
ktoyodモニタリングにおける4大シグナル
レイテンシ
トラフィック
エラー
サチュレーション