緊急改修で変えたのは、工程ではなく調整の優先度だった

緊急の障害が発生すると、改修作業そのものを急ぐことに意識が向きがちです。

しかし、本番リリースまでには、改修以外にもレビュー、承認、関係者との打ち合わせ、作業環境の確保が必要です。改修が終わっても、確認する人がいない、本番リリースで使う端末が空いていないという状態では、すぐに本番へ反映できません。

私が携わっていた運用保守では、緊急改修でも通常の改修フローを変えていませんでした。違ったのは、必要な人や端末、打ち合わせの調整を優先して進めたことです。

前回は、障害を調査した後にチケットへ「今すぐ・高・中・低」の優先度を設定し、「今すぐ」でも必要なリリース手続きを省略しなかった運用について書きました。

今回は、「今すぐ」と判断した緊急改修を、通常の流れを保ったまま本番リリースまで進めるために、何を先に調整していたのかを紹介します。

緊急改修でも通常の改修フローを使った

障害対応を急ぐからといって、緊急改修専用の別フローへ切り替えていたわけではありません。

通常の改修と同じように、改修内容をレビューし、必要な承認を受けてから本番リリースを行っていました。緊急性が高いことを理由に、レビューや承認を省略することはしていませんでした。

リリース後の確認も同じです。障害が発生していた部分だけでなく、改修によって既存機能へ悪影響が出ていないかを確認する基本的なデグレード試験と、ログ監視を行っていました。

変えていたのは工程ではなく、それぞれの工程に必要な調整の優先順位でした。

人と端末の調整を優先した

緊急改修では、担当者が改修を早く終えるだけでは足りません。

レビューする人や承認する人など、複数の関係者との調整が必要です。「今すぐ」の障害では、こうした人の調整をすぐに始めていました。

これは、確認を簡略化するためではありません。必要な確認を行える人に、緊急性を伝えて予定を確保してもらうためです。

打ち合わせが必要な場合も、優先して設定していました。改修、レビュー、承認を順に進めるために、関係者の予定を調整していました。

ここで優先していたのは、特定の工程だけではありません。本番リリースまでに関係する人の予定を早めにそろえることでした。

あわせて、本番リリース環境で使う端末も優先して予約していました。

改修とレビューが終わっても、リリース作業に必要な端末を確保できなければ、本番への反映を始められません。そのため、緊急性の高い障害では、端末の予約も優先して行っていました。

改修作業だけを見ていると、端末予約は小さな作業に見えるかもしれません。しかし、実際の本番リリースでは、こうした作業環境の確保も必要でした。

緊急改修では、技術的な作業だけでなく、その後に必要になる設備や関係者も優先して調整していました。

※レビュー担当者、承認者、打ち合わせ、本番リリース用端末を優先して調整するイメージです。

最終承認は運用保守責任者と顧客側で行った

本番リリースの最終承認は、運用保守責任者と顧客側で行っていました。

優先度が「今すぐ」であっても、改修担当者だけの判断で本番リリースを実施していたわけではありません。必要なレビューと確認を終えたうえで、運用保守責任者と顧客側の承認を受けて本番へ反映していました。

緊急時に変わったのは、承認そのものではなく、承認に必要な確認と調整を優先して進めたことです。

リリース後も確認してから完了した

本番リリースが終わっただけでは、障害対応を完了にはしていませんでした。

まず、障害が発生していた部分が正常に動作することを確認します。さらに、改修によって既存機能へ悪影響が出ていないか、基本的なデグレード試験を行っていました。

あわせてログを監視し、異常が発生していないことも確認していました。これらの確認で問題がなければ、障害対応を完了としていました。

緊急改修であっても、リリース後確認まで含めて一連の対応です。早く本番へ反映することだけを完了条件にはしていませんでした。

※障害箇所の動作、既存機能への影響、ログを確認してから完了とするイメージです。

まとめ

緊急改修でも、通常の改修フローは変えていませんでした。

優先していたのは、レビューや承認に必要な人の調整、打ち合わせの設定、本番リリース環境で使う端末の予約です。最終承認は運用保守責任者と顧客側で行い、本番リリース後も障害箇所、基本的なデグレード、ログを確認していました。

急ぐべきなのは、必要な確認を省略することではありません。本番リリースまでに必要な人と環境を優先して調整し、通常の流れを進めることでした。