サービス障害後、新機能を公開してよいか？ エラーバジェットの判断
障害への対応は終わったが、直近の失敗はサービス目標を超えている。次の新機能を予定どおり出すか、信頼性の改善へ時間を回すか。まず、失敗要求の件数と停止時間を混ぜずに残る予算を読み、原因と次の変更の関係から公開計画を考えます。
この記事の目次
障害後に残る予算を、何の失敗で数えるか
判断したいのは、機能公開を一律に止めるか、信頼性を直す変更を優先して通すかである。利用者に見える失敗の定義があり、原因と変更の関係を追えるなら、通常の機能公開を一時的に絞り、復旧と再発防止を進める。数字の定義があいまいなまま「予算が尽きた」と宣言するなら、止める根拠そのものを先に修正したい。
残り二百件と、許容停止43.2分は別の量
30日間で100万要求、成功率99.9％を目標とする例なら、失敗要求の予算は1000件。800件を消費すれば残り200件となる。一方、時間ベースの99.9％なら30×24×60×0.001＝43.2分が許容停止時間だ。要求数と分を同じ残予算として足すことはできない。
顧客が使わない時間の停止と、繁忙時の少数分の失敗は、時間指標と要求指標で重みが変わる。窓の外へ古い失敗が出ただけで予算が回復した場合も、故障原因が直ったとは限らない。再開判断には窓、対象要求、復旧の証拠を対応させる。上の数値はSLOの単位を示す条件計算で、推奨目標ではない。
利用者の失敗を何として数えたか
注文が失敗した回数だけを見ると、何度もやり直した一人の利用者を大きく数え、諦めて離れた人を数え損ねる。業務の完了を測るなら、最初の試行から結果が使えるまでを追い、失敗後に再挑戦できたかも記録したい。利用者の一部だけが使う新機能の失敗を全社のサービス目標へ混ぜる場合には、対象範囲を明示する。目標の設計が甘ければ、予算の残りを議論しても判断は正しくならない。
重要度の異なる業務も一緒に平均化しない。社内の画像の読み込みが遅いことと、支払いの確定ができないことを同じ失敗一件として扱うかは事業上の判断だ。顧客に約束した用途と時間帯を製品側が示し、運用側が測定できるか確かめる。理想的な数字を上から渡すより、失敗した利用者が何を失ったかを説明できる測り方を先に選ぶ。
エラーバジェットは停止命令ではなく、約束を読む道具
Google SREの例示的なエラーバジェット方針では、サービス目標に対して許容される失敗を見積もり、直近の期間に予算を使い切った場合は、重大な修正やセキュリティ対応以外の公開を止める。利用者の失敗を減らすことと改善の速度を調整する考え方である。ただし同ページにある期間や閾値は、その例のサービスの運用規則であり、全企業へコピーする数値ではない。
先に利用者の一件を定義する必要がある。画面を開けるだけでは、注文を最後まで送れないかもしれない。逆に社内試験の失敗を全利用者の障害として数えれば、本当の体験より悪い数字になる。Google SREのSLO導入解説は、製品、開発、運用の当事者が指標と目標を合意することを重視する。合意されない数字は公開の駆け引きの道具になり、改善の優先順位を決める助けにならない。
次の公開を止めることで、何を防げるか
新機能が原因で利用者の注文が止まったなら、同種の公開を保留し、影響した変更を戻し、再発しない方法を優先する理由がある。しかし外部の通信障害が主要因であり、自社の公開を止めても利用者体験が戻らない場合、全面凍結が最善とは限らない。Googleの導入解説も依存先による未達には異なる扱いがあると記す。原因の帰属だけでなく、止めることで何の危険を減らせるかを説明しなければならない。
また、修正にも危険はある。信頼性改善と名付けた大規模な構成変更を急いで入れれば、別の障害を招く。必要な変更を小さく分け、戻し方と観測方法を決める。昨日の失敗を減らすための変更なのか、将来の能力を増やすための変更なのか、受け取る側が判断できるようにする。「修正」というラベルだけで例外を認めない。
AWSの信頼性設計指針は、需要の急増や機能・セキュリティ更新のように外部・内部から起きる変化を見込む。変更を永久に止めれば需要の変化や安全上の修正に対応できない。この指針は設計の論点を示すもので、Googleの停止規則を適用すれば障害率が何％下がるかを測った研究ではない。
新機能と安全修正では、保留の意味が違う
以下は仮想例で、実在サービスの障害記録ではない。新しい推薦画面の公開直後に注文の完了率が落ち、旧版へ戻すと改善した。変更との関連が強いなら、次の推薦機能の公開は保留し、注文経路を守る修正と原因分析を優先する。目標の数字だけでなく、一件の注文が使える結果になったかを確認する。
条件を変える。予定していた変更は、認証の重大な欠陥を塞ぐ小さな修正で、現状を放置すると不正利用の危険が続く。利用者の失敗が増えていても「全変更を禁止する」を選ばず、限定した確認と戻し方を備えて修正を通す。逆に信頼性改善と称する大きな移行で、原因と関係が薄く、戻せないなら、回復を急ぐ局面では先送りする。安全性、必要性、可逆性によって案が変わる。
予算が残る場合にも、公開を急がないことがある
予算の残額だけで変更を許可しない。戻せないデータ移行は余裕があっても別途検証し、安全修正は停止による危険も比べる。Googleの例示方針を用いる場合も、外部依存や測定上の問題を理由に例外とした範囲、決定者、再評価日を残す。
止めた時間を改善へ配り、再開条件を決める
公開を止めるだけでは信頼性は改善しない。失敗の定義や計測の欠落を直す仕事、原因に対応した修正、次の変更を戻す試験へ時間を配分する。改善の責任者と確認日を置き、予算の数字が戻るのを待つだけの計画にしない。
再開する条件を先に決める
停止を決めるときには、公開再開の条件も同じ文書に書く。利用者の失敗が落ち着いたか、原因に対する対策が実際に効いたか、監視が異常を見つけられるか、戻す権限があるかを確認する。失敗の測定が変わっただけで数字が改善したなら、サービスの回復とは呼ばない。止めた変更を順番に再開し、同時に複数を入れて原因を読めなくしない。
一時停止は開発者への罰ではない。過去の失敗を受け、利用者が重要な仕事を終えられるよう注意を移す約束である。顧客への影響と変更の因果が見え、公開で危険が増えるなら新機能を保留する。一方、復旧や安全のための変更は、観測と戻し方を整えて通す。誰が、いつ、何を再開できるかまで合意して初めて、方針が行動になる。