全9回にわたって構築してきた保守自動化システム。その真髄は、実は「日々の運用フェーズ」にあります。 新しくクライアントが増えた時、手元にあるAIのルールブック（maintenance_rule.txt）を読み込ませ、以下 […]

自動化が回り始めると、今度は「エラーの誤報」という新たな悩みが生まれました。 例えば、大規模なサイトを tar コマンドでバックアップしている最中にアクセスがあると、「ファイルが変更されました（終了コード1）」という警告 […]

Hubサーバーから別のサーバーにログインしてバックアップを実行するには、SSH接続の自動化が必須です。しかし、ここでインフラ特有の壁に何度もぶつかりました。 ポートの罠: サーバーのSSHは標準の 22 ではなく 100 […]

システムが進化していく中で、最後に立ちはだかったのが「ローカル開発環境（Mac）と、実際に動いている本番サーバー間のコードの乖離（差分）」という、開発者なら誰もが一度は胃を痛める問題でした。 過去の緊急対応などで本番サー […]

個別のサイト改修が終わった後は、いよいよ全自動バックアップの要となる「Hubサーバー」の構築です。1つのサーバーを司令塔とし、シェルスクリプト（run-all.sh）をCronで毎月自動実行させる仕組みを作りました。 こ […]

容量対策を終えたことで、次の課題が見えてきました。それは「バックアップの実行頻度と、障害検知のスピード感のバランス」です。 7.7GBもある大容量サイトのバックアップ（圧縮処理）を毎日動かすのは、サーバーに不要な負荷をか […]

保守の自動化を進める中で、厄介なイレギュラーケースに遭遇しました。「1つのドメインの中に、法人向け（/wp/）と個人向け（/sub/）の2つのWordPressが別々にインストールされている」という特殊な環境です。 これ […]

全自動バックアップシステムが稼働し始め、順風満帆に見えた矢先、定期報告のメールを見て顔が青ざめました。ある特定のクライアントサイトのバックアップファイルが、1回あたり「7.7GB」という規格外の巨体で生成されていたのです […]

PHPの対応が終われば、次はCMS本体のアップデートです。管理下にあるサイトの中には、数年間放置され「WordPress 5.x系」のままになっているレガシーな環境もありました。 これをいきなり最新版（6.x系）に上げる […]