Google Cloud Platform

SRE チームの評価に役立つレベル別チェック リスト

DevOps_BlogHeader_D_Rnd3ifhy.JPEG

※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。

このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering(SRE)は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。

SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、SRE の構築に向けてスタートを切り、SRE プラクティスを実行に移すための具体的なヒントを提供します(本稿では、ワークブック内の章に対応する本稿での記述箇所にリンクを付加しています)。

私たちはよく、SRE の実施とは実際にどういうことなのかと尋ねられます。これは、お客様がそれぞれの SRE プラクティス を築き上げていくうえで、達成度の定量化に苦労されているからでしょう。この問題に対する単純で標準的な答えはありませんが、本稿では、初歩的なものから順に達成度を測るためのチェック リストを示していきます(決して網羅的なものではありませんが)。このチェック リストは、高信頼性サービスの担当部門が SRE モデルに向かってチームを変えていこうとするときに役立ちます。どのチェック リストも項目は時系列順に並べてありますが、実際のニーズや優先順位がチームによって異なることは私たちも認識しています。

経験豊富な SRE チームに属する方にとっては、このチェック リストは業界ベンチマークの 1 つとして役に立つかもしれません。他の人たちも自身のチェック リストをぜひ公開してください。もちろん、SRE は厳密な科学ではなく、実現過程でさまざまな難問にぶつかるでしょう。各項目の 100 % 達成には至らないかもしれません。それでも、継続していくことが SRE にとって大切だということを、私たちは Google での経験から知っています。

SRE の基本

次の 3 つは SRE の基本原則ですが、本番システムに対して責任を負うチームであれば、名前がどうであれ、SRE チームを作る前から、あるいは SRE チームへの転換と並行して、広く採用しているプラクティスでもあります。


初級者チーム

Google の SRE チームは、全部ではなくてもそのほとんどが、次のプラクティスと特長を確立しています。チームが置かれた環境にこれらの実現を阻むもっともな理由がないかぎり、私たちはこれらを、優れた SRE チームの基礎だと考えています。


次の項目も、発足したばかりの SRE チームで一般的になっているものです。こういうものがなければ、チームが不健全で持続可能性に問題がある兆候かもしれません。


中級者チーム

以下の項目は経験豊富なチームで一般的に見られるもので、チームがサービスの効率的な管理に積極的に取り組んでいることを示しています。


上級者チーム

次の項目は特にスキルの高いチームに見られるものですが、複数または全社の SRE チームがより広範な憲章を共有することで実現できる場合もあります。


以下は、望ましい SRE の特長でありながら、実際にはほとんどの企業が実現できていないものです。

  • SRE のオンコールが年中無休の 24 時間体制ではないこと。米国と欧州というように SRE チームが 2 つの地域に分散されており、どちらも副次的な扱いになっていないこと
  • SRE と開発チームが目標を共有し、SVP 以上の幹部からの指揮命令系統が別々になっていること(利害衝突を防ぐことに役立ちます)

次に何をすべきか

以上のチェック リストに目を通したら、次のステップは、その内容が自社のニーズに合うかどうかを考えることです。

まだ SRE チームが存在せず、初級者チーム向けチェック リストの多くが未達なら、冒頭で紹介した SRE ワークブックを最初の章から順に読むことを強くお勧めします。自社が Google Cloud Platform(GCP)のユーザーで、CRE の関与を希望される場合は、アカウント マネージャーに連絡してこのプログラムに応募してください。ただし、SRE はさまざまなインフラストラクチャに適用できるメソドロジーであり、この一連のエンジニアリング手法を用いるうえで Google Cloud の使用は前提条件でないということを、はっきりさせておきたいと思います。

また、人材採用の停滞などを解決するベスト プラクティスを共有するため、既存のカンファレンスに出席したり、他社とのサミットを組織したりすることもお勧めします。

変化の激しさゆえに、上級者チーム向けチェック リストの達成に苦労しているチームもよく見かけます。システム変更や人事異動が上達の遅延要因になるかもしれません。チームが初級者レベルの段階に逆戻りするなどの問題を避けるため、Google の SRE リーダーたちは、6 か月ごとにそれぞれのチームの主要指標をチェックしています。この場合、一部の項目はすでに標準になっているので、チェック範囲は上記のチェック リストよりも狭くなっています。

すでにお気づきかもしれませんが、本稿の中心的な問いに答えるということは、チームの影響力と健全性、そして何よりも大切なことですが、実際の仕事のしかたを評価するということです。結局のところ、最初の SRE 本で書いたように、自動化できないプロセスやソリューションを作っているなら、システムを維持するために人員を確保し続けなければなりません。人間がいなければ仕事がまわらないのであれば、人間の血と汗と涙をマシンに注ぎ込んでください。

だからこそ、あなたはもう SRE チームを設けているのでしょう。そのチームは効果的ですか? スケーラブルですか? 人々は満足していますか? SRE チームのスキルがどの程度であっても、チームの仕事と会社のサービスにはまだまだ発展、成長、強化の余地があるはずです。SRE チームの立ち上げ方をもっと詳しく学びたい方はこちらを参照してください。

本稿に力を貸してくれた多くの人々、特に Adrian Hilton、Alec Warner、David Ferguson、Eric Harvieux、Matt Brown、Myk Taylor、Stephen Thorne、Todd Underwood、Vivek Rau の各氏に感謝いたします。

- By Gustavo Franco, Customer Reliability Engineer