目次
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「SRE のこれまでとこれから」です。（開催日：2020年 6月16日）。第2部では、登壇者の古川さんの基調講演から SRE の文化や考え方を解説したうえで、組織に導入するための準備から、誰に何を説明するべきかなど、詳しく紹介していきます。
Infra Study Meetup の開催意義もそうですし、SRE や他のプラクティスは本で出ていると思います。しかし、文化や考え方は、本だけだとうまく伝えにくいですし、多くは出回っていないと思うので、SRE の文化を切り口に紹介しようと思いました。
文化とは、たとえば仮に SRE とか、SLI / SLO みたいなプラクティスがなかったと仮定して、どういった考え方、文化を持ってる組織ならば、今の SRE を生み出すことができるかといった視点で考えています。これができるようになれば、今の SLI / SLO を真似たうえで、さらに自分たちの組織にあった形に改良、または応用できると思います。
とはいえ、私も約1年しか学んでなく、まだ悩んでるところもあるので、こういう見方もあるんだなくらいの気持ちでみてほしいです。
人と機械のシステムは外せない要素だと思っていて、開発・運用する人のシステムや、利用するユーザーと入れていますが、それに加えて今までのインフラエンジニアとしてみてきたシステムの2つがあります。
開発チームと運用チームの信頼関係に関して、コミュニケーションスキルを思い浮かべて、技術的ではないという人もいますが、2つのシステムが揃って信頼性が成り立つので、ここもみていく必要があります。
SRE 本でも、SLI / SLO を満たしているとユーザーもうれしいと書いてありますが、信頼関係の話題は SRE 本でも少し薄いと思っていて、Google もおそらく同じ考えです。なので、 CRE（Customer Reliability Engineering；顧客信頼性エンジニアリング）が出てきたんでしょう。
つまり、内部の話 + エンドユーザーまで一気通関で、そこの考えが身につくことによって、初めてユーザーとの信頼関係も生まれてくるので CRE という外側に対するアプローチが重要です。
だから SRE に関するアウトプットを、Google は PDF などで公開していますが、それはある意味、Google自身のためでもあり、ユーザーと信頼関係を見出すためにやっているでしょう。インフラとアプリケーションの信頼性も大事な要素です。
信頼性にフォーカスした際の判断基準は、考え方とか設計思想のなかで信頼性が重要だと思っていて、これは信頼性を上げることよりも、信頼性に関して興味を持つことだと思います。たとえばインシデント対応、On Call対応や、変化に対しても、SREとしては、関心を持つべき項目だと思います。
たとえば Dokerfileや、CIC をどっちが組むかの話題がありましたが、SRE の分野からみたら、どっちがどっちのものかは関係なく、信頼性に関わるものなら SRE の範疇だと思います。
インフラシステムを作り出している人たちであれば、コンピュータサイエンスが重要だと理解してると思います。人のシステムを考える場合は人の心理も重要になるので、批難のないポストモーテム文化は、SRE本に載っていますし、障害時のストレス配下での精神状態を知っておくといい心理学に関することも載っています。
理由はその信頼性も見ていかないと全体の信頼性が保てないからです。なので、信頼性全体に対して興味を持ち、関心事にするのが考え方として重要だと思います。
SRE に限らず、完全を目指さない、信頼性100%を目指さない、Toil を0%にするのはなかなか難しいです。オペレーションをすべてなくす、1回のチャレンジで完全を目指すなど、SRE はとても分野が広いです。一人一人の能力にフォーカスして分野を切るわけではなく、信頼性にフォーカスして分野を切っているからです。1人ですべて SRE を実施する必要もスキルを全部獲得する必要もないでしょう。
あとは信頼性とのトレードオフです。速度と信頼性の変化量に対して、信頼性はトレードオフにあります。
ソフトウェアエンジニアリングや、分散システムのオブザーバビリティをやるシステムエンジニアリングの話は重要ですが、エンジニアリングを何か工学的アプローチととらえたほうがいいです。
たとえばトレードオフは、バランスであり、バランスを取れる人間がうまくやるといったら、”サイトリライアビリティ”までしかいきません。
これをモデルに仕込んで定量分析して、SLI / SLO のようなプラクティスを産んだことが価値のあることです。そこが”サイトリライアビリティエンジニアリング”だと思っています。信頼性にフォーカスして、そこの分野を考えつつ、考え方を狭めないでやっていくのが SRE の文化だと思います。
最後に SRE と組織です。どうやって導入するかを話します。
先ほど紹介した定義や文化を使い、社内でSLI / SLO を導入するための考え方や進め方を紹介します。
組織に SRE を実装すると考えてみましょう。システムに変更を加えることは、信頼性が下がることを意味するので段階的に入れたり、バランスを取る必要があります。
組織の信頼性が下がれば、SRE をストレスに感じたり、やりたくないと思われる確率が上がるため安全にやるのであれば、導入に時間はかかるし、いきなり複雑なものを入れないようにして、最初から完全を目指さないのがポイントです。
あとはシステムをリプレースするときに、当然そのシステムを知らないとリプレースできません。組織の規模や組織に対する変更手順。誰にいったら組織マネジメントをしている人に伝わるか。誰がマネジメントしているのか。そういったものをやってる人たちにいえば、ちゃんと実装されるのかどうかなど、リリース手順が整備されているか。また一部の部署で試す（カナリアリリース）ことができるのか。
実際のシステムでデプロイ手順もカナリアリリースもできない状態から、大きなシステムをインフラ技術で移行するのは怖いと思います。これは組織側も同じです。
組織が挑戦可能で失敗を非難しない文化でないと挑戦がしづらいし、評価をしてくれなければ、メンバーが違う組織に移ってしまいます。経営側の人にとって、それは損なので、そういった文化をちゃんと作ろうと説明するのがよいです。
SLI / SLO になると誰に説明するかを考えなくてはいけません。まず条件を決定できる人には、SRE を説明する必要があります。プロダクトマネージャーやプロダクトオーナー、 CTO や経営陣に説明する必要があります。
別会社の場合はとても難しいと思います。自分たちの考えを述べるだけではうまくいかないので、先方とうまく連携して課題解決する必要があります。
当然システムに関係する人にも説明する必要があります。開発チームと SRE チームは思い浮かぶと思いますが、カスタマーサポート、営業チームの人にも説明する必要があります。
何を説明するかですが、すべてを説明するのは難しいと思います。特に非エンジニアであれば、なおさらです。自分の専門分野じゃないものをいきなり渡されても読まないと思います。
ハードルが高いと思うので、たとえば SLI / SLO だったら、昨日発売された SRE ワークブックの2章、インプリメンティング SLO がおすすめです。あとは3章のリスクの受容や、4章のサービスレベル目標を抜き出して、説明したらいいと思います。
あとはビジネスにとって SRE が便利だと示すのも重要です。ビジネスにとって便利なツールでないと導入しないと思うので、そこら辺のデータがあれば示すといいと思います。
この発表資料は、初学者向けではないと思っています。SRE本を1回読んだり、「はじめに」を読んだ人が、どういった文化なのかを考え直すような仕様なので、この資料は流用できません。
私が作った資料は「わかる！ SRE ！」と、どっかで聞いたような、複雑でないタイトル名をつけて、覚えてもらえるように実施しました。
あとはアンケートをとって、資料をブラッシュアップしたり、フィードバックを得ておくといいと思います。
そういった説明をして、どこかのチームで実施するとなれば、準備をしていきます。
先ほどのシステムに機能を追加するみたいな話ですが、モックを作ったあと、ある程度これで良さそうと思えば、システム構成図やデザインドキュメントを書いたりすると思いますが、 SLI / SLO を導入する際には、ドキュメントをこういう設計でやっていると書いてもらうのがいいと思います。
たとえば SLO Docs 、ドキュメントのレビューをどうやってサイクルを回していくかや、誰が何をするのかです。
進め方については細かい話をしませんが、SLO を実装して SLI を実装してもいいし、 SLI を実装してからSLO を現場から提示するでも、どちらでもいいと思います。どちらでもいいですが、まずはサイクルを回していくことが重要です。
これは Mackerel チームの図ですが、Developer や SRE チーム、マネージャーがいて、Performance Working Group というのを毎スプリントやっています。そこで SLO を確認したり、スプリント会で見直しましょうとか、決定しましょう、SLO の決定権はプロジェクトオーナーにありますよなど。
CRE も、SLO に関しては敏感になってほしいです。スプリント会で一緒に見ましょう。こういう形でやっていきます。という図を作るといいです。
SLO Docs やエラーバジェットポリシーを作れば、それが設計ドキュメントになります。
その他 CTO などの決定権を持つ人と共同で進めると楽ですよとか、SREs の横断的組織を作るといいですよと書いてあります。
考え方に関しては、たとえば、SLI / SLO のプラクティスは、日本語版が発売された SRE ワークブックのインプリメント SLO に書いてある内容で、プラクティスにしたがっていれば自然とこうなります。
今日の発表の意図としては、そういったプラクティスが公開されてなくても、先ほどの文化や考え方を持って、一つ一つちゃんと考えていくと、今のSLI / SLO やプラクティスに近い形で実装できると思ったので、紹介しました。
これからは、より組織にあった SRE を実践したり、自分たちで作って、応用していく必要があります。プラクティスを真似るだけでなく、自分たちで生み出していく力も必要になります。真似るのも重要ですが、真似したうえで、思想、哲学、文化を理解して使えると、より強力です。
今回は私が考える SRE の定義を紹介しました。定義や文化、SRE を使うとSLI / SLO のプラクティスに近い形で実施できましたし、そういったことを考えていくことで、たとえば、受託でプロダクトオーナーが別の会社組織にいて、文化が違う場合に、うまくやる方法を自分たちで考えていくための力になるんじゃないかと思います。
ご清聴ありがとうございました。
SRE。2021年夏までMackerel SREチームのテックリードとしてMackerelの運用を担当。 現在はMackerelの運用に加え、CTOと共に社内全体のSRE組織作りに取り組んでいる。
