「今すぐ」でもリリース手続きは省略しない――障害チケットの優先度管理
本番環境で障害が起きたとき、「緊急なら、通常の手続きを飛ばしてでも直す」と考えることがあるかもしれません。
私が携わっていた運用保守では、緊急性の高い障害でも対応の流れ自体は変えていませんでした。まず通常の運用フローに従って責任者へ連絡し、障害を調査します。その結果をもとに障害チケットを発行し、「今すぐ・高・中・低」の優先度を設定していました。
「今すぐ」に設定するのは、手続きを省略するという意味ではありません。改修と本番リリースに必要な手続きを、ほかの案件よりも優先して進めるという意味です。
前回は、CSV出力が製品上限を超えないように、安全率をかけた件数で分割した運用について書きました。
今回は、障害を調査した後にチケットへ優先度を設定し、緊急案件でも必要なリリース手続きを省略せずに進めていた運用を紹介します。
優先度を付けるのは障害を調査した後
障害を検知した時点で、いきなり「今すぐ」と決めていたわけではありません。
障害発生後は、ほかの障害と同じ運用フローに従って責任者へ連絡します。その後、エラーの内容や影響範囲を調査し、対応が必要な問題として障害チケットを発行していました。
チケットを発行する運用保守責任者が、調査結果をもとに優先度を一次設定します。使用していた区分は、次の4段階でした。
今すぐ
高
中
低
ただし、「この条件なら高、この条件なら中」といった明文化された判定基準はありませんでした。一次設定の後、顧客側と運用保守責任者が運用への影響を確認し、実際の対応優先度を決めていました。
※障害発生後、連絡と調査を経てチケットを発行し、優先度を設定する流れを示すイメージです。
技術的な規模より運用への影響を見る
優先度を決めるときに重視していたのは、障害の技術的な難しさだけではなく、運用と利用者への影響でした。
たとえば、回避方法が用意されていても、その操作による負担が大きい場合や、多くの利用者へ影響が及ぶ場合は、緊急性が高いと判断していました。回避できるという理由だけで、機械的に優先度を下げていたわけではありません。
一方、回避方法がなく、対象機能を利用できない状態なら、影響はさらに大きくなります。機能の数だけを見るのではなく、その機能が止まることで誰が何をできなくなるのかを確認する必要がありました。
ログイン障害を「今すぐ」に設定した
実際に「今すぐ」とした例の一つが、ログイン障害です。
システム全体が停止したわけではありません。しかし、対象となる機能には誰もログインできず、その機能を利用できない状態でした。回避方法もありませんでした。
一部の機能で発生した障害でも、その機能を利用する全員が業務を進められません。このため、調査後に発行した障害チケットの優先度を「今すぐ」に設定しました。
ここで重要だったのは、「一部機能の障害だから影響も小さい」と判断しなかったことです。止まった機能の数ではなく、実際に利用できなくなった人と業務の範囲を見ていました。
「今すぐ」は手続きを飛ばす意味ではない
障害チケットを「今すぐ」に設定しても、通常と異なる特別なフローへ切り替えていたわけではありません。
改修した資産を本番環境へリリースするには、複数の手続きが必要です。緊急だからといって、それらを省略して本番へ反映することはしていませんでした。
違いは、必要な改修とリリース手続きを最優先で進める点です。通常の障害と同じ流れを使いながら、関係する確認や手続きを先に進め、早くリリースできるようにしていました。
※「今すぐ」でも手続きを省略せず、改修から本番リリースまでを優先して進める考え方を示すイメージです。
優先度と担当者・管理期限は別にしていた
「今すぐ・高・中・低」の優先度は、担当者の割り当てや管理期限とは別に管理していました。
優先度は、その障害をほかの案件と比べてどれだけ先に進める必要があるかを示します。一方、誰が対応するのか、いつまでに管理するのかは別の情報です。
実際の運用でも、優先度を付けただけで対応が進むわけではありません。調査結果を踏まえて担当を割り当て、必要な手続きを進めることで、本番リリースへつなげていました。
明文化された基準がなくても、影響は確認する
私が経験した運用では、4段階の使い分けについて厳密な判定表はありませんでした。そのため、この記事で「この条件なら必ず今すぐ」といった共通基準を示すことはできません。
それでも、判断の中心は一貫していました。運用への影響、利用できない機能、影響を受ける利用者、回避方法の有無などを確認し、運用保守責任者と顧客側で対応優先度を決めることです。
区分の名前を決めるだけではなく、その障害によって現場で何が止まっているのかを見ることが、優先度を判断する土台になっていました。
まとめ
障害チケットの「今すぐ」は、通常のリリース手続きを省略するための区分ではありません。
障害を調査してチケットを発行し、運用保守責任者が優先度を一次設定する。その後、顧客側と運用への影響を確認し、必要な改修とリリース手続きを最優先で進めるための区分でした。
ログイン障害のように、一部機能の問題でも、その機能を誰も利用できず、回避方法もない場合があります。障害の大きさを機能数だけで判断せず、利用者と業務への影響を見ることが重要でした。
次の記事：