止める時刻を先に書く — 変更の種類・影響範囲・切り戻し基準

一言でいうと

良い変更要求書は、「何をするか」よりも先に、「いつ中止し、どうロールバックするか」を書きます。ロールバックにかかる時間を作業ウィンドウから逆算して引くと中止判断時刻が出て、その時刻がロールバックのトリガーになります。リハーサルは、その計画が楽観的だったかどうかを作業前に教えてくれる唯一の方法です。

なぜ必要なのか

Google SRE本は、運用中のシステムで起きる障害の約70%が変更によるものだと書いています。変更をなくすことはできないので、変更が事故になる道を狭めるしかありません。その本が挙げる方法は3つあります。段階的に出すこと、問題を素早く正確に見つけること、問題が起きたら安全にロールバックすることです。

変更要求書(change request)と作業計画書は、この3つを作業前に紙の上で確認するための道具です。午前3時に、計画より20分遅れた作業者に「もう少しでできそうだ」という判断をさせると、たいてい続行します。中止の基準を事前に数字で書いておけば、その判断を疲れた人に任せずに済みます。

どう動くのか

変更の種類について、ITIL 4の変更実現(change enablement)の慣行は、変更を3つに分けます。

種類	意味	例
標準(standard)	リスクが低く、手順があらかじめ承認された、繰り返し行われる変更	承認済みの手順書どおりに行う設定値の調整
通常(normal)	評価と承認を経てスケジュールを組む変更	新しい手順書で行うDBボリュームの増設
緊急(emergency)	今すぐ行わなければ間もなく障害になるため、急いで処理する変更	数時間後に期限切れになる証明書の交換

種類を分けるのは、承認のコストをリスクに見合わせるためです。すべての変更を委員会に上げると人々は手順を迂回し、すべての変更をそのまま行うと事故が起きます。緊急変更も承認がないのではなく、短い経路で承認を受け、事後に記録を埋めます。

影響範囲は、「DB1台の再起動」であってもそのDBだけには及びません。そのDBを使うサービス、そのサービスを使うサービスまで、依存を最後までたどると、周知先と確認先が出ます。直接の依存だけを見て周知すると、2段階離れた精算レポートのチームが、朝になって空の画面を見ることになります。

作業ウィンドウと中止判断時刻は次のとおりです。作業ウィンドウが02:00–04:00で、ロールバックに最悪50分、余裕5分が必要なら、03:05が中止判断時刻です。この時刻までに作業が確認まで終わっていなければ、ロールバックを始めないとウィンドウ内に元の状態に戻りません。計画上の作業が60分なら03:00に終わるので、ウィンドウに「収まります」。ところが、60分という数字が楽観的だったらどうでしょうか。

ロールバック基準は測れるものでなければなりません。「問題が起きたらロールバック」は基準ではありません。「03:05までにS5の確認が終わっていなければ」「エラー率が1%を5分以上超えたら」のように、時刻・割合・件数で書きます。作業のステップごとに、終わったと判断するための確認方法(verify)も書きます。確認方法のないステップは、終わったかどうかわからないステップです。

事前チェックと周知は次のとおりです。作業を始める前に、ロールバックの根拠が生きているか(昨夜のバックアップは成功したか、スナップショットを取る空き容量はあるか)、作業対象が計画書の前提と同じか(バージョン・容量・パス)を確認するリストが、事前チェックです。1つでも食い違えば、作業を始めないのがルールです。影響を受けるサービスの担当者に、開始・終了・ロールバックの決定を誰がどの経路で知らせるかも、要求書に書きます。

リハーサルは、開発環境や複製環境で同じ手順を実際に実行し、ステップごとに開始・終了時刻を残すことです。計画と実際を比べると、どのステップが楽観的だったかが見えてきます。リハーサルで中止判断時刻を超えたなら、本番の作業でも超える可能性が高いです。ウィンドウを延ばす、作業を分ける、遅いステップを短くする方法を、先に探します。

現場での姿

韓国のSI・運用の現場では、これらの文書が「作業計画書」「作業結果書」「変更要求(CR)」という名前でやり取りされます。様式は会社ごとに違いますが、レビュー担当者が差し戻す理由はほとんど同じです。ロールバック手順が「原状復帰」の一言だけ、影響サービスの一覧が直接の依存だけ、作業時間の合計がウィンドウをぎりぎりまで埋めている、事前チェックにバックアップの確認がない、といったものです。

作業が終わったあとには、結果書が残ります。計画したステップごとに実際の開始・終了時刻、確認結果、計画と違った点を書き、ロールバックしたならその判断時刻と根拠を書きます。次の同じ作業の計画書は、この結果書の実測時間から出発します。結果書なしで毎回新しく見積もると、同じステップが毎回同じだけ遅れます。

最も高くつく失敗は、ロールバックの時間を計算しないことです。作業60分でウィンドウ120分なら余裕があるように見えますが、ロールバックに50分かかれば、余裕は5分しかありません。リハーサルの記録があれば、この余裕が実際にはマイナスだということを、作業前に知ることができます。

次のラボですること

3つの変更要求の種類を分け、サービスの依存一覧からDB再起動の影響範囲を最後までたどります。作業計画表とウィンドウから、作業とロールバックの時間、中止判断時刻を計算し、それを使ってJSONの変更要求書を書きます。ヘッダー部(種類・ウィンドウ・影響・事前チェック)と本体部(ステップごとの確認方法・測れるロールバック基準)です。最後に、リハーサル記録から最も遅れたステップを見つけ、中止時刻を超えたかどうかを判定します。