デプロイプロセスにテンプレートとチェックリストが必要な理由（必要ないと思っていても）
デプロイが始まろうとしている。チームのチャットで誰かが尋ねる。「マイグレーションの前にデータベースのバックアップは取った？」沈黙が流れる。さらに別の質問。「ステージング環境の設定は確認した？」さらに沈黙。結局誰かがマイグレーションを実行し、うまくいくことを祈りながら、何も壊れないことを願う。
この光景は、毎日のようにエンジニアリングチームの間で繰り返されている。チームが未熟だからではない。プレッシャーがかかっている状況で、人間の脳が20から30の手順を正確に覚えておくのが苦手だからだ。締め切りに追われていたり、本番障害に対応しているときに、忘れがちな手順こそが、しばしば障害の原因となる。
本当の問題は知識ではなく、記憶である
ほとんどのチームは、デプロイ中に何をすべきかを知っている。シニアエンジニアは何十回も実行してきた。DevOps担当者は手順を暗記している。しかし、誰かの頭の中にある知識は脆い。その人が休暇中かもしれない。別の障害に気を取られているかもしれない。単に調子が悪い日かもしれない。
問題は、人が知らないことではない。問題は、チーム全体が一貫して従える形で、誰もそれを書き留めていないことだ。チームメンバーがそれぞれ独自のメンタルチェックリストを持っていると、プロセスは予測不可能になる。ある人は必ずデプロイ後に監視ダッシュボードを確認する。別の人はいつも忘れる。結果として、うまくいく時もあれば、失敗する時もある、明確なパターンのないプロセスが出来上がる。
テンプレートは再現可能な出発点を提供する
デプロイテンプレートとは、特定の種類の変更に対する、あらかじめ定義された一連の手順のことだ。「この変更を本番に安全に反映するために、何を、どの順序で行う必要があるか？」という問いに答えるものだ。
テンプレートがあれば、毎回プロセスをゼロから考え直す必要がなくなる。アプリケーションデプロイの場合、テンプレートには以下が含まれるかもしれない。
- ビルドアーティファクトが意図したバージョンと一致することを確認する
- 必要に応じてデータベースマイグレーションを実行する
- 環境固有の設定を更新する
- まずカナリーまたはステージング環境にデプロイする
- デプロイされたバージョンに対してスモークテストを実行する
- 本番インスタンスに段階的にロールアウトする
- デプロイ後の監視とアラートを確認する
テンプレートは固定されたものではない。デプロイにはそれぞれ固有のコンテキストがある。今回はデータベースマイグレーションがないかもしれない。変更が小さすぎてカナリーデプロイが不要かもしれない。テンプレートはデフォルトのパスを提供し、そこから調整する。重要なのは、毎回ゼロから構築するのではなく、既知の構造から始めることだ。
変更の種類が異なれば、異なるテンプレートが必要になる。データベースマイグレーションテンプレートは、アプリケーションデプロイテンプレートとは異なる。インフラストラクチャ変更テンプレートは、シークレットローテーションテンプレートとは異なる。各テンプレートは、その種類の作業に関連する具体的な手順とリスクを捉えている。
チェックリストはテンプレートが見逃すものを捕捉する
テンプレートは何をすべきかを教えてくれる。チェックリストは、実際にそれを実行したことを確認する。プロセスの上に重なる検証レイヤーだ。
チェックリストは、特にルーチン作業のように感じられる場合に、スキップしやすい手順に対して有効だ。マイグレーションの前にバックアップを取ったか？最初にドライランモードでマイグレーションを実行したか？ロールバックが必要な場合に、古いバージョンがまだトラフィックを処理できることを確認したか？デプロイ完了から5分後のエラーレートを確認したか？
チェックリストがなければ、これらの手順は完全に記憶に依存する。チェックリストがあれば、それらは明示的な検証ポイントになる。誰かが各項目を確認し、完了したことを確認しなければならない。これにより、プロセスは「やったと思う」から「すべて完了したことを確認できる」へと移行する。
一貫性がトラブルシューティングを容易にする
すべてのデプロイが同じパターンに従うと、チームは共有されたメンタルモデルを構築する。何か問題が発生した場合、チームの誰でもデプロイログを見て何が起こったかを理解できる。エラーが発生したときにどの手順が実行されていたかがわかる。デプロイ前に何が確認され、デプロイ後に何が検証されたかがわかる。
この一貫性は、オンコールローテーションにおいて特に価値がある。エンジニアが午前3時に起きてデプロイの問題に対処する場合、この特定のデプロイがどのように構成されているかを推測する必要があってはならない。テンプレートとチェックリストにより、たとえエンジニアが当初の計画に関与していなくても、プロセスが馴染み深いものになる。
新しいチームメンバーにとって、テンプレートとチェックリストは、実際に使われるドキュメントとして機能する。シニアエンジニアに何週間も付き添う代わりに、テンプレートを学習し、期待されるフローを理解し、より早く貢献し始めることができる。知識はプロセスに取り込まれ、誰かの頭の中に閉じ込められない。
監査とコンプライアンスは副次的な利点
組織が規制要件や内部コンプライアンス基準を満たす必要がある場合、テンプレートとチェックリストは証拠となる。署名済みのチェックリストや記録されたテンプレートの実行は、チームが要求された手順に従ったことを示す。「すべて適切に実行された」という口頭での声明よりもはるかに信頼性が高い。
しかし、コンプライアンスが必要ない場合でも、監査証跡はインシデント後のレビューに役立つ。何か問題が発生した場合、チェックリストを振り返り、何が検証され、何が見逃されたかを正確に確認できる。これにより、「プロセスの失敗」という曖昧な議論が、どの特定の手順を改善すべきかという具体的な会話に変わる。
テンプレートとチェックリストを生きた状態に保つ
決して変更されないテンプレートやチェックリストは、徐々に時代遅れになっているものである。チームは定期的にデプロイドキュメントを見直すべきだ。インシデントのたびに、「チェックリストにこれを捕捉すべき手順があったか？もしなければ、何を追加すべきか？」と問いかける。
同様に、手順が自動化されたら、チェックリストから削除する。CIパイプラインがすでにデータベースマイグレーションを自動実行しているなら、手動のチェックリスト項目は必要ない。目標は最も長いチェックリストを持つことではない。目標は最も正確なチェックリストを持つことだ。
実用的なデプロイチェックリスト
以下は、ほとんどのアプリケーションデプロイに適用できる最小限のチェックリストだ。チームのコンテキストに合わせて調整すること。
- ビルドアーティファクトのバージョンが確認されている
- データベースマイグレーションスクリプトがレビューおよびテストされている
- マイグレーション前にデータベースのバックアップが取られている
- ドライランマイグレーションがエラーなく完了した
- ターゲット環境の設定値が検証されている
- カナリーまたはステージングデプロイがスモークテストに合格した
- 本番デプロイが段階的にロールアウトされている
- デプロイ5分後のエラーレートとレイテンシが正常である
- ロールバック計画が準備され、テストされている
まとめ
テンプレートとチェックリストは、官僚的なオーバーヘッドではない。それらは、運に頼るデプロイプロセスと、構造に頼るデプロイプロセスとの違いだ。最も一般的なデプロイタイプに対して、1つのテンプレートから始めよう。手順を順番に書き出す。重要な検証ポイントのチェックリストを追加する。インシデントのたびに見直す。チームの経験とともに進化させよう。目標は初日から完璧であることではない。目標は、記憶に頼るのをやめ、チームの誰もが従えるプロセスに頼ることだ。