組んだ直後は、たいてい問題なく動きます。困るのは半年後です。連携先の仕様が変わり、資料が古くなり、決まった時刻の処理が静かに失敗しはじめます。
ここで肝心なのは、いちばん多い壊れ方が「静かに止まること」だという点です。派手にエラーが出る故障は、まだ幸せなほうです。何も言わずに止まった処理は、誰も気づきません。気づくのは、たいていお客様からのご連絡です。
いちばん簡単で、いちばん効くのがこれです。中の状態を信じるのではなく、外から実際に開いてみる。当社は自社のサイト群に対して、約20分おきにこれをやっています。
点検した回数 ── 12,846回
正常だった割合 ── 98.54%
応答が返るまでの平均 ── 517ミリ秒
正常でなかった応答 ── 187回
187回という数を隠さずに書いているのは、0回だと書ける監視には意味がないからです。何も見つけない見張りは、見張っていないのと区別がつきません。
「なるべく早く気づく」では運用できません。数字で決めます。当社は15分にしています。落ちたまま誰も知らない時間を、15分より長くしない。それが守れているかどうかも記録します。
この数字は業務によって変わります。1日1回でよいものもあります。決めておくことに意味があり、値そのものは伺ってから決めます。
見つけたあと、すぐ人を呼ぶ設計にはしていません。手順が決まっていて、間違えても戻せるものは、その場で自動的に直します。当社では毎時30分に、この修復が走ります。
止まった定期処理を、もう一度実行する
切れた外部連携を、つなぎ直す
古くなったデータを、取り直す
作りかけで残った記録を、片づける
どれも、失敗しても元に戻せる作業です。第7章の基準がそのまま効いています。削除や送信は、この層には置きません。
ここが、実際に運用してみて分かったところです。見張りが黙ることがあります。
異常を知らせる仕組みが止まると、画面は静かなままです。異常がないのか、知らせる側が死んでいるのか、見た目では区別がつきません。しかも後者のほうが危ない。ですから当社は、毎時45分に番人を点検する別の仕組みを走らせています。最後に無事を知らせてきたのはいつか、を数えるだけの、単純な役です。
自動で直せなかったものは、障害として記録され、人の手元に上がります。ここで大事なのは、直せなかったという事実も必ず残ることです。
「自動で直しにいったが、直らなかった」を記録しない仕組みは、静かに問題を捨てます。落ちているより、落ちたことが消えるほうが厄介です。上がってくる件数を絞っているのは、上がってきたものに向き合う時間を残すためです。
実際に動いている台帳と、一日のどの時刻に何が走っているかは「制作するもの」のページに時刻ごと並べています。
C-08-1 何を見張るか ── 生きているかだけでは、ずれに気づけません。
C-08-2 警報を読める数に減らす ── 鳴りっぱなしの警報は、鳴っていないのと同じです。
C-08-3 自分で直す仕組みの限界 ── 検知だけ足すと、溜まります。