SRE G マネージャーの井上です。
本記事ではDevOpsに関する当社の取り組みをご紹介致します。
当社ではDORAのレポートをもとに 開発速度と信頼性の可視化して継続的に改善できる環境・仕組みを構築しております。
前回は開発速度について記載致しました。
今回は信頼性の関してのお話です。
DORAのレポート？
DORA社が提供しているDevOpsを科学的なアプローチで調査した研究レポートです。
DORA metrics
| Aspect of software delivery Performance | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment frequency | On-demand(multiple deploys per day) | Between once per day and once per week | Between once per week and once per month | Between once per month and once every six month |
| Lead time for changes | Less than one day | Between one day and one week | Between one week and one month | Between one month and six month |
| Time to restore service | Less than one hour | Less than one day | Less than one day | Between one week and one month |
| Change failure rate | 0-15% | 0-15% | 0-15% | 46-60% |
詳細は以下をご参照ください。 www.devops-research.com
信頼性指標
DORA metricsにおいて信頼性指標は下記二つがございますが、本記事では[Time to restore service]について記載致します。
- Time to restore service
Change failure rate
Time to restore service
いわゆるMTTRです。
本記事ではMTTRをさらに掘り下げてMTTDについても記載致します。
Mean Time To Repair (MTTR)?
サービスの復旧や修復にかかる平均時間（障害の平均時間とも言えます)です。
DORAのレポートによるとハイパフォーマーのMTTRは小さい傾向にあることがわかっています。
Mean Time To Detection (MTTD) ?
Wikipediaにはページがなかったため、あまり一般的な用語ではなさそうです。 当社のプロダクト関係者が障害発生に気付いた（検知した）平均時間として定義しています。 アラート発火した時間ではありません。
DORAのレポートの重要指標に位置付けられておりませんが当社では重要指標として考えております。
ソース
障害発生時に作成されたポストモーテムをもとに手作業で集計して可視化しております。
(まだ自動集計する仕組みが導入できておりません。今後の課題です。)
ポストモーテムとは
GoogleのSRE本に登場するドキュメントです。
障害発生時にどのようなことが起きて、誰が、何を、いつしたのかなどがタイムライン上に記載されております。 とても大切なことは非難しないことです。
事実ベースで振り返りを行い建設的なアイディアによるディスカッションを行います。 サービスの信頼性を高めていく取り組みの中核に位置する非常に重要なドキュメントです。
- 当社では、ポストモーテムを作成および振り返りをする文化が数年前から始まっております。ポストモーテムの振り返りから様々な改善施策が出ており、当社サービスの信頼性向上を支えております。
当社事例の紹介
当社には複数のサービス開発チームがありますが、今回はそのうちの１チームをメインに取り上げております。
前提条件
当社では、Gitlabを利用しております。そのためプルリク(PR)ではなくマジリク(MR)というワードを使用しております。
障害の内訳
- 全体の約80%(UX+General Bug)がMRのデプロイによって起こった障害であることが分かります。
軽微な障害が占める割合が多い
- 影響度が大きいほど早く気付く傾向にあるようです。
- 影響度が小さいほど発見が遅れる傾向にあるようです。
- 重大度１が最大級です。
- 重大度４が最軽微です。
- 重大度４の１件あたりの平均障害時間が長い傾向にあることがわかる。
検知時間と障害時間の関係性
検知の難しさと復旧作業の難しさに相関関係は見られません。
他チームの事例
前述はサンプリング数が少ないため、他のチームの情報も掲載致します。 類似した傾向にあることが分かります。
時系列による変化
- 直近になる程、障害の影響範囲が大きくなっていることが分かります。
図の◯が大きいほどユーザー影響が大きい障害です。
信頼性指標
| 期間 | MTTR | MTTD | MTTD/MTTR |
|---|---|---|---|
(全期間)2019/12/1 - 2021/04/16 |
20 hrs | 15 hrs | 76% |
(全期間) 同上 (外れ値除外) |
9hrs | 5hrs | 53% |
(2020年)2020/1/1 - 2020/12/31 |
21.25 hrs | 14.5 hrs | 69% |
(2020年) 同上(外れ値除外) |
5.25 hrs | 1.25 hrs | 25% |
(2021年)2021/1/1 - 2021/04/16 |
21 hrs | 10.5 hrs |
51% |
MTTD/MTTDは 平均検知時間/平均障害時間です。 つまり、障害時間全体のうち検知に要した時間の割合を指しています。
最も大きな数値を除外すると、大幅に各指標が改善することが分かりました。（一部の障害が信頼性指標を引き下げています)
わかったこと
可視化された情報 (MTTD/MTTRの数値)から、検知に要する時間を短縮することで大きく信頼性を向上できると期待しております。 そのため、現時点では検知に注目した改善活動を進めております。
例として大量のアラートが常時出続けている状況の中で、本当に重要なアラートが発火していることに気付くことは至難です。そういった状況を少しでも改善していくことでMTTDが改善され、MTTRも改善されます。同時にオンコール担当のエンジニアにとってもよりストレスが少ない環境を構築できるのではないかと考えております。
サービス・レベル・目標(SLO)の設定
MTTR, MTTDに対して、サービス・レベル・目標(SLO)を設定致しました。 SLOは死守する設定値ではなく努力目標という意味合いで設定しております。
基準値を設けたことでより現実的なアクションを導き出せるようになったのではと感じております。
アクション
開発チーム内にてディスカッションを行い、様々な改善策が出ました。 障害検知に関する改善活動を進めており現在運用段階に入っております。
数ヶ月運用しての気づき
ポストモーテムの振り返りの際に障害時のMTTR, MTTDについて意識が変わっていることに気づきました。
これまではSLOがなかったため基準がありませんでした。 常に短縮することばかりに注目していたように思います。
SLOが設定されたことで、SLO達成の有無を判断できます。 基準を満たしていれば短縮改善は不要という判断になります。
そうした状況の中で障害対応方法の課題についてより目がいくようになり、より健全な運用になってきたと感じております。
最後に
私たちは、開発チームとSREが対立するような構造にはなく 協業しながら開発速度と信頼性を同時に高めるため ともに日々努力しております。
当社では、ともに働く仲間を随時募集しております。 ともに良いプロダクトをつくりませんか？
以上、SREからのご報告でした。
