【ITニュース解説】A duration is only a duration if it has two ends

システムが安定して稼働しているかを確認することは、システムエンジニアにとって非常に重要である。特に、システムに何らかの問題が発生した際、その問題がどれくらいの期間続いていたのかを正確に把握することは、原因究明や再発防止策を講じる上で不可欠である。しかし、この「問題が続いていた期間」を正確に測定することは、私たちが考えるよりもずっと難しいという現実がある。

このニュース記事では、ある問題が「どれくらいの期間」続いていたかを正確に語るためには、三つの重要な要素が満たされている必要があると指摘している。それは、まず「明確な開始点」、次に「明確な終了点」、そして最後に、これら開始点と終了点を示す「証拠がまだ存在していること」である。これらのうち一つでも欠けている場合、その期間は信頼性の高い情報とは言えない可能性がある。

例えば、あるシステムが共有リポジトリにファイルをプッシュ（送信）できなくなっていた事例がある。ログにはプッシュが失敗したという記録が1229回も残されていた。しかし、この1229回という数字は、単にシステムが1229回リトライを試みた回数であり、問題が続いた期間そのものを直接示すものではない。重要なのは、最初の失敗のログに残された日付と、プッシュされずにローカルに残ったコミットのタイムスタンプという二つの日付であり、これらによって問題の開始と終了が特定できた。そして、この二つの日付を示すログやリポジトリの履歴が、問題解決後も存在していたため、期間を正確に測ることができたのである。

また、別の事例では、入力データを誤分類してしまい、その証拠すら消去してしまうバグが発生した。このバグは、手作業で数えることでようやく発見されたものだが、その修正の履歴がバージョン管理システム（Gitなど）のコミットコメントに記録されており、各修正の日付が明確に残っていた。これにより、障害の期間を54日間と正確に特定できた。このように、問題解決後も証拠となる情報が残り続けるバージョン管理の履歴は、サイレントな障害の期間を測定する上で非常に強力な手段となる。

しかし、最も注意すべき事例は、問題の修正自体が期間の証拠を破壊してしまうケースである。あるセンサーが36日間もデータを全く出力しなかった事例では、その沈黙期間を記録する唯一の証拠は、「センチネルファイル」と呼ばれる、ある特定のファイルの更新日時（mtime）だった。このファイルは、センサーが正常に動作しない際に更新され、その後は何も書き込まれない状態が続いたため、その更新日時が問題の開始を示していた。ところが、この問題を修正した際に、そのセンチネルファイルが更新されてしまい、せっかく記録されていた36日という数字の証拠が失われてしまった。このことから、問題を修正する前に、その期間を示す証拠を別の場所に記録しておくことの重要性が強く示唆されている。修理行為そのものが、障害の証拠を消し去ってしまうという事実は、システム運用において肝に銘じるべき点である。

さらに、「私は6週間この欠陥に気づかなかった」といった表現も、正確な期間とは言えない。これは、問題を発見するまでの期間を示すものであり、実際にシステムが6週間壊れていたことを意味しないからである。もしかしたら、その欠陥は数ヶ月前から存在していたが、たまたま6週間前に見始めたか、記録を取り始めたのかもしれない。この「発見までの時間」と「実際に問題が存在していた時間」の区別は非常に重要であり、システムの状態を測るのか、監視体制を測るのかによって、見るべき情報が変わってくる。

記事では、他にも期間の測定に関する様々な限界を挙げている。例えば、期間の一方だけが明確なケースや、期間を「1日から1ヶ月の間」といった範囲でしか示せないケースもある。また、測定元からすでに「約42時間」のように曖昧な情報として提供されるケースもあり、これらを無理に単一の数値にまとめるのではなく、曖昧さを含んだまま提示することも、正直な情報伝達のためには重要である。

結局のところ、システムエンジニアが学ぶべき最も重要なルールは、「明確な開始点を持たない期間は、真の期間ではない」という点である。それは、単に「誰かがいつその問題に気づいたか」という観察の事実を数字で語っているに過ぎない。繰り返しになるが、正確な期間を特定するためには、障害が発生した時点かそれ以前の日付を示す、理想的には障害によってのみ書き込まれる証拠（明確な開始点）、外部から問題が最初に確認された時点のタイムスタンプ（明確な終了点）、そしてその証拠が問題解決後も残っていること、の三つが不可欠である。特に、問題修正によって証拠が消える可能性がある場合は、修正作業に着手する前に、必ずその期間を示す数値を記録しておく習慣を持つべきである。

このニュース記事は、期間の測定に関する技術的な側面だけでなく、もう一つの重要な教訓も提供している。それは、監視ツールが自信を持って「正常」と報告していても、実際にはシステムに問題が発生しているケースが非常に多いという点である。記事で挙げられた15の事例のほとんどは、本来その問題を検知すべき監視システムではなく、人による手動確認、別の監視ツール、あるいは偶然の出来事によって発見されている。問題が長く放置されても、監視ツールは自信を失うことはなく、むしろ正常であるという確信を強めてしまうことがある。そのため、システムの状態を多角的に、そして定期的に確認する人間や他のシステムによるチェックが、見過ごされた障害を発見するために不可欠である。