会の詳細はこちら
https://sre-next.dev/2023/
1年ぶり2回目の参加で、オフライン参加は初になります！
前回の参加記はこちら
総括
一言でいうと今までにないカンファレンス体験でした。 カンファレンス自体のクォリティの高さに加えて、自分のSREの知識の定着度、エンジニアとしての歴的なタイミングもあり、カンファレンスを終え一回り成長できた（ある意味では成長を実感できた）気がします。
現職はサービスの特性もありインフラないしSRE領域は四半期に1度集中的に取り組み、あとはデータ基盤の諸々を行う間に適宜対応するような状態です。比率でいうと2:8くらい
エンジニア自体10名程でメインシステムはお陰様でEKS上で安定稼働しています。そのため過去の勉強会でEnablingSREとかの話を聞いても現実味が無いことも多かったです。
ここ1年でようやくSRE本を読み終え、他の勉強会・カンファレンスでも色々SREについて触れていく中でSREの解像度がそこそこ高い状態で、今回のSRE NEXTに参加しました。
今回のカンファレンスでは分かっていた状態からより深い領域まで理解が進んだ点もありますし、見落としていた部分を拾えたり、組織規模によって取り組み方は若干異なるにしろ根幹の部分と、SREの取り組みについての距離感的なものが掴めた気がします。
内容に対して自社に照らし合わせどこまでやっていくか、ここは切り捨てても良さそう、この領域は先々来るのでうっすらと理解しておくなど、自分の中で取り込む知識の濃淡を付けられるようになった気がします。
これは今回のセッションが組織規模・業種・テーマから幅広かったからというのもあるでしょうし、予備知識としてSREしかり、もうすぐ勤続3年である会社の立ち位置が分かってきているというのもある気がします。（もうすぐエンジニア歴10年…） また懇親会で現職を紹介しリアクションを得たり、他社の話を聞き生の色んな話を聞くことで、自分の立ち位置を再認識できたというのもあると思います。
この感覚は今までのカンファレンスにはなく、なんか不思議な感じです。（カンファレンス終了後数日ということで魔法にかかっているだけかもしれませんw） そもそもカンファレンス自体が久しぶりですし、自分の習熟度が高い状態で参加したカンファレンスが少ないのでは？という説もあります。
実はk8sとの距離感も最近分かりまして、現職ではEKS使っていて、一部OSSのカスタムリソースは使っているものの、作るほどではありません。Kubernetes Meetup Novice ですらその手の話題が多く、ついていけない感覚がありました。 ですが、カスタムリソースを作る場面は、既存システムで不便が出たらOSSの既存のリソース探して、それでもなかったら作る。というのが分かってからは必要なときにこの手の勉強会に参加すればいいし、聞く機会があるときは実装の細かい部分を聞き流してこういう課題のときはこういうアプローチがあるんだなと濃淡を付けて知識を取り込めるようになりました。
今回のセッションの学びの中から現職でやりたいことがいくつあり、どこまでやれるかはありますが、SREの考え方を活かし事業成長に繋げて行きたいと思います。
撮りたくなる工夫が多く撮ってしまった。（Twitterに上げるのは恥ずかしくて控えた）
学び
（当日のTwitterのpostを引っ張ってきつつ、後追いの感想とかを追加します） 毎回どこまで書くか迷いつつ今回はこのスタイルで
備えあれば患いなし：効率的なインシデント対応を目指すSREの取り組み
- LOWYAさん何回か買ったことあるけど、製造から販売まで一貫して行ってるの改めてすごい
- Severity Levels(SV) Datadogでラベル付けできるのは知っていたが、基準は全く考えていなかった
- ともかく容易に判定できるようにシンプルにするのが大事
- 遅延ならSEV-4,エラーならSEV-3
- 曖昧な表現は避ける（重要な機能、長時間の停止）
- 現職では障害が少なく判定する機会も少ないですが、先々そうなっていく際にどう運用していけばいいか分かった気がする
勘に頼らず原因を⾒付けるためのオブザーバビリティ
- オブザーバビリティ（可観測性、観測する能力）
- そもそもオブザーバビリティをキーワードでしか認識していなかったが完全理解できた
- 全体からドリルダウンでエラー調査大事なのわかる。思い込みで当たりつけてしまい余計に時間食う経験あるある
- オブザーバビリティを上げるためにMetrics、Trace、Logが重要。（現職はカバーできてる）
- このドリルダウン調査の仕方をDatadog諸々の使い方含め布教していくのもSRE
- 現職は障害が少なくこのような機会が少なめですが、せっかくDatadog使ってるわけだし期の区切りごととか、ポストモーテムのふりかえりとかのタイミングを作っていって浸透させていくと良さそう
- 一応半年に1度「犬を愛でる会」（Datadogを見る会）はやってる
- なんだかんだレイテンシーとかの改善のためにアプリケーションメンバーがAPM見るのとかはやっている気もする
【コミュニティコラボ企画】パネルディスカッション 信頼性に関わる、ご近所さんが集まりました
「CloudNative Days Tokyo」「Platform Engineering Meetup」「DevOpsDays Tokyo」を運営している3名のパネルディスカッション。オフライン限定コンテンツ
- CloudNative Daysはネタと習熟度の多様性のために運営増やしたとのこと。 横の連携は大変らしいが、ある意味人のマイクロサービス化？でパフォーマンス出そうとしているとも言えそう
- 運営サイドとしては幅広いネタを採用したいから、的外れかもしれないネタでもCfP出した方が良い…！
- 青山さんのk8s押しはすごい
- 現職ではk8s使っているものの、カスタムするほどでもなく距離感を感じつつも、必要になったときに豊富な情報があるのはよく、今は適切な距離感が分かっている。
- どのコミュニティも思想のゴールは違えど被るネタもあるし、アクションに対していくつものゴールを達成することはあるので捉え方次第。
- 流行りで職能名は変わったりするが、捉え方次第なのであまり気に過ぎなくて良いかもと思えてきた
- オフライン限定コンテンツで、配信を停止することで、配信班はお昼取れるのかなと感じた
プロダクトオーナーの視座から見た信頼性とオブザーバビリティ
- クリティカルユーザージャーニー（CUJ）
- これも聞いたことがあるようであまり理解していないキーワードだったが、なんとなく理解した
- SLIを決める上の上位に立つべき概念で、しっかりCUJが定まればSLI、SLOと決まっていくのだと改めて認識できた
- OpenTelemetryオライリーから発売された「オブザーバビリティ・エンジニアリング[1]」は非ベンダー依存を目指したアプリケーションモニタリングの実装方法としてOpenTelemetryを紹介しています。 監視基盤を実装する場合、Datadog[2]やNew Relic[3]などの監視SaaSを利用するかAWSやAzureが提供しているマネージドな監視サービスを利用すると思います。 直近の業務で使う機会はなさそうですが、アプリケーションモニタリングを収集するためのAPI、ライブラリ、エージェントを提供するOpenTelemetryという技術に興味が出てきましたので、概要やデモなどを紹介します。
- あまり知らなかったのですが、現職ではDatadogを使っているので使わなそうだなと思いつつ、発表内容を聞く限りOpenTelemetryを使うのは結構大変そうだった。
SREを以てセキュリティエンジニアリングを制す ― class Dev”Sec”Opsの実装に向けて
- セキュリティスコアの割合だけでは対応中々難しい。分かる なんのリスクなのか、どう対処するのが本質なのか、少し下がったらどうなのか等々
- セキュリティ、出発点は資産とは何か、どこまで守るか
- ここを見失うと漠然とした不安だけが残る
- Dependabotの残数だけではセキュリティのSLIは評価しにくい
- Dependabotのつらみなのか会場でざわめきが（！）
- セキュリティAWS Well-Architectedのセキュリティの柱を自力で答えるのは骨が折れてくるので、分かりやすくなってるセキュリティソフト使うのも手なんだろうな..
- 後々会話し、どちらかというとSecurityHUBの対処内容を丁寧にしているセキュリティソフトでした。
- スポンサーセッションのレベルが高いのとても良い
後々Flatt Securityのスポンサーブースを訪れ会話しました。
- ブラックボックス型が中心のイメージだった中で内側からアプローチする手法でここまでIaC寄りにまとまっているものは初めて見たので衝撃的でした
- 個人的には興味があったのですが、後々社内で確認したところペネトレーションテストである必要があるっぽく今回はマッチしなさそう…
電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践
- 同じIoTを扱う企業としてどのようにSLOやってるのかが気になっていた
- CUJに対して、IoTデバイスを対象にCMCをLuupで定義
- Critical Machine Communication
- マシンが期待通りにできる状態であるか
- Luupが独自に定義した言葉
- Luupのエンジニア、正社員10名、SRE2名で残りは業務委託。思ったより正社員が少ない
- この中でSREのEnablingしていく工夫も
- SLIにフォーカスしてSRE>IoT,Engineer＞Ops…etcに習熟度調査を行いながら浸透させていく
- Luupでは異常のあるデバイスは、貸出できないようにする（サービスアウト）することで、ユーザーの体験を担保している
- IoTデバイス系でも、今回見たくサービスアウトをコントロールできるタイプと、デバイスとユーザーが1対1でコントロールできないケースもあるよな（弊社）
（postは社名をtypoしてしまった…反省）
- 現職でもCUJ的な定義が一部ありますが、まだ表面的な指標にしかなっておらず、より深い領域の指標を定義していきたいと感じました
SREの組織類型に応じたリーダーシップの考察
- podcast「もう一度読むSRE」聞いております
- そんなCTOからSRE本の説明を受ける側（事業側）がみる考察内容でした
- リーダーシップ理論、最近はコンセプト理論。サーバントリーダーシップもそのうちの一つ なるほど
- SL理論の4つの状態とSREの導入かー こういう観点での話は中々無い気がする
- 指示的行動の多い少ない、援助的行動の多い少ないを軸に以下のようなフェーズで推移していく
- 指示型＞コーチ型＞支援型＞委任型
- なかなかSRE文化を中の人として導入する話は聞くけど、導入をサポートする立場の話は聞かないので新鮮でした。
- システム的な安定稼働（信頼性）は達成している（困っていない）が、そろそろユーザー体験としての信頼性にフォーカスして取り組むのもありなのかもしれない
Runbookに何を書き、どのようにアラートを振り分けるか？
※Runbook=手順書
- Runbookレベルでのアクションを決めたうえでアラートを作成する…ｳｯ
- 過去の経緯で作ったアラートがまだなんとなく残っていて、アラートが出ても特に対処を決めていないものがある…アラート出ても問題ないので緩和するか、別の方法で問題を検知するかどちらかで良い気がする（どっかでやる）
- 現職の組織の規模感的に、DevとOpsが分かれていないのでそこまで厳密にやらなくても良いかなと思いますが、手順書の最新化は置き去りになりがち（とは言えISMSの更新の中で年1でなんとなく見直される）なので、見直す機会を作るというか、今回の話の通りアラートと対処をしっかりと紐づけたほうが良いのかもしれない…
開発者とともに作る Site Reliability Engineering
- SREが仕事を作るのか、フィードバックを得ながら仕事をするのか
- 自己完結度とツールやSaaSの習熟度についてフィードバックを得る
- devがやれること（やりたいことはサポート）をやって、こぼれ球をSREが拾うスタイルというのはよく分かる
- 分かり手の不足w （EnablingSREの出番が必要になる組織ならでは感もある）
- 弊社ふりかえりは定着してきている（プロジェクトのふりかえりが甘い）けど、フィードバックの文化は弱い気がする。挑戦はぼちぼち？
- リクルート社の組織文化として、「ふりかえり」「フィードバック」「挑戦」が挙げられていた
- 大企業で信頼性を導入していく工夫がよくわかった気がする
- 現職の規模でどこまでやるかというのはまた難しい問題
信頼性目標とシステムアーキテクチャー
- サービスのフェーズ、予算を見ながらSLOを決めていく。正解はないが、http://r9y.dev はヒントになる
- クロージングキーノートだけあって、改めてSLOを復習しつつ、適切なSLOはフェーズ諸々によって違うので会話していくしか無いという原点に立ち返る内容でした。
そのほか当日の登壇資料一覧を他の方がまとめているのでリンクします
SRE Next 2023 資料一覧
集中力的な話
与太話です。結論から言うと全登壇、集中して聞けました。
1日を通すカンファレンスって全登壇に集中して聞けるかというのに不安があるわけです。若手の頃に比べ疲れやすくなっている気がするのもあり…
参加前は正直なところ内容がもりだくさんで不安があったのですが、20分単位の発表だったからか、休憩時間が適切だったのか、はたまたコロナを経たオフライン開催で十分な換気により酸素が不足していなかったのか。集中力が続きました。 どちらかというとスマホのバッテリーのほうが持たなかった（モバイルバッテリーを忘れたので、所々で仕事部屋の電源席で充電していた）
会議室Cは広さの都合上席が足りない場面があり、椅子取りゲームになっていました。半分くらい机を取っ払って椅子を置くのも手だったのかも？
スポンサーブース
前回のオンライン開催の記事で全く行かなかった話を書きましたが、今回は色んな仕組みもありぼちぼち回りました。
- スタンプラリー形式
- 最後に抽選に参加できノベルティが当たる。自分はホットアイマスクが当たった！
- 登壇で興味を持って聞きに行くパターン
- Xの投稿を見て行くハードルが下がって行くパターン
- 部屋の移動の導線上に合って寄り易い
なんかノベルティだけもらうのが気が引けてなんか話をしようとしてしまい、逆にアレな気はするときも合ったのですが… 主にスポンサーさんの目的としては採用目的、製品紹介でした。どっちか判断しにくい企業もあり「製品は何押しですか？」って聞いてしまったw
（週休3日できる企業増えてくれ…！）
懇親会ムーブ
料理を会場側が用意するタイプの箱だったため、料理・会場側スタッフ含め豪華でした。先行チケットで4000円払っているので相応だったと言えば相応だったのかもしれない。（というと怒られそうですがｗそもそも先行チケットは一般参加0円なのがすごい。先行じゃないものの費用はよく分かってない）
寿司も何度もデプロイされていた様子でしたし、デザートも食べお腹いっぱいになりました。懇親会では机にあるビールを飲みがち。野菜は人気なかった。
個人的には登壇者と話したいなどの特段なモチベーションは無いのですが、1卓20分位を目安に色んな人と話すことを意識して回りました。何人かの方とも名刺交換しました。
（別のカンファレンスでも思ったけど、XのID分からないからなんとなく記憶に残っても接点としてはそれっきりになってしまう…のでXアカウントシールとか名刺に貼ったほうが良い…もしくは手書き）
会話の流れで会社について聞かれることが多いですが、現職のビジネスモデルは一言で説明しにくく、今回はプレスリリースの画像を用意しておき30s-1minで説明するようにしました。
ユニークな事やっているというフィードバックと、IoTデバイスが故の大変さを感じてもらう事が多く改めて現職の立ち位置を認識できた気がします。
ちなみに懇親会のトーク内容はざっくりこんな感じ
SREかどうか聞く ＞ 会社について聞く ＞ この辺で名刺交換する ＞ 直近の課題感とか聞く （双方に聞きつつネタが尽きてきた頃にテーブルを去り次の場所へ）
眩しく見える登壇者と運営、参加者
午後一のトークセッションで、カンファレンスの運営側にフォーカスしたトークがあり、改めて運営の尊さを感じました。
また登壇という観点でCfPを出す人を自分のXでも観測するようになり、自分の周りはすごいなということを思う場面もあります。
はたまたオフライン開催が復活していく中で、各地各言語などの色んなカンファレンスに積極的に参加している若手や、色んな年代の運営サイドの人も見かけることが増え、自分にはできないなと感じることもあります。 （自分は意図的にこの領域に力を入れないという選択をしていて、年に2~4会のカンファレンス参加、チャンスが有れば登壇くらいのスタンスです）
ただ、CfPに関してはど直球のテーマなんて出せないという概念が、幅広いテーマを取りたいので解釈次第であり、出すことに意味があるということが分かったという意味では、敷居が下がった気がします。（データエンジニアとSREも解釈次第で共通項が合ったりなかったりするので）
おわりに
今回はセームタオルの一回水を吸わせて絞ったあとのように、色々吸水できる状態だったと感じます。
なんかミドルクラスのエンジニア（リード）としてアクションを行うときの選択肢の知識量しかり、裏付けに対しての自信がついた気がします。
日々の仕事に忙殺されつつも、今回の学びを少しずつ実践していきます！