URLは年次関係なさそうだけどいちおう。
オープニングセッションから懇親会までフル参加した。大変だったなーと思ったけど疲れの半分は昼飯抜きで参加したことによるものかもしれない。低血糖的な状態だった可能性はある。
いろんな会社のいろんな人がSREという概念にどう向き合うか試行錯誤していることが伝わってきて面白かった。課題の具体的な切り口は各社・各チームによってそれぞれだけど、構造的な共通点がありそう。
ざっと「SRE」的なものについての自分なりの納得をまとめると、
- SREはプロダクトチームが取り組むエンジニアリングの側面であり、運用とかインフラとか呼ばれていた人たちに求められていた漠然な要請を整理したもの
- 信頼性100%ではなくSLOの範囲に収まっていればよい
- SLOの許す範囲でリスクをとっていく
- エラーバジェットを消費しないアクションを増やす、既存のアクションが消費するエラーバジェットを減らす = 改善
- エラーバジェットだけでなく、パフォーマンス劣化バジェット、セキュリティバジェットとかいろんな枠が考えられる
- SRE職の人間も当然にアプリを直す。アプリチームとSREチームを分けるとしたら扱う対象ではなく責任を持つ指標が違うだけ
- わざわざプロダクト横断チームとしておく目的、機能性はあまり見えない。考え方を広める、技術支援をするなど?
- 伝統的に「共通のインフラ」を持っている組織ではそれと紐づいて信頼性が左右されるから横断チームを作るケースが多そう
- ベストプラクティスではなさそう
- 横断チームだけ置いても機能しない。SREはそれぞれのプロダクト開発の中で実践される必要がある
- SREはバックエンドだけでは成立しなくて、ユーザー体験全体までスコープに入れたい
- が、そこまでできている会社は多くないっぽい
- Javascript のエラーとかもちゃんと追ってる？ アプリは？
その上で DevOps というか効果的な開発・運用スタイルを作り込んでいくぞという話題があったように思う。グリーの人の Actionable なアラートについての考察と対応はすごくよくて参考にしたいなと思ったし、SREタスクは細かいいろんな種類のものが割り込みでいっぱい発生するので必ずペアでアサインするようにしてるっていう Google の話も納得感あった。普段やらないオペレーションは怖いから日常的にやるようにしようとか、ポストモーテムで人ではなく事実にフォーカスを当てるのはいうのは簡単だけど訓練必要とかも、当たり前だけどできてないなーという気持ち。オンボードやスキルセット、採用の話については「SRE固有のものは特にないよね」とパネルの人たちがだいたい一致していたのも印象的だった。
追記: Qiitaに資料まとめ作ってる人がいた。ありがたい。
