SREに関する国内最大級カンファレンスであるSRE NEXTに参加してきました！

SRE NEXT とは

Home | SRE NEXT 2023

SRE NEXTとは

信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。 SRE NEXT 2023は「Interactivity」「Diversity」「Empathy」という３つの価値観を掲げ、「双方向性のある意見交換の場にすること」「スタートアップから大企業まで、幅広い業種・領域・フェーズでのSRE Practice の実践を集約すること」「ビジネスサイド含めSRE以外の職責も含めて裾野を広げること」を意識して運営していき、より多様なSREの実践が普及することを目指します。

今回はハイブリッド形式、オフラインの会場は九段会館テラスで開催されました。自分は初めて行ったのですが建物が国会議事堂から突如生えてきたオフィスビルみたいでなんかすごかったです。（小学生）

印象に残ったトーク

印象に残ったトークをいくつか紹介していきます。

勘に頼らず原因を⾒つけるためのオブザーバビリティ

by SanSan株式会社じょーし (@paper2parasol) さん

speakerdeck.com

定義
- オブザーバビリティとは：システムの出力を調査することによって内部の状態を測定する能力
- オブザーバビリティが高い状況とは：ソフトウェアシステムのどんな状態でも、どんなに斬新で奇妙な問題でもデバッグして正しい原因を素早く見つけられる状況
- オブザーバビリティが低い状況とは：長く在籍するベテランが勘と経験に頼ったデバッグをしている
オブザーバビリティを支えるPrimary Signals
- メトリクス：システムのハイレベルな概要を示すが、必ずしも根本原因を明らかにするわけではない
- ログ：根本原因を特定する情報が含まれる可能性が高いが、情報量が多く絞り込みが必要
- トレース：特定のリクエストがシステムを通過する流れを可視化し、関連するログを絞り込む
理想的なデバッグ：ドリルダウン探索
- 原因が潜む範囲を狭めつつ、全体から細部へドリルダウンを繰り返しながら的確に原因を特定していく
- 勘と経験に頼った探索の問題点である「複合要因の見逃し」と「思い込みによる調査の難航」を防止
- Bill Oneでは、APM製品（サービスマップ・トレーシング）の導入により問題の特定能力を向上

オブザーバビリティの体系的な定義から始まり、理想な形のシステム調査を示した上で実際の取り組むを紹介するというプレゼン全体の流れがとてもまとまっていて分かりやすかったです。これまでログとメトリクスしか意識できていなかったのですがトレースの重要性を改めて認識することができました。

SREを以てセキュリティエンジニアリングを制す ― class Dev"Sec"Opsの実装に向けて

by 株式会社Flatt Security 米内貴志 (@lmt_swallow) さん

ReliabilityとSecurityは多くの点で類似点がある
- システムのライフサイクルに必要不可欠であり、設計段階での考慮が必要
- 問題が起きないとコストをかけにくく、問題が起きて初めて深刻になる
- SREのプラクティスをセキュリティにも活用できないか？
よくあるセキュリティスコアをSLI (Security Level Indicator) に置く問題点
- 範囲が不明瞭・不十分だとアクションに繋がらない
- 重大さがわからないと使いにくい（この値がどうだったら問題あり、と言えるのか）
- 割合を計算する指標は、特定のリスクの発生をぼかしてしまう
守りたいものと脅威を元に、何を計測するか決める
- プロダクトが持つ重要な資産と、それを取り巻く環境、環境内の脅威と考えうる脆弱性
- それを元に、どのレイヤーの何を見るとリスクが洗い出せるのかを考える
- システムによる差異はあるものの、クラウドネイティブなシステムでは大まかな類型が適用できる（→CSPM）
リスクをレベル分けして、レベル帯ごとにアプローチを変える
- Critical
  - 侵害を起こしうるリスク・最重要な管理権限の保護不足
  - エラーバジェット = 0、全て即時に対応する
- High / Medium
  - アタックサーフェースを作っている、侵害経路は不明確だが侵害時の影響が大きい
  - エラーバジェットでアジリティとのバランスを取りつつ管理していく
- Low / Info
  - 影響は軽微・意図した設定
  - 教育等に活用

ReliabilityとSecurityの類推から始まりSREのアプローチを転用できないかという着眼点の面白さや、思考実験によって指標に求められる要件を整理して落とし所を探っていくアプローチの上手さがさすがだなと思いました。近年クラウドの普及に伴ってシフトレフトやゼロタッチプロダクションなどがますます注目を集めていることを踏まえると、今後もセキュリティを絡めたSREの話題は増えていきそうですね。

Yahoo!ショッピング商品管理システムにおける、問い合わせ駆動の信頼性向上の取り組み

by ヤフー株式会社吉冨優太 (@tomi_bonobo) さん

不具合の疑いがある問い合わせでも、未解決のまま返答するケースがあった
- ヘルプデスク -> システム企画 -> 問い合わせエンジニアという体制
- 開発エンジニアが不具合疑いの問い合わせを把握していなかった
- 問い合わせエンジニアが調査に時間を取られ、開発者に連携していなかった
問題に逐次対応しながら、問い合わせ対応のプロセスを改善していく
- 問い合わせエンジニアと開発エンジニアの連携の不足 -> 各役割が取るべき問い合わせ内容を決めて振り分けルールを作成
- 問い合わせ経路・内容がバラバラで、解決までにかかる日数がまちまち -> 経路をSREで集約して全問い合わせの状況を誰でも確認可能に
- エンジニアからヘルプデスクへの追加情報の確認作業がしばしば発生 -> 問い合わせチケットのフォーマットを統一
- エンジニアの調査の内容がシステム企画の認識とずれていてやり直しが発生 -> 個別の問い合わせ以外で定期的に会話する場の整備
問い合わせ駆動の信頼性向上
- 問い合わせ業務フローの整備によってSRE/開発がお客様の声をチケットとして蓄積
- 問い合わせチケットの蓄積/分析によって、お客様の声を反映した優先度で不具合を修正・信頼性を向上していけるようになった

問い合わせ対応という一見遠そうに見える業務の改善にSREがコミットしてプロダクトの信頼性を向上していくという取り組みが素敵だなと感じました。またその改善策は一つ一つの問題に向き合った地道なものではありつつも、目的と手法、検証までがセットになったデータドリブンなアプローチに基づいていて着実に成果を生んでいるところが印象的でした。取り上げられていた問題もどれも身近なものですぐに業務に活かせるヒントも多かったです。