SRE NEXT 2023で「Runbookに何を書き、どのようにアラートを振り分けるか？」というお話をしました

sre

登壇＆参加記事です

今までのあらすじ（ずっとアラートの話してる気がする）

2020

dasalog.hatenablog.jp

2022

dasalog.hatenablog.jp

開発者とともに作る Site Reliability Engineering / SREing with Developers - Speaker Deck

で @yuuk1t さんも皆勤だったみたいな話をしていたので

（ワイも、と言いたかっただけです）

今回の発表まわりの蛇足

speakerdeck.com

「おかしい、何度やり直しても20分間早口おじさんになってしまう・・」

というのはさておき、Runbookの話でした。

x（慣れない）でも書いたのですがこれは2020の発表の伏線回収でもあったのでした

引用先のスライドにも書いてあるんですけど言ってしまえばこれは当時すでに存在した手法を自分たちの組織課題に合わせてアレンジしつつ取り込んだ、という話でもありめちゃめちゃ新規性のある話というわけではないのですが、そうはいっても実際問題組織が抱える課題はそれぞれで、自分たちの課題はこういったものでそれに対する解決をSRE的なプラクティスを踏襲しつつ実践してみた、ということで一つの解として参考になれば良いし、そこが聞く人にとっての価値であろうと考えこの内容にしました。

2020からのアラートの話も今回のRunbookの話もそうなのですが、このあたりの取り組みのモチベーションは自身の（あまりよくないなーと思った）体験がベースなっており、もう少し言うと自身が苦労したことを次の世代で同じように苦労する必要はないのではないか、という思いがありここらへんの負債（≒暗黙知）を減らせるような取り組みができればよい、そのためにSRE的なプラクティスがたまたま有効だったのでアレンジをしつつ採用したらよさそうだな、というのが個人的な考えでもありました。

もちろん発表でも少し触れた通り、ドキュメントを新規に作るということは（コードと同じように）、書いた瞬間から負債化のリスクを抱えており、「よかれと思って」仕組みを作ったものが今後かえって重荷になる可能性を孕んでいます（というか最終的には確実にするでしょう）。

今後の取り組みとして、そのあたりのライフサイクルをゆるやかに回す、総量をあるラインで留めてメンテナンスコストを一定に保つ、といったところがチャレンジになると考えています。

（そしてセッション後すぐにお声がけ頂いたりしてこれは大変嬉しかったですね、課題感はそれぞれですが、というのとこれはセッションの内容とも絡んでくるのですが各々の文脈におけるヒントになれば幸いです、課題に合わせてアレンジしつつやっていきましょう）

セッション

参加させて頂いたセッションについて、一応色々メモってはいたところから印象に残っているところを

ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜

樽石さんによるキーノート。

micro company architectureという壮大な話の一方でdockerイメージ全部入りアーキテクチャという話を対比しつつ、「コンピュータ・サイエンスの基礎を理解すると各種アーキテクチャに応用ができるよ」という話が実践されていて実際これこそがTHE SREみたいなことなのではないかというところに（個人的に）落ち着いて強さを感じたセッションでした。

LINEスタンプのSREing事例集：大量のスパイクアクセスを捌くためのSREing

maruさんによる、今から3ヶ月後に想定されているスパイクに備えて皆さんでやっていきましょう、という追体験型セッション。

印象ポイントとしては、本番環境で模擬負荷試験みたいなところで、インスタンス数を徐々に下げていって、実際じゃあ一台でこれくらいのRPSさばけるね、という（リリース前であれば）負荷試験でやる内容を本番でやるという話があり、これは大変理にかなってるなーと思いました。 すかすかだと負荷見積もれんし、じゃあ去年のものをそのままベースにするかというとなんらかの係数で推測はできるもののコードも諸々変更が入っているわけで、じゃあ今だったらどれくらいさばけるの？を直接的に得ることができるのは確かになーと思ったところでした。

エンジニアのためのSRE論文への招待

論文is敷居が高いと完全に思っている自分のような人間に向けたセッション。

自分はもうちょい世に出てきた技術からじゃあみていこうというレベルなのだけど10年先を見ていこうと思ったら、当たり外れはあるにせよこういったアカデミック分野をみていくべきなんだろうなあ、と思う次第でした。

各所ポインタをまとめてくれていますしsrelounge slack内にも #sre-paperチャンネルが作られたので入り口として覗いてみるのも良いですね。

【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜

こちらは配信なしで、各所のコミュニティの生の話が聞けて良きセッションでした。

お隣さん、で個人的にやはり思ったのはそれぞれ特色はありつつ、SREの文脈でももう少しこういう話あってもいいのでは、みたいな内容が他のカンファレンスでもあったりするのでそういったことを輸入する機会があっても良い、超個人的にはeBPFでオブザーバビリティ的な話がもう少しあってもいいと思うしなあ、みたいな話であったり、実際SRECONではこれくらいのトピック結構出てくるので、特色を損なわない程度に少しずつ相互交流があるとお互いいいよなあ、などと思った次第でした。

ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値

まずブルームバーグだ、という点でSRECON的な香りを感じておお、となったセッション。

セントラルモニタリングシステムを自前運用する話で、ちょうどその裏側のお話も懇親会で少し掘らせて頂いたのですが今後もネタがありそうだなあということで未来を感じる楽しみなお話でした。

開発者とともに作る Site Reliability Engineering

@chaspyさんの修論セッション。
チームにフォーカスした@chaspyさんらしい良いセッションでしたね。

最終的に文化の話になっていて、文化はたしかにプラクティスの上位というか根幹にくるもので、ベースの文化というのはおいそれと変わらないですし文化にマッチしないプラクティスはそもそも根付かないであろうというところで、翻ってなんらかのプラクティスを持ち込むためにはたとえ実際に良いものであったとしても文化にマッチするかどうか、を詰めるべきなんだろうな、などと考えた回でした。

信頼性目標とシステムアーキテクチャー

クロージングに来つつ、基本に立ち返るような骨太な話だなーという印象のセッションでした。
サービスの目標、SLOを定めじゃあどう実現していくかということについて深く考えていくとそこからアーキテクチャにするべきなのか、運用はどうあるべきなのかという話になり、当然そこにはコストも時間もかかり・・、というところで会話を通しての意思決定が重要になる、という話がありつつじゃあ実際どこまでやるべきか、を各々が決めていく、答えはないけどヒントならあるよ、という実際これがSRENEXT的な話でもあるよなあと思ったクロージングでした。

セッション以外

雑多に箇条書きで

  • 会場めちゃ良かった
  • コーヒー助かる、カンファレンス会場で豆を買ったのはさすがに初でした
  • 懇親会は話したいなーと思っていた方々とはだいたいお話できたと思いつつ限られた時間の中でもっと話したい人もいたなあという悩ましさ、ケータリングも配慮が行き届いていて大変良かったのですが人と話す方を優先したい気持ちが強くほとんどビールとトークという感じで終わってしまった

今後について

@chaspy_さんは引退！というお話をされていましたが自分もそこまでではないにせよ、登壇したさは今回ピークを迎えいったんネタも出しつくして一区切りかなーと思っております、まあ先のことはわからんですしなにか話したいネタが発生したらがんばるかもしれません。

コミュニティ的にも新しい分野、企業からの発表が増えてきてそれを聞いていきたいという思いも強く、イベントが続く限りなんらかの形で関わっていきたいなあとぼんやり考えております。

あと全般的に、成功事例！みたいなのばかりでなくもう少しナマな話があってもいいよねえというのもあって（いうて自分も2022の発表はそういうのをまあまあ出していったつもりはありつつ）、ゆるSRE方面ではそういうのをやろうかみたいな機運も一部ではあるらしいので若干興味が湧いているところでもございます。

最後に、運営皆様素晴らしいイベントをありがとうございました。

ハイブリッド開催めちゃ大変だったと思いますが、1参加者、スピーカーとしてスタッフ皆様に御礼申し上げます。