🦄

平均修復時間・変更障害率を可視化のメリットと改善のためのアクションーFour Keys運用

2023/05/09に公開

DevOps

開発生産性

fourkeys

エンジニアリングマネジメント

idea

Four Keysの個別指標ごとの基本的な解説記事を書いていきます。

今回は、変更障害率と平均修復時間を見る意味と指標の改善アクションをなぜ・どのようなことをやるのかについてご紹介します。

PR：Offers MGRはFour Keysの可視化機能があります

Offers MGRではFour Keysの可視化機能があり、

月次でのFour Keysのチーム・組織別の振り返りへの活用
半期ごとの技術戦略、組織戦略への活用

などの場面で、様々な企業で活用されております。

開発生産性を高める上で、まず現状・課題の把握を行い、チームごとでの改善への取り組みのマネジメントを行い、全体を引き上げていくツールとしてぜひお使いください。

Offers MGR プロダクト開発組織のパフォーマンス最大化

https://offers-mgr.com/lp/

変更障害率と平均修復時間を可視化、改善する意味

変更障害率 (Change Failure Rate)

変更障害率の改善に向けたアクションの簡易構造

変更障害率は、新しいリリースや変更が本番環境で問題を引き起こす割合を示す指標です。これは、開発チームがどれだけ安全かつ効果的に新しい変更を本番環境にデプロイできているかを評価するのに役立ちます。

変更障害率が低いほど、開発チームの品質管理が効果的であり、リリースされる製品や機能が安定していることを意味します。

変更障害率を見る理由

品質管理の効果性を評価する
1. 変更障害率が低いほど、プロダクト・ソフトウェアの品質管理がうまく機能していることを示します。
リスク管理の改善
1. 変更障害率を測定し、分析することで、リスクを特定し、対策を講じることができます。
チームのパフォーマンスを向上させる
1. 変更障害率を改善することで、開発プロセス全体がより効率的になり、チームのパフォーマンスが向上します。

平均修復時間 (Mean Time to Restore, MTTR)

平均修復時間の改善に向けたアクションの簡易構造

平均修復時間は、システムやアプリケーションの障害が発生した際に、問題を解決し正常な状態に戻すまでの平均時間を示す指標です。MTTRが短いほど、チームが迅速かつ効果的に問題を解決できていることを意味します。

平均修復時間を見る理由

問題解決の効率・問題解決力を評価
1. MTTRが短いほど、チームが迅速に問題を特定し、解決できる能力が高い
サービスの信頼性向上
1. MTTRを短縮することで、システムのダウンタイムが減少し、サービスの信頼性が向上する
顧客満足度の向上
1. 顧客がシステムやサービスの障害による影響を最小限に抑えることができ、顧客満足度が向上する
チームのスキルと経験の評価
1. チームの技術力や経験、問題解決能力を評価できる。また、改善の余地がある場合は、研修やスキルアップの機会を提供できる

変更障害率と平均修復時間の指標を評価することで、開発チームの品質管理や問題解決能力を把握し、改善を行うことができます。結果、開発プロセスがより効率的かつ安定的になり、組織全体のパフォーマンス向上につながります。

いつから取り組むべきか

結論として、変更障害率や平均修復時間の改善アクションは、プロダクトや組織のフェーズに応じて、適切なタイミングで実施することが重要です。

単にデプロイ頻度や変更のリードタイムだけを追い続けて不具合を引き起こすようなプロダクトにするのではなく、プロダクトや組織の成長に合わせて、改善アクションを計画的に取り入れ、実施していくことで、効果的な品質管理を行っていきましょう。

プロダクトのフェーズ

初期開発フェーズ
- 基本的な機能やアーキテクチャがまだ構築されていないため、変更障害率や平均修復時間の改善アクションを実施するのは早いかもしれません。
- しかし、品質管理やテスト戦略の策定を行い、初期段階から問題が発生しにくい環境を作ることが重要です。
成熟フェーズ
- プロダクトが安定し、顧客基盤が拡大している段階では、変更障害率や平均修復時間の改善アクションを実施することで、顧客満足度を維持・向上させることができます。定期的なレビューや改善アクションを計画し、実施することが重要です。
維持・サポートフェーズ
- プロダクトが成熟し、新機能の追加が少なくなった段階でも、変更障害率や平均修復時間の改善アクションは重要です。
- このフェーズでは、顧客からのフィードバックやサポートリクエストを分析し、問題解決能力を向上させることが求められます。

組織のフェーズ

新規組織やスタートアップ
- 新しい組織やスタートアップでは、まずは開発プロセスや品質管理の基本を築くことが重要です。その上で、徐々に変更障害率や平均修復時間の改善アクションを取り入れることで、組織全体の品質意識を高めます。
成長期の組織
- 組織が成長し、プロダクトやチームが拡大していく段階では、変更障害率や平均修復時間の改善アクションが重要になります。
- 定期的なレビューやベストプラクティスの共有を通じて、チーム間の知識や技術力を向上させ、効果的な改善アクションを実施していくことが求められます。
大規模組織やエンタープライズ
- 大規模な組織やエンタープライズでは、変更障害率や平均修復時間の改善アクションは、組織全体の効率や生産性を維持・向上させるために欠かせません。
- 組織全体での品質管理やプロセスの標準化、継続的な改善文化を確立することで、変更障害率や平均修復時間の改善が可能になります。

続いて、これらの具体的なアクション・改善方法についてです。

変更障害率と平均修復時間の改善方法

FourKeysの変更障害率（Change Failure Rate）と平均修復時間（Mean Time to Recovery, MTTR）を改善するためには、以下のアクションが必要です。

デプロイプロセスの自動化

なぜ必要か
1. 手動のデプロイプロセスでは、エラーやミスが発生しやすくなります。自動化することで、一貫性が保たれ、変更障害率が低下します。
どう改善するか
1. CI/CDツール（継続的インテグレーション・継続的デリバリー）を導入し、デプロイプロセスを自動化します。

コードの品質管理

なぜ必要か
1. 高品質なコードは、変更障害率を低下させ、問題発生時の修復時間を短縮します。
どう改善するか
1. コードレビューを徹底し、静的コード解析ツールを使用して品質を向上させます。
2. また、コーディング規約やガイドラインを定め、チーム全体で共有します。

弊社のケース
RubocopとCodeClimateによって自動チェックが行われており、特に社内用のコーディングルールはありません。

以下のStyleGuideによる自動チェック
https://github.com/fortissimo1997/ruby-style-guide/blob/japanese/README.ja.md

CodeClimateのCognitiveComplexityという認知複雑度計算による品質チェックが自動的に行われているような形です。
https://docs.codeclimate.com/docs/cognitive-complexity

テストの強化

なぜ必要か
1. テストが十分に行われていると、障害の早期発見が可能になり、変更障害率の低下とMTTRの短縮が期待できます。
どう改善するか
1. テストカバレッジを向上させ、単体テスト（ユニットテスト）、統合テスト（インテグレーションテスト）、システムテスト（システムインテグレーションテスト）などの各レベルでのテストを徹底します。
2. プロダクトの初期フェーズは、基本機能が実装されるので単体テスト・統合テストから強化し、事業やプロダクト成長・開発組織が拡大時に、システム全体の安全性を高めるためシステムインテグレーションテストも含めて強化していきます。
3. そのほかは、自動テストを実施し、リリース前の検証を強化します。

モニタリングとアラートの強化

なぜ必要か
1. 適切なモニタリングとアラートがあると、障害発生時に迅速に対応でき、MTTRを短縮できます。
どう改善するか
1. モニタリングツールを導入し、システムのパフォーマンスやエラー状況をリアルタイムで監視します。また、アラート設定を適切に行い、障害発生時に関係者に通知が行くようにします。

障害対応プロセスの見直し

なぜ必要か
1. 迅速かつ効果的な障害対応プロセスが整備されていると、MTTRの短縮が期待できます。
どう改善するか
1. 障害対応のプロセスを定め、関係者に周知徹底させます。また、定期的にリハーサルを行い、障害発生時の対応力を向上させます。

ポストモーテム分析の実施

なぜ必要か
1. ポストモーテム分析により、障害の原因を特定し、再発防止策を立てる
2. これにより、変更障害率とMTTRが改善されます。
どう改善するか
1. 障害が発生した場合、原因を特定し、再発防止策を策定
2. 分析結果を共有し、組織全体で学習・改善を進めます。

開発と運用の連携強化

なぜ必要か
1. 開発と運用の連携が強化されると、より迅速な障害対応が可能になり、MTTRが短縮されます。
どう改善するか
1. DevOps文化を推進し、開発チームと運用チームのコミュニケーションを促進します。また、両チームの協力体制を構築し、問題発生時に迅速に対応できるようにします。

スキルアップと教育

なぜ必要か
1. スキルの向上と教育により、チーム全体の問題解決能力が向上し、変更障害率の低下とMTTRの短縮が期待できます。
どう改善するか
1. 社内勉強会や外部研修を積極的に実施し、エンジニアの技術力向上を図ります。また、新しい技術やツールを活用し、チーム全体の生産性向上を目指します。

バックアップとロールバック戦略の見直し

なぜ必要か
1. 適切なバックアップとロールバック戦略があると、障害発生時に迅速に元の状態に戻すことができ、MTTRが短縮されます。
どう改善するか
1. 定期的にバックアップを実施し、ロールバックプロセスを見直します。また、ロールバックの自動化を検討し、障害発生時の対応速度を向上させます。

リスク管理と事前対策

なぜ必要か
1. 事前にリスクを特定し、対策を立てることで、変更障害率の低下とMTTRの短縮が期待できます。
どう改善するか
1. リスク管理プロセスを導入し、変更時に潜在的な問題を特定し、対策を実施します。また、リスクを最小限に抑えるためのアーキテクチャや設計を検討します。

最後に

Four Keysでプロダクト開発組織の現状を可視化した後に、チームごとや全社での技術戦略・施策を定義して改善を進めていくことが大切です。

改善の優先度を設定、評価項目に入れて強制力を高めるなどしてチームの改善に役立てていただければと思います。

Four Keysをまずは可視化して、コミュニケーションデータなどを見ながら個々人の業務改善・プロダクトチームの強化を図っていきたいという方はぜひOffers MGRをご利用ください。