WordPress の保守自動化を設計していると、必ずどこかで「ここまで来たら止めるか、それとも続けるか」の判断点に出くわします。私たちが特に長く悩んだのが、WordPress コア更新で異常が出てロールバックされたあとに、残りのプラグイン更新を続けるべきか・止めるべきかという分岐でした。
最終的に「止める」設計に切り替えたのですが、最初は「続ける」設計を採用していて、運用していくうちにいくつかの落とし穴が見えてきました。その経緯と判断を残しておきます。
3 つのケースを切り分ける
コア更新の結果は、ロールバックの観点で次の 3 パターンに分類できます。
- Case 1: コアロールバック成功 + 復旧確認 OK — RB 後にサイトが正常に戻った
- Case 2: コアロールバック成功 + 復旧確認 NG — RB 自体は走ったが、サイトはまだ壊れている
- Case 3: コアロールバック失敗 — そもそも RB 自体に失敗した
Case 1 は明らかに「続行」、Case 2 と Case 3 は明らかに「異常」ですが、その後どう動くべきかは単純ではありません。
旧設計 — HTTP チェックだけ切って続ける
最初の設計では、Case 2 / Case 3 でも保守処理は止めない方針でした。
_skip_http_check = True # コア異常後は HTTP チェックを止めて続行
# 後続のプラグイン/テーマ/翻訳更新はそのまま走る
ロジックはこうでした：「コアが壊れている状態でプラグインを 1 件更新したら HTTP が 5xx を返すのは当然。なら HTTP チェックを止めれば、誤って関係ないプラグインを巻き戻すことはなくなる」。
実際、これで誤検知は減りました。ただし運用していくと別の問題が見えてきました。
見えてきた 2 つの問題
問題 (a)：壊れた状態で更新が積まれて追跡不能になる
コアが壊れたままプラグイン 20 件を更新すると、ログ上は「20 件すべて成功」と記録されます。サイトは依然として壊れているのに、ログだけ見ると正常に見える。
翌日エージェンシーが「どこから壊れたか」を追跡しようとしても、コア起因か、後続のどれかの更新が引き金か、複合か が判別不能。安全策のつもりが、調査コストを跳ね上げる結果になっていました。
問題 (b)：プラグイン独立障害を検知できなくなる
_skip_http_check = True で HTTP チェックを切ると、コアと関係のないプラグイン側のバグ（メモリリーク・依存関係エラー・PHP バージョン非対応など）も同時に検知できなくなります。
「コアが壊れている期間中だけ HTTP チェックを切る」つもりが、実態は「この期間中の異常はすべて見えない」という状態。安全装置を意図的に外しているのと変わりません。
新設計 — Case 2 / 3 では止める
これらを踏まえて、Case 2 と Case 3 では 後続のプラグイン・テーマ・翻訳更新を一切実行しない ように変更しました。
if _halt_remaining: # Case 2 / 3 のとき True
# step_rollbacks は記録してから早期 return
return
ポイントは「ただ止めるだけではない」設計です：
step_rollbacksの記録は残す — 何が起きたかはログに完全に残る- 外側の visual_check / browser_automation / メール通知は走る — 最終 HTTP 確認とエージェンシーへのアラートは保証される
- 早期 return 後もレポート生成は走る — 「コアが壊れて止めました」というメッセージがクライアント向けレポートにも出る
Case 1（RB 成功 + 復旧 OK）は従来通り続行します。サイトは健全に戻っているので、残りのプラグインを HTTP チェック付きで安全に更新できる前提が成立しているためです。
受け入れたトレードオフ
この設計変更で「コアが壊れた日はその後の更新が一切止まる」ことになりました。スケジューラに乗せていた 20 件のプラグイン更新が、コア 1 件のロールバックで全部次回のメンテナンスまで先送りになる、という挙動です。
短期的には「全部止まるのか、不便だな」と感じる場面もあります。ただ実運用では：
- エージェンシーに「コアを直してください」という明確なシグナルが届く
- 次回のメンテナンスジョブは正常な状態から再開できる
- ログには「halted after core rollback」というはっきりした証跡が残る
の 3 つが、誤検知を抑える代わりに何が起きたか分からなくなるリスクと比べて、運用上は圧倒的に追跡しやすい結果になりました。
教訓 — 安全装置は「働かせる」が前提
「異常時にチェックを切る」設計は、一見賢く見えて、実際には異常を見えなくしてしまうことがあります。チェックを切るより、異常を発見した時点でいったん止めて、エージェンシーに判断を委ねるほうが、運用全体の予測性を保ちやすい。
保守自動化の設計で迷ったときの一つの指針として、「自動で対処しようとせず、人間に明確に伝える」方向に倒すことで救われる場面は意外と多いです。