mofmofのtechブログへ投稿した記事です。

mofmofでは最近、「LeanとDevOpsの科学」という本の輪読会を行い、DevOpsを実践する活動を始めました。

自社プロダクトへの導入の際に考えるべきことを4つ紹介します。

1. 導入の目的と期待する効果を明確にする

DevOpsはプラクティスは、変化の大きな市場環境において、組織のケイパビリティを高める事により、競争力や組織全体のパフォーマンスを向上することを目的としています。

一見どんな事業・プロダクトにも共通して使えそうにも思えますが、実際には、プロダクトを成長させるという目的にフォーカスしていると言えそうです。

特に難しいのが、後期段階や終了段階にあるプロダクトです。 どんどんデリバリをして行くというのではなく、ある程度保守フェーズに入っていたり、クローズに向かっているプロダクトなどでは、デプロイ頻度計測の重要性が下がってきます。

こういったプロダクトではデプロイ頻度を高めることが本当に重要なのか、変更失敗率を下げることを重視すべきか。細かな項目の優先度を考えて導入していく必要があります。

そのようなプロダクトが組織のパフォーマンスに与える影響を図る材料となったりといったことも考えられます。ただ、いずれにしてもDevOpsのプラクティスはすぐに結果が出るものではなく、長い目で改善していくものだということもおさえておく必要があります。

今回の目的は、こちらの記事にも書いたのですが、組織のパフォーマンス改善の指標として使えるのではないか。それを検証したいという、少し特殊な目的でした。 導入を検討する前にプロジェクトのオーナーや開発者に、現状の課題感や大枠のデプロイ頻度や障害頻度、ロードマップなどをヒアリングしました。

2. 計測指標を定義する

LeanとDevOpsの科学は以下の項目「Four Keys + 1項目」を計測しろと言っています。

• コードのデプロイ頻度

• コミットからデプロイまでのリードタイム

• 障害の平均復旧時間

• デプロイの変更失敗率

• 信頼性

これらを実際に取得する際に考えたことを記録として残します。

今回導入して検証しているプロダクトは後期段階のプロダクトで、新規機能開発は活発ではありません。とは言え利用しているパッケージや依存する外部サービスやライブラリのアップデートが多数あり、それらを安定的に反映していくためにリソースが常に確保されています。

こういった事情もあり、

deploys / a day / a developer (1日あたりのデプロイ数を開発者数で割った数) での計測を行います。 リソースが常に確保されているとは言え一定ではないため、稼働時間やリソース状況を考慮した数字が重要と考え、こちらを計測していくことにしました

開始前段階では、この数値が 0.06 くらいでしたので、0.1 に改善することを目標とします。

それぞれの指標についてどこを計測するかを定義する

• デプロイ頻度

  • mainのブランチへマージされたタイミングでGitHub deploymentを作成。それをデプロイとして計測する

• リードタイム

  • 初回commitからmainブランチへのマージまでの時間を計測

• 平均修復時間

  • PivotalTrackerのバグチケットがStartされてから、Acceptされるまでの時間を計測

• 変更失敗率

  • PivotalTrackerのバグチケットがAcceptされた数を計測

まずはGoogleのfour keysをそのまま使いつつ、今の組織に合うかどうか一つ一つ項目を見ていきました。

https://github.com/dora-team/fourkeys

3. Quickチェックを行い、最初に手を付けるべきところを決める。迷わずとにかく手を動かす

現状のヒアリングや分析から計測すべき項目を定義し終わったので、実際に指標を改善していく活動をしていきます。

ただ、効果がどのくらいのスパンで現れるかもわからず、どの対応がどの程度のインパクトを与えるのかもわかりません。どこから手を付けるか迷いました。

以下のGoogleのクイックチェックで、現状のパフォーマンスを可視化できます。 その後、追加のアンケートに答えると最初に手を付けるべき大項目を提示してくれます。

https://www.devops-research.com/quickcheck.html

まずはここで提示されたCIの改善に注力していきました。

具体的には

• CI周りの課題感を洗い出す

  • ヒアリング

  • カバレッジの確認

  • 静的解析ツールの自動実行

  • CIジョブのパフォーマンス改善

  • テストの追加

  • パフォーマンス課題になりそうな箇所の検知ロジックをCIで自動化

などを行っています。

4. 啓蒙する

DevOpsの活動はメンバー全員で行うことが必要です。

DevOpsとはなんぞやということで、まずは社内でLeanとDevOpsの科学の輪読会を開催しています。

その他にも、透明性を上げたり、権限を与えたりということがいい影響を与えるということで、 ツール選択の自由度を確保する ために、GitHub Actionsがプライベートリポジトリで使えないプランを利用していたので、アップグレードして使えるようにするなど細かな活動を続けていくことが重要そうです。

最後に

まずは導入までを行ってみた記録となります。引き続き活動していきます。