本記事はこちらからの転載になります。
モチベーション
大好きなテック系ポッドキャストe34.fmの#3でSREというロールについて簡潔かつわかりやすく解説されていたので、番組の紹介も兼ねて文字起こしをしてみました。起こしたのはmainセクションの第一部のみですがめっちゃ長いです笑
対象読者
- SREというロールの役割についてざっくり概要を知りたい人
- e34.fmがどんな番組なのか知りたい人
- ラジオの文字起こし記事が好きな人
注意事項
- 音声コンテンツの文字起こしなので記事としては多少冗長になっています
- 文字起こしですが文章として読みやすくなるように単語を補うなどしています
本編
@deeeet:D
@rrreeeyyy:R
@nari_ex:N
D : じゃあ早速第一部、SREとは何かについて整理してきたいと思います。じゃあまず、これはれい君への質問なんだけど、そもそもSREとはいったい何でしょうか。
R : すごい難しい質問に聞こえるよね。後で話すけど歴史的には世の中に出てきたのが2014年ぐらいで、日本語のSREの本か出たのが2016年だと思うんだけど、その序文にはサイトリライアビリティエンジニアリングという名前が内容をはっきり表現できていないことは認めざるを得ませんって書いてるんだよね。この時点で結構混乱してるんだけど、もともとはベンジャミントレイナーって人が2004年に作ったんだけど、その人が言うには、いわゆるオペレーション、旧来からあるサーバーオペレーションみたいなのを全部ソフトウェアエンジニアに任せた時に起こるもの、という風に説明されていて、そのオペレーションとか運用業務って日本語で呼ばれてるやつをソフトウェアの問題として捉えるっていうのが本質的にはSREというものを表してるんじゃないかなと今は自分では整理してる感じかな。
で結構いろんな解釈があると思うけど、本質的にはソフトウェアエンジニアをするっていうことだと自分は思っていて、例えば代表的なSREの取り組みとしてSLOという、データに基づいてオペレーションをどうするか決めるとか、そういう手法があるんだけど、それも元々は自分のサイトがちゃんと動いてるかどうかっていうのを計測しないで、やたらに100%の稼働率を目指そうとか、もしくはとにかくコストを安く済ませよう、みたいな感じでデータに基づいてない判断をしてたりしてたところをSLOといって、自分のサーバーというかサービスの信頼性がどれくらいなのか客観的にデータに基づいて判断していこうねっていう手法を取り入れて、自分のサイトの信頼性を制御してコストとかアジリティとかと天秤にかけながら適切な取り組みをできるって言うようなソフトエンジニアリングをサーバーオペレーションの分野でもやるみたいな取り組みが代表的にあって、なのでsysadminとかサーバー運用業務をソフトウェアエンジニアリングするみたいな捉え方を自分はしてる感じかな。
D : 自分も基本的には同じ考え方かな。自分なりにSREとは何かっていうのを表現してみるならば、客観的な指標、数字を基にリライアビリティをプロダクトのフィーチャーとして扱うためのプラクティスだったりとか組織文化をSREと言ってもいいかなと思ってて、数字でリライアビリティを扱うってのはどういうことかって言うと、例えばSLOを99.99%から99.999%にしたいですって言った時に、じゃあそのためには X と Y っていう機能を実装する必要があるよねっていう議論ができたりとか、もしくはSLOをバイオレートしてしまったからある機能の実装を後にしてZって機能を直さないといけないよねっていう議論ができることかなと思ってて、これって以前はかなり主観的だったりとか、経験的に決められてしまっていたことでSREのプラクティスによって大きく変わった部分じゃないかなと思ってるかな。後はサイトリライアビリティエンジニアリングなのでエンジニアのものとしてと 捉えられがちだけど自分はそうではないかなと思ってて、むしろエンジニアだけで閉じてては意味がないプラクティスで、さっき話したようなプロダクトの意思決定を会社全体で行われているのが最も重要な部分かなと思ってるかな。
N : SRE本の一章の最後の方もマネジメント層を巻き込まないと実現が難しいみたいなことが書いてあったりして、その辺りも会社全体での取り組みが必要というのは僕もそう思いますね。
D : そうですね。し、そこが一番難しいところかなと思います。じゃあ次は今日に至るまでのSREの簡単な歴史について教えてもらってもいいですか。
R : SREの歴史は日本に出てきたのかだいぶ最近のイメージがあるけど、Googleでは2004年にベンジャミントレイナーって人が最初に言ったオペレーションをソフトウェアの問題として扱って、オペレーション部隊と言うか、sysadminみたいなところにソフトウェアエンジニアを配置するとどうなるのかっていうコンセプトを持って始めたのが一番最初の、2004年のGoogleのSREチーム。で、それがずっと脈々と10年間ぐらいGoogleの中で育っていって、一番大きく海外で世に出たのがSREcon14っていう2014年にあったSREconの第一回で、そこのキートークでKeys to SREって言うトークをベンジャミントレイナーさんがしたっていうのが一番大きく世に出た最初のタイミングかなと思っていて、その次の年ですね、メルカリで日本で初めてかな、自分の知ってる限り初めてSREチームっていうチームが出てきたっていう形になっていて、その後2016年にSite Reliability EngineeringっていういわゆるザSRE本がオライリーから出た形になって、その後2017年に日本でサイトリライアビリティエンジニアリングっていう日本語版の本が出たっていう感じで、そこで自分の認識では日本でもSREチームとかSREグループって言う組織が増えてきたのかなぁという印象があって、この辺で日本の勉強会とかでもSREを取り扱った内容が増えてきたかなっていう印象がありますね。で、そっから2018年とかにはThe Site Reliability Workbook、これも日本語版が2019年に出てるけど、いろんな会社のプラクティスとか、実際SREをやってみた時のプラクティス、もっと実践的なプラクティス、どうすればいいかっていうのをワークブックという形で出していて、次は2020年、最近だとBuilding Secure and Reliable Systemsみたいな本が出たりしてるって言う形で、ここ7年ぐらいで世界的に結構広まってきた概念なのかなっていう印象ですね。
D : そうね。確かに、このGoogleが出してくれてる本の出版を追うと、それがそのままSREの始まりから広がり、で、かつ成熟していく過程ってのが見える感じかな。自分的にはサイトリライアビリティワークブックが特に好きで、最初のSRE本ってSREの原理原則的な話が多く書かれてて、それはそれで学びはあったんだけど、それに対する当時の反応ってどうだったかって言うと、あれはGoogleだからできるんだみたいなこと言ってる人が結構いて、SREは名乗ってるけど独自のことをやってるって言う事が多かったかなと思ってて、それに対して(SRE)ワークブックはGoogle以外の事例を示しつつ、どうSREを実装するかってのを紹介してて、もの凄い学びがあって今でも読む本のひとつで、凄い好きな本をかな。
R : 実際使える知識、実際にこれ見てやれば出来そうみたいなのはやっぱりサイトリライアビリティワークブックの方だよね。
D : そうだね。これは自分の印象だけどワークブック以降ちゃんとSLI/SLOをこういう風に実装してますっていう事例が多く出てくるようになったかなっていう風に感じてるかな。
もうちょい深くSREとは何かを理解しようと思った時に、他の似たようなロールだったりとかプラクティスとの違いを考えるといいかなと思うので、いくつか比較をしてきたいです。まずは一番分かりやすい所で、伝統的なインフラエンジニアだったりとかsysadminとの違いってどの辺りにあると思う?
N : これもSREブックに書いてあることなんだけど、sysadminアプローチ、SREが登場する前のいわゆる運用エンジニアって言われてたロールはいろんな既存のソフトウェアコンポーネント、ミドルウェア、当時でいうところのapacheとかmySQLとかを組み合わせて本番サーバーにデプロイしてそれを動作させてサービス作るっていうところがsysadminの仕事になってて、インシデント、サーバー障害が起きたりとか、新しいサービスをデプロイしたいってなったら手を動かして何か新しいミドルウェアとか新しいコンポーネントを組み合わせてサーバを構築するみたいなことをやっていたっていう感じで、重要なのはsysadminのアプローチっていうのはシステムが複雑になったりとかトラフィックが増えるに従ってやることが線形的に増える、新しいサーバーを手で100台デプロイしないといけないとか、そういう形でやることが線形に増えるようなアプローチがsysadminと呼ばれてるようなアプローチで、仕事が増えれば増えるほど、サービスが成長すれば成長するほど、システムが複雑になるほどsysadminのチームが大きくなるっていうのが特徴になっていて、一方SREってのはsysadminのアプローチをソフトウェアで解決しよう、再利用性があるとか1回やったこと何回もやらないとかSLOを使ってデータサイエンス的にやることを決めるみたいな形でソフトウェアエンジニアリングとしてsysadminの仕事を捉えることで、手作業をなくすとか、データに基づいて作業を進めるみたいな形でサービスが成長しても人数が線形に増えなくて良いアプローチ、ソフトウェアエンジニアによるアプローチっていうイメージですね。なんで、sysadminの仕事をソフトウェアエンジニアリングとかソフトウェアに限らずエンジニアリングを使って仕組みで改善していくんだよってのがSREとsysadminの違いかなという印象かな。
D : リアクティブに動くだけではなくて、プロアクティブにどんどん改善を行ってくっていう部分が大きく違う部分かな。れい君となりさんはSREが登場する以前からインフラ的な仕事をしてたと思うんだけど、経験としてSRE以前と以後で大きく変わった部分ってどの辺にあると思う?
R : 自分はハートビーツに2010年11月から2016年までいたんだけど、さっき言ったちょうどSREみたいな文脈が世に広まってくるタイミングで、ずっといわゆるsysadmin的な業務をしていて、自分はハートビーツの中でも結構早くソフトウェアとかソフトウェアエンジニアリングによるアプローチをやりたいなっていうか、自分で押し進めてた側をやっていて、クックパットに入ったからバンて変わったというよりかは、ハートビーツにいた頃からやってたんだけどクックパッドに入って、もっとよりソフトウェアエンジニアリングを書いてその規模が...っていうか、そうだ、ハートビーツにいた頃はお客さん、MSP事業なので、うちらはサーバーの仕事だけ見て、お客さんに構築したサーバーを提供するか、お客さんがやってるサービスのインシデントハンドリングをするみたいな業務がメインだったから結構ソフトウェアエンジニアリングでプロアクティブにやっていくのが難しくてクックパットに入って自分でアプリケーションの面倒も見れてアプリケーションコードをガリガリ書いていってパフォーマンスチューニングするとか、またはエンジニア向けに社内ツールを作るとかっていうのを結構プロアクティブに出来たってところがやっぱ自分の中でも結構体感を持って違ったなっていうイメージがあるね。
D : なりさんはどうですか?
N : 結構今、れいさんが言ったようにハートビーツはもともと少しソフトウェアエンジニアリングをやってこうという流れがありました。で、これはCTOの馬場さんがずっと、世の中の技術はこういう流れだよっていうテックコンパスをずっと表明していて、それの影響もあります。ただ肌で感じるようになったのは、2015-2016年ぐらいからお客さんの方からこういう風なシステムのインフラを効率化するシステムが欲しいとか、もうプログラミング必須になるような案件が少しずつ増えてきたんですね。なので僕もインフラエンジニアとして働いてる最後の2年間ぐらいはお客さんにサービス範囲外なんですけど、別で見積もりとか作りながらソフトウェアを納品したりっていうのがあったりしたので、本当にこのSREのムーブメントに合わせて業界全体とかお客さんのニーズが変ってきたなっていうのは肌で感じましたね。
D : それはSREの登場も要因としてあるだろうし、その上で動くアプリケーションがどんどん複雑になっていったってのもありそうですね。
N : そうですそうです。
D :SREとの比較で言うとDevOpsっていうプラクティスもインフラの業界ではここ10年でかなり大きく広がったプラクティスの一つかなと思っていて、比較をちょっとしていきたいんですけど、このDevOpsとSREとの違いってのはどの辺りにあると思いますか?
N : さっきの歴史で言うとSREはGoogle社内で2004年に始まったとあって、DevOpsは実は2008年ぐらいからムーブメントがあったので、実はバズったのはSREが後なんですけど起源としてはSREが始めかもしれないですね。SREとDevOpsの違いとかそのあたりの説明なんですが、まず起源が、今話した通り、生い立ちが違います。SREは先ほど説明があった通りGoogleの運用組織がソフトウェアの拡大に比例して増えなきゃいけないところをソフトウェアで置換するって話と、あと本に書いてあった通り開発と運用の組織サイロの二つの課題を解決するという話だったと思います。でDevOpsの期限は2008年のAgile Conferenceで発表があって、そこでも如何に開発と運用の組織サイロを解消するか、でインフラの仕事をどうやってアジャイルで回していくかっていう発表があって、それが皮切りになって始まったんですね。なのでDevOpsはアジャイル開発の背景があって、DevOpsの概念が生まれたというので開発運用の組織サイロを解消しようというところ結構大きいテーマとしてありますよね。で、2018年にSREとDevOpsがどう違うかについてGoogleから記事が出ていて、そこで話されているのが「class SRE implements DevOps」という言葉です。これがSREのプラクティスはDevOpsの範囲外も含んでいる、なのでSREとDevOpsで厳密にはスコープが被ってるところもあれば違うところもあるって話ですね。で、どう違うかと言うとDevOpsは抽象的な概念として定義されているんだけれどもSREはそこのDevOpsと被った範囲に対して具体的な手法が提案されているというふうにGoogleの記事に書いてあります。なので競合する手法ではなくて親しい友達だよ、と最後の結びにまとめてある感じですね。例えば、DevOpsとSREの例としてどんなものがあるかと言うと、DevOpsではエラーの発生を前提とすると言う目標があります。それに対してSREはSLOを前提として非難を伴わないポストモーテム行うというのがあります。なのでエラーの発生を前提とするって言われただけだとどうしていいかわからないけれどもSREの方はきちんとサービスレベル目標を定義しましょうとか、ポストモーテムと言って何か問題が起きた後にきちんと振り返りをして対策とかフィードバックを受けて今後に生かしていきましょうというプラクティスが定義されていてその辺りの抽象と具象という関係性の違いもあるかなと思います。
D : なのでDevOpsの具体的な実装としてSREのプラクティスがあるという関係性を考えることができそうですよね。
N : そうですね。
D : で、このDevOpsを考えた時にサイロ化ってのは重要なワードかなと思うんですが、このサイロ化によってどういう問題が起こっていたのかってはちょっと簡単に教えてもらってもいいですか。
N : そうですね。元々、ソフトウェアがコード化する前って開発と運用が同じ組織だったんですけど、コード化することによってその二つで開発組織、運用組織に分かれちゃいましたという経緯があって、開発部隊はたくさん機能をリリースしたいっていうのがあって、運用部隊は一方で安定した運用をしたい、なのでアクティブにサービス開発を進めたい開発チームと安定的にサービスを運用したい運用チームっていうのは根本的にモチベーションが逆行しちゃう。で、そこがコンフリクトの原因になって自分たちのやりたい思いっていうのがサービス自体に向かなくなってくるというのがサイロの一番の課題だと思っています。
D : 後はDevチームはコードだけを書いてその運用をOpsチームにぶん投げるっていうことしてると、本番環境での障害を受けるのがOpsチームのみになってしまって、その(障害の)解消だったりとか改善策ってのがOpsチームだけで閉じてしまって、それから適切にDevチームにフィードバックされなくなっちゃうから、リライアビリティだったりとかレジリエンシーの改善が進まなくなってしまうってのも大きい課題の一つかなと思います。で、SREにおけるSLI/SLOがまさにこの安定運用のための改善と機能開発のためのバランスを上手くとるための具体的な実装になってるじゃないかなと思います。
じゃあ具体的にSREのプラクティスについて話していきたいんですけど、既に何回か出てるようにSLI/SLOってのが特にSREでは重要なプラクティスかなと思うのでそれから話していたいんですけど、まずは改めて聞くんだけどSLI/SLO、あとエラーバジェットてのは何なのかってのを簡単に教えてもらいたいです。
R : 結構出てきているように開発と運用が分離するとかデータに基づいて自分の仕事をコントロールできないという問題があって、まずは自分の提供するサービスはどれくらい安定してるか、どれくらい信頼性があるのかっていうのを数値で見れるようにしましょうという取り組みがSLI/SLOという取り済みになると思っていて、その中でSLIってのは指標ですね。サービスレベルインジケーターなので指標。例えばHTTPリクエストの成功した数とか失敗した数とかね。一般的には成功したHTTPリクエストを全体のHTTPリクエストで割ったりするSuccess Rateと言われてるような割合を使うことが多くて、SLOは、SLIつまり指標に対してService Level Objectiveなので、どれくらい満せてればいいかっていう目標値になっていて、例えばSLIがSuccess Rateだとしたら、全体のリクエストの内99.9%は成功しててほしいよねっていう目標値を定めるというのがSLO。で、SLOと対というか反対の表現としてエラーバジェットってのがあって、100%からSLOを引いたもので、99.9%のSuccess RateをSLOとすると失敗して良いHTTPリクエストは0.1%あるよねっていうのがエラーバジェットの考え方ですね。
D : エラーバジェットはその名前の通りバジェットだから機能開発のリリースをするのにどれだけ余裕があるかという指標として使ったりできるって言う事だね。
R : そうだね。後で出てくるかもしれないけど、0.1%エラーバジェットがあって、どれくらいエラーバジェットを今使っているよねっていうのが分かるから、エラーバジェットを使い切ったらどうしようとか、使い切りそうだからどういうアクションをしよう、みたいな形でSLOを満たすためにエラーバジェットをどれくらい使っているかっての管理して、信頼性を高めるような機能実装をする方に振るのか、信頼性がちょっと悪いけど新しい機能をどんどん入れようっていう方向に進むのかって形で目標値に対してどれくらい余裕があるかっていうのを表現する値として使って仕事をコントロールするとか機能開発をコントロールすることに使える、だろうね。
D : このエラーバジェットに関して、Googleのカスタマーリライアビリティエンジニアの人が凄い良い事を言ってて、何て言ってたかって言うと、エラーバジェットを消費してないのは、イコール、イノベーションを起こしていないことと一緒であるということを言ってて、どういうことかって言うと、新しい機能を出すってのは最もエラーが起こりやすいっていうことだよね。エラーバジェットを消費してないってのは安定性に振りすぎてて機能開発が全然出来てないよっていうことに繋がるんだよね。なのでエラーバジェットは守るものではなくて、むしろ積極的に消費するべきものだよっていう指針として、すごい良い事を言ってるなぁと思った。
R : わかる。めっちゃいい。
D : じゃあ具体的にSLI/SLOを決めて行こうと思った時にどういうふうに決めていくのがいいかっての教えてもらいたいです。
R : これは、基本的にSREワークブックに書いてあることではあるんだけど、SLIはなんかの割合にする方が良くて、特に良いイベント数/全体のイベント数という風に値を定めると良いって書いてあって、さっきのでも同じなんだけど、成功したHTTPリクエストを分子にして、全体のHTTPリクエストを分母にするみたいな形で、良いイベントを分子にして全体のイベントを分母にするっていうのが良いという風にされていて、結構WebサービスとかだとHTTPリクエストの数とかにするけど、例えばいろんな考え方に応用できるとは思っていて、例えばめちゃくちゃな例だけども、配送業とかで、荷物全体の数と実際に配送に成功した荷物の数みたいな形でSLIを定めることもできると思っていて、そういう風に自分のサービスとか事業の要になる良いイベントと全体のイベントの割合として使うのが良いだろうというふうにプラクティスが書いてある感じだね。
D : なので自分のサービスのユーザーにとって何が一番大切かっていうのを考えるのがSLIを決める上で重要だよね。例えばあるサービスのユーザーにとってはいかにレスポンスが早く帰ってくるのかっていうのが重要になってきて、レイテンシがSLIになる場合もあるだろうし逆にレイテンシはそんなに重要ではなくて、それよりはいかに確実にリクエストのレスポンスが返ってくるかっていうのが重要になってSuccess RateがSLIになるって言う場合もあったりするよね。なんでユーザーの視点に立ってそのユーザにとって何が一番重要なのかっていうのを深く考えるのがすごい重要な点かなと思う。
R : 例えばNetflixとかだと昔のブログで、ビデオの視聴回数みたいなのが確か鍵になってるみたいな話が出てたりしていて、実際HTTPリクエストがどれだか成功してもNetflixってビデオを見るためにサービスを展開してる会社だからそこが見れないと意味ないよねみたいな形で値を設定してるっていうのを書いてたっいうのは結構印象的だったりするよね。実際、自分が前いたクックパッドでSLIを定めるような時も例えば全体のHTTPリクエストというよりかは、レシピ検索をする人のリクエスト成功率とか、結構レシピ投稿者を重視してたりしたから、その投稿の部分のSuccess Rateをみたりとか、あとはつくれぽみたいな投稿してくれる人の体験を大事にしたりっていうのを重視してどのユーザーを満足させたいとかどのユーザーにフォーカスを当ててやりたいみたいな事業のKPIと連動してSLIを定めるってことかやっぱ最近は多かったね。
D : なんでエンジニアだけで決めるよりもちゃんとプロダクトマネージャーとかと一緒に決めるのがいいよね。
R : SREが単独でHTTPリクエストだって決めるよりかは事業と連動した指標の方が後で出てくるけどステークホルダーと(SLOを)割った時にどうするみたいな話をしやすいっていうのすごくあると思うからそこを大事にする方がいいと思う。
D : 次はSLOをどう決めて行けばいいかちょっと教えてもらいたいです。
R : そうだね。SLOは最初からカチっと99.9%にしましょうっていって、それを守るためにすごい努力するとか、すごく頑張りたくないから、緩い値にするとかではなくて、はじめはバシっと決めてしまって、実際にそのHTTPリクエストとかだったら99.9%とかがよくあるけど、最初に決めることは大事ではなくて、そのSLOを決めた後にちゃんとそのSLIに従ってステークホルダーはこの値で満足できてますかとか、SREとか運用する人はこの値で疲労、疲弊してませんかとか、Developerのチームはこの値でちゃんと機能をリリースできてエラーバジェットを使えてますかっていうようなフィードバックを繰り返して新しい値に進めていくっていう仕組みを作ることが大事で、最初の値はそんなに重要じゃないという風には書かれていて、自分もその通りだと思う。
D : 決めれずに動けないってのが一番もったいなくて、とにかく決めて可視化してみて、でその改善のループをどんどん回してくってのが一番重要だよね。
じゃあ具体的にそのSLI/SLOってどういうふうに決めて運用してくのがいいかってのちょっと教えてもらいたいです。
R : 最初にどういう値をSLIとするかってのやっぱり決めないといけなくて、特に後でちょっと出てくるんだけどステークホルダー、事業責任者プロダクトオーナーとか授業に責任を持ってる人も巻き込んで進める方がよくて、SLIを決める時にそういう人を巻き込んで、どういう値を信頼性の指標としようねとかSLOは最初は雑に決めてどういう仕組みでまわしていこうねっていうのをまず決めるいうところがスタート地点になってると思う。その後は、インプリメンテーションとしては実際に値を計測するような仕組みをSREとかDeveloper Teamが実装していくっていうフェーズになっていて、例えばHTTPリクエストだったらロードバランサ、特にユーザーに近い方のメトリクスを使ってSLIを定めるとかそういう風なプラクティスがあって、HTTP Request Success Rateならロードバランサのメトリクスを使って、SLIを計測してみる。どれくらいの値になってるのか計測してみて、それを見てみた結果、最初はどれくらいのSLOにするのが良さそうなのかっていうのをざっくり決めて改善する仕組みを回すって言うので、後はSLI/SLOをどのくらいの周期でトラッキングするかっていうのも決める必要あって、いろんなタイムウィンドウを使って評価することができて、例えば一番いいのはローリングウィンドウっていって、4週間とか3週間とか3日とかね、そういう単位を決めてある特定の日数分だけでSLOを評価していくっていう方法と、もう一個カレンダーウィンドウっていって一月みたいな単位でSLOを評価するっていう、12月のSLOはこれですとか6月のSLOはこれですみたいな形で評価するってのがあって、基本的にローリングウィンドウの方が普段使うぶんには良いとされていて、それは例えば何か5月にめっちゃ障害起こしちゃいました、でも6月1日になったので新しい機能をどんどん入れていいです、みたいになるとやっぱりおかしいから、直近4週間とかの単位で継続的にトラッキングしていく方が良くて、カレンダーウィンドウの使い所としては結構長い期間で、じゃあこの四半期どれくらいでしたかとか、半年間1年間でどれくらいのSLOを満たしてましたか、みたいな評価をする時にカレンダーウィンドウを使うのがいいですね。なんでSLI/SLOを定めてどれくらいの期間で評価するのかを決めるってのが実装のところに入っていって、実際その値が決まったらステークホルダーとSLOを割ったらこういう風にしましょうとかDevelopperとSLOを割ったらを信頼性を上げる機能、例えば酷い品質のコードを一旦入れちゃったけどSLOを割った、エラーバジェットがもうなくなりそうっていうのでその機能を改修する方向で実装を進めましょうとか機能開発を進めましょうみたいな形でエラーバジェットを割りそうな時、エラーバジェットを割った時にプロダクトの方針としてはどうするのか、デベロッパーの方針としてはどうするのか、SREの方針としてはどうするかってのちゃんと合意しておく必要があって、この合意も最初に決めた契約をずっと守るわけじゃなくてSLOと一緒で定期的にこのagreementで大丈夫ですかっていうのを確認してアップデートしていくっていうのをやっていく必要があるね。それが実際に決まったら、それを文章化して残す、メンテナンスしていくっていうのがエラーバジェットポリシーとかSLOとかをドキュメント化して行って後はSLI/SLOを定期的にタイムウィンドウで眺めるためのダッシュボードとかアラートとかレポーティングっていうのをして運用を回していくっていう形になるね。大きく分けると、仕様策定、スペシフィケーション、インプリメンテーション、ステークホルダーアグリーメント、エラーバジェットポリシーを決めてドキュメント化してダッシュボードを見て定期的に回していくっていうのがちょっと長くなったけどSLI/SLOの資本的なライフサイクルだと思う。
D : 特にこのSLI/SLOライフサイクルの中で一番難しい、かつ肝になるのってステークホルダーアグリーメントの部分かなと思ってて、特にSREっていうプラクティスをはじめて導入するような企業だったりすると、そもそもSLI/SLOって何ですかっていう理解がエンジニア以外にも必要だし、かつそれをプロダクトの意思決定に使うことの価値、メリットってのを皆が理解する状態に持ってかないといけない。その上でSLI/SLOをどういう値にするかという議論が初めて出来て、その合意を取らないといけないから、やっぱなかなか難しそうだなっていう感じがするかな。
R : そうだね、めっちゃわかる。自分がクックパッドに直近までいた時のプラクティスとしては、このコンセプトを理解してもらうのがまず難しいじゃないですか。マネージャーとかステークホルダー全員にSRE本を読んでくださいっていうのっておかしいじゃん、ってのがあっておかしいとかよりも難しいことだと自分は思っていて、まずはSREチーム内でざっくりSLIもロードバランサメトリクスのSuccess Rateをトラッキングしてみようってことでトラッキングしはじめて、SREのチームがそれを割ってたらDeveloper Teamに話に行くとかっていうふうに最初はスモールスタートしてそれが軌道に乗ってきたと言うか、そういう風な取り組みをしていますって発信を結構続けてSLIとかSLOの文化を会社全体でちょっと理解してもらうっていうのを最初にやっていて、僕が辞める直前ぐらいにちゃんとプロダクトマネージャーとかエンジニアリングのマネージャーの人と、どういうSLIにしようとか、どのくらいのSLOにしようみたいな話し合いをしっかり持って値を決めるって事が出来ていて、最初からやるのが難しい時はそういう風にSREだけではじめてみるのも自分はアリなんじゃないかなとは思うけどね。
D : SREだったりとかエンジニアだけではじめてみて、その価値、メリットをどんどん全社的に広めていくっていうやり方ももちろんあるかなとは思うけどね。後はさっき言ったように、SLOはまずバシっと決めてそれを改善のループを回していくのがいいっていう話だったと思うけど、具体的にSLOをどう改善してくのがいいかっていう指針みたいの教えてもらいたいです。
R : SLOを割った時に、例えばレスポンスタイムもSLI/SLOに含めていて、なんか重い機能をリリースしちゃうとレスポンスタイムの指標が悪くなっちゃうよねっていうケースがあって、都度凄腕のチューニングが得意なエンジニアの人が対応したんだけどそれって大変じゃないみたいな話が出て、ウィークリーでみるとなんか改善してるねとか、上ってるね、みたいな指標ばっかり追っちゃうんだけど、さっき言ったカレンダーウィンドウで四半期に1回とか数ヶ月に1回見てみた時に、レスポンスタイムの改善にかかってるPRの数とか、工数多くない?みたいな話が出てSLOを緩めたりっていうのはあって、実際に対応する人が疲弊するかどうかみたいなのもカレンダーウィンドウの指標で聞いてみたりとかっていうのがあるかな。後はさっき言った、じゃあエラーバジェット全然使いきれてなくない?みたいになった時に、もっとサービスを発展させるとか新しい機能をガンガン入れた方がいいんじゃないかみたいなコミュニケーションをとる事も多分あると思う。
D : もしくは、カスタマーサティスファクションを意思決定の指標として使うっていう方向性もあるよね。 例えばSLOを満たしていたとしてもカスタマーサティスファクションが低かったらそれはSLOを厳しくしないといけない、もしくはそもそもSLIが違うかもねっていう議論ができたりするよね。
R : そうだね。SREワークブックにも書いてあったけど、サポートチケットの数とかを見るのがいいって書いてあって、サポートチケットの数がめっちゃ増えてるのにSLIはあんまり変動してないみたいな時はそもそもSLIの設定に誤りと言うか、見直した方がいいんじゃないかみたいなことが書いてあって、すごい面白い視点だと思う。
D : もしくは社内ではものすごくアラートが鳴りまくってるけどカスタマーサポートは無風みたいなことがあったらそれはSLIが違ってるっていう事になるよね。
R : うんうん、あるある。
D : SLI/SLOはこんな感じかな。他にこのSREのプラクティスで学びがあったとかその後の自分の働き方だったりとかに影響を与えた物って何かあったりしますか。
N : トイルを解消するっていう取り組みは伝統的なsysadminの業務をSREに変換するうえですごく重要で、そういった取り組みはものすごく僕は好きですね。特にMSPの会社、元々いたハートビーツという会社は色んなお客様の支援をたくさんやってるので数分に1回ぐらいのペースでアラートが鳴り続けるんですね。でその大量のアラートを如何に素早く対応するか、もそうですし、如何にその対応すべきアラートに絞っていくかっていう活動を継続的にやっていて、そのあたりのトイルを取り除くっていうところはひとつ僕の好きなSREの取り組みですね。
D : トイルはまずそのワード自体がすごい良いっすよね。
R : ふふふ。ワードがね。
D : トイルを消すぞみたいなことをみんなこのあと言い始めた感じだね。
R : 良く言ったね。
N : あと、もともとハートビーツでやってるところでいうと、ポストモーテムのカルチャーはかなり重要視していて、やはりオペレーションが非常に多いので同じようなミスを何回もしてしまうってことが頻繁に起きるんですね。なので、その度に振り返りをして対策をしていかないと、どんどんどんどん所謂トイルというか、お客さんに説明がつかないような回数同じミスをしてしまうことが多いのでポストモーテムみたいな取り組みは必須で取り組む必要があったという経緯もありますね。
D : ポストモーテムもSLI/SLOと一緒で組織全体として取り組んでいかないといけないプラクティスのひとつですよね。例えばポストモーテムで色んな課題が洗い出せたとしても、出てきた課題の改善を次のリリースサイクルとかにフィードバックできなかったらそれは意味なくなっちゃうわけで、次のリリースで必ずスケジュールされるような優先度付けとかは組織全体でできるようになってないといけないかなと思いますね。
N : もともとハートビーツだと同じ課題があって、沢山ポストモーテムがあがってきた結果、実際にそのポストモーテムを元に対策するっていうのが滞るってことがあったので、そこでやった対策はCTOとVPoEがきちんとディスカッションして週次できちんとウォッチをしながら遂行するところまで見るという取り組みをやってましたね。なのでこの辺りは結構いろんな組織で苦労してる部分なんじゃないかなと思います。
D : 確かにVPレベルでちゃんとコントロールしていくだったりとか、もしくは全社的に使えるような強い優先度っていうのを準備するのが大事な感じがしますね。
じゃあプラクティスもこんな感じかな。SREの歴史だったりとか概観ってのはつかめたと思うので、ちょっと今の話、今SREが登場してもう7年になるけど、今この2021年、SREがどうなってるのかっていうのをちょっと簡単に教えてもらってもいいですか?
R : これもSREワークブックにSRE Team Lifecyclesって章があって、最初はね、Googleもそうだけど全社に対して一個SREチームがある状態が今日本とか海外とかでもそういう状態になってる会社も結構あると思ってて、そこからどんどん進んでいくとカルチャーを広めていくと言うか、結局SREのプラクティスをどんどんステークホルダーとかデベロッパーに伝えていかないといけないよねっと、じゃないとうまく回らないよねっていうのがSLI/SLOとかポストモーテムの取り組みを持ってもそういう課題があるのでServise Embedded SREとかDistributed SREみたいな形でいろんなチームの近くに専門のSREチームを置くとか、実際にサービス開発チームの中に専任のSREを置くみたいな形でSREがどんどんひとつのチームじゃなくて分散していって各チームに一人とか二人いるような状態っていうのが最近も結構僕もクックパッドで実際Embedded SREとして働いていたりとかメルカリとかでもEmbedded SREの取り組みを始めますみたいな記事が出たりとかいろんな会社で聞くようになってきたかなという風に思っていて、それがある種、次のステップ、ライフサイクルの2段階目のステージなのかなと思っていて、最後のステージはSREっていうのが文化だけ残ってロールが消えるっていう状態が最終形なのかなと自分は思っていて、サービス開発チームとかステークホルダーが自然にSLIとかSLOとかポストモーテムの文化を実行できている状態ってのが、それで専任のSREみたいなロールは特にいないっていう状態が理想形なのかなと思ってて、そこが最終地点なのかなという風に思っていて、またもしかしたらそれが一周回ってSREチームみたいのを作って専門的な内容に、よりプラットホーム的な内容に取り組んでいくってい回帰もあるかもしれないけど、一旦のライフサイクルとしてはそういうライフサイクルがあるかなと思っていて、日本とか海外とか見てると最近はEmbedded SREとかっていうワードをよく聞くようになってきたってステータスかなと思ってるかな。
D : 今れい君が行ってくれたみたいに、うちも自分がいるプラットフォームチームとその上に、各チームにEmbeddedされていくEmbedded SREっていう二つの組織体制で動き始めていて、プラットフォームチームがサービス全体のリライアビリティだったりとか、その仕組み、自動化っていうものに責任を持っていてEmbedded SREは各サービスのドメインに特化したリライアビリティの問題の改善っていう部分に責任を持つという分けをしているかな。なんでこういう分けが必要かって言うと、リライアビリティってドメインによって全然やるべきことが違うよね。例えばメルカリのサーチみたいにものすごいリクエストを受けるような部分でやるべき事とメルペイのようにものすごいセキュリティーだったりとかリクエストの成功率が求められるような部分でやるべきリライアビリティのタスクって全然違うかなと思っててプラットフォームチームみたいに全体を見るべきチームがそういう各ドメインに特化した部分を見ていくってなかなか難しくて、こういうEmbedded SREみたいなチームがそういうところにEmbeddedされていってドメインスペシフィックなリライアビリティを改善するっていうの結構大事だなってのが実感として思ってるかな。し、これもれい君が言ってくれたみたいにEmbedded SREの役割は各ドメインのリライアビリティ問題を改善するだけではなくてSREとしてのプラクティスを会社全体に文化として広めていくというのも重要なミッションの一つでSREっていうロールがいなくてもエンジニアが自分達で自立してリライアビリティの問題っての解決できるようにしていくってのも重要なミッションの一つになってるかな。
R : ポットキャストでも何回か話題に出てきているけど97 Things Every SRE Should Knowの最後のSRE in the Third AGEっていう、前回も話題にしたけど、これグラファナの人が最後の章を寄稿してて、それに関連するブログも書いてるんだけど、最後はサービスプロバイダーになるんじゃないかっていう話も書いてあったりして、大きい組織は自分らの組織に特化したサービスとかプラットフォームを作るのが最もコスパがいいと思うんだけど、ちっちゃい組織だとなかなかそれも難しくて、SREの文化をちゃんと使えるようなサービスプロバイダを使うことでSLI/SLOをこのSaaSを使えばしっかり使えますとか、そういう風な専門のSREを外部から呼んで来て文化を根付かせてもらうみたいな形でワークさせる、SRE as a Serviceって書いてあるんだけど、そういう風なワークをするとか、特定のSaaSを使うみたいな形でちっちゃい組織はそっちの方がそういう風な形になっていくんじゃないかみたいな話も書いてあったよね。
D : 確かにうちみたいにプラットフォームチームとEmbedded SREチーム両方を準備できる余裕があるとこってあんまりないよね。
じゃあざっくりSREとは何か歴史含めてなんとなくわかったと思うので、かつれい君からめちゃくちゃいいバスが投げられたと思うのでここからは第2部でTopotalに関して色々聞いてきたいかなと思います。
まとめ
- SREの役割は既存のインフラエンジニアが抱えていた課題をソフトウェアで解決する
- SREのプラクティスはDevOpsという概念の具体的な実装にあたる
- 代表的なプラクティスとして
SLI/SLO、エラーバジェット、ポストモーテムがある - SREのプラクティスはSREだけのものではなく今後アプリケーションエンジニアやビジネスサイドにも重要となっていく(と思われる)