Slide 1

Slide 1 text

2024/07/31
 株式会社ビズリーチ
 神田 智史
 悩ましきSLO
 ~ HRMOSの場合 ~ 


Slide 2

Slide 2 text

1 神田 智史 KANDA Satoshi
 自己紹介
 経歴
 インフラエンジニア
 ↓
 セキュリティ/パフォーマンスQA 
 ↓
 SET
 ↓
 インフラエンジニア
 ↓
 シリーズ横断のSRE
 みてねヘビーユーザーです 
 このLTはここの話


Slide 3

Slide 3 text

「HRMOS」シリーズについて
 2 「HRMOS」シリーズは、人材のあらゆるデータ・業務が、なめらかにつながる仕組みを目 指しています。
 


Slide 4

Slide 4 text

3 プロダクト横断的なSLOを検討し策定した話
 


Slide 5

Slide 5 text

HRMOSのSRE が観測する指標の全体像
 プロダクトの
 信頼性
 開発組織の
 パフォーマンス
 開発組織のSRE ケイパビリティ
 システム モニタリ ング
 ポスト モーテム
 テスト
 SLI/SLO
 運用・トイ ル
 リリース プロセス
 インシデ ント管理
 オンコー ル
 セキュリ ティ
 稼働率
 速度
 リードタイム
 デプロイ頻度
 変更障害率
 障害復旧時間
 さらにここの話
 4

Slide 6

Slide 6 text

策定時の議論
 HRMOSシリーズ共通の信頼性基準(SLO)
 満足できる性能体験の定義
 性能体験を捉える指標の定義
 必要なときに、いつでも使える 
 (稼働率)
 Availability
 Request Success Rate
 ストレスなく、サクサク使える 
 (速度)
 LCP (Largest Contentful Paint)
 Latency 
 運用
 ● 毎月定期チェックを行い共有
 ● 半期毎にSREレポートとして、開発組織のパフォーマンス・ 開発組織のSREケイパビリティとともに部署・チームに展開
 5

Slide 7

Slide 7 text

6 SLO運用を始めてから起きた課題と改善
 


Slide 8

Slide 8 text

7 どこを改善したらいいのかわからない問題
 改善効果が見込まれるエンドポイントが何なのかが一見してわからない
 • リストアップしたエンドポイントを改善できた際の効果がすぐに分かる一覧を作成
 
 この3つのエンドポイントを改善すればリカバリ できます!的な運用が可能に
 


Slide 9

Slide 9 text

8 統一的なSLOでカバーできないものもある
 ユーザーが待ち時間を許容できるリクエストに対しても、一律の基準で計測している
 顧客満足度に則していない過剰な改善を求めることに繋がる懸念
 ↓
 ActivityWaitというSLOの導入
 
 • ユーザーがその画面のまま待つことが出来る適切なUI・UXの場合に設定できる
 • 例: ダッシュボード、検索、ファイルアップロード/ダウンロードなど。
 • UIでの対応を必須とする
 • [■■■■■■■■■■□□□] ローディングバー等
 策定時の議論

Slide 10

Slide 10 text

9 俺たちの戦いはこれからだ
 現在取り組んでいるもの
 • サービス間連携APIのSLO策定検討
 • 他サービスから呼び出されるAPIのSLO設定の是非
 
 • SLOのセグメンテーションの検討
 • 企業規模等のセグメンテーション
 • 適切な属性情報によるセグメント化
 
 • SLO悪化の事前検知手法をトライ
 • パフォーマンステストでのSLO確認
 • LatencyやLCPなど、SLOと同じ評価軸での測定
 


Slide 11

Slide 11 text

10 1. ユーザー体験を常に中心に
 2. SLOは継続的な改善が必要
 3. 具体的な改善指針が効果的
 まとめ
 悩ましきSLO
 
 悩み続けることがSLOなのかもしれない
 


Slide 12

Slide 12 text

No content