すべてに影響を与えたロールアウトストーリー

現実の敵 12f-2まで

XNUMX 月末、ホワイト ウォーカーがウィンターフェルを包囲している間に、さらに興味深いことが私たちに起こりました。私たちは珍しい展開を行いました。 原則として、私たちは (他の皆さんと同様に) 新しい機能を実稼働環境に継続的にロールアウトしています。 しかし、これは違いました。 その規模は、私たちが犯す可能性のある間違いがすべてのサービスとユーザーに影響を与えるほどでした。 その結果、計画および発表されたダウンタイム期間内に、売上に影響を与えることなく、すべてを計画どおりに展開しました。 この記事では、私たちがどのようにしてこれを達成したか、そして誰でも自宅でそれを再現できる方法について説明します。

ここでは、私たちが行ったアーキテクチャ上および技術的な決定について説明したり、それがどのように機能するかについては説明しません。 これらはむしろ、私が観察し、私が直接関与した最も困難なロールアウトの XNUMX つがどのように行われたかについての欄外のメモです。 完全性や技術的な詳細については主張しません。おそらくそれらは別の記事で登場するでしょう。

背景とどのような機能ですか?

私たちはクラウドプラットフォームを構築しています Mail.ru クラウド ソリューション (MCS) でテクニカル ディレクターを務めています。 そして今度は、すべてのユーザー アカウント、ユーザー、パスワード、ロール、サービスなどの統合管理を提供する IAM (Identity and Access Management) をプラットフォームに追加します。 なぜクラウドが必要なのかは明らかな疑問です。すべてのユーザー情報がクラウドに保存されているからです。

通常、そのようなものはプロジェクトの最初から構築され始めます。 しかし歴史的に見て、MCS では状況が少し異なりました。 MCS は XNUMX つの部分で構築されました。

• 独自の Keystone 認証モジュールを備えた Openstack、
• Mail.ru Cloud プロジェクトに基づくホットボックス (S3 ストレージ)、

その後、新しいサービスが登場しました。

本質的に、これらは XNUMX つの異なるタイプの承認でした。 さらに、Horizo​​n パネルで SSO (エンドツーエンド認証) が提供されたおかげで、一般的な Mail.ru パスワード ストレージや自作の openid コネクタなど、別個の Mail.ru 開発をいくつか使用しました。仮想マシン (ネイティブ OpenStack UI) の数。

私たちにとって IAM を作成するということは、すべてを単一のシステムに接続し、完全に私たち独自のものにすることを意味しました。 同時に、途中で機能を失うことはなく、リファクタリングせずに透過的に改良し、機能の面で拡張できる将来に向けた基盤を作成します。 また、当初は、ユーザーにはサービスへのアクセス (中央 RBAC、ロールベースのアクセス制御) やその他の小さなものに対するロール モデルがありました。

このタスクは、Python と Perl、いくつかのバックエンド、独自に作成されたサービス、いくつかの開発チームと管理者など、簡単ではないことが判明しました。 そして最も重要なことは、戦闘本番システムには何千人ものライブ ユーザーがいるということです。 これらすべてを作成し、最も重要なことに、死傷者を出さずに展開する必要がありました。

何を展開するのでしょうか?

非常に大まかに言うと、約 4 か月で以下を準備しました。

• 私たちは、インフラストラクチャのさまざまな部分で以前に動作していた機能を集約する、いくつかの新しいデーモンを作成しました。 残りのサービスには、これらのデーモンの形で新しいバックエンドが規定されました。
• 当社は、すべてのサービスで利用できるパスワードとキーの独自の中央ストレージを作成し、必要に応じて自由に変更できます。
• 私たちは Keystone 用に 4 つの新しいバックエンド (ユーザー、プロジェクト、ロール、ロール割り当て) をゼロから作成しました。実際、これがデータベースを置き換え、ユーザー パスワードの単一リポジトリとして機能するようになりました。
• 私たちは、すべての Openstack サービスに、ポリシーを各サーバーからローカルで読み取るのではなく、サードパーティのポリシー サービスにアクセスしてポリシーを取得するように教えました (はい、Openstack はデフォルトでそのように動作します)。

このような大規模な再作業には、異なる開発チームによって作成された複数のシステムにおける大規模で複雑な、そして最も重要な同期的な変更が必要です。 組み立てが完了すると、システム全体が動作するはずです。

このような変更を台無しにせずに展開するにはどうすればよいでしょうか? まず、少し将来のことを考えてみることにしました。

ロールアウト戦略

• 製品を複数の段階に分けて展開することも可能ですが、その場合は開発時間が XNUMX 倍に増加します。 さらに、しばらくの間、データベース内のデータが完全に非同期化することになります。 独自の同期ツールを作成し、複数のデータ ストアを長期間使用する必要があります。 そしてこれはさまざまなリスクを生み出します。
• ユーザーに対して透過的に準備できることはすべて事前に行われていました。 2ヶ月かかりました。
• リソースの作成と変更のためのユーザー操作のみに、数時間のダウンタイムを許容しました。
• すでに作成されているすべてのリソースの操作にとって、ダウンタイムは許容できません。 私たちは、ロールアウト中にリソースがダウンタイムなく動作し、クライアントに影響を与えるように計画しました。
• 何か問題が発生した場合のお客様への影響を軽減するために、日曜日の夜に展開することにしました。 夜間に仮想マシンを管理する顧客は少なくなります。
• 展開のために選択された期間中はサービス管理が利用できなくなることをすべてのクライアントに警告しました。

余談: ロールアウトとは何ですか?

＜注意・理念＞

IT スペシャリストなら誰でも、ロールアウトが何であるかを簡単に答えることができます。 CI/CD をインストールすると、すべてが自動的にストアに配信されます。 🙂

もちろんこれは真実です。 しかし、問題は、最新のコード配信自動化ツールでは、ロールアウト自体の理解が失われていることです。 現代の交通機関を見ていると、車輪の発明の壮大さを忘れてしまうでしょう。 すべてが自動化されているため、全体像を理解できないまま展開が行われることがよくあります。

そして全体像はこんな感じ。 ロールアウトは XNUMX つの主要な側面で構成されます。

1. データ変更を含むコードの配信。 たとえば、彼らの移住。
2. コードのロールバックとは、何か問題が発生した場合に元に戻す機能です。 たとえば、バックアップの作成などです。
3. 各ロールアウト/ロールバック操作の時間。 最初の XNUMX つのポイントの操作のタイミングを理解する必要があります。
4. 影響を受ける機能。 予想されるプラスの効果と起こり得るマイナスの効果の両方を評価する必要があります。

展開を成功させるには、これらすべての側面を考慮する必要があります。 通常、最初のポイントのみ、またはせいぜい 3 番目のポイントのみが評価され、その後、ロールアウトは成功したとみなされます。 しかし、XNUMX 番目と XNUMX 番目はさらに重要です。 ロールアウトに XNUMX 分ではなく XNUMX 時間かかるとしたら、どのユーザーがそれを望むでしょうか? それとも、ロールアウト中に不必要な何かが影響を受けた場合でしょうか? それとも、XNUMX つのサービスのダウンタイムが予期せぬ結果をもたらすのでしょうか?

第 1 幕..n、リリースの準備

最初に、私たちの会議について簡単に説明しようと思いました。チーム全体、そのメンバー、コーヒーポイントでの議論の山、議論、テスト、ブレインストーミングです。 それなら不要かなと思いました。 XNUMX か月の開発は常にこれで構成されます。特に継続的に提供できるものを作成していない場合は、ライブ システムの XNUMX つの大きな機能で構成されます。 これはすべてのサービスに影響しますが、ユーザーにとっては「Web インターフェイスの XNUMX つのボタン」以外は何も変わらないはずです。

展開方法についての私たちの理解は、新しい会議のたびに、そしてかなり大きく変わりました。 たとえば、請求データベース全体を更新する予定でした。 しかし、時間を計算したところ、妥当な展開時間内にこれを行うのは不可能であることがわかりました。 請求データベースをシャーディングしてアーカイブするのにさらに XNUMX 週​​間近くかかりました。 そして、予想されるロールアウト速度がまだ満足のいくものではなかったとき、私たちは追加のより強力なハードウェアを注文し、そこではベース全体が引きずられました。 もっと早くこれを実行したくなかったわけではありませんが、現在展開する必要があるため、選択肢がありませんでした。

私たちの一人が、ロールアウトが仮想マシンの可用性に影響を与えるのではないかと疑念を抱いたとき、私たちは XNUMX 週間かけてテスト、実験、コード分析を実施しました。その結果、このようなことは本番環境では起こらないという明確な理解を得ることができ、最も疑念を抱いていた人たちも同意しました。これとともに。

その間、テクニカル サポートの担当者は、展開後に変更されるはずだった接続方法に関するクライアント向けの指示を作成するために、独自の独立した実験を実施しました。 彼らはユーザー UX に取り組み、説明書を作成し、個人的なコンサルティングを提供しました。

可能なすべてのロールアウト操作を自動化しました。 最も単純なものであっても、すべての操作がスクリプト化され、テストが常に実行されていました。 彼らは、サービスをオフにする最善の方法、つまりデーモンを省略するか、ファイアウォールでサービスへのアクセスをブロックするかについて議論しました。 私たちは展開の各段階でチームのチェックリストを作成し、常に更新しました。 すべてのロールアウト作業について、タイミングを含むガント チャートを作成し、常に更新しました。

そして…

ロールアウト前の最終段階

...いよいよ展開の時間です。

よく言われるように、芸術作品は完成するものではなく、作業が完了するだけです。 すべてを見つけることはできないことを理解しながら、すべての合理的な仮定を立て、すべての可能なケースに備え、すべての重大なバグを解決し、すべての参加者ができる限りのことを行ったと信じて、意志を持って努力する必要があります。 展開するコードの数が増えるほど、これを納得させるのは難しくなります (さらに、すべてを予測するのは不可能であることは誰もが理解しています)。

予期せぬ影響やダウンタイムに伴うユーザーのリスクをすべてカバーするために可能な限りのことを行ったと確信できた時点で、展開の準備が整ったと判断しました。 つまり、次の場合を除いて、あらゆる問題が発生する可能性があります。

1. (私たちにとって神聖で最も貴重な) ユーザー インフラストラクチャに影響を与える、
2. 機能: ロールアウト後のサービスの使用は、ロールアウト前と同じである必要があります。

展開中

8ロール、XNUMXは干渉しない

ユーザーからのすべてのリクエストに対して 7 時間のダウンタイムをとります。 現時点では、ロールアウト計画とロールバック計画の両方があります。

• ロールアウト自体には約 3 時間かかります。
• テストに2時間。
• 2 時間 - 変更のロールバックに備えて予約します。

ガント チャートは、アクションごとに作成され、どれくらいの時間がかかるか、何が順番に起こるか、何が並行して行われるかが示されています。

ロールアウト ガント チャートの一部。初期バージョン (並列実行なし) の XNUMX つ。 最も価値のある同期ツール

すべての参加者には、ロールアウトにおける役割、実行するタスク、および責任が決定されています。 私たちは各段階を自動化し、展開し、展開し、フィードバックを収集し、再度展開しようとします。

イベントのクロニクル

それで、15月29日日曜日午後10時にXNUMX人が出勤しました。 主要な参加者に加えて、単にチームをサポートするために来てくれた人もいて、彼らには特に感謝しています。

また、主要なテスターが休暇中であることにも言及する価値があります。 テストせずに展開することは不可能であり、オプションを検討中です。 同僚が休暇中に私たちをテストすることに同意し、そのことにチーム全体から多大な感謝を受けています。

00:00。 停止
ユーザーのリクエストを停止し、技術的な作業を示す看板を掲げます。 監視員は悲鳴を上げていますが、すべて正常です。 落ちるはずのもの以外に何も落ちていないことを確認します。 そして移行の作業を開始します。

誰もが時点ごとに印刷されたロールアウト計画を持っており、誰がいつ何を行うのかを誰もが知っています。 それぞれのアクションの後、タイミングを確認し、それを超えていないことを確認し、すべてが計画どおりに進んでいます。 現段階でロールアウトに直接参加していない人は、同僚の迷惑にならないよう、オンライン トイ (Xonotic、タイプ 3 もどき) を起動して準備を進めています。 🙂

02:00。 ロールアウト
うれしい驚きです。データベースと移行スクリプトの最適化により、ロールアウトが XNUMX 時間早く終了しました。 「ロールアウト！」という大将の叫び声。 すべての新機能は運用中ですが、今のところインターフェイスでのみ確認できます。 全員がテストモードに入り、グループに分類され、最終的に何が起こったのかを見始めます。

結果はあまり良くありませんでした。10 分後、チーム メンバーのプロジェクトに何も接続されておらず、何も動作していないことに気づきました。 迅速な同期により、私たちは問題を表明し、優先順位を設定し、チームに分かれてデバッグに入ります。

02:30。 XNUMX つの大きな問題と XNUMX つの目
XNUMX つの大きな問題が見つかりました。 私たちは、一部の接続されたサービスが顧客に表示されなくなり、パートナー アカウントで問題が発生することに気づきました。 どちらも、一部のエッジケースにおける移行スクリプトが不完全であることが原因です。 今すぐ修正する必要があります。

少なくとも 4 つの目を使用して、これを修正するリクエストを作成します。 私たちはプリプロダクション中にそれらが機能し、何も壊れていないことを確認するためにテストします。 転がってもいいよ。 同時に、定期的な統合テストを実行すると、さらにいくつかの問題が明らかになります。 どれも小さいですが、修理が必要です。

03:00。 -2 問題 +2 問題
以前の XNUMX つの大きな問題が修正され、小さな問題もほぼすべて修正されました。 修正に専念していない人は全員、自分のアカウントで積極的に作業し、見つけたものを報告しています。 優先順位を付けてチームに分配し、重要でない項目は午前中に残しておきます。

再度テストを実行すると、新たに XNUMX つの大きな問題が発見されました。 すべてのサービス ポリシーが正しく到着したわけではないため、一部のユーザー リクエストは承認を通過できません。 さらに、パートナーアカウントに関する新たな問題も発生します。 急いで見てみましょう。

03:20。 緊急同期
新しい問題が XNUMX つ修正されました。 XNUMX つ目として、緊急同期を計画しています。 何が起こっているかは理解しています。以前の修正により XNUMX つの問題は解決されましたが、別の問題が発生しました。 休憩を取って、結果を残さずに正しく実行する方法を見つけます。

03:30。 六つの目
私たちは、すべてのパートナーにとってすべてがうまくいくために、ベースの最終状態がどうあるべきかを理解しています。 私たちは 6 つの目でリクエストを作成し、それを実稼働前に展開し、テストし、実稼働に向けて展開します。

04:00。 すべてが機能しています
すべてのテストに合格し、重大な問題は見当たりません。 時々、チーム内の何かが誰かにとってうまくいかない場合、私たちはすぐに対応します。 ほとんどの場合、警報は誤報です。 ただし、場合によっては、何かが届かなかったり、別のページが機能しないことがあります。 私たちは座って、修正して、修正して、修正します。 別のチームが最後の大きな機能である課金を立ち上げています。

04:30。 復帰不能点
後戻りできない時点、つまり、ロールバックを開始すると、与えられたダウンタイムに間に合わなくなる時が近づいています。 請求書作成には問題があり、すべてを把握して記録しているにもかかわらず、顧客からのお金を償却することを頑なに拒否しています。 個々のページ、アクション、ステータスにいくつかのバグがあります。 主要な機能は動作し、すべてのテストは正常にパスします。 ロールアウトが行われたと判断し、ロールバックはしません。

06:00。 UI で誰でも利用できるようにする
バグが修正されました。 ユーザーの興味を引かないものは後回しにされます。 私たちはインターフェースを誰にでも公開します。 ユーザーからのフィードバックと結果の監視を待ちながら、引き続き請求の作業を続けます。

07:00。 APIのロードに関する問題
API の負荷の計画を少し誤ってこの負荷をテストしたが、問題を特定できなかったことが明らかになりました。 その結果、リクエストの約 5% が失敗します。 力を合わせてその理由を探ってみましょう。

請求は頑固で働きたくもありません。 変更を冷静に実行するため、延期することといたしました。 つまり、すべてのリソースがそこに蓄積されますが、クライアントからの償却は行われません。 もちろん、これは問題ではありますが、一般的な展開に比べれば、重要ではないようです。

08:00。 APIを修正
負荷の修正をロールアウトしたところ、障害は解消されました。 私たちは家に帰り始めます。

10:00。 全て
すべてが修正されています。 モニタリング中は静かで、お客様のところではチームは徐々に眠っていきます。 請求は残っておりますので、明日復元させていただきます。

その後、日中に一部のクライアント向けにログ、通知、リターン コード、カスタマイズを修正するロールアウトが行われました。

ということで、展開は成功しました！ もちろん、もっと良くなる可能性はありますが、完璧を達成するには何が不十分であるかについて結論を導き出しました。

合計で

展開に向けた 2 か月間にわたる積極的な準備の間に、数時間から数日間にわたる 43 のタスクが完了しました。

ロールアウト中:

• 新しい悪魔と変更された悪魔 - 5つの部分、2つのモノリスを置き換えます。
• データベース内の変更 - ユーザー データを含む 6 つのデータベースすべてが影響を受け、ダウンロードは XNUMX つの古いデータベースから XNUMX つの新しいデータベースに行われました。
• 完全に再設計されたフロントエンド。
• ダウンロードされたコードの量 - 新しいコードが 33 行、テスト中のコードが約 3 行、移行コードが約 5 行。
• すべてのデータはそのままであり、顧客の仮想マシンは XNUMX 台も損傷しませんでした。 🙂

適切な展開のための優れたプラクティス

彼らはこの困難な状況で私たちを導いてくれました。 ただし、一般的に言えば、ロールアウト中にそれらに従うことは有益です。 しかし、展開が複雑になればなるほど、それらが果たす役割も大きくなります。

1. 最初に行う必要があるのは、ロールアウトがユーザーにどのような影響を与える可能性があるか、またはどのような影響を与えるかを理解することです。 ダウンタイムは発生しますか? その場合、ダウンタイムはどれくらいですか? これはユーザーにどのような影響を与えるのでしょうか? 考えられる最良のシナリオと最悪のシナリオは何ですか? そしてリスクもカバーします。
2. すべてを計画してください。 各段階で、ロールアウトのすべての側面を理解する必要があります。
   • コードの配信。
   • コードのロールバック。
   • 各操作の時間。
   • 影響を受ける機能。
3. ロールアウトのすべての段階と各段階でのリスクが明らかになるまで、シナリオをプレイしてください。 疑問がある場合は、休憩を取って、疑わしいステージを個別に検討することができます。
4. ユーザーの役に立つのであれば、各段階を改善することができますし、そうすべきです。 たとえば、ダウンタイムが短縮されたり、リスクが除去されたりします。
5. ロールバック テストは、コード配信テストよりもはるかに重要です。 ロールバックの結果、システムが元の状態に戻ることをテストで確認する必要があります。
6. 自動化できるものはすべて自動化する必要があります。 自動化できないものはすべて、事前に虎の巻に書いておく必要があります。
7. 達成基準を記録します。 どの機能をいつ使用できるようにする必要がありますか? これが起こらない場合は、ロールバック計画を実行してください。
8. そして最も重要なのは人々です。 誰もが、自分が何をしているのか、なぜ、そして展開プロセスでの自分の行動に何が依存するのかを認識する必要があります。

一言で言えば、適切な計画と綿密な調整があれば、売上に影響を与えることなく、望むものは何でも展開できます。 本番環境のすべてのサービスに影響を与えるものであっても。

出所： habr.com