次世代Webカンファレンス2019 聴講メモ #1 「SRE」
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容は後日配信される公式の動画をご覧ください。
(わかる範囲でしか書いてなくて、もっと面白いやり取りもたくさんあったのでぜひ動画でo( )o)
SRE
#nwc_sre
- @kani_b:クックパッド SRE・セキュリティ
- @deeeet:メルカリ マイクロサービスプラットフォーム
- @y_uuk1:先月まではてな(Mackerel) → 来月からさくらインターネット
聞きながらのメモなのもあってアカウントの頭文字を敬称略で書かせていただいています、すみません。。。
内容めも
SRE
kani_bさん(以下「k」) :シスアドと違って、ソフトウェアエンジニアがインフラもやるようになってSREになっていくと思う。ソフトウェア開発の割合は?
- deeeetさん(以下「d」)
Googleのやり方を目指している。
全タスクをreactive/proactiveにラベリングして、半々の量になるように。
というか対応系タスクが増えてきたことで、ラベリングによって可視化(on github)してそれらが50ぱーを超えないようにしようとなった。
タスクはマネージャーが調整する。新規事業のリリース前後はreactiveなタスクの需要が上がるので、それを察知して、依頼が来る前にproactiveなタスクをやっちゃう。 reactive全てがtoilであるというわけではない。- reactive
アラート対応、開発者からの要望対応 - proactive
プラットフォーム構築 = より良いプラットフォームを作る
- reactive
- y_uuk1さん(以下「y」)
前職ではソフトウェア開発の割合は低かった。 - k
割り込み仕事の割合は、その人が持っているタスクによって変わってくる。複数人で1サービスを持ったりという工夫をする。
開発者との調整はいくらやっても割り込んでしまうので、SREチーム側のやり方を変える必要がある。もちろん自動化等の改善業務は進める。
タスクの可視化
d:どうやって可視化しているのか?
- k:
1つのチケットに書いてあるタスクの粒度が違っていて、単純にラベルを貼っても正確には可視化できない。
定期的に各人がどういうタスクをやっているか共有して、運用の仕事が多いメンバーをフォローする。 - y:
スクラムの手法で、タスクにポイントをつけてベロシティを計測している。差し込みの量はここでわかる。
toilを計測するのは難しかった(例えば一瞬で終わるものとかもあって)ので「本来やるべきタスクをどれだけやれたか」を可視化した。
オンコールの運用
- y:
振り返りは平日毎日。即時対応が必要なものはオンコール担当、その後対応が必要なものはみんなで。
週末は当番制。平日は起きてる人が対応していた。
ポストモーテムについて、クライアントに報告するかはフィルタリングされていた。
以前、過去2年分のインシデントを見直して、実現できていない対応をロードマップに組み込んだりしていた。 - d:
モノリス時代のオンコールは基本SREチーム。毎日primary, secondaryの担当が決まっていた(週一でまわってくる)。
ポストモーテムについては、アラートごとにインシデント内容・影響・対応をまとめて、週一でその1週間の全インシデントについて振り返りをやる。
議論はSlackで完結する。
SLI, SLO
- y:
SRE本のとおり策定しようとしてみたけど、結局時間で稼働率を測った。 - d:
両方ともとても大事だと考えていて、SLI, SLOが無いならSREを名乗れないと思っている。
プロダクトを出すときに必ずSLI, SLOを設定するようにしている。 (k:強く設定しようとすると「限りなく100%」ってなっちゃうと思うけど、そうはいかない。どう設定するのか)
決めるのはSREではなくデベロッパーになっている。本当はSLOのオーナーを決めないといけなくて、PMやCTOとか、その人達が数値の妥当性を検討するべき。
うちはまだできていない。
サービスによって、ツーナインでいいのかフォーナイン必要なのかが変わってくる。
k:プロダクトを作る側も、ある意味"あきらめる"ことが必要になってくる。ビジネス側にどう説明するのがいいんだろう。
- d:
100ぱーは無理だということをPMに理解してもらわないといけない。PMが理解しないならSLO設定の意味が無くなる。 - y:
求められる可用性に対して、その実現のために必要なタスクを洗い出してポイントをつけて「これをやるならこっちのタスクはできなくなります」と説明することになる。 - k:
SLIは持っていて、SRE自身がSLOも持っている。SRE本と同じようにエラー数/リクエスト数をベースにしている。
エラーバジェット
k:監視にはどういうもの使っていた?
- d:
モニタリングはdatadogで、重大なものはpagerdutyに飛ばしている。いまpagerdutyはほとんど全員が持っている、全体で170アカウントくらい。 - y:
サーバーサイドエンジニアもオンコールを持ちましょうという流れになっている。
監視はもともとインフラチームが設定していたけど、SLOをエンジニアが持つようになるとエンジニアが自発的に設定してくれるようになった。 - d:
オオカミ少年アラートが多すぎた。今後はアラートを設定するときは全員でレビューするようにしたい。
「これ設定すると俺たち朝に起こされるぞ、どっちをとる」みたいな。 - k:
最近prometheus + alertmanagerに移しつつある。アラート設定をテキストで書いてテストもやるようにしたい。
インフラのセルフサービス
- d:
せっかくマイクロサービス化して自立性の高い開発者チームを作っても、SREがボトルネックになっては意味が無い。
基本的にソフトウェア開発者チームに全権限を渡している。監視やインフラ基盤はできるだけGCPなどで使えるマネージドのものを使う。
オンコール含めて。
(k:そこにSREが入るタイミングは?)
それらを実行するCI等の仕組みを提供する。 - k:
うちももともと全権限をインフラチームが持っていて、何をするにもインフラチームにお伺いを立てる必要があった。
ソフトウェア開発者から見てもやりにくいし、なんとなくインフラチームって怖いし(笑)
DBのスキーマ変更も開発環境構築もセルフサービスでできるようになっている。
これからのSRE
k:セルフサービスが進むとこれからSREチームの役割はどうなっていくんでしょうか
- y:
みんながSREになっていって「SRE」という職種そのものは消滅する、みたいな流れでいいと思う。大きいところだと専門のチームが必要だと思うけど。
マネージドサービスも増えているし。 - d:
感覚的に、たとえばSLOがツーナインまでなら開発者だけでいいと思う。でもスリーナインを超えてくると専門のSRE人員が必要になることもある。
SREがいなくなるというより、SLOの高いクリティカルなサービスのチームにSREが入っていくことになると思う。
開発者チームにSREがembededしていくのは良いことだし、進めていくべき。 - y:
ML Opsみたいな、マネージドサービスがまだ無い分野をオペレーションする必要がでてきたときにSRE的な仕事が復活してくると思う。 - k:
SRE職人がやるんじゃなくて、開発者それぞれがSRE的な仕事をやっていく。 - y:
SREというのはDBとかの各分野のスペシャリストではなく、いろんな分野を「信頼性」っていう観点から体系化して「なんかよく知らんけどこれらを組み合わせてうまいことやる」っていうジェネラリストだと思う。SREは科学ではなく技芸である、という考え方を支持している。
どういう人がSREになっていくか
- k:
システムを理解してソフトウェアエンジニアや、科学的なアプローチにトライできる人かな - y:
いずれ失職すると思ってるけど、マネージドサービスとたたかうことになると思うので、創造的なことがやれるといいのかな - d:
組織として「SRE」をやっていって、それをリードする人がいる、ということになると思う
感想
用語からわからないところもあってぐぐりながら聞いてた。けどもともとインフラにも興味あったし考え方とか問題点とか聞けて面白かった。
SREチームが作ってくれたものにしろ自分で外のマネージドサービスを使うにしろ、わけもわからず使ったら結局サービス落としたりオオカミ少年アラートを増やしたりすることになるわけで、ソフトウェアエンジニアこそ今ちゃんと勉強しないといけないと思った。
「マネージドサービスとたたかってSREは失職する」という話はそのままソフトウェアエンジニア(狭義)にも言えることだなあ。。。