システム監視を 「システムを監視するだけ」で 終わらせないために

Transcript

1. システム監視を 「システムを監視 👀 するだけ」で 終わらせないために 導入レベルと実践課題 SLI/SLO 2026/7/26 SRE Lounge Hiroshima #2
2. 自⼰紹介 宇田 誠之朗（うだ せいしろう） 年 株式会社Skillnote に 一人目SRE として入社 現在は開発EM 広島からフルリモート 2022
3. 用語の定義 ：システムの可⽤性を測る主要な測定値 ： の目標値 ： を満たさなかった場合の条件契約 ：プロダクトにとって最も重要なユーザーの操作の流れ(Critical SLI SLO SLI SLA SLO CUJ User Journey)
4. のよく耳にする声 SLI/SLO システム監視はしているがSLI/SLOを定めていない 定めているが有効活用できていない、活⽤方法がわからない インフラ健全性指標としてのみ使用している
5. の活用とは SLI/SLO はシステムに詳しくない人間でもシステムの健全性を 測ることができる客観指標 活用できている状態 ＝インフラ運用者・システム監視者だけでなく、 組織の意思決定と行動が指標をもとに⾏われている状態 SLI/SLO
6. 導入レベル例 SLI/SLO 状態 Lv0 監視はしているがSLI/SLOなし Lv1 CUJ(or 監視要件)を決める、SLIを計測している Lv2 SLOを定め計測している(SLI/SLO/CUJが揃っている) Lv3 ポリシーをチーム・部門で合意し、意思決定に活⽤している Lv4 ポリシーを部門横断・社内で合意し、意思決定に活⽤している Lv ポリシーはSLO違反時の対応や意思決定の基準など(エラーバジェットポリシー)
7. 整備の取り組み 整備の流れ CUJを定義 SLI：多くのメトリクスの中からCUJに影響するSLIを選別 成功リクエスト率、 レスポンスタイム API 副) テナント別の毎時リクエスト数 / 同時アクティブユーザー数/DB AAS 当時参考にした情報 Google Cloud Well-Architected Framework https://docs.cloud.google.com/architecture/framework/reliability 本 ゴールデンシグナル等 SRE SLI/SLO/
8. 定義における課題 SLO プロダクト特性 マルチテナント型サービス 製造業エンプラ向け 情報集約性・表現自由度が高いメイン機能 前提となる要件 テナント毎 API毎のパフォーマンスの偏差が大きい マクロ 全体 を見ると顧客体感を取りこぼし、 → ( ( ) ミクロ 個別テナント)を追うと個別最適化やもぐらたたきになる 社内でパフォーマンス信頼性のコンセンサスをとりにくい
9. 定義のアプローチ SLO 目的に応じてAPIリクエスト軸とテナント軸の指標の分離 APIリクエスト軸＝プロダクト健全性指標 ダッシュボードで統合健全性指標 アグリゲート として監視 DatadogSLO SLO は仮運用中 ( SLO) テナント軸 =顧客満足度向上 のパフォーマンス下位テナントを一覧にしたダッシュボードを作成 SLI Teams の誰でも見れる場所へ埋め込み 事業判断との連結 NPSと計測指標のつなぎ込み パフォーマンス課題の共通認識醸成 タスクフォース活動で改善を推進
10. まとめ は重要指標を全てSLIにするのではなく ステークホルダーとあるべき姿を共有の上、 それを測る指標を定める SLI/SLOの活用を成果に繋げるには時間がかかる 意思決定に繋げるための信頼性思想の定着は まだ試行錯誤中 SLI/SLO
11. ありがとうございました