SRE の要素とオブザーバビリティの実践への道のり
はじめに
こんにちは。Datadog Japan で Sales Engineer をしている 木村健人(AoTo)です。 Google Cloud の公式ユーザーグループ Jagu’e’r(Japan Google Cloud Usergrouup for Enterprise) では、Observability-SRE 分科会の運営をしています。
システムに携わる方々(開発者・運用者・プロダクトマネージャーなど)がオブザーバビリティを導入し実践するまで、どのような道のりを辿れば良いのでしょうか。
ある日 SRE としての役割を受け持った際、どのような過程を経てオブザーバビリティの実践へ至るのでしょうか。
本記事では、日々の業務やコミュニティで関わる方々を参考に、どのようにして SRE を浸透させオブザーバビリティの実践まで辿り着くかを「SRE の要素」と共に考察します。
免責事項
本記事内で説明される内容は、筆者個人の経験に基づく意見・考え方の一例であり、所属組織を代表するものでは一切ございません。 この記事は『SRE をはじめよう』をはじめとする SRE 関連書籍の知見を踏まえて、筆者独自の視点から 「SRE の要素」を定義しオブザーバビリティの実践との関連を考察するものです。
SRE の要素
ここからは、SRE の思想・文化・役割・組織・実践という軸で考察をします。
皆さんご存知の通り、SRE とは Site Reliability Engineering の略称です。 SRE の定義は「組織がシステム・サービス・製品において適切なレベルの信頼性を継続的なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野」と『SRE をはじめよう』の冒頭で触れられています。
そのため、そもそも SRE は思想・文化・役割・組織・実践を指すのではなく、それらの元となるエンジニアリング=工学分野を指すということです。 SRE そのものや思想・文化・実践を ※SREing*、SRE を目的として活動する役割・組織を SREs と区別して記載することもあります。
今回はこれらを区別せずに、思想・文化・役割・組織・実践を SRE の各要素1として捉えます。そして、それぞれの要素から SRE をはじめる際に、どのように SRE を成熟させるかを考察します。そして、オブザーバビリティの実践に果たす役割と失敗する要因を例示します。
SRE の思想
SRE が生まれた Google でも、SRE という名前がつく前から思想として広がるところから始まったはずです。 エンジニアリングやプロダクトに SRE を浸透させていくには、まずその思想を理解することから始まります。2
個人が SRE の思想を理解し賛同することで、SRE の支持をする文化が醸成されていきます。そうしてやがて SRE の実践を役割としてもつ個人や組織が生まれ、最終的に実践につながります。
図1: 思想からはじめる SRE
しかし、これらの要素は必ずしも順序立てて成熟していくものではありません。実際には思想から始まり文化が醸成される前に何かしらが実験的に実践されたり、組織ができることで文化が醸成されることも多くあります。 各要素は相互補完的でありながらも、SRE の思想はこれらの中でも重要な位置を占めていることは間違いありません。思想を理解しないと文化は醸成できませんし、誤った実践を推進する可能性もあります。
図2: 思想を中心とした SRE
SRE の思想とオブザーバビリティの実践
SRE の思想は、オブザーバビリティの実践に欠かせないものです。 監視エージェントのデプロイ・アプリケーションの計装・ログの収集を経てオブザーバビリティを導入しても、それらのテレメトリの正しい扱い方がわからなければシステムのオブザーバビリティは獲得できません。
一方で、こうした SRE の思想や実践を文献の通りに取り入れようとすることで失敗につながります。 こうした思想が自分の所属する組織にどのように受け入れられるのか、どのようにして実践できるのかを考える必要があります。
SRE の文化
SRE の思想を個人ではなく組織へ浸透させるには、その文化を醸成していく必要があります。 この文化は SRE の思想を理解していなくても、自然と発生する可能性があります。「非難のないポストモーテム」のように SRE でも大切とされる文化は、成熟した運用組織では達成されている場合が非常に多いです。
こうした組織文化からどういったものが SRE に必要とされるかを理解することで、「SRE の文化」を作り上げることができます。 しかし、こうした文化を醸成するには、実際に取り組まれているいくつかの実践からのフィードバックも必要となります。そして、SRE の文化を作り上げていくことも、役割としての SRE の責務です。
図3: SRE の文化に作用する各要素
SRE の文化とオブザーバビリティの実践
SRE の文化があることで、オブザーバビリティの実践は加速します。 必ずと言って良いほど、SRE の文化は監視・オブザーバビリティを土台として必要としています。
一方で、文化があり思想が理解されない場合は個人の不満に繋がりますし、役割や組織としての SRE が出来上がらなければその文化は長続きしません。 望ましい文化の下支えとして、肩書き(組織・役割)として SRE を名乗れる状況が求められます。
SRE の組織・役割
SRE の肩書き(組織・役割)が出来上がることで、思想や文化を組織に定着させやすくなります。 突然ソフトウェアエンジニアや運用エンジニアから SRE に肩書きが変わった際に、意欲的な個人は SRE の思想を学び文化を作り上げます。
しかし一方で、なんとなくで SRE になってしまった個人の場合はどうでしょうか。私の知る限りでは、このパターンで SRE 肩書きとなる人が最も多く、そして最も失敗するパターンです。 SRE の肩書きを受け持ったがその中身や実態に変化がない場合は、「SRE」という言葉は形骸化し(肩書きのイメージの向上以外に)意味をなさなくなります。
図4: 形骸化した SRE の組織と役割
SRE の形骸化はどのように避けられるのでしょうか。 それは「SRE」という名称を肩書きにする前に、その組織・役割のミッションを見直すことです。
組織・役割のミッションが「ソフウェアのバグ改修」や「オンコール業務」であったなら、「信頼性の向上による成果」など SRE の思想を反映したミッションを取り入れることが重要です。そして可能であれば、SRE の思想をある程度理解している個人が最初の SRE となることが理想です。
SRE の組織・役割とオブザーバビリティの実践
オブザーバビリティの実践を推進するために、SRE の肩書きが役に立ちます。 オブザーバビリティを実践する上では必ずしも肩書きは必要ありませんが、それを自らの責務として実行する組織・役割があることでオブザーバビリティが推進されます。
一方で、前述のように SRE の思想や文化が伴わない場合は、オブザーバビリティを導入したとしてもそれを適切に扱えずに失敗に繋がります。 役割・組織に SRE の思想・文化を取り入れたミッションを設定することで、個人や集団が SRE の思想や文化を受け入れやすくなり、やがてそれらが自身の思想・文化になります。
図5: SRE のミッションの思想と文化への作用
SRE の実践
サイトリライアビリティワークブックによると、運用業務はオンコール業務・リクエスト対応・インシデント対応・ポストモーテムの4つに分類されます。これらの運用業務だけでなく、運用業務のトイルを削減するための施策を実行するのもまた SRE の実践で重要な項目です。
これらの実践は SRE の各要素に支えられて実現できるものですが、実践を通して SRE への理解を深め文化や組織を成長させることも可能です。 そのため、詳細に思想を理解したり正式に肩書きを得る前に、できることから SRE の実践を推進するアプローチも有効です。
ただし、これらの実践が適切に評価されたり、正式な役割として受け入れられるためには、SRE の文化や肩書きが整っていることが望ましいです。
図6: SRE の実践を支える各要素
SRE の実践オブザーバビリティの実践
SRE の実践をする中で、オブザーバビリティも自然と実践されるはずです。 オブザーバビリティはプロダクトの信頼性を向上させる基礎であり、オブザーバビリティなくして SRE は実践できません。
しかし、オブザーバビリティの向上に限らない SRE の実践だけを重視してしまうと、運用業務をこなすだけで満足してしまう場合があります。いわゆる「アラート疲れ」や「アンコールモンキー」と呼ばれる状態です。 これらは、オブザーバビリティの導入によりアラートのトリガーだけを増やし、効果的な通知や対処方法を考慮していない状態です。
こうした状態は SRE の責務を全うしている感覚を得て、本当に必要な「トイルの削減」や「50%ルール」などの実践を疎かにしてしまいます。 特定の業務を実践することを重視するのではなく、「トイルの削減」のようにそれらの効率化を推進する施作も重要な項目であることを忘れないようにしましょう。
おわりに
ここで取り上げた SRE の各要素は、どれもオブザーバビリティの実践にとって重要です。そして、どこからでも SRE をはじめる機会があります。 SRE に興味があり自身のプロダクトに取り入れたい場合や、役割・組織として SRE をはじめる・関わることになった時に、オブザーバビリティの実践までどのような要素が必要かを考えるきっかけとなれば幸いです。
また、ご自身の SRE の取り組みやチームの成熟度を確認したい場合は、Google Cloud のブログに公開されている『SRE チームの評価に役立つレベル別チェック リスト』を是非お試しください。
そして、オブザーバビリティの導入から実践までは、まだまだ必要な段階があります。 SRE Magazine 003号の『それでも、SRE の銀の弾丸を求めて』でも触れたサービスの信頼性階層では、オブザーバビリティは信頼性に対する取り組みのはじまりでしかありません。
オブザーバビリティを導入するだけではなく実践して理解を深めるためにも、オライリーの SRE 本を是非お手にとってみてください。 それぞれの SRE にとって最適な形のオブザーバビリティの形が見えてくるはずです。