リリースの前夜に手順書を読み返している。当日は業務が終わるのを待って、夜に作業を始める。何人かが待機していて、問題が出たら連絡が飛ぶ。終わったあとも数日は落ち着かない。引き継いだシステムを運用していると、この形に行き着くことがあります。
緊張の原因は、リリースが難しいことではありません。失敗したときに元へ戻せないことです。戻せるなら、多少の失敗は起きても構わない。順番を変えて、戻す仕組みを先に作ります。
いま戻せるのか確かめる
最初にやるのは、直前のリリースを取り上げて、それを取り消す手順を書き出すことです。頭の中で追うのではなく、実際に打つコマンドと触るファイルまで書きます。
ここで止まる箇所が出ます。アプリケーションのコードは前のバージョンに戻せるが、その間に走ったバッチが書き換えたデータは戻らない。設定ファイルをサーバー上で直接編集していて、変更前の内容が残っていない。ライブラリを上げたときに一緒に入った依存が、どれだったか分からない。
止まった箇所が、いま抱えているリスクの一覧です。全部を解決する必要はありません。書き出した時点で、次にどこへ手を入れるかが決まります。
コードと設定を戻せる形にする
コードを戻すのは、比較的簡単な部類です。デプロイのたびに、前のバージョンをサーバー上に残しておく。新しいものへの切り替えは、参照先を差し替えるだけにする。この形にすると、戻す操作は参照先を元に向け直すだけになります。
手間がかかるのは設定のほうです。サーバーに入って直接書き換えた設定は、変更の履歴がどこにも残りません。まず、いま動いているサーバーの設定ファイルを丸ごとリポジトリに取り込みます。差分が出たら、その差分こそが誰も把握していない変更です。取り込んだあとは、サーバー上で直接編集するのをやめます。
つまずくのは、設定に本番の接続情報や鍵が混ざっているときです。これらは分けて扱う必要があるので、リポジトリに入れる前に切り出します。ここを面倒がって全部そのまま入れてしまう事故が起きやすい場所です。
データベースの変更を分ける
戻せなくなる原因の大半はここにあります。コードは戻せてもテーブルの構造が新しいままだと、古いコードが動きません。
対処は、構造の変更とコードのリリースを同じ日にやらないことです。列を追加するなら、先に追加だけをして、その状態で古いコードが問題なく動くことを確かめる。新しいコードはその次のリリースで出す。列を削除するときは逆で、先にコードから参照を外して、しばらく動かしてから削除します。
この進め方だと、リリースの回数は増えます。一度で済ませたい気持ちになりますが、まとめた回のリリースが、戻せない回になります。
データそのものを書き換える処理は、さらに慎重に扱います。更新前の値をどこかに残さずに一括更新をかけると、取り消す方法がなくなります。件数が少ないうちは、更新対象を別テーブルに退避してから実行します。
切り戻しを練習する
手順を書いただけでは、戻せる状態になったとは言えません。書いた手順は、たいてい途中で足りなくなります。
本番と同じ構成の環境を用意して、実際にリリースしてから戻します。障害が起きていない平常時にやります。このとき、手順書を書いた人ではない人に操作させます。書いた人は書いていない前提を頭に持っているので、手順の穴に気づきません。
練習すると、時間が分かります。戻すのに40分かかると分かっていれば、リリースの判断は変わります。夜間作業の終了時刻から逆算して、何時までに問題が出なければ完了と見なすかを決められる。この時刻を先に決めておくと、当日に迷いません。
練習の頻度は、半年に一度でも効果があります。人が入れ替わったあとは必ずやります。
外部連携があるときの限界
自分たちのシステムの中で完結する処理は、ここまでの方法で戻せます。戻せないものもあります。
他社のAPIに送信した内容、送ってしまったメール、相手先のサーバーに置いたファイル。これらは取り消せません。リリースで影響する範囲にこうした処理が含まれるなら、戻せる前提では設計できません。作業中は該当の処理を停止しておいて、動作を確認してから再開する形にします。
停止できるように作られていない場合は、それを先に直します。外部への送信を一時的に止める仕組みは、切り戻し以外の場面でも使います。
この段階でやらなくていいこと
戻せる状態を作る話をすると、自動化の仕組みを整える方向に進みがちです。順番としては後です。
手動の手順が確実に動くことを先に確かめます。手順が固まっていない段階で自動化すると、動かなくなったときに中で何が起きているか分からなくなります。三回か四回、手で実行して同じ結果になることを見てから、自動化を考えます。
テストを整えるのも、切り戻しができるようになったあとで構いません。順序が逆になると、テストを書いている数か月の間、リリースは相変わらず戻せないままです。
どこから手を付けるか判断できないときは、直前のリリースを取り消す手順を書くところに戻ります。書けない箇所が見つかれば、そこが最初の作業です。全体の計画を立てる前に、一つ戻せるようにするほうが早く進みます。
