NGINX Conf 2019 での LinkedIn、Dell、Gremlin によるサイト信頼性エンジニアリング パネルから得られた 3 つの重要なポイント

NGINX Conf 2019 では、さまざまなテーマを扱った50 以上の録画セッションを実施しましたが、このブログでは、業界で最もホットなトピックの 1 つから得た教訓を共有します。 サイト信頼性エンジニアリング (および関連トピックのカオス エンジニアリング)。 ここでは 3 つの重要なポイントに焦点を当てますが、セッション全体をこちらで視聴することをお勧めします。

1.    SRE の定義

会話は、パネリストがサイト信頼性エンジニアリングという用語をどのように定義するかから始まり、パネリストは一貫して、本質的には次のようになるとコメントしました。 「サイトが稼働していることを確認するために何でもします。」 しかし、それだけでなく、彼らは「問題が発生したときには徹底的に調査し、できるだけ早く問題を解決すること」と「顧客中心の考え方で開発チームを支援すること」も強調しました。 また、説明の中に従来のネットワーク運用チームとのおおよその類似点がいくつかあることに気づきましたか? はい、私もそう思います。しかし、あるパネリストは私の考えを汲み取って、「一部の組織では、ネットワーク運用チームの名前を変更するだけで SRE チームを設立していますが、これは最善の方法ではありません」と強調しました。 これについてはいくつか議論がありましたが、私がここで得た教訓は、SRE と NetOps の最大の違いは、SRE 担当者が「開発チームまたは顧客対応チームに所属し、ビジネス目標に真に集中する」ということだということです。

2.    カオスエンジニアリングと障害注入

SRE 機能の重要なトピックの 1 つは、カオス エンジニアリングの概念です。 カオス エンジニアリングの詳細な説明はこの記事に譲りますが、このセッションでは、実際には「重大な障害を特定し、迅速に修正するためのアプローチ」、つまり消防訓練に似たものについて説明します。 カオス エンジニアリングは火災訓練との類似点もありますが、回復、耐久性、可用性のメトリックを定量的に分析することに重点を置いている点で、その目標はより広範囲にわたります。

障害注入は、2014 年にNetflix によって導入された、かなり一般的な方法です。 これは、障害シミュレーション メタデータをテスト目的で、制御しながら運用環境にプッシュするテスト手法です。 これらの取り組みは通常、サービス (またはサイト) の可用性と信頼性を高めるために SRE チームによって主導されます。

3.    SRE の KPI とスキルセット

SRE をどのように測定すべきかについて興味深い議論がありました。 MTTD (平均検出時間) と MTTR (平均応答時間) が重要な指標であるという点についてはいくつかの指摘がありましたが、パネリスト全員が、指標は業界や運用するシステムやサイトによって異なることに同意しました。 議論から得られた良い提案は、「まず、次のような質問をしてみるとよいでしょう。 「『最も重要なシステムのトップ 5 は何ですか?』と尋ねると、優先順位を決めるのに役立ちます。」

SRE 職に求められるスキルセットも、取り上げられたトピックの 1 つです。 パネリストによると、これは実行するシステムによっても異なります。 (たとえば、NGINX を実行している場合、SRE の採用には NGINX の経験が重要になります。) グループからの素晴らしい提案は、SRE リソースを拡大し、より適切に装備するために、会社のさまざまな領域とシステム間で SRE 担当者をローテーションさせる方法を検討することでした。 また、SRE チームがトレーニング、オフサイト、専用の Slack チャンネル、「ゲーム デー」などの SRE コミュニティ イベントやアクティビティに参加するようにしてください。その他の役立つ提案もご覧ください。

結論 – 2020 年は独自の SRE 戦略を定義する時期でしょうか?

一言で言えば、多くの組織が SRE の概念と役割をどのように定義し、活用するかをまだ学習中であることが明らかになりました。また、パネリストが繰り返し述べたように、これらは業界やシステム (さらには個々の企業) によって異なることがよくあります。 全体的に、カオス エンジニアリングは来年も引き続き取り組むことになります。おそらく、これは、これがあなたとあなたの組織にとって何を意味するのかを考え始めるのに最適な時期なのではないでしょうか。