目次
2022.05.08 2023.08.14 約5分
| この記事は、2020年6月16日に行われた フォークウェルが主催する技術イベント「Infra Study」の内容を再編集し、記事化したものです。 |
Googleが提唱した「SRE」。現在では多くの組織で実践されています。しかし、プロダクトの性質、組織の規模、チーム構成などと切り離して考えることは難しく、組織毎に異なった課題が出てくることも事実。自分たちの組織にあったSREを取り入れるためには、SREの文化を理解することが重要です。本記事では、SREの原理原則、文化を再整理し、どのように組織で取り組むかを紹介します。
私は2019年頃から SREを学び始めたので、初心者から中級者になるタイミングです。第一人者ではないので、これまでとこれからを軽く紹介したうえで、私が考える SRE の定義、文化や考え方、最後に組織の話を絡めながら紹介します。
2003年にGoogleが提唱したSRE（Site Reliability Engineering）は、しばらくの間は Google のプラクティスでした。2012〜2016年にかけて徐々に浸透し、アウトプットが増加。Webサービス事業者の中のプラクティスへ進化していきます。2020年現在は、全体のプラクティスから、明るい方向へ少しずつ進出し始めているのが、今のフェーズです。
ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。(中略)SREが、その内容をはっきりとは表現できていないことは認めざるをえません。(中略) 私達が学んだことを他の組織も利用できるようにすること、SREという言葉が意味する役割と意味をもっと上手く定義することの両方を目的としている
引用元：SREとは
これは一般に SRE本と呼ばれる『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』から抜粋したものです。SREが何を指すのかはGoogle自身も定義できていないようですが
「信頼性こそがあらゆるプロダクトの基本的な機能」であり、誰も使えないシステムは有益ではない
とも述べられてます。私も「これは SRE の内容か？」と思ったときは、信頼性に関わることならYES と捉えるようにしています。
私の考えるSREは、信頼性のある Webサービスを提供するため、条件を考慮したシステムを設計・実装・運用する、または課題をエンジニアリングで解決していくことだと考えます。条件とは、ビジネス上の条件、システムはヒューマンマシンシステムと捉えています。たとえば自動車は、走ることを目的に、どんどん機能を実装していき、大量生産できるようになり、コモディティ化しました。人が使うようになり事故が多発したので、安全について考えるようになり、信頼性工学や安全工学の分野が入ってきました。インフラも同じです。機械的なシステムは、昔に比べ容易になりました。しかし本当は人側のシステムを絡めて、安全や信頼性について考える必要があります。自動車の安全基準と同様に、徐々に Webサービス業界のインフラも、人を絡めてシステムの話ができるようになってきたと考えています。
どのような考え方や文化を持ってる組織ならば、今の SRE を生み出すことができるか？といった視点で考えました。とはいえ、私も約1年しか学んでなく、まだ悩んでるところもあるので、こういう見方もあるんだなくらいの気持ちでみてほしいです。
人と機械のシステムは外せない要素です。開発チームと運用チームの信頼関係に関して、コミュニケーションスキルを思い浮かべて、技術的ではないという人もいますが、2つのシステムが揃って信頼性が成り立ちます。
信頼性にフォーカスする、これは信頼性に興味を持つことも大切です。誰がどの数値を見るかという細かい話ではなく、信頼性に関するものごと全てに興味を持つべきだし、SREの範疇に該当すると思っています。
SRE に限らず、完全を目指さない、信頼性100%を目指さないことは大切です。Toil を0%にするのはなかなか難しいです。一人一人の能力にフォーカスして分野を切るわけではなく、信頼性にフォーカスして分野を切っているからです。1人ですべて SRE を実施する必要も、スキルを全部獲得する必要もないでしょう。
速度と信頼性の変化量に対して、信頼性はトレードオフにあります。
ソフトウェアエンジニアリングや、分散システムのオブザーバビリティをやるシステムエンジニアリングの話は重要ですが、エンジニアリングを工学的アプローチと捉えるべきです。たとえばトレードオフは、バランスであり、バランスを取れる人間がうまくやるといったら、”サイトリライアビリティ”までしかいきません。これをモデルに仕込んで定量分析して、SLI / SLO のようなプラクティスを産んだことが価値のあることです。そこが”サイトリライアビリティエンジニアリング”だと思っています。信頼性にフォーカスして、そこの分野を考えつつ、考え方を狭めないでやっていくのが SRE の文化だと思います。
前述の定義や文化を使い、社内でSLI / SLO を導入するための考え方や進め方を紹介します。
組織に SRE を実装すると考えてみましょう。システムに変更を加えることは、信頼性が下がることを意味するので段階的に入れたり、バランスを取る必要があります。組織の信頼性が下がれば、SRE をストレスに感じる可能性が上がるでしょう。安全に進めるならば、導入に時間がかかること、最初から完全を目指さないことがポイントです。
また組織が挑戦可能で失敗を非難しない文化、新しいことにチャレンジできる土壌、つまり心理的安全性の高い組織をつくることもポイントです。
SLI / SLO を説明します。まず条件を決定できる人には、SRE を推進する理由やメリット、進め方などを説明する必要があります。当然システムに関係する人にも説明しましょう。開発チームと SREチームは当然のことながら、カスタマーサポート、営業チームの人にも説明しておくと良いでしょう。
ただ全てを説明し、納得してもらうことは難しいと思います。特に非エンジニアであれば、なおさらです。自分の専門分野じゃないものをいきなり渡されても読まないし、ハードルが高いですよね。このあたりの書籍を抜粋し説明すると伝わりやすいかと思います。
| サイトリライアビリティワークブック ―SREの実践方法
2章：インプリメンティング SLO SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム 3章：リスクの受容 4章：サービスレベル目標 |
下記は私が実際に社内説明用に作成した資料です。「わかる！ SRE ！」と、複雑でないタイトル名をつけて、覚えてもらえるように実施しました。
説明したあとは、あとはアンケートをとって、資料をブラッシュアップしたり、フィードバックを得ておくといいと思います。
大変な説明作業を経て、SREが採用されたら具体的に導入準備に取り掛かりましょう。SLI / SLO を導入する際には、ドキュメントを残しましょう。たとえば SLO Docs 、ドキュメントのレビューをどうやってサイクルを回していくかや、誰が何をするのかなどをログに残します。SLO Docs やエラーバジェットポリシーを作れば、それが設計ドキュメントになります。
これからは、他社のプラクティスを真似るだけでなく、より自分たちの組織にあった SRE を実践したり、作っていく必要があります。
古川：考え方が変わり、個人的にやめたことはあります。昔だとちゃんと割れ窓を潰したり、できるだけ通知をゼロに保とうなど。私は MSP で、24時間365日、監視のアルバイトをしていましたが、その考えがもとにあったので、そういうことをやりましたが、それらはやめたのではなく、もっと優先度が高いものがあると思って後回しにしてることが多いです。
まつもとりー：優先度は、どうやって決めるんですか？
古川：たとえば Toil は50%と決めたりすると、それに溢れたタスクはあるんですけど、その前に信頼性にフォーカスした際にやらなきゃいけないことがあると思います。
たとえばさっきの Toil の事態を計測して、50%以下に抑えて改善のほうに力を回すなど。考え方はそう変わりました。取り組みをやめたのではなく、優先順位が変わりました。あとやることが増えましたね（笑）
まつもとりー：日々、溢れるくらいやることがあるから、取捨選択をしなくてはいけないということですか？
古川：取捨選択しなくてはいけないけど、視座が上がったんですかね。今までは運用チームでやるべきタスクをバランスよくやってましたが、どちらかいえば、プロダクト全体に対して、どうバランスがいいかみたいな。
そこは SLI / SLO をモデリングしましょうと話があったと思いますし、今も完璧な SLO が実施・運用できるレベルまでは達していませんが、そこのバランス感覚が変わりました。
インフラチームとしてはやりたいが、ビジネス側と要件を考えたときに、もっと優先すべきことがあると考えたら、そこを考慮する動きができるようになりました。
古川：Google がログインという技術誌にシステムエンジニアリングとは何か、を出してるので、読んでもらうといいかと思います。今回のスライドの参考文献のなかにも上がっています。キャリアに対するラダーが全然ない。 Google もはしごが高いといっていて、アプリケーションエンジニアから SRE システムエンジニアになる。つまり SRE の形になる人もいれば、インフラや運用側がステップアップする形もありますが、難しいという、ざっくりとした結論になっています。私もスイッチやネットワークを作ったり、設計から入っているので、インフラ運用エンジニアから上がってきていますが、ステップするのに、あまり境目を作らないのが重要だと思います。文化や考え方ですが、信頼性にフォーカスするものであれば、何でも学ぶぐらいの勢いがあるといいです。今回は組織の話をしましたが、本当はジュニパーのスイッチを触ったりとか、そういうのが好きな人間です。あとコードもアプリケーションエンジニアに比べたら全然書けないし、得意ではないと思います。でも、そこで SRE になろうと思ったら、信頼性に対してフォーカスしてる分野なんだから信頼性に関わることは少なからず自分のなかに入れる。能力が足りないので、自分の力を鍛えていくための意思の転換が必要だと思います。
古川：明確に分けなくていいと思います。 SRE という職種名ですが、個人的にはそんなに好きではありません。そこに職種をつけなくてもいいと思っていて、SRE をしてるインフラエンジニアとアプリケーションエンジニアがいてもいいと思います。文化や考え方は持ってる必要があると思いますが、SRE をしてくのであれば、さっき言った考え方を持っていくうえで、たとえば自分がインフラエンジニアの DB のスペシャリストだと思うのであれば、DB のスペシャリストとして信頼性を担保していくんだと考えていれば、問題ないと思います。考え方を持つのが重要です。さっきいったコミュニケーションの話に無関心になると、それは自分の仕事ではないと思ってしまいます。SRE として重要な項目だと思っているだけでも、コミュニケーションスキルが変わってくると思うので、 DB の信頼性についてわかりやすい SLI / SLO を実装したいとか、出してあげようとなると思います。そういう形でステップアップできると思います。
まつもとりー：SRE が必要になったとき、その SRE という組織に実装するみたいなお話があったと思いますが、そのときは少なくとも元々インフラ運用エンジニアをやっていた人に対して、SRE を組織に実装していくためのスキルが必要になるんですよね。
古川：そうですね。ただ1人で完璧にできる必要はないと思っていて、組織でカバーできればいいと思います。たとえば SRE に対する知識が十分にある CTO やエンジニアリングマネージャーがいて、その人が組織に対して SRE の実装をするのでれば、他の人たちはそういった文化を知ったり、考え方を理解して、尊重する必要はあるとは思いますが、皆が組織の話を全部やる必要はないです。ただ、組織全体のバランスとして、少なくとも1人はそういったことをやれる人が必要だと思います。私の場合はたまたまそれが私だったので自分でやっています。
古川：1番最後のスライドに、はてなの組織図をざっくりと載せているので、そちらを参考にしていただけるとわかると思いますが、うちがそうですね。メルカリさんと近い形だと思います。SRE NEXT 2020での @deeeet さんの発表がかなり近いです。SRE チームではなく、プラットフォームチームなので、少し違う話にはなりますが、うちはシステムプラットフォーム部という昔のインフラ部署があり、そこにはインフラの人しかいませんでしたが、それが変わってきて、システムプラットフォームという SRE を用意しているチームと、私は Mackerel というプロダクトの SRE として移りました。今はてなだと、いろんなサービスがありますが、個々の事業グループに対して、必ず1人は SRE の人が専任で開発チームに所属していて、そのうえで会社全体の SRE として担当する、プラットフォームチームがあります。担当範囲や責務もプラットフォームチームと SRE の違いは、@deeeetさんの発表がとてもいいので、そちらをみていただけるといいかと思います。近場のユーザーとしては開発チームになっていて、開発チームの SRE としては、プロダクトのエンドユーザーを見る形になるので、責務範囲は少し変わってきます。具体的な範囲について、プロダクトに直接関係するSLI / SLO は開発チームに所属してる SRE が見ていく形です。Mackerel であれば、Mackerel の API の可溶性やエラーレートを設計するのは開発チーム内の SRE と開発チーム全体が取り組んでいる内容になっています。
まつもとりー：発表のなかで SRE のチームに元々インフラなどを運用してたエンジニアだけでなく、アプリ開発者も入ればいいとお話があったと思いますが、すでにはてなさんでは実践中なんですか？
古川：はい。いま実践中で、開発チームと SRE チームで分かれてるわけではなく、Mackerel という開発チームのなかに SRE の人と Developer がいます。なので、同じスプリントで回していたり、マネージャーも同じ人だったりします。そうしたほうがプロダクトに近い SLI / SLO を設計できます。プラットフォームチームはどちらかといえば、もっと横断的に、SLI / SLO などがうまくいってないチームや、そこに対する相談に乗っています。また他のチームでこういうことしてるので一緒にやりませんかと持ちかけたり、開発チームの SRE をさらにサポートしてあげる SRE みたいな立ち位置で、システムプラットフォームチームの人がいて、何か困ったら、その人たちも助けを求めます。
まつもとりー：さっきの質問であったとおり、横断的に参加している SRE チームの担当範囲の中の一つとして、徐々に SRE を実践していく人が、インフラエンジニアやプラットフォーム側の人間だけでなく、開発側のエンジニアもそういう発想にしていきたい。しかし、いきなりそこは難しいから、もっと SRE を専門としているチームのメンバーが入って、一緒にやりつつ、サポートしながら、全体としてはその範囲を広げていって、チーム内でやれるようにしていく。そういった担当範囲があるんですね。
古川：はてなはプロダクトが多いです。200人弱しかいないなかで、サービスがいっぱいありますし、受託もやっていて、Mackerel という SaaS もやっています。SRE 寄りのプロダクトのほうが多いですし、マイクロサービスよりもプロジェクトのほうが多い時期もあったので、そこは SRE の採用を頑張り、1人を配置できるような形にして、開発チームでうまく動けるように回している最中です。
古川：私の場合はエンジニアリングマネージャーやテックリードに近い立場になっているので、 SLI / SLO を今後どうしていくかや、考え方、設計思想をどうやっていくかに時間を充てることが多いですね。
他のチームメンバーの仕事ですと、たとえばコンテナ化を進めているメンバーがいたり、そのコンテナ化したうえで必要になるメトリックが、たとえば VM からコンテナになると、メトリックのシュートが変わるので、どういった SLI がいいかとか、またログをいい感じに見るためにどうすればいいかなどをメインで仕事をしてる人が多いです。
当然、障害などへの対応も割り込んできますが、基本的にはオブザーバビリティやモニタリングの仕事が多いです。サービスを作りたいとなれば、設計もしますが、そういったことをしてる人が多いです。
SRE。2021年夏までMackerel SREチームのテックリードとしてMackerelの運用を担当。 現在はMackerelの運用に加え、CTOと共に社内全体のSRE組織作りに取り組んでいる。
さくらインターネット研究所の上級研究員、京都大学博士(情報学)、複数社の技術顧問。インターネット技術に関するミドルウェアからOS辺りの研究開発やエンジニアリング、組織整備や組織文化醸成、EM、PdMも専門。2018年 Forkwell技術顧問就任。
