5月21日に、SRE集中コースがSlurmeで開始されます。参加者は丸3日間、高負荷サービスをサポートする理論と実践に没頭します。仕事や家族の問題はありません-ただ勉強するだけです。カットの下で、私たちはあなたが参加することを決定した場合にあなたを待っているものをあなたに伝えます。
SREヘルプ
サイト信頼性エンジニアリング（SRE）-情報システムの信頼性を確保します。これは、数千、数百万のユーザーがいるサイト、サービス、およびアプリケーションをサポートするための新しいアプローチです。このアプローチはGoogleで始まり、現在世界中に広がっています。ロシアでは、SREはYandex、Mail.ru、Sberbank、Tinkoff、MTS、Megafonなどの企業で実装されています。
経験豊富な開発者とシステム管理者がSREエンジニアになります。サーバーオペレーティングシステム、ネットワーク操作、監視ツール、およびプログラミングスキルに関する深い知識が重要です。これらのハードスキルはすべて、SRE方法論（高い信頼性を確保するのに役立つ特定のプラクティス）に重ね合わされています。
「SREはアラートや事後分析についてはそれほど重要ではありません。これは、夜間に弱体化するコードが本番環境に到達しないという事実に関するものです。」
SREを実装したエンジニアとのコミュニケーションから
長い間、SREに関する主な知識源はGoogleの同名の本でした。現在、いくつかの英語とロシア語のトレーニングプログラムがあります。それらの1つは、Slurmeで集中的なSREです。
インテンシブフォーマット
集中コースはオンラインで行われ、講義と実践的なセッションで構成されています。スピーカーとのズームとテレグラムチャットで放送があります。
2種類の練習。実習には2つのタイプがあります。例によるカスタマイズとタスクの作業ですが、その解決策は事前に決定されていません。集中コースでは、ケースと呼ばれ ます。
実際のサービスでのチームワーク。事件に取り組むために、集中の参加者は5-8人のチームで団結します。各チームは、チケットを注文するためのWebサイトをホストするアプリケーション（複数のVDS）を備えたスタンドを受け取ります 。
集中 故障シミュレーションの参加者が安定した運用を保証するチケット注文サービス
。集中的な作業中に、サイトの作業でいくつかの大きな障害が発生します。チームのタスクは、原因を特定し、その再発を排除して防止することです。ケースは実際の経験に基づいています。スピーカーは、SREの練習中に直面した問題を収集し、これらの問題をシミュレートする環境を作成しました。
経験豊富なスピーカー。集中プログラムは以下によって開発され、実施されます。
- Databricksのスタッフソフトウェアエンジニア、IvanKruglov氏。
- Artyom Artemiev、TangoMeのリードSRE。
- Mail.ru Cloud SolutionsのシニアDevOpsエンジニア、PavelSelivanov氏。
サポート。キュレーターは、チームで団結し、共同作業を整理するのに役立ちます。 Slurmのスピーカーとテクニカルサポートエンジニアが、複雑な問題の解決をサポートします。
リモートフォーマット。講義はZoomでブロードキャストされ、タスクのディスカッションはSlackで行われます。講義のメモはすべて保存され、集中的に使用できるようになります。しばらくしてから、すでに落ち着いた雰囲気の中で講義に戻ると便利です。
3日間の完全な没頭。インテンシブは、モスクワ時間の10:00から18:00までの3日間にわたって設計されています。講義と昼食の間に短い休憩があります。
5月21日から開始します。まだ余裕があります。
詳細と登録
以下は完全な集中プログラムです。
1日目：SREの理論に精通し、監視とアラートを設定します
初日は、SREの理論に精通し、監視とアラートの設定方法を学び、集中的な他の参加者とチームを組みます。
メトリックSLO、SLI、SLA、およびそれらがビジネス要件にどのように関連しているかについて説明しましょう。消防隊の監視とルールを設定するためのベストプラクティスを共有します。最初の実際的なケースを紹介します。
トピック1：監視
- なぜ監視が必要なのですか、
- 症状と原因、
- ブラックボックス対。ホワイトボックスモニタリング、
- ゴールデンシグナル、
- パーセンタイル、
- 警告、
- 可観測性。
練習：基本的なダッシュボードを作成し、必要なアラートを設定します。
トピック2：SRE理論
- SLO、SLI、SLA、
- 耐久性、
- エラーバジェット。
練習：ダッシュボードにSLO / SLI +アラートを追加します。
練習：システムの最初のロード。
ケース1：下流中毒。大規模なシステムでは、相互に依存するサービスが多数あり、それらが常に同じように機能するとは限りません。あなたのサービスが正常であり、あなたが依存している隣のサービスが定期的にダウンしているとき、それは特に不快です。トレーニングプロジェクトはそのような状況に陥り、可能な限り最高の品質を提供できるようになります。
トピック3：インシデント管理
- レジリエンスエンジニアリング、
- 消防隊がどのように並んでいるか
- 事件においてあなたのチームはどれほど効果的ですか、
- インシデントリーダーのための7つのルール、
- 消防士のための5つのルール、
- HiPPO-最高の支払いを受けた人の意見。コミュニケーションリーダー。
ケース2：上流中毒。SLOの低いサービスに依存している場合、これは1つのことです。あなたのサービスがシステムの他の部分のためのものであるとき、それは別の問題です。これは、評価基準が合意されていない場合に発生します。たとえば、1秒以内にリクエストに応答して成功したと見なしたが、依存サービスは500モスクワ時間しか待機せず、エラーで終了します。この場合、メトリック調整の重要性について説明し、クライアントの目を通して品質を確認する方法を学びます。
トピック4：プロジェクトのSREオンボーディング
大企業では、他の部門からのサービスのサポートを引き受ける別のSREチームを形成することは珍しくありません。ただし、すべてのサービスをサポートする準備ができているわけではありません。満たす必要のある要件をお知らせします。
2日目：環境とアーキテクチャの問題を解決する
2日目は、環境の問題（ヘルスチェックの詳細な分析があります）とアーキテクチャの問題の2つのケースを解決することを中心にほぼ完全に構築されています。講演者は、事後分析の操作について話し、チームで使用できるテンプレートを提供します。
トピック5：ヘルスチェック
- Kubernetesでのヘルスチェック、
- 私たちのサービスは生きていますか？
- Execプローブ、
- initialDelaySeconds、
- セカンダリヘルスポート、
- Sidecar Health Server、
- ヘッドレスプローブ、
- ハードウェアプローブ。
ケース3：環境問題と正しいヘルスチェック。Healthcheckのタスクは、ダウンタイムサービスを検出し、サービスへのトラフィックをブロックして、ユーザーが問題に直面しないようにすることです。また、サービスへのリクエストをルート化して回答を得るだけで十分だと思う場合は、間違いです。サービスが応答しても、パフォーマンスが保証されるわけではありません。環境に問題がある可能性があります。このケースを通じて、正しいヘルスチェックを構成し、トラフィックを処理できない場所に移動させないようにする方法を学習します。
トピック6：事後分析の実践-前のケースに基づいて事後分析を作成し、スピーカーで分析します。
トピック7：インフラストラクチャの問題の解決
- MySQLの監視、
- SLO / SLI for MySQL、
- 異常検出。
ケース4：データベースの問題。データベースも問題の原因となる可能性があります。たとえば、レプリケーションリレーを監視しない場合、レプリカは廃止され、アプリケーションは古いデータを返します。さらに、このようなケースをデバッグすることは特に困難です。現在、データに一貫性がありませんが、数秒後にデータが失われ、問題の原因が明確になりません。ケースを通して、デバッグのすべての苦痛を感じ、そのような問題を防ぐ方法を学びます。
3日目：交通シールドとカナリアの解放
本番環境の高可用性については、トラフィックシールドとカナリア展開の2つのケースがあります。これらのアプローチについて学び、それらを適用する方法を学びます。誰が知っているとしても、私たちは手作業でハードコアチューニングを計画していません。
トピック8：トラフィックシールド
- リクエスト数と事業運営の増加のグラフの振る舞い
- 飽和および容量計画
- traffic shielding rate limiting
- sidecar rate-limiting 100
5: traffic shielding. ? , 100 , 1000. , , , . , .
9: Canary Deployment
- k8s (Rolling Update vs Recreate),
- canary blue-green ,
- blue-gree/canary release k8s,
- canary release GitLab CI/CD,
- canary release,
- .gitlab-ci.yml.
6: . ,
, - . , . Canary Deployment, .