障害対応は「復旧したら終わり」ではなかった――障害票を閉じるまでに確認していたこと

システムが使える状態まで戻り、プログラムの修正も終わった。

それでも、私が携わったプロジェクトでは、障害票をまだ閉じないことがありました。

復旧したことと、障害対応が完了したことは別に考えていたためです。

前回は、本番リリース後の通常運用後に、どのように完了判断をしていたのかを紹介しました。

振り返ると、障害対応では「何をしたか」だけではなく、現在どの段階まで進んでいるのかを区別することが重要でした。

エラーを検知しただけなのか。
業務は復旧しているのか。
恒久対応まで終わっているのか。
本番反映後の確認まで終わっているのか。

今回は、私が携わったプロジェクトで、障害票を完了にするまでにどのような段階があったのかを紹介します。

エラーを検知しても、処理が失敗したとは限らなかった

本番移行後は、定時バッチや通常業務中のログを確認し、エラーが発生していないか重点的に監視していました。

ただし、

エラーを検知した ＝ 処理が失敗した

とは限りません。

実際に、本番移行後の月次バッチで監視時間を超過し、エラーとして検知されたことがありました。

しかし確認すると、処理そのものは正常に終了していました。

移行期間中に滞留したデータをまとめて処理したことで、通常より時間がかかっていたことが原因でした。

そのため、監視ツールにエラーが表示された時点では障害と決めつけず、まず実際の処理結果やログを確認していました。

監視結果は、対応を始めるきっかけとして扱っていました。

業務が復旧しても、恒久対応が残ることがあった

障害が発生した場合、まず業務を継続できる状態へ戻す必要があります。

すぐに恒久的な修正ができない場合には、応急処置や暫定的な運用によって復旧させることもありました。

例えば、自社では修正できない他社製品の不具合です。

一時的な回避方法によって利用を再開できても、製品側の修正パッチ適用やハードウェア交換などが残っている場合があります。

この場合、

業務が復旧した ＝ 恒久対応まで完了した

ではありません。

利用できる状態には戻っていても、対応そのものは残っています。

そのため、後から必要になる作業は障害票やRedmineなどの管理ツール上に残し、対応状況を追跡していました。

本番へ修正を反映しても、障害票はまだ閉じなかった

保守運用側だけでは原因を判断できない問題については、必要なログやデータを取得し、維持開発側へ調査を依頼していました。

プログラム改修が必要と判断された場合は、修正と確認を行ったうえで本番環境へリリースします。

ここでも、

本番リリースが完了した ＝ 障害対応が完了した

とはしていませんでした。

テスト環境で問題がなくても、実際のデータ量や利用方法、処理タイミングによって同じ問題が再発する可能性があります。

そのため、本番へ反映した後も通常運用の中で状況を確認していました。

本番反映後は、通常運用で問題がないことを確認した

本番リリース後に確認していたものの一つがエラー監視です。

修正した問題と同じエラーが再び発生していないかを確認します。

もう一つが、実際にシステムを利用している利用者からの申告でした。

監視上は正常でも、利用者の操作の中で初めて分かる問題もあります。

そのため、システム側の監視結果だけではなく、利用者側から問題が報告されていないことも確認材料にしていました。

本番へ修正を反映しただけではなく、実際の運用でも問題が解消していることを確認するところまでを障害対応の一部として扱っていました。

担当者の作業完了と、障害票の完了も別だった

私が携わったプロジェクトでは、維持開発側が改修して本番へリリースしただけで、障害票を完了にはしていませんでした。

改修を担当した人と、障害対応そのものの完了を判断する人が同じとは限らなかったためです。

本番反映後の運用状況を確認し、問題が解消していることを確認したうえで、運用保守の責任者が完了を判断していました。

つまり、

担当者の作業完了 ＝ 障害管理上の完了

でもありませんでした。

開発担当者から見れば作業が終わっていても、運用側ではまだ確認中という段階があります。

この違いを分けておくことで、本番反映後に残っている確認作業も追跡しやすくなっていました。

振り返ると、障害対応には複数の「状態」があった

当時の対応を振り返って整理すると、障害対応には次のような段階がありました。

障害によって実際の対応経路は異なり、保守運用側だけで解決する場合も、維持開発側で調査や改修を行う場合もありました。

したがって、すべての障害がこの順番を通るわけではありません。

重要だったのは、一本道の手順を守ることではなく、

「今どこまで進んでいるのか」
「次に何を確認する必要があるのか」
「何が残っているのか」

を区別できることでした。

こうして段階を分けておくことで、復旧後や本番反映後に残っている対応も追跡しやすくなっていました。

まとめ

私が携わったプロジェクトでは、障害対応を「システムが使えるようになったら終了」とは考えていませんでした。

検知したこと。
復旧したこと。
恒久対応を行ったこと。
本番へ反映したこと。
通常運用で問題がないことを確認したこと。

それぞれを別の段階として扱っていました。

特に印象に残っているのは、

復旧した ＝ 障害対応完了ではない

という点です。

業務が再開できても恒久対応が残っていることがあります。

本番へ修正を反映しても、実際の運用で問題がないか確認する作業が残っています。

そのため、障害票では現在どこまで対応できていて、何が残っているのかを管理し、最後に運用上問題がないことまで確認して完了を判断していました。

障害対応では「直したか」だけではなく、何を確認すれば本当に完了と言えるのかを分けて考えることが重要だったと感じています。

次の記事：