mofmofのメンバーに向けてDevOps活動を浸透させるために、DevOpsで解決したい課題や計測方法などを書き出してみます。
課題
mofmofでの導入の背景・ニーズについて。
mofmofはアジャイル開発を得意としており、開発と運用の連携を目指す体制の下地はある。
ただ、以前から質とスピードがトレードオフになる状態があった。
具体的には、言語やフレームワークのバージョンアップが溜まりがちだったり、開発が進むと開発時に考慮すべき項目が増えたり、影響範囲が広がり開発が遅くなるような課題である。
リファクタリングを週に一定時間設けるなどをしたが、そういった開発環境の改善活動がもたらす効果が見えづらいという課題もあった。
また、受託開発の会社として、複数の案件をそれぞれの開発者が担当しているが、案件ごとに知見が閉じてしまう問題もあった。
そこで、品質やリファクタリングを捨てない方法としてDevOpsに目をつけた。
DevOps
開発（Development）と運用（Operations）が連携して協力する開発手法。 目的は、製品の品質向上とリリースサイクルの高速化を実現すること。
アジャイルやリーンで、確実に品質の高いリリースを行うことを目指す。
「LeanとDevOpsの科学」という書籍では、品質が高いほど開発速度も上がるということが、統計的に示されている。
DevOpsをどう活用するか
DevOpsの実行は以下のようになっている。
- DevOpsの導入に向けた組織的な意志決定と戦略策定
- チーム間のコミュニケーションと協働の促進
- 開発と運用のプロセスの統合と自動化
- 継続的なインテグレーションとデリバリーの導入
- モニタリングとフィードバックループの確立
mofmofでは、2については、基本的に下地ができている。メンバーにアジャイル理解があり、必要な改善を行っているはずだ。
3, 4についても基本的に必要なものは導入しているはずであるが、自動化の余地はまだまだあるかもしれない。
mofmofではまず5、そして1という順で注力していくことにした。
モニタリングによって現状を把握し、目標を立てて改善の戦略を立てていく。
現状を把握する①
Take the DORA DevOps Quick Check
いくつかの質問に答えるとDevOpsについての現状把握ができるページ。DevOps研究組織であるDORAが出している。 まずはこのページで現状を確認する。
他の業界や組織とも比較できると記述があり、結果をmofmof内で保持することでチーム間での比較にも使える。
現状を把握する②
またもDORAが出しているFour KeysというDevOpsの開発パフォーマンスを可視化するツールで可視化する。
計測する指標とパフォーマンス
| 指標 | Highパフォーマンス | Middleパフォーマンス | Lowパフォーマンス |
|---|---|---|---|
| デプロイ頻度 | 1日に1回以上のデプロイを週3日以上（稼働が50%の場合は1.5日/週） | 週に1回以上デプロイする週が月の過半数 | 週に1回未満のデプロイ |
| 変更失敗率 | 0~15% | 16%~45% | 45%より高い |
| リードタイム（直近3ヶ月の中央値） | 24時間以内 | 168時間以内 | 168時間より多い |
| サービス復旧時間（直近3ヶ月の中央値） | 24時間以内 | 168時間以内 | 168時間より長い |
それぞれみていく。
デプロイ頻度
コアとなる指標。デプロイが頻繁に行えるということは、小規模な変更を頻繁にリリースできる状態であり、結果的に品質も向上する。
mofmofにおける計測方法
以下のいずれかをデプロイとして計測する。
パフォーマンスの目安（直近の3ヶ月の情報で計測する）
| パフォーマンス | |
|---|---|
| High | 1日に1回以上のデプロイを週3日以上（稼働が50%の場合は1.5日/週） |
| Middle | 週に1回以上デプロイする週が月の過半数 |
| Low | 週に1回未満のデプロイ |
変更失敗率
デプロイ頻度を改善する際に、品質を落とさずに改善するために見る指標。 雑なリリースが増えては本末転倒なので、変更失敗率を上げずにデプロイ頻度を高めることを目指す。
mofmofにおける計測方法
PivotalTrackerに障害の原因Commitを記載する。 記載されたCommitを含むデプロイを失敗とみなす。
パフォーマンスの目安（直近の3ヶ月の情報で計測する）
| パフォーマンス | |
|---|---|
| High | 失敗率が0~15% |
| Middle | 失敗率が16%~45% |
| Low | 45%より高い失敗率 |
リードタイム
開発開始からリリースまでにかかる時間。 mofmofではステージング環境までのリードタイムも計測。 ボトルネックが開発にあるのか、運用との連携にあるのかを明らかにして改善に繋げたい。
mofmofにおける計測方法
前回のDeployment以降の最初のCommitから、Deploymentが作成されるまでの時間をリードタイムとして計測。
パフォーマンスの目安（直近の3ヶ月の情報で計測する）
| パフォーマンス | |
|---|---|
| High | 直近3ヶ月の中央値が24時間以内 |
| Middle | 直近3ヶ月の中央値が168時間以内 |
| Low | 直近3ヶ月の中央値が168時間より多い |
サービス復旧時間
信頼性を測る指標として測定する。サービスがダウンした際に
- ダウンしたことに気づける
- どこが原因なのか突き止めやすい
- 誰でも復旧できる
- 改善に繋げられる
といった要素によって向上する。
mofmofにおける計測方法
PivotalTrackerのバグストーリーが開始してからAcceptされるまでの時間を計測対象とする。
パフォーマンスの目安（直近の3ヶ月の情報で計測する）
| パフォーマンス | |
|---|---|
| High | 直近3ヶ月の中央値が24時間以内 |
| Middle | 直近3ヶ月の中央値が168時間以内 |
| Low | 直近3ヶ月の中央値が168時間より長い |
改善戦略
案件、チーム横断で改善を行う部隊を別途作りました。 DevOpsの導入や指標測定の設定、目標や改善策の提案を主導します。
事例や知見の共有を促し、同じ条件でのモニタリングを見比べ、それぞれの状況を俯瞰しつつ知見をためます。
プロジェクト関係者全員で、改善できる体制を作りたい。
