概要
2023年9月29日に開催されたSRE NEXT 2023に参加してきました。この記事は、そのときの感想レポです。
自分の立ち位置
現在の自分：アプリケーション開発
やってみたいこと：クラウド、インフラ系、SRE
参加した目的：SREについてより知るため
全体的な感想
-
どのSREもシステムの信頼性をより高めていきたいという思いが感じられた。
-
SREチームだけではなく、開発チームもSREを意識することが重要である。
-
SREチームは開発チームと協力関係を築くべき。
-
属人化の解消の実績が多かった。
-
玄人向けな仕事であると前々から聞いていたが、そのような人が取り組むことで始めて真価が発揮される仕事だと思った。
参加したセッションの感想
1.ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜
内製化チームの立ち上げから、設計、コーディングをCTOとして全てに関与していくのは、かなりすごいと思った。また、イオンネクストのプラネットフォーム開発において、後から変えられない根幹の設計をとにかく厳格にしていくのは、いいアイデアと思ったと同時にそれを他の開発メンバーは意図を理解しているのかと疑問も浮かんだ。個人的に、入社当時の山積みの問題に思い当たる節がいくつかあって共感した。
2.LINEスタンプのSREing事例集：大量のスパイクアクセスを捌くためのSREing
万全な準備をするために3カ月前からサーバーの増設と様々な検証を行うところに本気度の高さをひしひしと感じた。特に、カオスエンジニアリングの考え方を検証に取り入れて、高負荷の試験を行っているのは、テスト環境よりも一層に本番に近い環境で検証可能ないい取り組みだと思った。システムの信頼性の向上には、先を見据えて準備をする姿勢も重要であると今回の事例紹介で実感した。
3.備えあれば患いなし：効率的なインシデント対応を目指すSREの取り組み
インシデント対応におけるセキュリティレベルズの明確化は非常に重要だと思った。インシデントの重要度を明確化することで対応時の動きをメンバーで統一することができ、余計なタスクをそぎ落とすことができると感じられた。また、インシデントファイヤードリルといったインシデント対応における模擬訓練を定期的に実践することはインシデント対応に課題があるチームではやっておくことが推奨されると思われる。LINEのセッションでも出てきたが、ドリルの取組はカオスエンジニアリングのツールを用いたものだったため、運用の現場においてカオスエンジニアリングの考え方の取り組みが活発化しているのを認識した。
4.勘に頼らず原因を見つけるためのオブザーバビリティ
オブザーバリティの向上のためドリルダウン探索を採用しているメリットがかなりわかった。ベテランのデバッガーは確かに頼りになると思われるが、セッションでも話されていた属人化、勘または思い込みによる調査難航、複合要因を見逃すケースなどといったデメリットがあるため、ドリルダウン探索を用いることで他のデバッガーも質の高いデバッグができると感じた。将来的には、ドリルダウン探索とベテランデバッガーの知見を両方使えるとより良いデバッグができると思った。
5. プロダクトオーナーとしてSLOに向き合う。Mackerelチームの事例
SLOを導入することでシステムの信頼性を定量化ができ、それを根拠にすることでチームメンバーだけでシステムの信頼性が担保されていることを判断できるようになる手法が面白かった。プロダクトオーナー自身が介入するタイミングをSLOの導入で減らすことで開発速度を上げるのは良い事例だと感じた。セッションでも言ってた通り、信頼性はユーザー側からしたら、反応が薄い事柄なのはその通りでしかないため、オーナーや開発メンバーの説明による理解を得る課題があるのは共感した。