エラーバジェット

SLOで定めた信頼性の目標に対して、許容される障害や品質低下の量。SLOが稼働率99.9%なら、残りの0.1%がエラーバジェットになる。予算が残っていれば新機能のリリースを進め、使い切りそうなら変更を控えて信頼性の改善を優先する、という判断に使う。

故障が発生してから修理が完了するまでの平均時間。保守性の指標であり、MTTRが小さいほど修理が速く保守性が高い。故障検知、診断、修理、復旧確認の各フェーズの時間を含む。

本番システムに意図的に障害を注入し、システムの耐障害性を検証するプラクティス。Netflixが提唱したChaos Monkeyが有名。定常状態の仮説を立て、実験を行い、差異を観測して改善に繋げる。分散システムの信頼性向上に活用される。

システムの障害やインシデントが収束した後に、発生の経緯、影響、根本原因、対応の良かった点と問題点、再発防止策を分析して文書にまとめる活動、またはその報告書。個人の責任を追及しない（ブレームレスな）姿勢で行い、組織として仕組みを改善することを目的とする。SREで重視される。

システムの運用や障害対応で、担当者が行う手順を具体的にまとめた手順書。定常の作業の手順、警告を受けたときの確認と対処の手順、エスカレーションの連絡先などを記し、対応の属人化を防いで品質をそろえる。手順をスクリプトにして自動で実行できるようにすることも多い。

業務時間外も含め、担当者が交代で待機し、システムの障害やアラートが発生したときにすぐに対応できるようにしておく体制。待機の当番表、通知の仕組み、対応の手順（ランブック）、エスカレーションの経路を整え、担当者の負担が過大にならないよう当番の頻度や不要なアラートの削減にも配慮する。

システムの外部に出力される情報から、内部の状態をどれだけ推し量れるかの度合い。ログ、メトリクス、トレースを収集して相互に関連付け、あらかじめ想定していなかった障害でも、どこで何が起きているかを調べられるようにする。マイクロサービスのように構成が複雑なシステムの運用で重視される。