目次
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「SRE のこれまでとこれから」です（開催日：2020年 6月16日）。第3部では、登壇者の古川さんとまつもとりーさんが視聴者からの質問に回答します。SRE の人たちが普段どんなお仕事をしているか？ SRE の担当範囲として取り組むのをやめたことは？ など、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組織作りに取り組んでいる。
