自動化が壊れた日のための備え

自動化したものは、いつか必ず壊れる。これは悲観ではなく、前提だと考えている。参照していたファイルの形式が変わる、外部サービスの仕様が更新される、自分が半年前に書いた設定を忘れる。原因はさまざまだが、永久に動き続ける仕組みは存在しない。だから問いは「壊れるかどうか」ではなく、「壊れたとき、どれだけ静かに戻せるか」になる。

手動の経路を捨てない

自動化でいちばん危ういのは、その工程を手でやる方法を忘れてしまうことだ。仕組みが動いている間は問題ない。けれど止まった瞬間、手順を知っているのが「壊れた仕組み」だけだと、復旧は手探りになる。

だから私は、自動化した工程でも、手動でやる場合の手順を短く残すようにしている。完全なマニュアルでなくていい。「この処理は本来、Aを開いてBに貼り、Cを実行するだけ」という骨格があれば、仕組みが止まっても運用そのものは続けられる。小さなスクリプトから始める定型処理の置き換えで紹介した事業者が、並べ替えだけを自動化して転記を手元に残していたのも、結果的にこの保険になっていた。

変更の履歴が復旧を速くする

壊れたとき、最初に知りたいのは「最後に何を変えたか」だ。昨日まで動いていたなら、原因は最近の変更にある可能性が高い。ところが個人の運用では、この変更履歴がいちばん残りにくい。記憶だけが頼りになり、その記憶は当てにならない。

情報処理推進機構（IPA）は、システムの信頼性に関する資料の中で、変更管理と記録の重要性を繰り返し挙げている。大規模システムの話に見えて、これは規模を問わない。設定を変えたら日付と内容を一行書く。それだけで、半年後の自分は原因の切り分けを一段速くできる。

一度だけ、戻す練習をする

もう一つ習慣にしているのは、仕組みを組んだ直後に、わざと止めて戻してみることだ。本番で壊れてから初めて復旧手順を考えるのと、平時に一度試しておくのとでは、慌て方がまるで違う。Google の『Site Reliability Engineering』も、障害を想定した訓練を平時に行う価値を説いている。個人の規模なら、大げさな演習は要らない。スクリプトの参照先を一時的に間違ったパスに変え、エラーに気づけるか、元に戻せるかを確かめるだけでいい。

壊れることを前提にすると、自動化はむしろ気楽になる。完璧に動き続けることを期待しないから、止まっても落胆しない。手動の経路を残し、変更を記録し、平時に一度だけ戻す練習をしておく。どれも仕組みを足すより地味だが、ひとり運用の静けさを底で支えている。次に新しい工程を仕組みに移すときは、動かす設定と同じ熱量で、戻し方も決めておきたい。そうした手順を一冊にまとめる話はひとり運用を支える「手順書」のつくり方へ続く。