wwwave'sTechblog |ウェイブのエンジニアブログ

株式会社ウェイブのエンジニアによるテックブログです。会社の話や Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。

株式会社ウェイブの人事部ブログです。社内の雰囲気やイベント、福利厚生などについてお伝えいたします!

株式会社ウェイブのエンジニアブログです。 エンジニアの目線から会社の話や技術的な話をしていきます。

可視化して改善せよ(信頼性編)

SRE G マネージャーの井上です。

本記事ではDevOpsに関する当社の取り組みをご紹介致します。

当社ではDORAのレポートをもとに 開発速度と信頼性の可視化して継続的に改善できる環境・仕組みを構築しております。

前回は開発速度について記載致しました。

tech.wwwave.jp

今回は信頼性の関してのお話です。

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についても記載致します。

f:id:sys_wwwave:20210604154825j:plain
MTTRとMTTDの関係図

Mean Time To Repair (MTTR)?

サービスの復旧や修復にかかる平均時間(障害の平均時間とも言えます)です。

平均修復時間 - Wikipedia

DORAのレポートによるとハイパフォーマーのMTTRは小さい傾向にあることがわかっています。

Mean Time To Detection (MTTD) ?

Wikipediaにはページがなかったため、あまり一般的な用語ではなさそうです。 当社のプロダクト関係者が障害発生に気付いた(検知した)平均時間として定義しています。 アラート発火した時間ではありません。

DORAのレポートの重要指標に位置付けられておりませんが当社では重要指標として考えております。

ソース

障害発生時に作成されたポストモーテムをもとに手作業で集計して可視化しております。

(まだ自動集計する仕組みが導入できておりません。今後の課題です。)

ポストモーテムとは

GoogleのSRE本に登場するドキュメントです。

障害発生時にどのようなことが起きて、誰が、何を、いつしたのかなどがタイムライン上に記載されております。 とても大切なことは非難しないことです。

事実ベースで振り返りを行い建設的なアイディアによるディスカッションを行います。 サービスの信頼性を高めていく取り組みの中核に位置する非常に重要なドキュメントです。

  • 当社では、ポストモーテムを作成および振り返りをする文化が数年前から始まっております。ポストモーテムの振り返りから様々な改善施策が出ており、当社サービスの信頼性向上を支えております。

当社事例の紹介

当社には複数のサービス開発チームがありますが、今回はそのうちの1チームをメインに取り上げております。

前提条件

当社では、Gitlabを利用しております。そのためプルリク(PR)ではなくマジリク(MR)というワードを使用しております。

障害の内訳

  • 全体の約80%(UX+General Bug)がMRのデプロイによって起こった障害であることが分かります。

f:id:sys_wwwave:20210604171323p:plain
障害の内訳

軽微な障害が占める割合が多い

  • 影響度が大きいほど早く気付く傾向にあるようです。
  • 影響度が小さいほど発見が遅れる傾向にあるようです。

f:id:sys_wwwave:20210604171420p:plain
重大度ごとの障害時間

f:id:sys_wwwave:20210604171542p:plain
重大度ごとの障害件数

  • 重大度1が最大級です。
  • 重大度4が最軽微です。
  • 重大度4の1件あたりの平均障害時間が長い傾向にあることがわかる。

検知時間と障害時間の関係性

検知の難しさと復旧作業の難しさに相関関係は見られません。

f:id:sys_wwwave:20210604171721p:plain
検知時間と復旧作業時間の関係

f:id:sys_wwwave:20210604171803p:plain
検知時間と障害時間の関係

他チームの事例

前述はサンプリング数が少ないため、他のチームの情報も掲載致します。 類似した傾向にあることが分かります。

f:id:sys_wwwave:20210604171903p:plain
検知時間と復旧作業時間の関係

f:id:sys_wwwave:20210604171940p:plain
検知時間と障害時間の関係

時系列による変化

  • 直近になる程、障害の影響範囲が大きくなっていることが分かります。

f:id:sys_wwwave:20210604172137p:plain
復旧時間および影響度(バブルチャート)

図の◯が大きいほどユーザー影響が大きい障害です。

信頼性指標

期間 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からのご報告でした。

可視化して改善せよ(開発速度編)

SRE G マネージャーの井上です。

本記事ではDevOpsに関する当社の取り組みをご紹介致します。

当社ではDORAのレポートをもとに 開発速度と信頼性の可視化して継続的に改善できる環境・仕組みを構築しております。

今回は開発速度の関してのお話です。

DORAのレポート?

DORA社がDevOpsに関して科学的なアプローチで研究したレポートです。 優秀な組織とそうではない組織について、何が違うのか、どういった取り組みをしているのかが記載されております。

DORA metrics ?

以下の4つとされています。

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%

今回は上2つを扱います。 Velocity(開発速度)の指標となっております。

ソース(2019年レポート)

www.devops-research.com

留意事項

Scrumなどでよく出てくるVelocity (ストーリーポイント消化量)と同じワードですが、切り口が異なります。 本記事では、ScrumのVelocityの話は出てきません。

WHY / なぜやるのか

何のために可視化するのでしょうか。

サービス開発において、開発速度と信頼性は非常に重要な指標となっています。 それらはDevOpsにおいて注目されている指標です。

そういった情報が感覚値のままでは「開発速度は早いのか、遅いのか」わかりません。 分からないので、改善できたしてもより適切な評価は難しいと思います。

そこで先人の知恵を借りて可視化することで 開発チームが自律的に継続的に改善できることを期待しています。

HOW / どうやるのか

当社ではGitlab CEを利用した開発を行なっております。 CI/CD は gitlab-runner を利用しております。

そのため、開発速度を可視化するためのソースはGitlabから抽出しています。 SaaS版GitlabのUltimateではすでにDORA metricsが提供されておりますが、当社ではCE版のため自作致しました。

前提条件

当社の開発環境

  • Gitlab
  • CI/CD .. Gitlab runner

用語

  • Merge Request (MR)

定義

可視化するに当たって当社で定義した内容は下記の通りです。

deployments frequency

  • 1日あたりの本番環境への平均デプロイ回数

参照データ

  • Gitlabで管理されているdeployments(デプロイすると作成されるレコード)を利用

lead time for changes

  • MR がmaster branchにマージされてから、本番に反映されるまでの平均時間

f:id:sys_wwwave:20210604102316j:plain
lead-time-for-changes の計測範囲

参照データ

master branchにマージされた時刻
  • master branchにコミットが作成された時刻
本番に反映された時刻
  • Gitlabで管理されているdeploymentsのdeployが終わった時刻

アーキテクチャ

f:id:sys_wwwave:20210604120931j:plain
architecture

Result / 結果

当社ではサービス開発チームは複数ございます。 今回はその中の1チームをご紹介致します。

算出期間

計測開始 計測終了
2018/11/29 2021/05/20

Deployments frequency

項目 単位
データ数 2000+ count
平均本番反映回数/日(週5) 3.1 counts

計算を単純化するために祝日は含まず。1週間5営業日で計算しています。 (祝日は非営業日です)

Lead time for changes

項目 単位
平均 159 min(分)
中央値 97 min(分)
データ数 2000+ counts
MR本番反映数/日(週5) 3.6 counts

ヒストグラム

f:id:sys_wwwave:20210604102425p:plain
lead-time-for-changes ヒストグラム

分布

0-125(min) 0-250(min)
73.62% 93.98%

250分以内に94%程度のMRが本番反映されていることがわかりました。

時系列(Y軸対数)

f:id:sys_wwwave:20210604102455p:plain
lead-time-for-changes 時系列(Y軸対数)

時間の経過とともに安定してきていることが分かります。

開発チームの立ち位置

冒頭に記載したDORA metricsのElite Performers に属することが分かりました。 2019年のレポートによると、当社の開発チームは上位20%のEliteに属することがわかりました。

可視化してレポートの情報と比較することで開発速度がどのようなものか見えてきました。

最新状態が可視化されることで、ディスカッションしやすい状態になりました。 これまで数多の改善をしてきましたが、可視化したことで新たな改善項目が挙がっております。 私たちは現状に満足せずにさらなる開発速度向上を推進していきます。

最後に

私たちと一緒にスピード感のあるサービス開発をしませんか?

以上、SREからのご報告でした。

トップに戻る