この記事のポイント
- 同じ公開の失敗が1日に2回起き、4回やり直しても通らなかった
- 海外の自動化から本番への経路が弱点と見て、届ける作業を手元に戻した
- 何のために動くか説明できない仕組みは、止める前に担う仕事を探す
Q. 長年動いている自動の仕組みを止める前に、何を確認すべき?
A. その仕組みが黙って担っている別の仕事がないかを確認してください。弊社では毎朝の定期実行を外そうとして、予約投稿を本番に反映する役目を担っていたと気づきました。外していれば、予約した記事は指定日になっても公開されず、エラーも出なかったはずです。
長年使っている機械や仕組みを、そろそろ整理しようと思ったことはありませんか。
「これ、何のために動いているんだっけ」と誰も正確には説明できないまま、なんとなく残っている設備。触らないほうが安全な気がして、そのままにしていることも多いと思います。
弊社にも、まさにそういう仕組みがありました。整理しようとして、危うく事故になるところでした。
もう一つのサイトで、同じ失敗が起きた
少し前、このコラムで自動公開が止まった日、自分のPCから公開した話を書きました。あのときは一回限りの応急処置でした。
今回はその続きです。別のサイトで、同じ種類の失敗が1日に2回起きました。原稿の準備と事前確認はどちらも成功しているのに、最後の「本番へ送り届ける」一歩手前だけが失敗する。海外で動く自動化の仕組みから、契約しているサーバーへの接続が断続的に切れていました。4回やり直しても、4回とも通りません。
1回だけなら「運が悪かった」で済んだかもしれません。ですが思い出すと、6月に経験したもう一つのサイトの障害も、まったく同じ経路で起きていました。**2つの独立したサイトで、同じ経路が、同じように壊れる。**個別の障害ではなく、エコシステム全体が抱える構造的な弱点だと考え直しました。
「その場しのぎ」と「仕組みの問題」は別のこと
同じ出来事が2回目に起きたとき、多くの場面で似た問いが立ちます。もう一度直すか、仕組みごと見直すかです。
| よくある場面 | その場しのぎ | 仕組みの問題として見る |
|---|---|---|
| 同じ機械が2拠点で同じ壊れ方をする | その都度、修理して終わる | 型そのものに欠陥があると疑う |
| 同じミスを別の担当者もしてしまう | 「気をつけて」で終わる | 手順自体を見直す |
| 同じクレームが別の店舗からも届く | 個別に謝罪して終わる | 商品や仕組みの共通原因を疑う |
1回は偶然でも、2回は構造です。弊社が踏んだのも、まさにこの分かれ道でした。
経路を変えて、4サイトを1つの手順にまとめた
4回のリトライが全滅した時点で判断しました。「もっと粘り強く」ではなく「別の道を使う」。
6月の一件で分かっていたのは、海外の自動化からは詰まりやすいが、国内の手元のパソコンからなら安定して繋がるという事実です。1サイトの応急処置だった手法を、4サイト全部の標準手順に格上げしました。
自社で運営している4つのサイトの公開手順を、1つの共通の手順にまとめました。海外の自動化は完全になくさず、**役割を変えています。**原稿の準備と事前確認までは今まで通り自動、その先の「本番に反映する」作業だけを手元のパソコンからの作業に切り替えました。品質のチェックは自動、届ける作業は手動という分業です。
手動に戻す代わりに、歯止めを作った
ここで気をつけたのは、「自動をやめる=丁寧さも手放す」にしないことでした。公開作業そのものに、送る前の確認を何段か組み込みました。おかしな状態なら、実行せずにその場で止まります。前回から中身が変わっていなければ何もしない、という決まりもその一つです。
とくに本番を丸ごと消す事故につながる状態を止める部分は、6月の同期の仕組み(元に無いものは向こうからも消える)に対する保険です。急いでいる時ほど外してはいけない、というのが6月の教訓でした。
外す直前に見つかった「隠れた仕事」
海外の自動化を役割変更するにあたり、4サイトのうち1サイトには「毎朝自動で動く」設定がありました。てっきり、外しても問題のない設定だと思っていました。
作業を任せていたAIエージェントの引き継ぎメモに、一文がありました。「機能面で見落とされやすい点なので、特にご確認ください」
読んで、はっとしました。そのサイトには、日付が変わった瞬間に公開される予約投稿があります。その「予約分を本番に反映する」役目を、まさにこの毎朝の定期実行が黙って担っていたのです。
もしそのまま外していたら、予約していた記事は指定日になっても永遠に公開されません。エラーも出ません。誰かが気づくまで、誰にも分からない障害になっていたはずです。
「変更なしならスキップ」という決まりとも衝突していました。原稿に変更が無くても、日付が変わっただけで公開対象が増えるサイトがあるからです。そこで「日付に依存するサイト」という区分を1つ足しました。該当する1サイトだけは変更が無くても毎回組み立て直して送り、他の3サイトは従来どおりのルールのままにしました。
学びと、次にやること
**トラブルは「どの段階で止まったか」を見る。**準備と事前確認が通っていて、最後の一歩前だけが落ちるなら、疑うべきはコードではなく経路や権限です。
仕組みを外す時は、その仕組みが黙って担っていた仕事を探す。「ただの定期実行」に見えたものが、実は別の役目を持っていました。名目と実体がズレている仕組みは、思っている以上によくあります。
**AIエージェントの引き継ぎメモは、必ず読む。**今回の落とし穴は、AIが書き残してくれた一文で気づけました。忙しい時ほど流し読みしがちですが、任せきりにせず、報告には目を通すことが大切です。
数日のうちに、この手順を毎朝自動で起動する設定も整いました。海外の自動化は品質保証に専念し、本番へ届けるのは安定した経路から、しかも毎朝決まって動く――応急処置が、標準の運用に育った形です。
もし社内に「毎日動いているけれど、何のために動いているか誰も正確には説明できない仕組み」があれば、止める前に一度、立ち止まって確認してみることをお勧めします。名目と実体がズレている仕組みほど、外した後に静かに困ることになります。
関連コラム
- 自動デプロイが止まった日、最後は自分の PC から公開した コラムを公開しようとしたら、海外の自動デプロイがサーバーにつながらず失敗が続きました。原因を切り分けて、国内の自分のPCから手動で公開しました。自動化の隣に、自分で出せる経路を残しています。
- 壊れたメールを、担当者がボタン1つで全員に送れるようにする直前でした お客様へのお礼メールを、担当者が画面から送れるようにする。その画面を作る前に中身を開けたら、宛名が全員「事務局 様」になっていました。使いやすい画面は、正しさも誤りも同じ強さで広げます。画面より先に中身を直し、承認者の代わりに仕組みを置いた話。
- あと数日遅かったら、社員名簿が消えていました 「返事が来ない」を「問題なし」と受け取っていませんか。社内の自動処理に同じ思い違いが仕込まれていて、通信エラー1回で社員名簿が初期状態に戻る一歩手前でした。事故が起きる前に見つけた話です。