ウェビナー「SRE - hype or the future?」の文字起こし

ウェビナーの音声が貧弱なので、文字に起こしました。

私の名前はメドベージェフ・エドゥアルドです。 今日は、SRE とは何か、SRE がどのように登場したか、SRE エンジニアがどのような作業基準を持っているか、信頼性の基準について少し、そのモニタリングについて少し話します。 頂上を歩きます。XNUMX 時間では多くを語ることはできませんが、追加の検討用の資料を提供します。皆さんのお越しをお待ちしています。 スラーム SRE。 XNUMX月末にモスクワで。

まず、SRE とは何か、つまりサイト信頼性エンジニアリングについて説明しましょう。 そして、それが別の立場として、別の方向としてどのように現れたか。 すべては、従来の開発サークルでは、開発と運用が XNUMX つのまったく異なるチームであり、通常は XNUMX つのまったく異なる目標を持っているという事実から始まりました。 開発チームの目標は、新機能を展開し、ビジネスのニーズを満たすことです。 運用チームの目標は、すべてが機能し、何も壊れていないことを確認することです。 明らかに、これらの目標は互いに矛盾しています。すべてが機能し、何も壊さないようにするには、新機能のロールアウトをできる限り少なくする必要があります。 このため、現在 DevOps と呼ばれている方法論が解決しようとしている内部矛盾が数多くあります。

問題は、DevOps の明確な定義と DevOps の明確な実装がないことです。 私は 2 年前にエカテリンブルクのカンファレンスで講演しましたが、これまで DevOps セクションは「DevOps とは何か」というレポートから始まりました。 2017 年で、Devops は誕生してからほぼ 10 年になりますが、それが何なのかについてはまだ議論が続いています。 これは、Google が数年前に解決しようとした非常に奇妙な状況です。

2016 年、Google は「サイト信頼性エンジニアリング」という書籍を出版しました。 そして実際、SRE 運動が始まったのはこの本でした。 SRE は、特定の企業における DevOps パラダイムの特定の実装です。 SRE エンジニアは、システムが確実に動作するように努めます。 彼らはほとんどが開発者から来ており、場合によっては開発に強い経験を持つ管理者から来ています。 そして、彼らはシステム管理者がかつて行っていたことを行いますが、開発の経験とコードに関するシステムの知識が豊富なため、これらの人々は日常的な管理作業には関心がなく、自動化に傾いているという事実につながります。

SRE チームにおける DevOps パラダイムは、構造的な問題を解決する SRE エンジニアが存在するという事実によって実装されていることがわかりました。 これは、人々が 8 年間話題にしてきたのと同じ、開発と運用の関係です。 SRE の役割は、新人が SRE になるわけではないという点でアーキテクトの役割と似ています。 キャリアの初期段階にある人は、まだ経験がなく、必要な幅広い知識を持っていません。 なぜなら、SRE では、いつ、何が問題になる可能性があるのか​​について、非常に微妙な知識が必要だからです。 したがって、ここでは原則として社内と社外の両方である程度の経験が必要です。

SRE と Devops の違いについて説明するかどうかを尋ねられます。 彼女はたった今説明されました。 組織における SRE の位置についてお話しましょう。 Ops がまだ別の部門であるこの古典的な DevOps アプローチとは異なり、SRE は開発チームの一部です。 彼らは製品開発に携わっています。 SRE の役割をある開発者から別の開発者に引き継ぐアプローチもあります。 彼らは、たとえば UX デザイナー、開発者自身、場合によってはプロダクト マネージャーと同じようにコード レビューに参加します。 SRE は同じレベルで機能します。 SRE が展開ごとに次のように言うように、それらを承認し、レビューする必要があります。「わかりました、この展開、この製品は信頼性に悪影響を及ぼしません。 もしそうなら、それはある程度の許容範囲内です。 これについてもお話します。

したがって、SRE にはコードを変更する拒否権があります。 また、一般に、SRE が正しく実装されていない場合、これによりある種の小さな競合が発生します。 サイト信頼性エンジニアリングに関する同じ本の中で、これらの競合を回避する方法については、XNUMX つではなく多くの部分で説明されています。

彼らは、SRE が情報セキュリティにどのように関係しているかを尋ねます。 SRE は情報セキュリティに直接関与していません。 基本的に、大企業では、これは個人、テスター、アナリストによって行われます。 ただし、セキュリティに影響を与える一部の操作、一部のコミット、一部のデプロイメントが製品の可用性にも影響を与える可能性があるという意味で、SRE はそれらとも対話します。 したがって、SRE 全体として、アナリストを含むセキュリティ チームを含むあらゆるチームと対話します。 そのため、SREは主にDevOpsを導入する際に必要となりますが、同時に開発者の負担も大きくなってしまいます。 つまり、開発チーム自体が、運用の責任も負わなければならないという事実にもはや対処できなくなっています。 そして、別の役割があります。 この役割は予算で計画されています。 この役割はチームの規模に応じて定められることもあれば、別の人が現れることもあれば、開発者の XNUMX 人がその役割を果たすこともあります。 これが、最初の SRE がチームに登場する方法です。

SRE の影響を受けるシステムの複雑さ、つまり操作の信頼性に影響を与える複雑さは、必然的なものでもあり、偶然的なものでもあります。 必要な複雑さとは、製品の複雑さが、新しい製品機能に必要な範囲まで増加することです。 ランダムな複雑さとは、システムの複雑さが増加するものの、製品の機能やビジネス要件がこれに直接影響しないことです。 開発者がどこかで間違いを犯したか、アルゴリズムが最適ではないか、または特別な必要なしに製品の複雑さを増大させる追加の関心事が導入されたかのいずれかであることがわかります。 優れた SRE は常にこの状況を遮断する必要があります。 つまり、ランダムな追加により難易度が上昇するコミット、デプロイメント、プル リクエストはブロックされる必要があります。

問題は、なぜ豊富な知識を持つエンジニア、システム管理者をチームに採用しないのかということです。 開発者がエンジニアの役割を果たすことは、最良の人員配置ソリューションではないと言われています。 エンジニアの役割を担う開発者が常に最良の人員配置ソリューションであるとは限りませんが、ここで重要なのは、運用に携わる開発者は自動化に対する欲求がもう少しあり、自動化を実装するための知識とスキルセットをもう少し持っているということです。この自動化。 したがって、特定の操作やルーチンの時間だけでなく、MTTR (平均復旧時間、回復時間) などの重要なビジネス パラメーターも短縮します。 したがって、これについては後ほど説明しますが、組織のためにお金を節約します。

次に、SRE の運用基準について説明します。 そしてまず第一に信頼性についてです。 中小企業や新興企業では、サービスがうまく書かれていれば、製品がうまく書かれていて、正しく書かれていれば機能し、壊れることはないと考えられることがよくあります。 それだけです。私たちは良いコードを書いているので、壊すものは何もありません。 コードは非常にシンプルで、壊す部分は何もありません。 これらは、テストは必要ないと言う人たちとほぼ同じです。なぜなら、これらは XNUMX つの VPI メソッドであるのに、なぜここで中断する必要があるからです。

もちろん、これはすべて間違っています。 そして、これらの人々は、実際にそのようなコードに噛まれて壊れてしまうことがよくあります。 物事は時々、最も予測不可能な方法で壊れます。 時々人々は「いいえ、そんなことは決して起こらない」と言います。 そしてそれは常に起こります。 それは十分に頻繁に起こります。 100% の可用性は決して実現しないため、誰も 100% の可用性を目指して努力することがないのはこのためです。 これが標準です。 したがって、サービスの可用性について話すときは、常に 2 について話します。 3 ナイン、4 ナイン、5 ナイン、5 ナイン。 これをダウンタイムに換算すると、たとえば 5 ナインは年間 2 分強のダウンタイムとなり、3,5 ナインは XNUMX 日のダウンタイムになります。

しかし、ある時点で POI、つまり投資収益率が減少することは明らかです。 ツーナインからスリーナインに移行すると、ダウンタイムが 3 日以上短縮されることになります。 フォーナインズからファイブナインに移行すると、ダウンタイムが年間 47 分短縮されます。 そして、ビジネスにとってそれは重要ではない可能性があることが判明しました。 そして一般に、必要な信頼性は技術的な問題ではなく、まず第一にビジネスの問題であり、製品の問題です。 製品のユーザーにとって許容されるダウンタイムのレベル、ユーザーが何を期待しているか、支払った金額、たとえば、ユーザーが失う金額、システムが失う金額。

ここで重要な問題は、残りのコンポーネントの信頼性がどのようなものかということです。 なぜなら、信頼性が 4 ナインのスマートフォンでは、5 ナインと 2 ナインの差は見えないからです。 大まかに言って、あなたのサービスでスマートフォンに年間 10 回故障が発生した場合、その 8 回は OS 側で故障が発生している可能性が高くなります。 ユーザーはこれに慣れており、年に XNUMX 回以上は気にしません。 信頼性の向上と利益の増加の代償を相関させる必要があります。
SRE に関する本には、スリー ナインから 4 ナインに増加する良い例があります。 可用性の増加は 3% 弱であることがわかります。 そして、サービスの収益が年間 0,1 万ドルであれば、収益の増加は 1 ドルになります。 手頃な価格を 900 上げるのにかかるコストが年間 900 ドル未満であれば、その値上げは経済的に合理的です。 年間 900 ドルを超えるコストがかかる場合、収益の増加が人件費や資源コストを補えないため、もはや意味がありません。 そして、スリーナインで十分です。

もちろん、これはすべてのリクエストが等しい単純化された例です。 スリー ナインからフォー ナインに移行するのは十分に簡単ですが、同時に、たとえば 3 ナインから 4 に移行すると、すでに 2 ドルの節約となり、経済的に合理的です。 当然のことながら、実際には、登録リクエストの失敗はページの表示の失敗よりも悪く、リクエストの重みは異なります。 ビジネスの観点からはまったく異なる基準があるかもしれませんが、いずれにしても、特定のサービスについて話していない限り、原則として、これはかなり信頼できる近似値です。
サービスのアーキテクチャ ソリューションを選択する際に、SRE がコーディネーターの XNUMX 人になるかどうかという質問を受けました。 安定性が失われないように、既存のインフラストラクチャに統合するという観点から考えてみましょう。 はい、SRE は、プル リクエスト、コミット、リリースと同じように、アーキテクチャ、新しいサービス、マイクロサービスの導入、新しいソリューションの実装に影響を与えます。 なぜ経験が必要である、資格が必要であると前に言いましたか。 実際、SRE は、あらゆるアーキテクチャおよびソフトウェア ソリューションにおける阻害要因の XNUMX つです。 したがって、エンジニアとしての SRE は、まず、特定の決定が信頼性や安定性にどのような影響を与えるかを理解するだけでなく、それがビジネス ニーズとどのように関係しているのか、どのような観点からそれが許容され得るのかを理解する必要があります。そうではない。

したがって、ここでは、SRE で伝統的に SLA (サービス レベル アグリーメント) として定義されている信頼性基準についてのみ説明することができます。 おそらくよく知られた用語でしょう。 SLI (サービス レベル インジケーター)。 SLO (サービスレベル目標)。 サービス レベル アグリーメントは、特にネットワーク、プロバイダー、ホスティングを扱ったことがある人にとっては、おそらく象徴的な用語です。 これは、サービス全体のパフォーマンス、ペナルティ、エラーに対する一部のペナルティ、指標、基準について説明する一般的な合意です。 そして、SLI は可用性の指標そのものです。 つまり、SLI は、サービスからの応答時間、パーセンテージとしてのエラー数です。 ある種のファイルホスティングの場合は帯域幅である可能性があります。 認識アルゴリズムに関して言えば、指標は、たとえば、答えの正しさであってもよい。 SLO (Service Level Objective) は、それぞれ、SLI 指標、その値、期間の組み合わせです。

SLA が次のようになるとしましょう。 このサービスは、年間を通じて 99,95% の時間利用可能です。 または、99 件の重要なサポート チケットが四半期ごとに 3 時間以内にクローズされます。 または、クエリの 85% は毎月 1,5 秒以内に応答を受け取ります。 つまり、エラーや失敗はごく普通のことだということが徐々に理解できるようになるのです。 これは許容できる状況であり、私たちはそれを計画しており、ある程度は期待しています。 つまり、SRE は間違いを犯す可能性のあるシステムを構築し、エラーに正常に対応し、エラーを考慮する必要があります。 そして、可能な限り、ユーザーが気付かない、または気付いているような方法でエラーを処理する必要がありますが、すべてが完全に失敗しないようにするための何らかの回避策があります。

たとえば、ビデオを YouTube にアップロードし、YouTube がすぐに変換できない場合、ビデオが大きすぎる場合、フォーマットが最適でない場合、当然のことながらリクエストはタイムアウトで失敗せず、YouTube は 502 エラーを出しません。 , YouTube は次のように言います。「すべてが作成されました。ビデオは処理中です。 10分ほどで出来上がります。」 これはグレースフル デグラデーションの原則であり、これを行ったことがある人なら、たとえばフロントエンド開発でよく知られています。

次に説明する用語は、信頼性、エラー、期待を考慮して作業するために非常に重要であり、MTBF と MTTR です。 MTBF は、故障間の平均時間です。 MTTR 平均回復時間、回復までの平均時間。 つまり、エラーが発見された瞬間から、エラーが発生した瞬間からサービスが完全に通常の動作に復元されるまでの経過時間です。 MTBF は主にコードの品質に関する作業によって修正されます。 それは、SRE が「ノー」と言えるという事実です。 そして、SRE が「ノー」と言うとき、彼は有害だから、悪いからそう言っているのではなく、そうしないと全員が苦しむからそう言っているのだということをチーム全体が理解する必要があります。

繰り返しになりますが、他の開発者が SRE を嫌い始めないようにする方法については、私が頻繁に参照している本の中にさえ、たくさんの記事、たくさんの方法、たくさんの方法があります。 一方、MTTR は SLO (サービス レベル目標) に取り組むことを目的としています。 そしてそれはほとんどが自動化です。 たとえば、当社の SLO は四半期あたり 4 ナインの稼働時間であるためです。 これは、3 か月以内に 13 分のダウンタイムを許容できることを意味します。 そして、MTTR は 13 分を超えることはできないことがわかりました。 13 分以内に少なくとも 1 回のダウンタイムに対応した場合、その四半期の予算全体がすでに使い果たされていることを意味します。 SLO を破っています。 クラッシュに対応して修正するのに 13 分という時間は、機械にとっては長いですが、人間にとっては非常に短いです。 なぜなら、人がアラートを受け取るまで、反応するまで、エラーを理解するまで、すでに数分かかるからです。 人がそれを修正する方法、正確に何を修正するか、何をすべきかを理解するまで、さらに数分かかります。 実際、サーバーを再起動する必要があるだけ、または新しいノードを立ち上げる必要がある場合でも、手動での MTTR はすでに約 7 ～ 8 分です。 プロセスを自動化すると、MTTR は XNUMX 秒、場合によってはミリ秒に達することがよくあります。 Google は通常、ミリ秒について話しますが、実際には、もちろん、すべてがそれほど良いわけではありません。

理想的には、SRE はその作業をほぼ完全に自動化する必要があります。これは、MTTR、そのメトリクス、サービス全体の SLO、そしてそれに応じてビジネス利益に直接影響するからです。 時間を超えると、SRE に問題があるかどうかを尋ねられます。 幸いなことに、誰も責めることはありません。 これはバルムレス事後分析と呼ばれる別の文化で、今日は説明しませんが、Slurm で分析します。 これは非常に興味深いトピックであり、たくさん話すことができます。 大まかに言えば、四半期ごとに割り当てられた時間を超過した場合、少しずつ全員に責任があることになります。つまり、全員を責めることは生産的ではありません。代わりに、おそらく誰も責めるのではなく、状況を修正して、自分の持っているもので取り組みましょう。 私の経験では、このアプローチはほとんどのチーム、特にロシアでは少し異質ですが、理にかなっていて非常にうまく機能します。 したがって、記事の最後に、このトピックに関して読むことができる文献をお勧めします。 または、Slurm SRE にお越しください。

説明しましょう。 四半期あたりの SLO 時間が超過した場合、ダウンタイムが 13 分ではなく 15 分だった場合、誰が責任を負えるでしょうか? もちろん、SRE が何らかの間違ったコミットまたはデプロイメントを行ったことは明らかなので、SRE が原因である可能性があります。 データセンターの管理者は、何らかの予定外のメンテナンスを実行した可能性があるため、この責任がある可能性があります。 データセンターの管理者がこの責任があるのであれば、SLO を調整するときにメンテナンスを計算しなかった運用部門の担当者も責任があることになります。 この原因は、データ センター契約に署名し、データ センターの SLA が必要なダウンタイムを考慮して設計されていないという事実に注意を払わなかったマネージャー、テクニカル ディレクター、または誰かに責任があります。 したがって、この状況では少しずつすべてが責任があります。 そしてそれは、この状況では誰かを責めても意味がないことを意味します。 しかし、もちろん修正する必要があります。 だからこそ事後分析があるのです。 そして、たとえば、GitHub の事後分析を読むと、これは常に非常に興味深い、小規模で予期せぬストーリーであり、それぞれのケースで、この特定の人物が原因であるとは誰も言っていないと置き換えることができます。 非難の対象は常に特定の不完全なプロセスにあります。

次の質問に移りましょう。 オートメーション。 他の文脈で自動化について話すとき、私はよく、実際に節約できる時間よりも自動化にかかる時間を取らずに、タスクの自動化に取り組むことができる時間を示す表を参照します。 引っ掛かりがあります。 問題は、SRE がタスクを自動化すると、自動化が MTTR に直接影響するため、時間だけでなくコストも節約できるということです。 いわば、枯渇するリソースでもある従業員や開発者の士気を節約します。 彼らはルーチンを減らします。 そして、たとえ時間コストの観点から自動化が意味をなさないように見えても、これらすべてが仕事、そしてその結果としてビジネスにプラスの影響を及ぼします。

実際、ほとんどの場合そうなっており、SRE の役割において何かを自動化すべきではないケースはほとんどありません。 次に、いわゆるエラー バジェット、つまりエラーのバジェットについて説明します。 実際、自分で設定した SLO よりもすべてがはるかに優れている場合、これもあまり良くないことがわかります。 SLO は下限としてだけでなく、おおよその上限としても機能するため、これはかなり悪いことです。 SLO の可用性を 99% に設定し、実際に 99,99% になった場合、ビジネスにまったく悪影響を及ぼさない実験の余地があることがわかります。なぜなら、これは自分ですべてまとめて決定したものであり、実際にそうであるからです。このスペースは使用しません。 あなたにはミスに対する予算があり、あなたの場合はそれが使い果たされていません。

それをどうするか。 私たちは文字通りあらゆるものにそれを使用します。 運用環境でのテスト、パフォーマンスに影響を与える可能性のある新機能の展開、リリース、メンテナンス、計画的なダウンタイムの場合。 逆のルールも適用されます。予算が使い果たされた場合、新しいものをリリースすることはできません。そうしないと SLO を超えてしまうからです。 予算はすでに使い果たされており、何かをリリースしましたが、それがパフォーマンスに悪影響を及ぼす場合、つまり、それ自体が SLO を直接増加させる何らかの修正でない場合は、予算を超えており、これは悪い状況です。分析、事後分析、そして場合によってはプロセスの修正が必要です。

つまり、サービス自体がうまく機能せず、SLO が費やされ、予算が実験やリリースではなく、サービス自体に費やされた場合、興味深い修正ではなく、興味深い機能ではなく、興味深いリリースの代わりに。 創造的な作業の代わりに、予算を元の状態に戻すための愚かな修正に対処したり、SLO を編集したりする必要がありますが、これも頻繁に行うべきではないプロセスです。

したがって、エラーに対してより多くの予算がある状況では、SRE と開発者の両方の誰もが関心を持っていることがわかります。 開発者にとって、バグに対する多額の予算は、リリース、テスト、実験に対処できることを意味します。 SRE にとって、エラーに対する予算が設定され、その予算を入力することは、直接的に業務を適切に遂行していることを意味します。 そしてこれは、ある種の共同作業の動機に影響を与えます。 開発者として SRE の意見に耳を傾ければ、ルーティンの作業が減り、良い仕事をするためのスペースが増えるでしょう。

実稼働環境での実験は非常に重要であり、大規模なチームでは SRE にほぼ不可欠な部分であることがわかりました。 これは通常、カオス エンジニアリングと呼ばれます。これは、Chaos Monkey と呼ばれるユーティリティをリリースした Netflix のチームに由来しています。
Chaos Monkey は CI/CD パイプラインに接続し、運用環境のサーバーをランダムにクラッシュさせます。 繰り返しますが、SRE の構造では、ダウンしたサーバー自体が悪いのではなく、それは予期されているという事実について話しています。 予算内であれば許容され、ビジネスに悪影響を与えることはありません。 もちろん、Netflix には十分な冗長サーバーと十分なレプリケーションがあるため、これらすべてを修正でき、ユーザー全体が気付かないほどであり、さらに、予算に応じて XNUMX 台のサーバーを残す人はいません。

Netflix はしばらくの間、このようなユーティリティのスイート全体を提供していましたが、その XNUMX つである Chaos Gorilla は Amazon のアベイラビリティーゾーンの XNUMX つを完全にシャットダウンします。 そして、そのようなものは、何が何に影響を与え、何が何に依存するかが完全には明らかでない場合に、まず隠れた依存関係を明らかにするのに役立ちます。 これは、マイクロサービスを使用していて、ドキュメントが完全ではない場合には、よく知られているかもしれません。 また、これは、ステージングでは捕捉できないコード内のエラーを捕捉するのに非常に役立ちます。負荷スケールが異なる、負荷パターンが異なる、機器が異なるという事実により、ステージングは​​厳密には正確なシミュレーションではないからです。また、おそらく他のものもあります。 ピーク負荷は予期せぬ、予測不可能な場合もあります。 そして、このようなテストは、やはり予算を超えないものですが、ステージング、自動テスト、CI / CD パイプラインでは決して検出できないインフラストラクチャ内のエラーを検出するのに非常に役立ちます。 そして、それがすべて予算に含まれている限り、サービスがそこでダウンしたことは問題ではありません。非常に恐ろしいように思えるかもしれませんが、サーバーがダウンしたのは何という悪夢でしょう。 いいえ、それは正常です、それは良いことです、それは虫を捕まえるのに役立ちます。 予算があれば、それを使うことができます。

Q: どのような文献をお勧めできますか? 最後にリストを記載します。 文献はたくさんありますので、いくつかのレポートを紹介します。 SRE はどのように機能するのでしょうか。また、独自のソフトウェア製品を持たない企業や開発が最小限の企業でも SRE は機能しますか。 たとえば、主な活動がソフトウェアではない企業の場合です。 主な活動がソフトウェアではない企業では、SRE は他の場所とまったく同じように機能します。企業では、開発されていない場合でもソフトウェア製品も使用する必要があり、更新をロールアウトする必要があり、変更する必要があるためです。インフラストラクチャは成長する必要があり、拡張する必要があります。 そして、SRE は、これらのプロセスで起こり得る問題を特定して予測し、ある程度の成長が始まりビジネス ニーズが変化した後にそれらを制御するのに役立ちます。 少なくとも数台のサーバーがあり、少なくともある程度の成長が見込まれる場合には、SRE を導入するためにソフトウェア開発に関与する必要はまったくありません。

大企業には実験するための予算とスペースがあるため、小規模なプロジェクトや小規模な組織にも同じことが当てはまります。 しかし同時に、これらの実験の成果はすべてどこでも使用できます。つまり、SRE は、もちろん Google、Netflix、Dropbox にも登場しました。 しかし同時に、中小企業や新興企業はすでに凝縮された資料を読んだり、本を読んだり、レポートを見たりすることができます。 彼らはそれについてより頻繁に聞くようになり、具体的な例を見て、私はそれが大丈夫だと思います、それは本当に役立つ可能性があります、これは私たちにも必要です、それは素晴らしいです。

つまり、これらのプロセスを標準化するための主要な作業はすべてすでに行われています。 あなたの会社における SRE の役割を具体的に決定し、これらすべてのプラクティスを実際に実装し始めるのはあなた自身です。これらのプラクティスについては、すでに説明しました。 つまり、中小企業にとって有益な原則から、これは常に SLA、SLI、SLO の定義になります。 ソフトウェアに関与していない場合、これらは内部 SLA と内部 SLO、つまりエラーに対する内部予算になります。 これはほとんどの場合、チーム内やビジネス内で興味深い議論につながります。インフラストラクチャや、ある種の理想的なプロセスの組織、理想的なパイプラインに必要以上の費用がかかることが判明する可能性があるためです。 IT 部門にあるこれらの 4 つのナインは、現在は実際には必要ありません。 しかし同時に、時間を費やし、ミスのために予算を他のことに費やすこともできます。

したがって、監視と監視の組織化は、どのような規模の企業にとっても有益です。 そして一般的に、間違いは許容され、予算があり、目標がある場合、この考え方は、3 人のスタートアップから始めて、あらゆる規模の会社にとっても役立ちます。

技術的なニュアンスについて最後に説明するのは、モニタリングです。 SLA、SLI、SLO について話している場合、予算内に収まっているかどうか、目標を遵守しているかどうか、最終的な SLA にどのような影響を与えるかを監視することなしには理解できないからです。 私は、監視が次のように行われるのを何度も見てきました。たとえば、サーバーへのリクエストの時間、平均時間、データベースへのリクエストの数など、何らかの値があります。 彼にはエンジニアが決めた基準がある。 メトリクスが標準から逸脱すると、電子メールが届きます。 原則として、これはすべてまったく役に立ちません。まず、人が毎回アラートを解釈する必要がある場合、つまり、メトリクスの値が意味するかどうかを判断する必要がある場合、大量のアラートや監視からの大量のメッセージが発生するためです。何らかの行動が必要だということ。 そして第二に、基本的に何もアクションを必要としない場合、彼はこれらすべてのアラートに気付かなくなるだけです。 これは優れた監視ルールであり、SRE を実装する際の最初のルールは、通知はアクションが必要な場合にのみ送信されるべきであるということです。

標準的なケースでは、イベントには 3 つのレベルがあります。 アラート、チケット、ログがあります。 アラートは、すぐに行動を起こす必要があるものです。 つまり、すべてが壊れているので、今すぐ修正する必要があります。 チケットは遅延したアクションが必要なものです。 はい、何かをする必要があります。手動で何かをする必要があります。自動化は失敗しましたが、次の数分間はそれを行う必要はありません。 ログとはアクションを必要としないものであり、通常、物事がうまくいけば誰もそれを読むことはありません。 ログを読む必要があるのは、振り返ってみると、しばらくの間、私たちが気づかなかった何かが壊れていたことが判明した場合だけです。 それとも、いくつかの調査を行う必要がありますか。 ただし、一般に、アクションを必要としないものはすべてログに記録されます。

これらすべての副作用として、アクションが必要なイベントを定義し、それらのアクションがどのようなものであるべきかを十分に説明できた場合、これはアクションを自動化できることを意味します。 つまり、何が起こるかということです。 警戒から出発します。 行動に移してみましょう。 このアクションの説明に進みます。 そして、自動化に移ります。 つまり、あらゆる自動化はイベントへの反応から始まります。

監視から、可観測性と呼ばれる用語に移ります。 ここ数年、この言葉についてちょっとした誇大宣伝も行われてきました。 そして、文脈を無視してその意味を理解する人はほとんどいません。 しかし重要な点は、可観測性はシステムの透明性の指標であるということです。 何か問題が発生した場合、正確に何が問題だったか、またその時点でシステムがどのような状態であったかをどれだけ早く判断できるか。 コードに関して言えば、どの関数が失敗したか、どのサービスが失敗したか。 たとえば、内部変数や設定の状態はどうなっていましたか。 インフラストラクチャの観点からは、障害が発生した可用性ゾーンと、Kubernetes がある場合は、障害が発生したポッドとポッドの状態が示されます。 したがって、可観測性は MTTR と直接の関係があります。 サービスの可観測性が高いほど、エラーの特定が容易になり、エラーの修正が容易になり、エラーの自動化が容易になり、MTTR が低くなります。

再び中小企業の話に戻りますが、チームの規模にどう対処するか、小規模なチームには別の SRE を雇う必要があるのか​​、という疑問は今でもよく聞かれます。 これについては少し前にすでに話しました。 スタートアップやチームなどの開発の最初の段階では、SRE を暫定的な役割にすることができるため、これはまったく必要ありません。 そして、少なくともある程度の多様性があるので、これによりチームが少し活性化されます。 さらに、成長に伴い、一般に SRE の責任が非常に大きく変化するという事実に人々が備えることができます。 人を雇う場合、当然、その人はある程度の期待を持っています。 そして、これらの期待は時間が経っても変わりませんが、要件は大きく変化します。 したがって、SRE をどのように雇用するかは、初期段階では非常に困難です。 自分で栽培する方がはるかに簡単です。 しかし、考えてみる価値はあります。

おそらく唯一の例外は、非常に厳格で明確に定義された成長要件がある場合です。 つまり、スタートアップの場合、これは投資家からの何らかの圧力、一度に数倍の成長を予測する何らかの圧力である可能性があります。 その場合、SRE を雇用することは、正当化できるため、基本的に正当化されます。 私たちには成長のための要件が​​あり、そのような成長によって何も壊れないという事実に責任を負う人材が必要です。

もう一つ質問です。 開発者がテストに合格した機能を何度もカットしたが、本番環境が中断され、ベースがロードされ、他の機能が中断された場合に何をすべきか、どのようなプロセスを実装するか。 したがって、この場合、導入されるのはエラーに対する予算です。 また、一部のサービス、一部の機能はすでに本番環境でテストされています。 少数のユーザーのみが、すでに実稼働環境にある機能がデプロイされている場合は、カナリアになる可能性がありますが、たとえば、すべてのユーザーの XNUMX パーセントで何かが壊れても、まだ要件を満たすことが期待されています。エラーに対する予算。 したがって、はい、エラーが発生し、一部のユーザーにとってはすべてが壊れますが、これは正常であるとすでに述べました。

SREツールについての質問がありました。 つまり、SRE が使用するもので、他の人は使用しないものは何かあるでしょうか。 実際、高度に専門化されたユーティリティがいくつかあり、たとえば、負荷をシミュレートしたり、カナリア A/B テストに従事したりするある種のソフトウェアがあります。 ただし、基本的に SRE ツールキットは開発者がすでに使用しているものです。 SRE は開発チームと直接対話するためです。 また、異なるツールを使用している場合、同期に時間がかかることがわかります。 特に、SRE が大規模なチームで作業している場合、複数のチームが存在する大企業では、全社的な標準化が非常に役立ちます。50 のチームで 50 の異なるユーティリティが使用されている場合、SRE はそれらのユーティリティを把握している必要があるためです。全て。 そしてもちろん、そんなことは決して起こらない。 そして、少なくとも一部のチームの仕事の質、管理の質は大幅に低下するでしょう。

ウェビナーが終わりに近づいています。 いくつかの基本的なことを伝えることができました。 もちろん、SRE については XNUMX 時間で語ったり理解したりできるものではありません。 しかし、この考え方、主要なポイントは伝えることができたと思います。 そして、興味があれば、そのトピックを掘り下げ、自分で学び、他の人や他の会社でそれがどのように実装されているかを見ることができます。 したがって、XNUMX 月初旬に Slurm SRE までお越しください。

Slurm SRE は XNUMX 日間の集中コースで、私が今話していることについて話しますが、より深く、実際のケースを使用し、実践を伴うため、集中コース全体が実践的な作業を目的としています。 人々はチームに分かれます。 皆さんは実際のケースに取り組むことになります。 したがって、Booking.comのインストラクターであるIvan KruglovとBen Tylerがいます。 サンフランシスコ出身の Google 出身の素晴らしい Eugene Barabbas が来ています。 そして、私もあなたに何か言います。 ぜひご来店ください。
それで、参考文献。 SREに関する参考文献があります。 最初の 同じ本、というより Google が書いた SRE に関する 2 冊の本についてです。 もう一つ SLA、SLI、SLO に関する小さな記事ここでは、用語とその適用についてもう少し詳しく説明します。 次の 3 つは、さまざまな企業の SRE に関するレポートです。 初め - SRE の鍵、これはGoogleのBen Trainerによる基調講演です。 XNUMX番 - Dropbox の SRE。 XNUMXつ目はまた SRE から Google へ。 からの第XNUMX報 Netflix の SRE、5 か国に主要な SRE 従業員は 190 人しかいません。 これらすべてを見るのは非常に興味深いことです。DevOps が異なる企業、さらには異なるチームにとって意味するものが大きく異なるのと同じように、SRE は、たとえ同じ規模の企業であっても、非常に異なる責任を負っているからです。

カオス エンジニアリングの原理に関するリンクがさらに 2 つあります。 (1), (2)。 最後に、「素晴らしいリスト」シリーズからの 3 つのリストがあります。 カオスエンジニアリングについて SRE 約 SRE ツールキット。 SRE のリストは信じられないほど膨大です。すべてに目を通す必要はありません。約 200 の記事があります。 キャパシティ プランニングと責任のない事後分析に関する記事を強くお勧めします。

興味深い記事： 人生の選択肢としての SRE

いつも聞いていただきありがとうございます。 何かを学んだことを願っています。 さらに学ぶために十分な資料が手元にあることを願っています。 それではまた。 できればXNUMX月に。
ウェビナーはエドゥアルド・メドベージェフ氏が主催しました。

PS: 読書が好きな人のために、Eduard が参考文献のリストを提供しました。 実際に理解したい方は大歓迎です スラーム SRE.

出所： habr.com