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

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

⾃⼰紹介名前: Shogo Fukami 所属: 株式会社カナリー役割: テクニカルリードエンジニア（テックリード）趣味: 週2で温泉‧サウナ
温泉ソムリエ認定 X: @react_nextjs

「SLO / SLIを策定して運⽤してください。」「アラートの仕組みを作ってください。」

アプリケーションエンジニアの僕「何それ美味しいの？」状態でした

意識することなくSREのキャリアをスタートしました

課題 SLO/SLI: そもそもアプリケーションの信頼性が測れない ‧何をもって「OK」なのか基準が不明確アラート基盤: 障害を正しく検知できない / ノイズ多い ‧「狼少年」状態のアラート →
本当の障害を⾒逃すリスク影響サービスの品質レベルが不明、事故の⾒逃し or アラート疲れ、

やったこと（SLO/SLI基盤） SLI定義 Datadogでの実装 SLO算出⽅法の整備成功リクエスト率レイテンシ Web Core Vitals エラー率
エラーバジェットアラートバーンレートアラートダッシュボード作成ローリング/カレンダーウィンドウエラー予算管理

難しかったこと（SLO/SLI） PdMとのSLI/SLOの合意形成が難しいサービスレベルの⽬線合わせの必要性対応: 反復的なアプローチで解決ビジネス価値 ≒ お客様体験 ≒ 技術指標
① 定義候補 → ② サンプル可視化 → ③ ⼩さく運⽤ → ④ ⾒直し

やったこと（アラート基盤構築）既存アラート棚卸しとノイズ削減（重複‧無効‧閾値⾒直し） SentryとDatadogをDatadogに⼀本化（集約/運⽤負荷軽減） Datadog Workﬂow AutomationでAIを使⽤した⼀次対応フロー整備

難しかったこと（アラート基盤）フロントエンドのアラートは多変数: ブラウザ/OS/Bot/JSランタイムなど⼀次調査が⼤変でした対応: Workﬂow AutomationでAI化調査を挟み、再現条件/影響範囲を⾃動要約効果: 調査時間短縮、誤検知削減、優先度付けが明確に

半年で得た学びアプリケーション開発と違いSREは守りの分野だが、事業の速度を⽀える攻めの基盤でもあるエンジニアを5年ぐらいやってると未経験の分野でも⼀定以上の成果は出せるいいサービスを継続していくにしてもSREの領域はアプリケーションエンジニアでも⼀度は経験した⽅が良い

まとめ / Thank you 計測 → 合意 → ⾃動化で「⾒える化」と「静かな運⽤」を実現
次の⼀歩: 皆さんのサービスでも SLI定義から始めてみてくださいご清聴ありがとうございました

Shogo Fukami