駆け出しSREが半年で作り上げた仕組みと学びのまとめ

Transcript

1. 駆け出しSREが半年で作り上げた 仕組みと学びのまとめ Shogo Fukami
2. ⾃⼰紹介 名前: Shogo Fukami 所属: 株式会社カナリー 役割: テクニカルリードエンジニア（テックリード） 趣味: 週2で温泉‧サウナ 温泉ソムリエ認定 X: @react_nextjs
3. 「SLO / SLIを策定して運⽤してください。」 「アラートの仕組みを作ってください。」
4. アプリケーションエンジニアの僕 「何それ美味しいの？」 状態でした
5. 意識することなくSREのキャリアをスタートしました
6. 課題 SLO/SLI: そもそもアプリケーションの信頼性が測れない ‧何をもって「OK」なのか基準が不明確 アラート基盤: 障害を正しく検知できない / ノイズ多い ‧「狼少年」状態のアラート → 本当の障害を⾒逃すリスク 影響 サービスの品質レベルが不明、事故の⾒逃し or アラート疲れ、
7. やったこと（SLO/SLI基盤） SLI定義 Datadogでの実装 SLO算出⽅法の整備 成功リクエスト率 レイテンシ Web Core Vitals エラー率 エラーバジェットアラート バーンレートアラート ダッシュボード作成 ローリング/カレンダーウィンドウ エラー予算管理
8. 難しかったこと（SLO/SLI） PdMとのSLI/SLOの合意形成が難しい サービスレベルの⽬線合わせの必要性 対応: 反復的なアプローチで解決 ビジネス価値 ≒ お客様体験 ≒ 技術指標 ① 定義候補 → ② サンプル可視化 → ③ ⼩さく運⽤ → ④ ⾒直し
9. やったこと（アラート基盤構築） 既存アラート棚卸しとノイズ削減 （重複‧無効‧閾値⾒直し） SentryとDatadogをDatadogに⼀本化 （集約/運⽤負荷軽減） Datadog Workflow AutomationでAIを使⽤した⼀次対応 フロー整備
10. 難しかったこと（アラート基盤） フロントエンドのアラートは多変数: ブラウザ/OS/Bot/JSランタイムなど⼀次調査が⼤変でした 対応: Workflow AutomationでAI化調査を挟み、再現条件/影響範囲を⾃動要約 効果: 調査時間短縮、誤検知削減、優先度付けが明確に
11. 半年で得た学び アプリケーション開発と違いSREは守りの分野だが、事業の速度を⽀える攻めの基盤でもある エンジニアを5年ぐらいやってると未経験の分野でも⼀定以上の成果は出せる いいサービスを継続していくにしてもSREの領域はアプリケーションエンジニアでも⼀度は経験し た⽅が良い
12. まとめ / Thank you 計測 → 合意 → ⾃動化で 「⾒える化」と「静かな運⽤」を実現 次の⼀歩: 皆さんのサービスでも SLI定義から始めてみてください ご清聴ありがとうございました