障害監視の成功を分解する——工程の実行記録と観測期間で復帰を判定する

成功した診断に、障害が載っている

社内の集計画面が開かないと連絡があり、管理担当が診断を実行したとします。診断は終了し、結果には警告が記載されています。管理画面には「成功」と出ましたが、利用者からはまだ開けないという返事が来ます。診断が成功したのに障害が残るのは矛盾でしょうか。診断の目的が、異常と未確認事項を報告することなら、報告を作れた時点でその仕事は成功しています。画面を直す仕事は別に残ります。

監視と保守では、起動全体、各工程、失敗、後続の復帰を分けて残し、修復報告を別担当が観測して受け入れる構成が役立ちます。この基盤で確認できるのは、実装と試験の条件までです。正常環境での演習は受渡しの確認になっても、実際の障害修復の証拠にはなりません。クラウド上の障害再現と復旧の確認は、別の検証として残ります。

読み解く出発点は、「成功」という語の主語を補うことです。診断報告の作成が成功したのか、情報取得の工程が成功したのか、利用者の操作が回復したのかで、次に確認する相手と材料が変わります。例の連絡から、途中で記録が途切れる条件、次の起動で工程が通る条件、過去の原因が不明な条件へ進めて、証拠からどこまで判断できるかを考えます。

仕事全体と、観測した工程を分ける

例の診断が、稼働状況の取得、ログの取得、報告の作成、通知という順で進むとします。ログの取得だけが時間切れでも、ほかの情報と未取得の事実をまとめた報告は作れます。起動全体に一つの成功印だけを付けると、ログまで読めたように見えます。反対に、工程の失敗だけを全体の失敗とすると、有用な診断報告ができたことまで隠れます。全体と工程を別々に記録する理由はこの差を残すためです。

実装では、各工程の開始と終了、結果、状態、例外の種類などを保存する設計があります。決められた工程名を使うことで、前回のログ取得と今回のログ取得を対応させられます。入力した秘密そのものや長い例外本文をそのまま記録する構成ではありません。障害調査に何でも保存すると、認証情報などを記録へ混ぜる危険があります。診断に必要な状態と、残さない情報を先に区切ることも観測設計の一部です。

何秒かかったかを測る目的なら、時計が調整されても戻りにくい経過時間用の測り方を使います。一方、いつ起きたかを他の出来事と並べるには時刻が必要です。両者は用途が異なります。工程に十秒かかったと分かっても、通信、認証、相手の処理のどこで十秒使ったかは、工程内をさらに観測しなければ分かりません。記録の細かさ以上の原因を読み取らないことが、次の調査を選ぶ前提になります。

経過時間は、時計の調整の影響を受けにくい専用の時計（Pythonのtime.monotonic）で測ります。時刻の表示とは別の単調時計で差分を取り、処理を観測できた区間の長さを残す役割です。SQLiteの台帳には実行、工程、失敗、復帰を分けて保存します。工程を識別する名前と観測範囲をそろえることで、無関係な成功を復帰の根拠にしない構成になります。

実停止時刻と、検出時刻を混ぜない

例えば、ログ取得が十時に始まり、実行中のコンピューターが十時三分に止まったとします。終了の後処理は動かず、次の起動は十一時です。実行中のコンピューターが十時三分に止まったことを担当者が別の記録で知っていても、工程の保存記録に開始しか残っていなければ、そこで得られるのは十一時に未終了の工程を見つけた事実です。実停止の十時三分と検出の十一時を、同じ終了時刻として扱ってはいけません。

実装では次の起動で古い実行中の工程を中断として検出します。このとき終了欄へ置く時点は、中断を見つけた時刻です。終了の後処理が動かなかったため測れていない経過時間を、設定上の時間上限や開始からの差で埋めることはしません。例なら十一時から十時を引いて一時間と記載しても、実際に一時間処理していたという証拠にはなりません。未知の値を空けておく方が、記録の意味を保てます。

それに対して、動いている処理が時間切れを捕捉し、終了の後処理まで実行できた場合は、その工程の実測時間を残せます。画面にはどちらも時間切れに近い警告が出るかもしれませんが、測れた範囲は違います。利用者へ障害時間を報告するなら、工程の記録だけで停止の長さを断定せず、別の観測も必要です。「十一時に中断を検出、実停止時刻はこの記録では不明」と書くことが、精度のある報告になります。

最初の失敗を残すと、後の異常を追える

診断の途中でログ取得が失敗し、その後の通知も失敗したとします。最後のエラーだけを保存すると、調査者は通知障害が発端だったように読みます。実装では工程の例外を扱い、最初の失敗を保持する構成が見られます。起動全体の失敗と、各工程で観測した問題を分けることで、何が先に起き、どこまで後続を進めたかを読みやすくします。

例ではログを取得できなかったため、診断報告に未確認事項が残っています。通知の失敗は、その報告を担当者へ届けられたかの問題です。通知を直してもログの未確認が消えるわけではありません。逆にログ取得が回復しても、連絡が届くことまでは保証しません。時間の順序と担当の違いを記録へ残すと、修復の優先順位を具体的に選べます。利用者の画面が使えない原因については、まだ別の調査が必要です。

正常時の記録も捨てずに使います。失敗した工程の前後で何が成功したかを知れば、全てを一度に再調査するより対象を絞れます。ただし先行工程の成功が、その後も状態が維持された証拠とは限りません。稼働状況の取得時点では応答があっても、数分後の利用者操作で失敗することはあり得ます。記録を原因の結論としてではなく、次の確認範囲を選ぶ材料として読む姿勢が必要です。

復帰の条件は、同じ工程の後続成功

十一時の起動で、前に失敗したログ取得が今度は成功したとします。実装では同じ工程の後続の成功を、復帰の判断に使います。別の工程が成功しただけでは、ログ取得の失敗を復帰扱いにしません。例なら診断報告を作れたことはログ取得の復帰の代わりにならず、ログを取れるようになったことは社内画面の利用再開の代わりになりません。対応する工程を固定して比べることが要点です。

復帰の記録は通知を送る前に保存されます。通知が時間切れでも、工程が成功した事実は残せます。通知の成否を工程の復帰判定に混ぜると、通知が届いたことを根拠に復帰を判断する循環が起こるため、この二つは分けています。読み手には「ログ取得の経路は復帰を観測、連絡の到達は未確認」という形で二つを示す方が、次の担当の行動を選びやすくなります。

ただし、後続の一回が成功したことは、障害原因を取り除いた証明とは限りません。一時的な負荷や通信の揺れなら、原因を修正しなくても成功へ戻る場合があります。今は使えると判断するための観測と、同じ異常が再発しないと判断するための調査は、必要な範囲が違います。工程の復帰を過小評価する必要もありませんが、そこで確認できたこと以上の意味を持たせないことが、実務で使える成功表示につながります。

過去の原因が消えても、現在は調べられる

保持期限を超えた古い記録を清掃した後、現在の集計には警告がないとします。今の保持状況が正常であることは確認できても、昨日の警告が何に起因したかは、必要な記録が失われていれば分かりません。この条件では過去の警告を誤報とも断定できません。現在の利用再開を決める調査と、過去の原因を解明する調査を分けると、原因不明を隠さずに次の仕事を進められます。

最近のエラーを読む工具にも観測範囲があります。実装では直近二時間を対象とし、百件で打ち切ることがあります。例の調査が十一時なら、さらに前の時間帯や百件を超えて省略された部分は、この結果だけでは分かりません。「エラーなし」は対象期間と件数の範囲での結果です。利用者の障害が前夜から起きていたなら、直近二時間の空の一覧で一晩中正常だったと結論づけることはできません。

ここで次に選ぶ調査は、足りない情報によって変わります。現在の画面が開けるかを知りたいなら利用者相当の操作を確かめ、前夜の原因を知りたいなら保持された別の記録や担当の操作履歴を探します。既に消えた記録を復元できない場合は、その不足を報告へ残します。すべての疑問へ一つの監視結果で答えようとすると、現在の状態を確認できたという有用な成果も、過去の未解明事項も正しく伝わりません。

この条件の報告なら「現在は画面を取得できる。前夜の停止原因は保存期限を過ぎたため未特定。直近二時間では同じ異常を観測していない」と書けます。この報告からは当面の利用再開と、次の夜に備える観測追加を別々に決められます。再発の原因を知りたい業務なら保存期間の見直しを検討しますが、期間を延ばす前に、必要な情報と保存しない秘密の境界を維持できるかを確かめます。

修復したという報告を、別の観測へ戻す

管理担当が設定を直し、「復旧しました」と報告したとします。報告の形が整い、必要な説明があることは最初の検査で確認できます。しかし、それは担当者が書いた内容の自己申告です。この構成では、その後に作業者と別の担当が決められた工具を使って実状態を読みます。修正した設定の説明と、修正後の状態の観測を分けることで、報告だけを根拠に修復を受け入れないようにしています。

社内画面の例なら、稼働状況が正常、保持集計が予定の範囲、必要に応じて最近のエラーを確認、という材料を揃えます。それでも利用者の権限に固有の障害は、管理側の応答だけでは検出できないかもしれません。そのため、利用者が困っていた操作に相当する確認を追加する必要があります。稼働状況やログを読む検査だけでは、利用者ごとの操作まで自動検査できません。

別担当の受入では、観測期間を添えることも重要です。修正後の二時間に再発がなかったと分かっても、それ以前やそれ以降の無障害は証明できません。本人認証や組織上の独立性まで、担当名が違うだけで成立するわけでもありません。誰が何を読んだか、作業者の報告以外にどの現物を確かめたかを示すことが、引き継ぐ人に必要な証拠になります。

試作の合格条件に、分からない値も入れる

試験には、入れ子になった工程、同じ工程の復帰、秘密の本文を保存しない条件、中断を次の起動で検出する条件が定義されています。これらは設計と試験の定義で、実際の環境での実行結果とは分けて扱います。正常な環境で報告を作り、別担当が読む演習は、受渡しの確認としては意味がありますが、実際の障害を再現して直した証拠や、現行環境の無障害を保証する証拠とは分けて扱います。

自分の運用で試すなら、工程が時間切れを捕捉できる場合と、実行中のコンピューターが止まって終了の後処理が動かない場合を分けます。前者では実測が残り、後者では次の起動の検出時刻が残って、測れない経過時間が勝手に埋まらないことを期待結果にします。さらにログ取得の失敗後、別の工程だけを成功させ、ログ取得が復帰扱いにならないことを確かめます。同じ工程の成功を加えた正常例では、対応する復帰が残ることを見ます。

導入の最初の作業として、今ある成功表示の主語と観測範囲を書き出してください。診断報告の完成を確認する欄、工程の復帰を確認する欄、利用者の操作を確認する欄へ分ければ、足りない調査が見えます。時刻が不明なところ、記録が失われたところは、そのまま未確認として担当へ渡します。誤った精密さを作るより、分かっている範囲と次に必要な観測を示す方が、障害後の判断と再発調査を進めやすくなります。