これで何ができるか
自動化が「エラーを出さずに壊れた」ことを、自分より先に機械に見つけさせます。
自動化を作ると、必ずこの日が来ます。
- 気づいたら3日前のデータがずっと表示されていた
- メールが来なくなっていたが、いつからか分からない
- ページは開くのに、中身が途中で切れていた
どれもエラーメッセージは出ません。処理は緑のチェックマークで「成功」しています。だから気づけません。
上が処理の成否、下が実際に出てくるデータ。処理は全部成功しているのに、出てくるものは止まっています。この状態を捕まえるのが目的です。
この記事では、それを見つけてGitHubのIssueを自動で立てるところまでをAIに作らせます。無料で、45分です。
前提
|
|
| かかる時間 |
45分 |
| 費用 |
無料 |
| 必要なもの |
GitHubアカウント / 監視したいサイトやサービス / ファイルを作れるAI |
| プログラミング |
不要 |
先に 定時実行をAIに作らせる を読んでおいてください。
AIへの頼み方
1. 「正常とは何か」を一緒に決めさせる
ここが一番大事で、一番飛ばされる工程です。いきなり「監視して」と頼むと、ページが開くかどうかだけを見る監視ができます。それでは静かな故障は捕まりません。
私のサイトが正常に更新されているかを、毎日自動でチェックする仕組みを作りたいです。
その前に相談させてください。「正常」を外から測れる形にすると、何を見ればいいと思いますか。
特に知りたいのは、エラーを出さずに更新だけが止まっているケースを捕まえる方法です。ページは開くし処理も成功しているのに、中身が数日前のまま、という状態です。
相談から始めると、たいてい3つに整理されます。
1つ目と2つ目は派手に壊れるので自分でも気づきます。3つ目だけが、気づけない壊れ方を捕まえます。
2. 3つ目を必ず入れさせる
3つとも入れてください。特に3つ目、「ページに書かれている更新日が今日の日付か」を必ず入れてください。
日付は日本時間で比較してください。ページの表示が昨日以前なら異常として報告してください。
「日本時間で」を明示してください。言わないと世界標準時で比較して、毎朝9時間ぶんだけ誤報が出ます。
3. 検知の条件を、見た目に依存させない
更新日を見つける方法ですが、ページのデザインを変えたら壊れる作りにしないでください。
「特定の見た目の中にある日付」ではなく「ページのどこかに書いてある最終更新日」を拾う形にしてください。デザイン変更で検知が壊れると、直すまで警報が鳴り続けます。
実際、トップページの整理をしたときに検知が壊れて、「日付が見つからない」と毎日鳴り始めました。監視は監視対象より壊れやすいので、最初から緩めに作ってもらってください。
4. 通知の形を決めさせる
異常を検知したら、GitHubのIssueを自動で立ててください。
条件:
- 検出した項目は全部まとめて1つのIssueに書いてください（1個直して再実行、の往復を避けたいです）
- すでに同じ内容のIssueが開いているときは、新しく立てずにコメントを足してください
- 正常なときは何も通知しないでください
メールより Issue のほうが「未対応のものが一覧で残る」ので取りこぼしません。同じ通知で埋まらないよう、2日目以降はコメントを足すだけにします。
5. 監視する時刻を指定する
これを間違えると、毎日偽の警報が鳴ります。
チェックする時刻ですが、監視したい処理は朝7時半ごろに動き、遅れたときの再試行が9時前まで続きます。
監視はその後、十分に余裕を取った時刻にしてください。早すぎると、対象が遅れているだけなのに異常と判定してしまいます。
90分以上のバッファを取ります。狼少年になった監視は無視されるようになり、無いのと同じになります。
6. 監視には書き込ませない
この監視は読み取り専用にしてください。異常を見つけても、自分で直そうとしないでください。
権限も、読み取りとIssueを立てることだけに絞ってください。
「ついでに直す」を付けさせないでください。読み取り専用に徹すれば、監視が原因で壊れることが構造的にありえなくなります。自動修復が必要なら、それは別の仕組みとして作ります。
7. 動かす前に、わざと壊して試させる
実行する前に、この監視が本当に異常を検知できるか確かめたいです。
わざと異常な状態を作って（存在しないページを見に行かせる、古い日付を渡す、など）、ちゃんと検知してIssueが立つところまで確認してください。
「検知できるはずです」ではなく、実際に動かして確かめてください。
監視は「鳴らないこと」が正常なので、壊れていても分かりません。作った直後にわざと鳴らしておかないと、いざというとき鳴らない監視を何ヶ月も信じることになります。
うまくいかないときの言い直し方
毎日、異常でもないのに通知が来る
毎日、異常が無いのに警報が鳴ります。過去1週間の検知内容を一覧にして、それぞれ本当に異常だったか分類してください。
そのうえで、誤報の原因と、どう直せば誤報だけ減らせるか案を出してください。いきなり直さず案を見せてください。
誤報を放置しないでください。鳴っても無視するようになった監視は、無いのと同じです。むしろ「監視している」という誤った安心を与えるぶん有害です。
何も鳴らないが、本当に見張れているのか不安
この1ヶ月、一度も警報が鳴っていません。本当に監視が動いているか確認したいです。
直近の実行履歴を見せてください。あわせて、いまわざと異常を起こして、検知されるか試してください。
監視そのものが止まっていた
監視の仕組み自体が止まっていても、私は気づけません。
各自動処理の「最後に成功した時刻」を集めて、しばらく動いていないものを報告する仕組みを、別に作ってください。ただし、その仕組みは極力単純にしてください。
後半が重要です。複雑な監視は、必ず監視対象より先に壊れます。
検知が細かすぎる／大雑把すぎる
いまの判定は厳しすぎます（緩すぎます）。判定の基準値だけを調整したいので、どこを変えればいいか教えてください。他の部分は触らないでください。
応用・次の一手
まず1項目から始めてください。
最小構成で始めたいです。「トップページに書かれている更新日が今日か」だけを毎日チェックする仕組みを作ってください。他は後から足します。
これだけで、静かな故障の大半は捕まります。完璧な監視を設計しようとして作らずに終わるより、雑でも今日動かすほうが100倍マシです。
慣れてきたら、監視対象を「自動化そのもの」に広げます。自動化を増やすほど、この仕組みの価値は上がります。10本の自動化を人間が毎朝目視で確認するのは無理ですが、10本を1本の監視で見るのは簡単だからです。