【ITニュース解説】A third of our releases went out through the emergency path

システムの開発現場では、新しい機能や修正をユーザーに届けるために、ソフトウェアを本番環境に適用する「デプロイ」という作業が日常的に行われている。このデプロイは、システムの安定性や信頼性を保つ上で非常に重要な工程であり、通常は様々な安全策が講じられている。しかし、ある開発チームで、このデプロイプロセスに大きな問題が潜んでいることが明らかになった事例を紹介する。

このチームでは、ある火曜日の夜遅く、午後11時に行われたデプロイによって、ウェブサイトの検索機能が約40分間停止するという事故が発生した。このデプロイは、通常では考えられないような短時間で完了したもので、その理由は「緊急パス」という特別なデプロイ経路が使用されたためだった。緊急パスとは、その名の通り、非常に緊急性の高い状況でのみ使用されることを想定したもので、通常のデプロイプロセスに含まれる多くの安全確認ステップがスキップされる。具体的には、本格的な統合テストや、本番環境に近いステージング環境での長時間の検証（ソークテスト）、そして複数人によるコードの最終確認（レビュー）といった重要な工程が省かれていたのだ。これらのステップがスキップされた状態で本番環境に適用された結果、システムの予期せぬ不具合を引き起こし、検索機能の停止という事態に至ったのである。

この事故をきっかけに、チームは緊急パスの利用状況について詳細な調査を行った。当初は、緊急パスが使用されるのはごく稀なケースだろうと考えていたが、調査結果は衝撃的なものだった。過去90回行われた本番環境へのデプロイのうち、実に31回、つまり全体の約3分の1がこの緊急パスを利用していたのだ。さらに驚くべきことに、これらの31回のデプロイのほとんどは、真に「緊急」と呼べるような状況ではなかった。テストも検証もレビューも行われない、安全対策が極めて不十分な経路が、日常的なデプロイ手段として使われていたのである。

なぜこのような状況が生まれてしまったのだろうか。決してチームメンバーが無謀だったわけではない。問題は、通常のデプロイ経路、つまり「標準パス」にかかる時間に起因していた。標準パスでデプロイを完了させるには、およそ52分が必要だった。このうち、システムの各部分が正しく連携するかを確認する「統合テストスイート」と呼ばれる一連のテストが約34分を占めていた。しかもこのテストは不安定で、およそ5回に1回は途中で失敗し、再実行が必要になることがあった。そのため、標準パスでデプロイを完了させるには、実際のところ1時間15分から、時には2時間もかかることが常態化していたのだ。

一方で、緊急パスはわずか6分でデプロイが完了する。例えば、ウェブサイト上のテキストを少し修正するだけの軽微な変更を営業時間終了間際の午後5時に適用したい場合や、顧客がシステムの問題解決を今か今かと待っているような緊急のバグ修正を行う場合を想像してみてほしい。1時間以上かかる標準パスと、わずか6分で終わる緊急パス。このような状況では、緊急パスを選ぶことは、決して「怠慢」や「手抜き」ではなく、目の前の問題を迅速に解決するための「合理的」な選択となってしまう。さらに、この緊急パスは利用する際の手間が一切なく、利用履歴も記録されなかったため、チームにとって何の抵抗もなく選択できるオプションとして存在していたのである。

この問題の根本原因は、まさしく「利用履歴が記録されなかった」という点にあった。どこにも、緊急パスがどれくらいの頻度で使われているかを数える仕組みがなかったのだ。利用状況に関するレポートもなく、デプロイに緊急パスを使ったことを示すラベルもなく、週ごとの集計も行われていなかった。「誰も測定しない管理は、管理として存在しない。それは単なる選択肢として存在するだけだ」という言葉が示す通り、緊急パスは監視されないがゆえに、その利用が際限なく増えていったのである。

チームはこの状況を改善するために、三つの重要な変更を行った。まず一つ目は、すべてのデプロイに、それが標準パスで実施されたのか、緊急パスで実施されたのかを示すラベルを付けるようにしたことである。そして、その利用状況の割合を毎週チーム全体に共有するようにした。この「可視化」だけでも、他の具体的な対策を何も講じていない最初の2週間で、緊急パスの利用は劇的に減少した。人々は自分たちの行動が可視化されることで、意識的に適切なパスを選択するようになったのだ。

二つ目の変更は、緊急パスの利用に対するハードルを上げるものだった。緊急パスを使用する際には、必ず具体的な理由をテキストで入力することを義務付けた。また、緊急パスでのデプロイが開始されると、チームが利用しているコミュニケーションツール（チャネル）に自動的にその旨が通知されるようにした。これにより、緊急パスが使われたことがチーム全体に周知され、利用者はその理由に責任を持つことになる。さらに、緊急パスでデプロイされた後でも、バックグラウンドでフルテストスイートが実行されるようにし、もしそこでテストが失敗した場合には、自動的に以前の状態にシステムを「ロールバック」（元に戻す）する仕組みも導入された。これにより、緊急パスを利用した場合でも、最終的な安全性が一定程度確保されるようになった。

そして最も重要な三つ目の変更は、問題の根本である「標準パスの遅さ」そのものに取り組んだことだった。チームは2週間を費やして、この真の課題の解決に注力した。まず、統合テストスイートの「並列化」を行った。これは、複数のテストを同時に実行できるようにすることで、テスト全体の実行時間を大幅に短縮する手法である。次に、テストが不安定でしばしば失敗する「フレーク」（flake）なテストを特定し、そのうち特に問題の大きい6つのテストを「隔離」（quarantine）した。これらのテストが、テスト失敗のほぼ全てを占めていたため、これらを一時的に通常のテストスイートから外し、個別に改善に取り組むことで、テスト全体の安定性を向上させた。これらの努力の結果、標準パスの実行時間は、これまでの52分から、驚くべきことにわずか14分にまで短縮されたのだ。

これらの改善策が実行された結果、緊急パスの利用状況は劇的に変化した。今では、過去90回のデプロイの中で緊急パスが使われるのは約2回に過ぎず、そしてその2回は本当に緊急を要するケースであったという。この事例は、「もしあなたの提供する安全な経路が十分に遅ければ、安全ではない経路はもはや例外ではなくなる」という重要な教訓を示している。つまり、人々はシステムの運用プロセスを「回避している」のではなく、そのプロセスが「設計された通りに反応しているだけ」なのである。プロセスの設計者が意図しない使われ方がされている場合、それは多くの場合、そのプロセス自体に改善の余地があることを示していると言えるだろう。