今年はSLI/SLOの導入を頑張ってました！ 2024.12.18 渋谷でSRE忘年会

シンプルフォーム株式会社 自己紹介 2 守屋邦昭(@Zepprix) 経歴 ソシャゲのサーバーエンジニア ↓ 不動産テックの SRE ↓ 2024年2月にシンプルフォーム株式会社に入社 金融機関などで「法人の審査業務」等に利用できる SaaS の開発・運用 SRE Magazine 004 号に 寄稿させていただきました！ シンプルフォーム株式会社の一人目の SRE インフラチームと開発チームを兼任 Embedded SRE として開発や信頼性向上活動をやってます

シンプルフォーム株式会社 金融エンタープライズに特化した 法人調査の自動化システム 3

シンプルフォーム株式会社 今年やったこと 4 開発組織全体で意識する SLI/SLO の導入

シンプルフォーム株式会社 背景 5 各種メトリクスを可視化するダッシュボードが整備されており、DevOps チームが毎朝チェックしている 監視も整備されており、ユーザーから問い合わせが来る前に障害を社内で検知できているケースが多い 障害発生時にはエンジニアと CS が迅速に連携できている 当初は不要な気がしていた New Relic ダッシュボード すでにいい感じに運用できているし、 無理して SLO を設定しなくてもよいのでは？

シンプルフォーム株式会社 一転、導入する機運が高まった理由 6 複数チームに分かれているが、プロダクト数に合わせて分割されているわけではない 基盤プロダクト「SimpleCheck」など開発・運用時に複数チームが触る領域がいくつか存在する プロダクト間の API 連携もあり SimpleCheck SimpleMonitor 新規プロダクト DevOps T R&D 新規プロダクト T データ収集の自動化・効率化 T QA T インフラ T データ収集用 社内システム プロダクトとエンジニア組織構成

シンプルフォーム株式会社 一転、導入する機運が高まった理由 7 DevOps T データ収集の自動化・効率化 T 各チームの価値観の違い R&D 新規プロダクト T 新規プロダクトを 早くリリースした い！ 手動オペレーション を改善したい！ 同じシステムを触っていても、チーム毎に責任領域が異なるため価値観は異なる システム障害への感度など可用性に対する意識は DevOps チームが特に高い エンドユーザー 可用性を担保したい！

シンプルフォーム株式会社 一転、導入する機運が高まった理由 8 DevOps T データ収集の自動化・効率化 T R&D 新規プロダクト T それも大事だけ ど他にもやるこ とが.... DevOps チーム目線だと他チームが運用している連携用 API の可用性やデータ精度が システム全体の品質担保のネックになっているという意識が芽生えてしまう 一方で他チームにも優先したい課題が多くある 連携用 API の可用 性やデータ精度が 気になる... 各チームの価値観の違い

シンプルフォーム株式会社 9 一転、導入する機運が高まった理由 SLI/SLOへの期待 xxチーム xxチーム xxチーム xxチーム xxチーム 守るべき水準 (SLO) 品質や性能等に対する意識がチーム毎に異なる現状がある 意識を引き上げる必要もあるが同時に過剰に安全側に倒しすぎて生産性を落とすのもよくない どこまで守れば良いのかの水準を定めて「攻めと守りのバランス」を取れるようにしたい

シンプルフォーム株式会社 10 一転、導入する機運が高まった理由 DevOps T データ収集の自動化・効率化 T R&D 新規プロダクト T SLI/SLO策定委員会を結成 各開発チームからの有志 + CTO で構成 エンドユーザー(顧客)の目線も入れるため CS メンバーにも入ってもらう 開発組織全体で意識する SLI/SLO の検討を開始！ CTO CS

シンプルフォーム株式会社 11 どのようなプロセスで進めたか 委員会メンバーが各チームでファシリ 「我々が守るべき品質とは？」など伝わりやすい表現で進める 意見が発散しすぎることを防ぐために最低限のルールは決めておく 各開発チームで SLI 候補をブレスト あるチームで実施したブレストの様子 ブレストのルール 計測可能であること → 抽象的過ぎても後でまとめられない 達成目標(SLO)を設定する前提で指標を考えること → 改善していく価値がありそうな指標をイメージしてもらう

シンプルフォーム株式会社 どのようなプロセスで進めたか SLI/SLO を設定する目的を早い段階でドキュメント化！ 数ある SLI 案に優先度をつけていくための判断基準 やりたいことが発散しすぎる事態を防ぐ (例) 経営層への説明資料として使う、顧客に SLA として開示する ブレスト結果をまとめるための軸を定めておく 開発組織全体で共通課題として意識する → SLA までは一旦いかない 継続的な運用改善により顧客からのシステムへの信頼を維持する → 運用改善に繋がりそうな SLI 候補に絞っていくために役立った 12 設定した目的

シンプルフォーム株式会社 結果 SLIとして計測する指標が決定！ 13 委員会結成から 2ヶ月程度でなんとかここまでこれた....

シンプルフォーム株式会社 よかったこと 指標について考える中で現状の運用の課題が炙り出された あえて大勢の意見を集約する形を取ったことでより本質的な指標を定義できた 障害対応時にエンジニアが挙げる一次報告と CS がほしい情報に差分があるケースがあった ポストモーテムで「もっと早く検知できなかったのか？」という観点も重要！という意見が出てきた その結果、SLI/SLO とは別にインシデントレスポンスやポストモーテムの改善がスタートした 当初、守屋は API レイテンシやエラー率を計測することをイメージしていたが、 可用性だけではなくデータ精度やセキュリティなど重要度の高い指標が意見として上がってきた (例) 脆弱性のあるライブラリの混入率 ➢ SLI/SLO の検討プロセス自体が現状の運用について見直す契機となった ➢ 社内に公開した際により皆の納得感が得られる SLI を定義できた 14

シンプルフォーム株式会社 来年やりたいこと 現在は SLI モニタリングできるように計測や可視化(ダッシュボード)の仕組みを実装中 しばらく計測した実績値から SLO を順次定義していく予定 運用イメージ SLI/SLO をいい感じに運用する エンジニア定例でダッシュボードを確認し、異常がある場合は委員会から担当チームに対応を依頼 月一で委員会の定例 MTG を行い各指標のチューニングや改善施策を議論 エラーバジェット整備などは今後検討 15

シンプルフォーム株式会社 ご清聴ありがとうございました！ おわり 16