Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「なぜ」を残し、SLOを育てる IaCによるSLI/SLO運用の実践

Avatar for Nealle Nealle
February 18, 2026

「なぜ」を残し、SLOを育てる IaCによるSLI/SLO運用の実践

Japan Datadog User Group Meetup#15@東京 での登壇資料です。
https://datadog-jp.connpass.com/event/378380/

Avatar for Nealle

Nealle

February 18, 2026
Tweet

More Decks by Nealle

Other Decks in Technology

Transcript

  1. 2026.02.18 Japan Datadog User Group Meetup#15@東京 
 株式会社ニーリー 
 高

    直我 @nogtk 
 NEALLE 「なぜ」を残し、SLOを育てる 
 IaCによるSLI/SLO運用の実践 
 1
  2. 4 氏名 所属 経歴 高 直我 / Naoga Taka 


    株式会社ニーリー
 プロダクト統括本部 プラットフォームエンジニアリングG 
 SRE / プラットフォームエンジニアリング 
 趣味 ゲーム 🎮 (最近ペルソナ3Rをクリアしました) 2019-2024 (株式会社マネーフォワード) 
 Backendエンジニアとキャリアをスタート 
 担当プロダクトがオンプレ -> AWS に移行したことをきっかけに 
 AWS/k8s/Datadog あたりの技術に触れ、徐々に軸足がそちらに 
 2025- (株式会社ニーリー) 
 SRE へロールチェンジしニーリーにジョイン 💪
 1|自己紹介 
 @_nogtk_ @nogtk
  3. SLI / SLO とは 
 3|なぜ SLI/SLO ダッシュボードを IaC するのか

    
 8 • SLI (Service Level Indicator: サービスレベル指標) 
 ◦ サービスの品質を測る指標
 ◦ リクエストのエラーレート、レイテンシ etc.
 
 • SLO (Service Level Objective:サービスレベル目標) 
 ◦ SLI として定めた指標の目標値
 ◦ p99 でAPIレイテンシが 200ms 以内 etc.
 ➡ システムの健全性を数値で管理する仕組み 

  4. “システムの健全性” を定義するのは難しい 
 3|なぜ SLI/SLO ダッシュボードを IaC するのか 11 •

    リクエスト成功率は99.9%あれば十分?レイテンシは?
 • そもそもリクエスト成功率とレイテンシを見てればシステムの健全性が 測れているんだっけ?
 • システム(プロダクト)の成長・提供価値のアップデートに、SLI/SLO 視点でも追従していく必要性 
 ➡ システムの健全性の定義 (SLI/SLO運用) は反復的なプロセス 🔁
 一度決めて終わりというものではない 

  5. 3|なぜ SLI/SLO ダッシュボードを IaC するのか 12 SLOの定義とターゲットは、時間と共に システムの振る舞いについて学ぶにつれ て、いつでも見直していくことができま す。初めに厳しすぎるターゲットを設定

    して、後からそれが実現できないことが 分かってから、緩めていくよりは、緩め のターゲットから始めて厳しくしていく 方が良いのです。 SLIやSLOは、それらが表現している サービスの実態が時間とともに変化する につれて、変わっていくべきものです。 時間の経過に伴い、それらを検証して改 良することを恐れないでください! “2.6.1 SLOの品質の改善” より 
 “4.3.2 ターゲットの選択” より 

  6. • 過去の判断がわからず困る 
 ◦ なぜこのSLIになっている?
 ◦ なぜエラーレートは 99.9% ではなく 90%?


    
 • 変更に対する躊躇 
 ◦ 本当に SLO の閾値変えていいのかな...?
 ◦ 過去に何か理由があったのでは?
 
 • 同じ議論の堂々巡り 
 ◦ それ前も議論したよね
 3|なぜ SLI/SLO ダッシュボードを IaC するのか 13 反復するには「なぜ」の記録が不可欠 
 ➡ 意思決定のログが反復プロセスを加速させる 🏃

  7. 3|なぜ SLI/SLO ダッシュボードを IaC するのか 14 そこで SLI/SLO リソースの IaC

    🔧📝
 • Datadog の SLO / ダッシュボードを IaC することで、変更の 証跡がPRとして残る! 
 ◦ 自然と変更ログが残る “力学” が働く
 

  8. 4|どのように IaC しているか 16 ① SLO のリストを宣言 
 ② SLO

    / Dashboard 用の Terraform module に値を渡す 
 ③ それぞれの module 内でリソース作成 

  9. 4|どのように IaC しているか 17 【左の例】
 “トップページを開く” というシナリオに 対して以下を宣言している
 
 •

    フロントエンドのパス
 • バックエンドのパス
 • 1週間・1ヶ月の成功率/レイテン シ

  10. 4|どのように IaC しているか 23 • 
 最終的にこんな Diff で、PR をマージし

    Apply することで、 SLO / ダッシュボードが自動で更新される 👏

  11. 5|課題 25 
 • Terraform コードが技巧的・重厚になりつつある 
 ◦ 今は比較的 Terraform

    に明るい SRE メンバー中心にメンテしている
 ◦ 今後プロダクトエンジニアに委譲していく流れも踏まえると、もっとシンプルにして いきたい気持ちが
 
 • ちょっとしたメモがダッシュボードに残せない 
 ◦ 悪化時の調査ログや “調査中” などのメモを残したい時がある
 ◦ 毎回 Terraform 経由で apply or import するのもしんどい
 ◦ ダッシュボード下部に Terraform 管理外のメモ用ウィジェットを置いて運用してい る

  12. • 変更ログをちゃんと追いたいリソースは IaC を検討する 
 ◦ SLO をトピックに今回はお話しした
 ◦ 設定不備を許容したくないクリティカルなモニターなど、他にも適用できる

    リソースはありそう
 
 • 「なぜこの設定値か」というコンテキストは資産になる 
 ◦ コード化 + コンテキスト (意思決定ログ) によって AI エージェントにもフレ ンドリーに
 
 
 6|まとめ 27 まとめ