安全なデプロイ プラクティス

リリースが期待に応えられない場合もあります。 ベスト プラクティスを使用し、すべての品質ゲートを通過したにもかかわらず、運用環境の展開でユーザーに予期せぬ問題を引き起こす問題が発生することがあります。 これらの問題の影響を最小限に抑え、軽減するために、DevOps チームは、特定のリリースの公開と実績のあるパフォーマンスのバランスをとる漸進的公開戦略を採用することが推奨されます。 リリースが運用環境で実証されると、全員が使用するまで、より幅広い層のユーザーがリリースを利用できるようになります。 チームは、本番環境でのリリースの品質と速度を最大化するために、安全な展開方法を使用できます。

顧客への露出を制御する

DevOps チームは、さまざまな方法を採用して、顧客への更新の公開を制御できます。 歴史的に、A/B テストは、さまざまなバージョンのサービスやユーザー インターフェイスが目標目標に対してどのように機能するかを確認したいチームにとって一般的な選択肢でした。 また、A/B テストは、通常、変更が小規模であり、サービスの顧客側のエッジで異なるリリースを比較するだけであることが多いため、比較的簡単に使用できます。

リングを介した安全な導入

プラットフォームが成長するにつれて、インフラストラクチャの規模と視聴者のニーズも拡大する傾向があります。 これにより、新しい導入に伴うリスクと、それが約束する更新の利点とのバランスをとる導入モデルに対する需要が生まれます。 一般的な考え方は、特定のリリースは、リスクに対する許容度が最も高い少数のユーザー グループにのみ最初に公開されるべきであるということです。 その後、リリースが期待どおりに機能すれば、より幅広いユーザー グループに公開できるようになります。 問題がなければ、プロセスは、全員が新しいリリースを使用するまで、より広範なユーザー グループ、つまりリングを通じて続行できます。 GitHub Actions> や Azure Pipelines などの最新の継続的デリバリー プラットフォームを使用すると、あらゆる規模の DevOps チームがリングを使用したデプロイメント プロセスを構築できます。

機能フラグ

特定の機能は、リリースの一部として展開する必要がある場合がありますが、最初はユーザーに公開されていません。 このような場合、機能フラグは、環境、リング、またはその他の特定の展開に基づいて構成を変更することで機能を有効にすることができるソリューションを提供します。

ユーザーオプトイン

機能フラグと同様に、ユーザーのオプトインは露出を制限する方法を提供します。 このモデルでは、特定の機能はリリースで有効になりますが、ユーザーが特に必要としない限り、ユーザーに対してアクティブ化されません。 リスク許容度の決定はユーザーに委ねられるため、ユーザーは特定の更新をどのくらい早く導入するかを決定できます。

通常、複数の実践が同時に行われます。 たとえば、チームは非常に特殊な使用例を目的とした実験的な機能を持っている場合があります。 これには危険が伴うため、内部ユーザーが試しられるように最初のリングにデプロイする予定です。 ただし、機能がコードに含まれている場合でも、その機能がユーザー インターフェイスを介して公開されるように、誰かがリング内の特定の展開に対して機能フラグを設定する必要があります。 その場合でも、機能フラグは、ユーザーが新しい機能の使用をオプトインするためのオプションを公開するだけである場合があります。 リングに参加していない人、その展開に参加していない人、またはオプトインしていない人は、この機能を利用できません。 これはかなり不自然な例ですが、プログレッシブ露光の柔軟性と実用性を説明するのに役立ちます。

チームが早い段階で直面する一般的な問題

チームがよりアジャイルな DevOps プラクティスに移行すると、従来のモノリシックなデリバリーから移行した他のチームと同様の問題に遭遇する可能性があります。 数か月に 1 回のデプロイに慣れているチームは、安定化のためにバッファリングするという考え方を持っています。 導入ごとにサービスに大きな変化が生じ、予期せぬ問題が発生することが予想されます。

ペイロードが大きすぎます

数か月ごとに展開されるサービスには通常、多くの変更が加えられます。 これにより、すぐに問題が発生する可能性が高まり、また、新しいものが非常に多いため、それらの問題のトラブルシューティングが困難になります。 より頻繁な配信に移行すると、デプロイされる内容の違いが小さくなり、より集中的なテストが可能になり、デバッグが容易になります。

サービス分離なし

モノリシック システムは従来、展開されるハードウェアをレベルアップすることによって拡張されてきました。 ただし、インスタンスで問題が発生すると、全員に問題が発生します。 簡単な解決策の 1 つは、複数のインスタンスを追加して、ユーザーの負荷を分散できるようにすることです。 ただし、多くのレガシー システムはマルチインスタンス向けに構築されていないため、これにはアーキテクチャに関する重要な考慮事項が必要になる場合があります。 さらに、他の場所に統合したほうがよい機能のために、かなりの重複リソースを割り当てる必要がある場合があります。

新しい機能が追加されるたびに、マイクロサービス アーキテクチャ が、より優れたサービス分離によって運用と拡張に役立つかどうかを検討してください。

手動の手順は間違いにつながります

チームが年に数回しかデプロイしない場合、配信の自動化には投資の価値がないと思われるかもしれません。 その結果、多くの展開プロセスは手動で管理されます。 これには多大な時間と労力が必要であり、人的ミスが発生しやすくなります。 最も一般的なビルドおよびデプロイメントタスクを自動化するだけで、時間のロスや強制的エラーを削減するのに大いに役立ちます。

チームはコードとしてのインフラストラクチャを利用して、展開環境をより適切に制御することもできます。 これにより、新しい機能や依存関係がさまざまな展開環境に導入されるときに、運用チームに手動で変更を加えるようにリクエストする必要がなくなります。

デプロイメントを実行できるのは運用担当者だけです

一部の組織では、すべての導入を運用スタッフが開始および管理することを要求するポリシーを採用しています。 過去にはそれには正当な理由があったかもしれませんが、アジャイル DevOps プロセスは、開発チームがデプロイメントを開始して制御できる場合に大きなメリットをもたらします。 最新の継続的配信プラットフォームでは、誰がどの展開を開始できるか、誰がステータス ログやその他の診断情報にアクセスできるかを詳細に制御できるため、適切な担当者ができるだけ早く適切な情報を入手できるようになります。

不適切なデプロイメントが進行し、ロールバックできない

場合によっては、デプロイメントに問題が発生し、チームがそれに対処する必要があることがあります。 ただし、プロセスが手動であり、情報へのアクセスが遅く、制限されている場合、以前に動作していた展開にロールバックすることが困難になる可能性があります。 幸いなことに、展開の失敗のリスクを軽減するためのさまざまなツールや実践があります。

基本原則

安全な導入方法の採用を検討しているチームは、その取り組みを支えるいくつかの基本原則を設定する必要があります。

一貫性を保つ

運用環境での展開に使用したものと同じツールを開発環境とテスト環境で使用する必要があります。 依存関係やツールの新しいバージョンからよく発生する問題などがある場合は、コードが運用環境にリリースされる直前に問題を発見する必要があります。

信号の品質を重視する

あまりにも多くのチームが、信号の品質をあまり気にしないという共通の罠に陥っています。 時間が経つにつれて、黄色の警告を緑色の承認に変えるためだけにテストを書いたり、質の高いタスクを引き受けたりすることに気づくかもしれません。 高品質のシグナルはプロジェクトの脈動を表すため、非常に重要です。 デプロイの承認に使用する品質シグナルは、毎日定期的に追跡する必要があります。

導入にはダウンタイムをゼロにする必要があります

すべてのサービスを常に利用できることが重要ではありませんが、チームは、新しいバージョンを一時的に停止することなく新しいバージョンをデプロイできる、またデプロイする必要があるという考え方を持って、DevOps の配信および運用段階に取り組む必要があります。 最新のインフラストラクチャとパイプライン ツールは現在十分に進歩しており、事実上どのチームでも 100% の稼働時間を目標にすることが可能です。

導入は勤務時間内に行う必要があります

チームが、デプロイメントにはダウンタイムが必要ないという考え方で作業している場合、デプロイメントがいつプッシュされるかはあまり問題になりません。 さらに、勤務時間中、特に一日の早い時間帯と週の早い時間帯に展開をプッシュすると有利になります。 何か問題が発生した場合は、爆発範囲を制御するのに十分な早めに追跡する必要があります。 さらに、全員がすでに作業を開始し、問題の解決に集中していることになります。

リングベースの導入

成熟した DevOps リリース プラクティスを持つチームは、リングベースのデプロイメントに取り組むことができます。 このモデルでは、新機能はまず、最もリスクを許容する顧客に展開されます。 導入が実証されると、全員が使用するようになるまで、対象ユーザーはさらに多くのユーザーを含むように拡大されます。

リングモデルの例

一般的なリング展開モデルは、ユーザーとインフラストラクチャを慎重にセグメント化することで、問題をできるだけ早期に発見できるように設計されています。 次の例は、Microsoft の主要チームがリングをどのように使用するかを示しています。

輪	目的	Users	Data Center
0	導入によってもたらされたユーザーに影響を与えるバグのほとんどを検出します	内部専用、リスクとバグに対する高い許容度	米国中西部
1	チームが広範囲にテストしていない領域	幅広い製品をご利用のお客様	小規模なデータセンター
2	スケール関連の問題	パブリック アカウント、理想的にはさまざまな機能セットを使用する無料のアカウント	中規模または大規模のデータセンター
3	内部口座の規模の問題と国際関連の問題	大規模な社内口座とヨーロッパの顧客	社内データセンターとヨーロッパのデータセンター
4	残りのスケールユニット	他人	すべての展開ターゲット

ベーク時間を許可する

ベーク時間 という用語は、次のリングに拡張する前にデプロイメントの実行が許可される時間を指します。 問題によっては、症状が現れ始めるまでに数時間以上かかる場合があるため、リリースが準備完了とみなされるまで、適切な期間使用する必要があります。

一般に、ほとんどのシナリオでは、1 日 24 時間あれば潜在的なバグが明らかになるのに十分な時間です。 ただし、この期間には、営業時間内にピークとなるサービスの場合、丸営業日を必要とするピーク使用期間が含まれている必要があります。

ホットフィックスを迅速化する

ライブサイトインシデント (LSI) は、バグが本番環境に重大な影響を与えるときに発生します。 LSI では、ホットフィックス を作成する必要があります。これは、優先度の高い問題に対処するために設計された帯域外アップデートです。

バグが Sev 0 (最も深刻なタイプのバグ) である場合、責任を持って可能な限り迅速に、影響を受けるスケール ユニットに修正プログラムを直接展開できます。 修正によって状況が悪化しないことが重要ですが、この重大度のバグは非常に破壊的であると考えられているため、すぐに対処する必要があります。

Sev 1 と評価されたバグは、リング 0 を介して展開する必要がありますが、承認され次第、影響を受けるスケール ユニットに展開できます。

重大度の低いバグの修正プログラムは、計画どおりにすべてのリングを通じて展開する必要があります。

要点

どのチームもアップデートを迅速かつ可能な限り最高の品質で提供したいと考えています。 適切に実践すれば、デリバリは DevOps サイクルの生産的かつ苦痛のない部分になります。

• 頻繁に展開します。
• スプリント全体を通して緑色を保ちます。
• 開発、テスト、本番環境で一貫した導入ツールを使用します。
• 自動化と承認を可能にする継続的デリバリー プラットフォームを使用します。
• 安全な展開手順に従ってください。

次のステップ

機能フラグ がユーザーへの新機能の公開を制御する方法を学びましょう。