概要
自分用の記事の自動投稿が動いていない気がして、調べました。
自動化の監視で0件を異常と読んでしまう人へ。状態と履歴を切り分ける確認順を紹介します。
ダッシュボードには赤が3つ並んでいます。
- 予約キューが0/10
- 失敗マーカーあり
- 健全性チェッカーが異常終了
実測すると、3つは同じ種類の情報ではありませんでした。
予約キューの0/10は「出ていない」ではなく「もう出た」状態でした。送信済みAPIを確認すると、その日の枠で実際に送信されていました。
失敗マーカーの最終行は6日前で、その8分後のコミットで既に直っていました。これは直る前の履歴が残っていたものです。
一方、健全性チェッカーは、自己参照による偽陽性が現在も続く構造でした。列挙対象に自分自身が含まれ、自分の異常終了コードを良性リストに入れていないためです。
そして、本当に壊れていたのは、赤が付いていないところでした。
状態と履歴を分ける前提
この記事では、いまの状態と、過去に起きた出来事を分けて考えます。
- 状態：いまの値
- 履歴：過去に起きた出来事の記録
今回、予約キューの0/10、失敗マーカー、健全性チェッカーの異常終了を、いま起きている異常として読んでいました。
しかし、実測すると、それぞれ別の情報を示していました。
落とし穴1：「0件」は「無い」と「終わった」の両方を意味する
予約キューの表示は 0/10 でした。
これを「一度も出ていない」と読んでしまいます。
送信済みAPIを確認したところ、その日の枠は実際に送信されていました。
予約キューは送信すると空になります。つまり、次の2つが同じ0になります。
- 成功した直後
- 一度も動いていない状態
残数だけでは、「もう出た」と「一度も動いていない」を区別できません。
0件
├─ 成功した直後
└─ 一度も動いていない状態
今回、区別できたのは、送信済みAPIを確認したからでした。
落とし穴2：追記式の失敗マーカーは、状態ではなく履歴
失敗マーカーのファイルがありました。
最終行の日付は、6日前でした。
しかも、その8分後のコミットで既に直っていたと確認できました。
マーカーは追記式です。直っても消えません。
そのため、ファイルが存在することだけでは、いまも壊れているとは判断できません。
調べ物をするときは「その情報源はいまも生きているか＝最終更新日を挙げる」を自分のルールにしていました。
それなのに、最終更新日を見ず、生きた故障として作業計画に書きました。
規約は、読む場所に置いてあっても、読む習慣がなければ効きません。
落とし穴3：監視器を監視対象に含めると、自分の警報で自分を鳴らし続ける
3つ目の赤は、健全性チェッカー自身の異常終了でした。
このチェッカーは、「予定どおり動いていないタスク」を列挙する作りです。
問題は2つ重なっていました。
- 判定対象に自分自身が入っていた
- 自分の異常終了コードを良性リストに入れていなかった
自己参照を除外する条件は、次のように書けます。
const targets = tasks.filter(
task => task.role !== "健全性チェッカー"
); // 監視器自身を数えると、自己参照の偽陽性が継続する
こうなると、
- 1件でも異常が出る
- 自分が異常終了する
- 次回、自分の異常終了を異常として数える
- また自分が異常終了する
という自己参照ラッチになります。
図解：0件を読む確認順
0件・赤い表示を見る
│
▼
現在の状態か、過去の履歴か
│
┌────┴────┐
▼ ▼
送信済みAPI 最終更新日
を確認 を確認
│ │
└────┬────┘
▼
監視器自身が判定対象に
含まれていないか確認
│
▼
赤がない処理のログや再試行の状況も確認
0件を見たときの確認
今回の確認で分かったのは、予約キューの0/10だけでは、送信済みか未実行かを判断できないということです。
最初に、送信済みAPIを見ます。
その次に、失敗マーカーの最終行の日付を点検します。過去の記録が残っている場合、その後に修正が入っているかも確認です。
最後は、健全性チェッカーの判定対象に自分自身が含まれていないかを確認します。自分の異常終了コードが良性リストに含まれているかも見ます。
本当に壊れていたのは、赤が付いていないところだった
本当に壊れていたのは、朝に走る2本でログを取っていないことでした。
失敗の理由は標準エラーにしか出ず、再試行設定も0でした。
その朝の失敗は、1時間後に手で走らせて黙って埋められていました。
失敗しても画面には何も表示されません。
赤にすらなりません。
手作業の後追いは、故障を直さずに故障の症状だけ消します。
自動化が失敗しても人が埋めるので、外から見ると健全に見えます。
状態と履歴を分けて読む
今回の3つは、いずれも、その値だけではいま壊れているか判断できないものを赤として読んだことが原因でした。
| 見ていたもの | 実際に分かったこと |
|---|---|
| 予約キューの0/10 | その日の枠は送信済みAPIで送信済みだった |
| 失敗マーカー | 最終行は6日前で、その8分後のコミットで既に直っていた |
| 健全性チェッカーの異常終了 | 自分自身を対象に含め、自分の異常終了を数え続ける構造だった |
そして、本当に壊れていたのは、ログがなく何も表示されない処理でした。
監視画面を見るときは、赤い表示だけでなく、何も表示されていない処理も確認する必要があります。
今回の誤読は訂正済みで、確認された2つの欠陥については修正を委譲済みです。
同じところで詰まっている人の役に立てばうれしいです。