スラームSRE。 Booking.com と Google.com の専門家による完全な実験

私たちのチームは実験が大好きです。 それぞれの Slurm は、前のスラームの静的な繰り返しではなく、経験を反映し、良いものからより良いものへの移行です。 しかし、 スラームSRE 私たちは、参加者にできるだけ「戦闘」に近い状態を与えるために、まったく新しい形式を適用することにしました。

集中コース中に私たちが行ったことを簡単に説明すると、次のようになります。
私達は勉強してる。" SRE は単なる理論ではほとんど価値がありません。実践、実際の解決策、実際の問題のみです。

参加者は、ドミトリー・アナトリエヴィッチの例に倣い、激しい競争意識によって誰も居眠りしたり、iPhone で「Angry Birds」を起動したりすることがないよう、チームに分けられました。

問題、グリッチ、バグ、タスクは XNUMX 人のメンターによって参加者に提供されました。 Booking.com (オランダ) の主任開発者、イワン・クルグロフ氏は次のように述べています。 Booking.com (米国) の主任開発者であるベン・タイラー氏は次のように述べています。 Eduard Medvedev 氏、Tungsten Labs (ドイツ) の CTO。 Evgeniy Varavva、Google (サンフランシスコ) の総合開発者。

また、参加者はチームに分かれて競い合います。 面白い？

イワン、ベン、エドゥアルド、エフゲニーは、競技開始前に、貧しいスラーム SRE 参加者たちを優しいレーニン主義者の目を細めて見ています。

したがって、タスクは次のとおりです。

私たちは私たちのもの、新しい世界を築いていきます...

映画チケット集約サイトがあります。 インシデントは事前に作成されたシナリオに基づいてメンターによって考案され (ただし、特に高度で陰湿な即興演奏を排除する人は誰もいません)、サイトのパフォーマンスはさまざまな指標によって記述されます。 問題は大きく異なる可能性があります。ムーラン ルージュ劇場のチケットがデータベースにロードされていません。 映画やパフォーマンスのポスターは 10 秒以上でデータベースにロードされます。 個々の映画の説明が止まってしまいます。 注文の 0,1% はすでに予約されています。 時々、支払い処理システムが XNUMX ～ XNUMX 分間クラッシュすることがあります。 そして、Slurm SRE 参加者には、実際の仕事において、非常に多くの不愉快な出来事が降りかかる可能性があります。

私たちはあらゆることに対応する準備ができています...そして誰でも。

私たちの長い間苦労してきた Web サイトは、いくつかのマイクロサービスで構成されています。 その役割は、すべての映画館のショー、料金、空席に関するデータを集約することです。映画のアナウンスが表示され、映画館、ショー、ホール、場所の選択、チケットの予約と支払いが可能になります。 一般に、視聴者が夢見ることしかできないすべてのもの。 しかし、ユーザーは、サイトの安定性とアクセシビリティを求めて内部でどれほど壮大な闘争が起こっているのかを疑うことさえありません。

集中的なサイトでは、SLO、SLI、SLA 指標を生成し、アーキテクチャとインフラストラクチャを開発し、サイトを展開し、監視とアラートを設定しました。 そして出発します。

SLO、SLI、SLA

SLI - サービス レベル インジケーター。 SLO はサービス レベルの目標です。 SLA - サービス レベル アグリーメント。

SLA は ITIL 方法論の用語で、サービスの顧客とそのサプライヤーの間の正式な合意を意味します。これには、サービスの説明、当事者の権利と義務、そして最も重要なことに、サービスの提供に関して合意された品質レベルが含まれます。サービス。

SLO はサービス レベル目標です。SLI によって測定されるサービス レベルの目標値または値の範囲です。 SLO の通常の値は、「SLI ≤ 目標」または「下限 ≤ SLI ≤ 上限」です。

SLI はサービス レベル指標であり、提供されるサービス レベルの一側面を表す慎重に定義された定量的尺度です。 ほとんどのサービスでは、主要な SLI はリクエストの遅延、つまりリクエストに対する応答を返すまでにかかる時間とみなされます。 その他の一般的な SLI には、受信したすべてのリクエストの一部として表されるエラー率や、通常 XNUMX 秒あたりのリクエストで測定されるシステム スループットが含まれます。

まず飛行機を壊し、次に女の子を壊し、そして女の子を壊します...

内部および外部の要因により、最初の数分から SLO が「損なわれ」始めました。 開発者のミス、インフラストラクチャの障害、訪問者の殺到、DDoS 攻撃など、すべてが管理者の頭に落ちました。 SLO を悪化させるものすべて。

「 - 参加者の皆さん、急いでいますが、最初に失敗するのは... すべてです！」

その過程で、講演者は安定性、エラーバジェット、テストの実践、中断と運用負荷の管理について話し合いました。

私たちはストーカーでも大工でもありません...

それから参加者は物事を修正し始めました - 重要なことは、最初に何を掴むべきかを理解することです。

「――主よ、このように、この形で、このような位置で壊れるのを私は見たことがありません！」

そこで、事故が起きました。 支払い処理サービスが停止しています。 できるだけ短期間で機能を回復するにはどうすればよいでしょうか?

専門家たちは参加者たちを愛情を込めて見つめながら、別のトリックを準備している。

各チームは事故をなくすためにグループの作業を組織し、同僚を巻き込み、関係者（ステークホルダー）に通知します。 同時に優先順位も設定します。 このようにして、参加者は、非常に限られた時間条件下でプレッシャーの下で働く訓練を行いました。

「どんな恐怖が出てきたの！？」

息を吐き出してエクササイズを終了します

各問題が解決され、サイトが一時的に安定した後、チームは講演者と一緒に、SRE の観点からインシデントを調査しました。 問題の発生原因、除去の進行状況などを詳細に分析しました。 その後、チームごとに、そして全体として、監視を改善する方法、アーキテクチャを賢明に変更する方法、開発と運用へのアプローチを調整する方法、規制を修正する方法など、それらをさらに防止する方法について決定を下しました。 講演者は事後分析の実践をデモンストレーションしました。

「他に誰が拷問を望んでいるだろう！ - 私！"

チームの成功は電子スコアボードに厳密かつ明確に記録されました。

XNUMX位には関係者からのボーナス。

出所： habr.com