派遣：それに対する不合理な恐怖

デプロイメントの不安は現実です。デプロイメントに関連する人間の感情を理解し、恐怖を最小限に抑えるためのベストプラクティスを学びましょう。

CrowdStrike に関連する最近の障害により、850 万台の Windows オペレーティング システムに影響が及び、航空会社や病院を含むさまざまなグローバル サービスに混乱が生じました。複数の分析により、このインシデント自体の根本原因が調査されました。

しかし、ソフトウェア エンジニアとして、私たちはデプロイメントに関連する人間の感情、特に本番環境を壊してしまうのではないかという不安という側面を見逃していると思います。この記事では、その点について詳しく掘り下げてみたいと思います。内容は次のとおりです。

• リリースエンジニアリングの機能を理解する。
• ソフトウェア エンジニアが重視することと、重視しないこと。
• 継続的デリバリー (CD) の影響。
• 手動デプロイメントの概要。
• 手動展開の問題とその解決策。

リリースエンジニアリング

ソフトウェア エンジニアの観点からデプロイメントの恐怖について掘り下げる前に、まずリリース エンジニアの役割を理解しましょう。リリース エンジニアリングは、最新の CI および CD ツールと Kubernetes の標準化により、近年大幅に進化しました。これらの進歩にもかかわらず、主な責任は変わりません。

• 一貫性があり、繰り返し可能なデプロイメント:リリース プロセスを標準化することで、本番環境への不適切なデプロイメントのリスクを軽減します。

• サービスの中断の削減: 標準化されたプロセスにより、チームは、リリースによって問題が発生するシナリオに対するロールバック戦略など、有害な本番環境のインシデントに対処する準備も整います。

• パフォーマンスの監視と最適化:より高速で信頼性の高い展開のためにパフォーマンスの改善を探します。

• エンジニアリングとの連携:開発者、QA、DevOps チームと緊密に連携して、すべての新規および既存のサービスに明確に定義されたデプロイメント プロセスがあることを確認します。

ソフトウェアエンジニアが気にすること

リリース エンジニアとは異なり、製品チームで働くソフトウェア エンジニアは、デプロイメントの特定の側面のみに関心がある場合があります。

• 迅速なコードマージ:マージを迅速に行うことで、作業を検証し、新しいタスクに進んだり、依存タスクのブロックを解除したりすることができます。

• 運用インシデント: エンジニアは運用中のすべてのインシデントを気にするわけではありませんが、コードの変更によって運用が停止することについては間違いなく気にします。

• デプロイメント スケジュール: エンジニアは、変更がいつ公開されるか、または公開されたかを追跡して、変更に関するリアルタイムのフィードバックにアクセスできるようにしたいと考えています。

ソフトウェアエンジニアが気にしないこと

私たちが気にかけるものもありますが、気にかけないものもあります。

• 展開方法: 効率的で信頼性の高い展開プロセスの必要性は認識していますが、それがどのように実行されるかは重要ではありません。

• 他の変更の影響: 問題が発生しない限り、他の開発者による無関係な変更については心配しません。

• デプロイメント管理: エンジニアは、ソフトウェア チーム内で誰がデプロイメントを管理するかについては無関心です。たとえば、デプロイメントの管理を任されている場合にのみ、デプロイメントの管理に関心を持ちます。

継続的デプロイメント (CD) の影響

では、その恐怖は継続的デプロイメントとどのような関係があるのでしょうか?

たくさん。

研究により、継続的デプロイメント (CD) の [いくつかの利点](https://dora.dev/capabilities/continuous-delivery/#:~:text=DevOps%20Research%20and%20Assessment%20(DORA,as%20higher%20levels%20of%20availability) が実証されており、当然のことながら、その多くは心理的な性質のものです。継続的デプロイメントでは「人間が関与する」必要がなくなるため、テスト インフラストラクチャに対する強い信頼が必要になります。

言い換えれば、自動テストは、本番環境の信頼性を確保するだけでなく、心理的安全性も提供し、時には非合理的に、デプロイメントに対する不安を軽減します。開発者として、変更を手動で検証するように求められる場合よりも、CD プロセスで変更を加える方が安心です。

しかし、これらの CD 戦略が普及しているにもかかわらず、多くの企業では依然として手動でデプロイメントを開始しており (人間が関与している)、CD 実装に対して慎重なアプローチを取っています。この行動は、チームがリリース プロセスの監視を維持し、必要に応じて介入することを好むことを示しています。

これは心理的安全性の観点から理解することが重要です。手動によるデプロイメントは、誰かがプロセスを監視して、問題が発生した場合に対処していることを意味します。これにより安心感が得られますが、デプロイメントを行う人に恐怖心を抱かせ、人為的ミスが発生しやすくなります。

手動デプロイメント

欠点があるにもかかわらず、ほとんどのチームはデプロイメントを手動で管理しています。一般的な手動デプロイメントには、次のようないくつかの手順が含まれます。

監督

リリースが公開される前に、誰かがデプロイメント プロセス全体を監視します。この人物は、問題の兆候がある場合に介入する役割を担います。チームには、デプロイメントを管理し、問題が発生したときに対処するオンコール担当者がいます。

専用リリースチーム

一部のチームには、リリースがスムーズに進むように専用のリリース エンジニアリング チームがあります。これは高度な専門性を意味するため、展開プロセスはより効率的で信頼性の高いものになります。

スプレッドシート

一部の企業では、変更を検証するためのスプレッドシートを維持しています。これにより、企業はこれらの変更を体系的に確認して承認し、事前に定義された品質基準を満たしていることを確認できます。

手動QA

スプレッドシートに加えて、手動 QA は企業が追加するもう 1 つのレイヤーです。手動 QA は、新しいリリースを本番環境に展開する前にステージング環境でテストします。ただし、テスト環境は完璧ではないため、実際のシナリオの一部は考慮されません。

手動展開ではどこで問題が発生するのでしょうか?

手動によるデプロイメントのみに依存しているソフトウェア開発チームでは、さまざまな問題が発生する可能性があります。

少人数グループへの依存

これによりボトルネックが発生し、場合によってはリリースの遅延や人的エラーにつながる可能性があります。また、この特定の人が退職したり、必要なタスクを実行できなかったりすると、チームに問題が発生する可能性があります。

リスク軽減戦略なし

不利な本番環境のインシデントに対処するための戦略はありません。インシデントが発生すると、リリース チームは、解決と意思決定を支援する関係者を見つけるために奮闘する必要があります。

ヒューマンエラーが発生しやすい

コマンドまたはスクリプトに誤字があるか、展開前または展開後の手順を実行し忘れています。

高い努力

デプロイメントにはプロセスの監視が必要なため、時間のかかる作業になります。また、デプロイメントの頻度も大幅に低下します。たとえば、デプロイメント全体を監視するのに 1 時間かかる場合、リリース チームは、その時間を節約するために、変更が少ない日はデプロイメントをスキップすることを決定する場合があります。

コミュニケーションの崩壊

製品チームからは、リリースの状態や、変更がいつ本番環境に導入されるかは不明です。

これらの課題を見ると、エンジニアがデプロイメントを恐れる理由が簡単に理解できます。デプロイメントの失敗のリスク、高いリスク、ダウンタイムを低く抑えるプレッシャーも、この恐怖感の一因となっています。

これらの失敗は、テストの自動化を増やすことで最小限に抑えることができます。ただし、これらのテストはテスト環境で実行されるため、自動化されたテストですべてのエラーが検出されるとは期待しないでください。失敗は予想されますが、その割合は減少します。

私たちはこれに対して何ができるでしょうか?

継続的デプロイメントをセットアップするだけですか? 言うのは簡単ですが、実行するのは難しいです。欠点はありますが、適切に管理されていれば手動デプロイメントでも問題ありません。目標は次のとおりです。

• 生産上の事故を回避するためのガードレールを提供する
• 人的ミスを減らす
• 誰でもデプロイをトリガーできるようにする
• デプロイメントが頻繁に行われるようにする

ガードレール – カナリアとロールバック

カナリアおよびロールバック戦略は、停止の影響を軽減し、多くの場合、自動的に危機を回避するのに役立ちます。

カナリア リリースでは、新しいリリースが本番環境のトラフィックの一部に公開されます。これにより、チームはテスト中には発生しなかった可能性のある問題についての洞察を得ることができます。

一方、ロールバック戦略は、エンジニアがリリースを以前の安定したバージョンの状態に戻すのに役立ちます。これは、本番環境への展開後に新しい問題が発生した場合に実行されます。

ヒューマンエラーの削減 – 標準化

効率、一貫性、信頼性、および高いソフトウェア品質をもたらす標準的な導入方法論を定義します。DORAは、 DevOps の現状レポートで、信頼性が運用パフォーマンスの向上につながることを示しています。さらに、標準化されたプロセスにより、リリース プロセスの繰り返しが可能になり、自動化できます。このプロセスを自動化すると、チームは生産コストを低く抑えることができます。

導入プロセスの民主化

デプロイメント プロセスを民主化することで、特定の個人への依存がなくなります。ソフトウェア エンジニアなら誰でもデプロイメントできるようにすれば、徐々に恐怖心が軽減されます。「誰でもデプロイメントできるなら、それほど難しいことではありません。」レゴを共有しましょう。

頻繁な展開

デプロイメントの不安を軽減するには、デプロイメントを減らすのではなく、増やす必要があります。DORA レポートでは、バッチ デプロイメントが小規模であれば問題が発生する可能性が低くなり、開発者の心理的障壁が低くなることも強調されています。

開発者エクスペリエンスの向上

何がデプロイされているかを明確にすることで、開発者のエクスペリエンスが向上します。開発者は、デプロイがいつ行われ、どのような変更が含まれているかを簡単に把握できます。この透明性により、開発者は変更がいつ有効になるかを追跡でき、インシデント調査が簡素化されます。

定義されたリスク軽減戦略

ロールバックとホットフィックスでは、実行すべき手順が定義されている必要があります。これにより、運用中のインシデントに関する判断の不確実性が排除されます。たとえば、ロールバックを容易にするために、チームが実行すべきビルド手順とデプロイ手順が別々に用意されている必要があります。

同様に、ホットフィックスやチェリーピックの扱い方を標準化することで、リスクが高い場合でも操作が簡単になります。

機能フラグ

機能フラグは、運用環境でインシデントの原因となった新機能をオフにできるキルスイッチのようなものです。これにより、エンジニアは運用環境でのインシデントを迅速に解決できます。

結論

ソフトウェア チームは、コストのかかるミスを避けるために、製品開発の最初からリリース エンジニアリングを優先事項として扱う必要があります。また、Crowdstrike の障害のようなインシデントによって開発手法が損なわれないようにする必要があります。デプロイメントの不安に対処し、実稼働環境でのインシデントを防ぐには、いくつかの重要な戦略が必要です。

• 展開プロセスの標準化に投資します。
• カナリア リリース、戦略的ロールアウト、ロールバック、ホットフィックスなど、明確に定義されたリスク軽減戦略を設定します。
• デプロイメントを民主化することで開発者エクスペリエンスを簡素化し、誰もが参加できるようにします。

Aviator では、開発者がより速く、より優れたものを構築できるように、開発者生産性ツールを基本原則から構築しています。デプロイメントを管理する最新の方法については、 Aviator Releasesをご覧ください。