search
LoginSignup
1

More than 1 year has passed since last update.

posted at

updated at

Organization

Accelerate State of DevOps report を読む

この記事は カオナビ Advent Calendar 2021 10日目です。

株式会社カオナビのプロダクト本部SRE部オペレーショングループに所属している、棚橋です。
オペレーショングループでは本番デプロイ作業や日々発生する運用業務の自動化や効率化を行っています。

Accelerate State of DevOps とは

毎年世界中から、ソフトウェア・デリバリーやオペレーションや組織のパフォーマンスのデータを集めて統計的手法を用いて分析し、まとめたレポートです。

私は『LeanとDevOpsの科学』でその存在を知りました。

この中で今回は4つのキーメトリクスをベースにした、Software Delivery and Operation(以下SDO)とドキュメントの品質のページに注目しました。

4つのキーメトリクス

2つずつそれぞれThroughput(処理速度)Stability(安定性)の指標に分けられています。

レポートのP.9より抜粋
スクリーンショット 2021-12-09 5.50.52.png

Throughput

デプロイ頻度

1日あたりの本番デプロイ回数(デプロイの他に本番環境のリソースや設定変更なども含む)が指標になります。
このレポートだと最大1460回/年=1日4回もデプロイしている企業がいるとのことで、この回数はさすがに多くて驚きました...(グローバルな企業とかだと十分にありえそうですがさすがに働きすぎなのでは...)

カオナビの場合は、現在1日複数回の本番デプロイを安定的に行っていますが、土日やその前の金曜日は本番にデプロイしない運用にしています。さらにそこに祝祭日もあるので、実際のところ500回〜600回が目標になれば良いのではないかな、と思っています(それに向けて鋭意改善模索中)。

リードタイム

コードをコミットしてから本番へのリリースにどれくらい時間がかかるかが指標になります。

リードタイムが1時間未満であればハイパフォーマーということですが、カオナビでは安定して1時間未満というところまではまだできておらず、デプロイプロセスや仕組みを改善して安定的に1時間未満でデプロイできるようにはしていきたいと思っています。

Stability

MTTR(平均修復時間)

問題が発生してからサービス復旧までの時間を指標にしていて、こちらもリードタイムと同じように1時間未満であればハイパフォーマーに分類されます。

問題が発生してからサービス復旧までの定義が気になるところで、たとえば障害発生後に即座に変更を戻すことで事象解消=サービス復旧というパターンもありえるかと思います(根本的な障害原因の対応はこの後別にやる想定)。

カオナビでは障害の一部のパターンについてはリードタイムを計測していますが、全てのパターンで実績が取れているわけではないため、何かしら指標を定義してもう少し広義でのMTTRを計測してみたいと思っています。

変更失敗率

本番環境へのデプロイや変更の内、サービス障害やサービス停止などにつながったリリースがどれくらいあるかの指標となっています。

変更失敗率 = 変更失敗回数 / 本番デプロイ回数

変更失敗0を目指すのは素晴らしいことですが、0を維持し続けるのはとても大変です。
そのため本番デプロイ回数を増やし、変更失敗率の変動をできるかぎり小さくすることが望ましいと認識しています。

前述どおりカオナビでは1日あたり複数回リリースをしていることで、比較的に変更失敗率は低くなる傾向にあります。実際の変更失敗率は5%前後を維持していて、最終的な目標としては2%を目指しています。

これら4つのキーメトリクスの数字は、実際にまとめて社内で共有できたら良いなと思っています(ここで言っておけばやるだろうという追い込み)。

ドキュメントの品質

もう一つ気になったところとして、2021年から内部資料の品質にも注目しているようで、マニュアルやREADME、コードコメントなど開発や運用に関わるドキュメント全般を対象に調査を行ったようです。

レポートには以下の観点でドキュメントの品質を評価した頁がありました。質の高いドキュメントを作成しているチームはSDOのパフォーマンスが高いそうです。

  • 読者の目的達成に役立つ
  • 正確で、最新で、包括的である
  • 見つけやすく、整理されていて、明確である

ちょっと抽象的で「そんなことはわかっとる」という感じではありますが、ドキュメントの品質については『情報アーキテクチャ』や『SREの探求』の第19章がテーマになっているので、読んでみると良いかもしれないです。

また高いドキュメントの品質を保つためのプラクティスとしては以下のようなものがあげられていました。

  • オーナーを決める
  • ユースケースをドキュメントにする
  • 既存のドキュメントを更新・編集するためのガイドラインを作成する
  • 不正確な情報や古い情報の削除するガイドラインを作成する

レポート内にも記載ありますが、専門的な知識や指針・方針をチーム間や全体で共有するためには、ドキュメントが重要な役割を持っているはずです。
メンテナンスがとてもめんどくさいですが、レポートに記載されているプラクティス、特に更新や削除のためのガイドラインは実践してみる価値がありそうだなと思いました(「作成」のガイドラインはあっても、「更新」や「削除」のガイドラインが意外とない)。

終わりに

2021年ならではの内容として、COVID-19によるパフォーマンスの影響などの調査もありました。他にも5つ目の指標として、運用パフォーマンスへの言及があったりカルチャーに関する調査など、まだまだ読み足りていません。

このレポートにあるようなエリートなハイパフォーマーになれるように日々改善をしていきたいと思います。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
1