障害対応中にシステム変更してよいか？ 緊急修正と通常更新の区別
注文が止まり、複数の担当者が設定変更や切り戻しを提案している。今この障害を回復させるために、どの変更を、誰の判断で、どの順序で通すか。本稿では対応中の通常更新を保留し、復旧に必要な変更の例外承認と、凍結解除の条件を扱う。
変更凍結を決めるなら、止める範囲と例外を同時に決めたい。問うべきは、変更が障害を広げる可能性、復旧に本当に必要か、失敗したときに戻せるかである。本稿では障害対応中の変更を、通常更新、復旧に必要な変更、原因不明の変更に分け、解除までの判断を考える。
この記事の目次
全停止の目的は、変更の混入を減らすこと
GoogleのSRE本にある障害事例では、設定変更が広い範囲の不具合を生み、担当者による取り消しの変更が回復につながった。別の自動化の事例では、追加の処理が被害を広げないよう、関連する自動化や保守作業を止めた。どちらもGoogle自身の事例であり、他社の障害で同じ手順が必ず最短になるという比較実験ではない。Google SRE「Emergency Response」
二つの例が示すのは、「変更」という一語で全部同じ扱いにできないことだ。障害を広げる自動化を止める変更と、既知の悪い設定を戻す変更は、通常の機能追加とは目的が違う。凍結の理由を「リリース禁止」とだけ記録すると、この差が担当者へ伝わらない。
まず、新しい機能、関係のない設定調整、性能改善の試行は原則として保留する。障害の影響が見えない時間に、状態をさらに変える理由が薄いからだ。一方、停止や切り戻し、利用を継続させる限定的な修正は、別の判断経路を用意する。例外を現場の口頭判断へ丸投げしない。
ただし、関係のない変更を止める期間が長いほど、セキュリティ修正や運用上必要な更新も滞る。緊急時の凍結を常設の管理方式にしないため、開始時点で対象システム、対象変更、判断者、再評価の条件を残す。
緊急変更にも、理由と確認が必要になる
NISTのSP 800-53は米国政府向けの情報システム管理策を示す。構成変更の統制では、変更の提案、影響の検討、承認、記録といった流れを扱う。緊急変更を日常の手続きを単に無視する許可として読まない。これは統制の指針であり、障害時の変更を何分で承認すべきかを実証した研究ではない。NIST SP 800-53 Rev.5
障害中に十分な通常会議を開けないなら、確認の深さを影響の大きさに合わせて変える。それでも、何を直すか、どの観測で効果を確かめるか、戻せるか、誰が止めるかは残したい。実行後には実際に何を変えたかを記録し、事後の検討につなぐ。速い判断と、記録を持たない判断は同じではない。
特に「念のため、他も一緒に直す」は危うい。変更をまとめるほど、回復した理由も悪化した理由も読みづらくなる。可能なら復旧に必要な最小の変更へ絞り、結果を見て次へ進む。この順序は研究から出た万能な最小単位ではなく、因果を追いやすくするための編集上の提案だ。
緊急承認で決めるのは、復旧に必要な変更の範囲です。機能追加まで同じ枠へ含めると、復旧の効果と副作用を追いにくくなります。修正案、効果を確かめる操作、失敗したときの次の案をそろえます。データまで戻せるかは、切戻しと互換性の記事で別に確認します。 切戻しと互換性
「戻せる」の中身を、対象ごとに確かめる
設定を元の値へ戻せても、その間に書き込まれたデータは元に戻らない場合がある。変更の影響が画面に限られるのか、注文や請求など後から取り消せない行為へ及ぶのかを分ける必要がある。
Googleの事例でも、変更の取り消しが速く効いた例がある一方、依存関係の想定不足で当初の戻し方が機能しなかった例がある。同じ組織の経験で方向が分かれる。戻す操作の存在と、障害時にその操作が使えることを混同しない。Google SRE「Emergency Response」
復旧変更を提案するときは、影響する経路、確認する利用者操作、失敗時の次の手を短く並べたい。誰が効果を確認するかまで決める。操作した人が「完了」と言っても、利用者が正常に仕事を再開できたとは限らないからだ。
他チームへの影響があるなら、統括役を置いて変更の順序を共有する。別々の担当者が同時に復旧を試すと、互いの変更が結果を打ち消すことがある。危機対応の速さは、同時に多く手を動かすことだけで生まれない。
架空の受注障害では、三つの案が変わる
以下は仮想例である。受注画面で注文が完了しない。直前に変更した設定が原因らしく、元へ戻す手順が確認されており、注文データへの影響も把握できる。この場合は通常更新を凍結したまま、当該設定の切り戻しを優先する。変更後に新しい受注を実際に完了できるかを見て、回復を判断する。
条件を変え、同じ設定を戻すと、新形式で保存した注文を読めなくなるとする。直前の変更が怪しくても、単純な切り戻しを急ぐ案は適切ではない。新規入力を一時的に制限し、現在のデータに対応できる修正を検討する。戻し方を先に設計し直す必要がある。
さらに障害は収まったが、原因に関係しない新機能の公開を待っている場合はどうか。復旧後の観測が安定し、担当者が変更の影響を見分けられる状態になるまでは保留を続ける。永遠に禁止するのではなく、確認できる状態を解除条件にする。
三つの答えの差は、障害の大きさだけではない。何を変えるとどの状態に戻るのか、どの証拠で利用者への影響を見られるかにある。
凍結そのものが復旧の障害になる場合
たとえば障害中の通信経路を切り替える設定は、新しい変更であっても、利用者が使える状態を戻すために必要かもしれない。Googleの障害対応例も、原因となった変更の取り消しを実施している。凍結の例外は後から違反として隠すのでなく、復旧に必要だった理由と結果を通常の記録へ戻す。
逆に、脆弱性の修正という理由だけで、障害中のサービスへ大きな更新を重ねるのも危険だ。攻撃の可能性が現に高いか、更新を待つ間に別の隔離策が使えるか、修正が今回の障害へ影響するかを比べる。ここで示すのは「セキュリティ修正を待て」という規則ではなく、緊急変更の影響を並べて判断する枠組みである。
変更を解除する責任者がいないと、復旧担当は次の公開を恐れて凍結を続けがちになる。逆に現場が疲弊したまま解除すれば、監視や切り戻しの準備が追いつかない。解除では、観測が安定したことと、変更後に監視する担当者がいることを両方確認したい。
解除後の最初の変更では、通常より広い範囲へ一度に配布しない理由もある。障害で観測基盤自体が弱くなっていたなら、小さな変更でも結果を読む力が落ちている。監視が回復したか、問い合わせを受ける窓口が動くかを確かめ、再開の範囲を決める。
解除の合図を「障害票を閉じた」だけにしない
解除時には、主要な利用者の操作が戻ったか、同じ警告が再発していないか、復旧のために入れた暫定変更の責任者がいるかを確認する。根本原因の調査が終わっていなくても、通常変更を限定的に再開できる場合はある。一方、原因の見立てが変わり続け、観測も不安定なら、画面上の回復だけで全変更を開放しない。
凍結中に積み上がった更新も、一度に全部流さない。緊急性と依存関係を見て順番を付け、再開後の最初の変更が新しい障害を隠さないようにする。実施した緊急変更は、通常の構成記録へ反映して次の担当へ渡す。
結論は、障害中の変更を無条件で許すことでも、すべてを止めることでもない。通常更新は保留し、復旧に必要な変更は理由・観測・失敗時の対応を揃えて通す。凍結解除は、回復を確認し、次の変更の影響を見分けられる状態になったときに行う。