独占記事：本番環境への導入を予定している変更が壊滅的な失敗に終わった場合、爆発範囲はどれほど大きくなるのでしょうか？Overmindは、爆発が起こる前にそれを防ぐ方法を考案した最新の企業です。
CEO の Dylan Ratcliffe 氏は「爆発半径」という言葉に熱心だ。これは、デプロイメントが計画通りに進まなかった後に暗い表情でダッシュボードを眺めるエンジニアにとっては、あまりにも馴染み深い言葉だろう。
ディラン・ラットクリフ（写真：オーバーマインド）
Overmind は、変更が環境にどのような影響を与えるかを予測し、特定の更新がどの程度リスクを伴う可能性があるかを正確に示すことを目的としています。
同社はRenegade Partnersが主導するシードラウンドで600万ドルを調達したばかりだ。一部のAI企業が調達した巨額ではないものの、それでもかなりの額だ。
... 現在では、多くのお客様にとって必須の段階まで到達しています。そのため、分析が完了し、出力結果に対応するまで、本番環境へのデプロイは許可されません。
変更やデプロイメントの影響を予測するのは厄介な問題です。可観測性の世界には、何か問題が発生したときに警告を発するツールが数多く存在しますが、事前に予測するのは容易ではありません。多くのエンジニアは、物事が軌道から外れたときの、あの沈んだ気持ち（おそらくそれと同じくらいひどい）を経験したことがあるでしょう。誰も責任を取って開始しようとしないレビュー会議で、身動きが取れなくなった経験があるでしょう。
最近、エンジニアは、コードの作成だけでなく、「何が問題になる可能性があるのか？」という問いかけにおいても、AI ツールに大きく依存するようになりました。
ラトクリフ氏はOvermindのアプローチを次のように説明する。「Terraformの変更をそのまま受け取って、何が起こるかを推測するのではなく（AIを使えば簡単にできますが、AIはあらゆる結果を推測し、あまり役に立たない出力を生成します）、私たちが行っているのは、実際の本番環境インフラに、変更内容をリアルタイムで重ね合わせることです。」
変更影響分析の分野では、Overmindだけが企業ではありません。例えば、Puppetは顧客向けに影響分析ツールを販売しています。Overmindのアプローチは、個人または企業のCI/CDパイプラインに組み込むことです。
「私たちは Terraform と AWS だけを使って作業を開始しました」と Ratcliffe 氏はThe Register に語ります。「そして、このアプローチをある程度検証し、それが実際に機能し、正確であるだけでなく、人の行動を変えるほど説得力のある予測を生成できることを確認できました。」
「例えば、プルリクエストに『何かが壊れるよ』というコメントを残しても、それがあまりにも漠然としていて、実際に変更することはない、つまりボタンを押すのをやめないだろうということは役に立ちません。」
「そのため、私たちはこれに取り組んできました。そして今や、多くのお客様にとって必須の段階にまで到達しました。そのため、この分析が完了し、出力結果に対処するまでは、本番環境に展開することはできません。」
どれも素晴らしいように聞こえますが、ラットクリフ氏は、組織によってワークフローが必ずしも同じというわけではないと指摘します。「本番環境へのデプロイのワークフローが全く同じ人は二人といません。これは非常に個人的な問題です。ただ『やり方が間違っています』と指摘するだけでは済まないでしょう。なぜなら、彼らは長年かけて学び、苦労してきたからです！」
ラトクリフ氏は、導入や変更分析に関する標準的な運用手順を既に確立している企業に対し、物事の進め方を強制するのではなく、ワークフローに適応させるというモデルを拡張しています。「適応させる必要があります」と彼は言います。「標準運用手順（SOP）を変更してもらうことは期待できません。」
AIアシスタントの話題に戻ると、エンジニアがこの技術を利用して、一見完璧に見えるインフラコードを生成し、それが壊滅的な結果をもたらすリスクが高まっています。ラトクリフ氏は、ある顧客について、開発者がCopilotを使って素晴らしいTerraformコードを作成しているものの、「変更がもたらす影響を理解していない」と語っています。
- HashiCorpがIBM傘下の生活への適応について語る
- IBMはHashicorpを気に入り、ついに64億ドルの契約を締結
- HashiCorpは、部屋の中の大きな青い象をそっと避けながら、「Terraform 2.0」を発表した
- OpenTofuがバージョン1.8に登場、より多くのユーザーを喜ばせる機能を搭載
「つまり、彼らが非常に大きな影響範囲を持つ変更を提案した場合、彼らは変更を提案することを阻止しようとしているのではなく、実際にボタンをクリックして変更を適用することを阻止しようとしているのです。」
「つまり、この場合、Overmind は、自分の行動が及ぼす影響を理解していない開発者のための学習ツールのようなものです。」
理論的には、エンジニアはミスを犯すことは許されるべきだが、そのミスが生産に近づく前に、次回のためにそこから学ぶべきだということになる。
ラトクリフ氏は将来、AIアシスタントの領域をさらに深く掘り下げ、何が問題になるかを考慮したスクリプトを生成したいと考えています。「アシスタントがTerraformコードを作成している間に、実際のデータを使ってそれらの質問に答えられるようになります。」
とはいえ、ラットクリフ氏は、Overmindのようなツールを開発上の欠点を覆い隠すための応急処置として使うべきではないとも認めている。「これは、サービスの信頼性を高めるための設計に代わるものではありません」と彼は言う。「自動テストに代わるものでもありません。」
しかし、本番環境の正確なレプリカで徹底的な詳細テストを行うことが現実的ではない、あるいは不可能な場合には、非常に有用なツールとなります。ラトクリフ氏は、テスト環境が本番環境と大きく異なる極端な例として、NASAのボイジャー探査機を挙げています。
「テストはラックに積まれたボイジャーのようなもので、ビット反転は一切ありません。宇宙線に晒されることもありません。一方、本番環境では…」
違う。
「これは、生産は常に予想以上に困難であり、生産を再現することはできないということを示しています。」
「何かが何をするかを計画する場合でも、生産がどのようになるべきかではなく、現時点でどのようになっているかを考慮する必要があります。」®
