Four keysが組織に馴染むか試したい時にどうするべきか

2023年7月1日 10:56

こんにちは、kubopです。
Four keysについて色々と考えていて、どうしたら簡単にとれるようになるか考えていました。
最初は手運用となると思いますが、まず始めるならこんな感じかなーと想像して書いてます。

デプロイ頻度

組織による正常な本番環境へのリリースの頻度

現在デプロイをgithub actionsや、CircleCI、Zapierなど自動化している場合に限りですが、デプロイ毎にスプレッドシートに書き込みます。
GASの知識が必要ですが、やるならばgithub actionsでmaster(main) branchにMergeされた時点か、或いはdeployコマンドを打たれたjenkinsをトリガーにして書き込みをします。

変更のリードタイム

commit から本番環境稼働までの所要時間

github actionsを使ってベースブランチにmergeされた瞬間と、first commitの時間の差分を出してどの程度の時間でMergeされたかを計測します。
こちらもGASを使ってスプレッドシートに書き込むと良いと思います。

name: Comment Merge Time
on:
  pull_request:
    branches:
      - main # baseブランチの指定
    types: [closed]

jobs:
  lead-time:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    steps:
      - name: checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: calc time
        run: |
          gh api graphql -f id="${{ github.event.pull_request.node_id }}" -f query='
            query ($id: ID!) {
              node(id: $id) {
                ... on PullRequest {
                  mergedAt
                  commits(first: 1) {
                    nodes {
                      commit {
                        authoredDate
                      }
                    }
                  }
                }
              }
            }
          ' |
          jq -r '.data.node | .mergedAt, .commits.nodes[0].commit.authoredDate | fromdate | strftime("%s")' |
          xargs -n 2 |
          awk '{printf "%d", ($1 - $2) / 60 }'|
          xargs -I{} echo LEAD_TIME_HOUR={} >> $GITHUB_ENV
      - name: comment
        run: |
          gh pr comment ${{ github.event.pull_request.html_url }} \
          -b "@${{ github.event.pull_request.user.login }} $(expr ${LEAD_TIME_HOUR} / 60 / 24)日 $(expr ${LEAD_TIME_HOUR} / 60)時間 ${LEAD_TIME_HOUR}分"

サービス復元時間

組織が本番環境での障害から回復するのにかかる時間

障害時には必ず、障害発生chをslackで作成します。
障害発生chが作成された時間〜復旧した時間を計測します。（最初は手運用になるかなと思います。）
インシデントコンダクタが時間を測るといった運用にすれば良いかなと思っています。

インシデントフローを明確に定義し、運用することで一定可能かなと思います。

また、この場合は外れ値が想定されます。例えばインシデント発生から、データ復元時間(バッチを作って過去データを復旧するなどの時間)などに何日もかかってしまう場合。
この場合は、「サービスが正常に運用できるようになった時間」を計測するようにすると外れ値がなくなるかなと思います。

変更障害率

デプロイが原因で本番環境で障害が発生する割合（%）

ここまでくると簡単で、単純に障害が発生した回数と、リードタイムで活用したPRの数を計算してあげれば算出できるかなと思います。

まとめ

本格的にFour keysを測る、といった前に効果測定してFour keysが十分に利用可能かどうかを調べるためにササっとできることをまとめてみました。
私がもしやるならこのあたりから手運用して3ヶ月程度コストをかけて、Four keysが組織にあっているかどうかまずはトライしてみるかなと思います。

スプレッドシートにとりあえず保存しておき、Data Studioで可視化してダッシュボード化する、というのも私はまずやると思います。

この記事が気に入ったらサポートをしてみませんか？