「動かなかった」を見つけるために、台帳に時刻表を持つ

24時間動かしている端末で、約90本の自動処理が動いています。毎晩の取り込み、朝の通知、定時の集計、常駐のBot。1本ずつは小さくても、全部を人が覚えておくことはできません。

データ連携の仕事を長くやってきて、失敗を検知して自動で復旧する仕組みは何度も作りました。その中でいちばん難しかったのが、最後に残った「動いていない」の判定です。失敗は記録に残るので拾えます。動いていないは、記録そのものが無い。ここを埋めるために、プログラム台帳を持ちました。何が在って、どの端末で、いつ動く決まりか。台帳が要る理由は3つあります。「動かなかった」は記録に残らないので、時刻表が無いと判定できないこと。追加や更新を人が書き込む運用は続かないこと。そして、全体を1枚で眺められると、重複や無駄をAIが見つけられること。この3つを順に書きます。

記録には「動いた」しか残らない

自動処理は、動けば記録を書きます。成功なら成功、失敗なら失敗と理由。ところが「動かなかった」ときは、何も書きません。書く側が動いていないのだから当然です。

失敗は記録を読めば分かります。動かなかったは、記録を読んでも分かりません。「本来なら今ごろ記録があるはずなのに、無い」と気づくには、「本来なら」を知っている何かが要ります。それが台帳の時刻表です。

台帳には、プログラムごとに間隔の種類と、間隔の書き方を持っています。毎日、短い間隔、週次、月初。「6時間ごと」「毎日3時」「毎月10日」。見張りはこれと実行の記録を突き合わせ、時刻表から見て来ているはずの記録が無ければ「止まっている」と知らせます。

測れるのは、定時に動くものだけです。常駐で起動と停止しか記録しないものは、再起動しない限り記録が増えず、何時間に設定しても必ず鳴ります。これは間隔で測らず、プロセスが居るかを実機で見ます。見張りから外した理由は台帳の備考に残します。黙って見えなくなった、にしないためです。

時刻表は台帳が持ち、待つ時間は台帳から配る

「記録が来ていない」を、最初は一律7日で測っていました。28本が引っかかりました。月に1回のもの、常駐のものが混ざっていたからです。

次に、見張りを75本に広げたとき、待つ時間を1本ずつ手で決めました。台帳では「常時稼働」「毎月10日」なのに、2〜3日で見張るものが4本まぎれました。誤報は鳴りすぎなので、しばらくすると誰も見なくなります。鳴らないのと同じくらい悪い。

間隔は台帳が持っています。それを見ずに手で決めるから食い違う。そこで、間隔の種類ごとの決まりを1か所に書き、台帳から待つ時間を配るようにしました。台帳の種類を直せば、見張りも一緒に直ります。

待つ時間は、1周期に取り込みの遅れぶんの余裕を足したものより、必ず長くします。6時間ごとに動く1本が、待つ時間も6時間だったために毎周期かならず「要確認」になっていたことがあります。実行は全部成功していて、記録が届くまでの数分が「6時間経った」に化けていました。

緩めるときは実測です。直近30日の記録から、待つ時間を超えた空きが何回あったかを数え、繰り返し起きるものだけを拾います。いちばん長い空きだけを見ると、Macを一晩閉じた1回で落ちます。数えるのは、いまの時刻表になってからの記録だけです。時刻表を変えると、その前の記録は別の決まりで動いていたものだからです。

追加も更新も、台帳に載るのは自動

台帳を人が書き込む運用は、続きません。元は別の道具で管理していて、朝の棚卸しで実機と突き合わせて直す形でしたが、それでも直し忘れは出ました。8月に自社の業務アプリの中へ移し、台帳に載る道を3つにしました。

1つ目は、作るときに一緒に書くこと。プログラムを新しく作るのはAIで、起動の定義を置くのと同じ手順の中で、台帳の行も書きます。順番の決まりもあり、台帳に「稼働中」と書く前に起動の仕組みに載せたときは、検査が落ちました。

2つ目は、知らない記録が来たら自動で載せること。実行の記録を台帳に取り込む処理は、台帳に無いプログラムの記録を見つけたら、「見張らない」の印を付けて登録します。増えたのに誰も知らない、を防ぎます。人は台帳を開いて、それを稼働中にするか、種類を付けるかを決めるだけです。

3つ目は、台帳と実機の突き合わせを毎日の検査にすること。台帳が「稼働中」なのに実機に居ないもの。実機に居るのに台帳に無い、または「停止」「廃止」のもの。どちらかがあれば朝の通知に出ます。この検査を入れたきっかけは、朝夕に動く配信を止めた日に台帳を直し忘れ、見張りが毎日「消えた」と言い続けたことでした。入れた日に、台帳に載っていないのに動いていたプログラムも1本見つかりました。突き合わせは、直し忘れだけでなく、抜けも見つけます。

台帳の写しを別に持っていた頃は、写しが嘘をつきました。廃止にした1本が写しでは稼働中のままで、見張りが毎回1件の誤報を出しました。いまは見張りが台帳を直接読みます。写しは、台帳のデータベースが読めないときの非常用として、毎晩1回だけ書き出しています。

台帳を俯瞰すると、重複と無駄が見える

台帳が1枚にまとまると、人が1本ずつ覚えていたときには見えなかったものが見えます。同じ時間帯に固まっているもの。同じ情報源を、別々のプログラムが取りに行っているもの。役目が後継に移ったのに、残っているもの。

これを見つけるのはAIです。プログラムを足す前に台帳を渡して、「同じことをしている処理はすでにあるか」「まとめられるものはあるか」を聞きます。9月に、チャットへ出していた通知の仕組みを業務アプリの側へ寄せたとき、常駐のBotと朝夕の配信は役目が無くなり、廃止にできました。台帳の状態を「廃止」に直し、起動の定義は消さずに名前を変えて残します。

通知の側にも効きます。記録も決めごとも台帳にあるので、新しいプログラムを足しても、通知の仕組みを直す必要がありません。通知は1プログラム1日1回まで。毎回鳴らして無視される通知にしない。

台帳は、止まっていないかを見るための道具として作りましたが、使ってみると保守のための道具でもありました。何が在るかを1枚で言えると、減らす判断ができます。

失敗は、AIが直す

「動いていない」を見つける前に、失敗の側は先に自動化してあります。見張りは朝と夕方に全端末の記録を読み、失敗と、時刻表から見て来ていない記録を拾います。拾ったものは、まず機械が1回だけ再実行します。同じプログラムに対して1日1回まで。それで直れば、朝の通知に「直した」とだけ残ります。

再実行で直らなかったものは、手が要る一覧に書き出され、朝にAIが引き取ります。AIは記録の末尾と起動側の記録を読んで原因を分け、直せるものは直して再実行します。一時的な回線の切れ、残った施錠ファイル、設定の明らかな誤り。直せないものは、鍵の失効や別の端末の問題として、人がやる手順に整えて通知に出します。

通知は、チャットではなく自社の業務アプリに入れています。通知には「なぜ知らせているか」が付いていて、アプリが強さを決めます。「直した」の報告は読むだけのものとして静かに置き、人の手が要る「お願い」だけに操作の印を付けます。直っただけの日に「操作が要ります」の印が付くと、本当に手が要るものの数が水増しされるからです。何も無い日は通知を出しません。通知の仕組みそのものは 通知は「なぜ知らせているか」を一緒に出す に書いています。

失敗は記録に残るので、ここまでは台帳が無くてもできます。台帳が要るのは、記録に残らない「動いていない」を同じ流れに乗せるためです。時刻表があるから、来ていない記録を失敗と同じ入口に入れられます。

まとめ

• 「動かなかった」は記録に残らない。台帳の時刻表と突き合わせて初めて分かる
• 待つ時間は台帳から配り、1周期より必ず長く。緩めるときは実測で
• 台帳に載るのは自動。作るときに一緒に書き、知らない記録は自動登録し、実機と毎日突き合わせる
• 台帳を1枚で眺めると、重複と無駄が見える。減らす判断はここから
• 失敗は機械が再実行し、直らなければAIが直す。台帳があると「動いていない」も同じ流れに乗る

台帳を直すのは人で、直し忘れに気づくのは機械です。

取り込みが止まったかを見張る話は 約90本の取り込みを、見に行かずに見張る に。自社の業務アプリの全体は 特設ページ にまとめています。

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。