デプロイ・QA・Four keys を自動化×見える化する freee の統合デリバリー基盤 2024.06.15

01　自己紹介 & freee とは
 02　SRE Platform Delivery と統合デリバリー基盤
 03　デプロイフローの標準化
 04　Four Keys と Staging確認の計測・可視化
 05　統合デリバリー基盤のまとめ
 06　Four Keys への向き合い方
 07　課題とこれから
 目次


　 01. 自己紹介とfreeeとは


　 4 ● profile ○ 出⾝: 広島県広島市 ● work ○ 2022.04 : freee に新卒⼊社 ○ 2022.06 : SRE Platform Delivery に配属 ○ 2024.07: ⾦融のプロダクト開発チームに異動 ● trend ○  スプラトゥーン3 ○ バスケ 藤原 彰人 freee株式会社 / SRE Platform Delivery Fujihara Akito プロフィール画像の トリミング⽅法

　 freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、 統合型経営プラットフォームを開発‧提供し、 だれもが⾃由に⾃然体で経営できる環境をつくっていきます。 起業やビジネスを育てていくことを、もっと魅⼒的で気軽な⾏為に。 個⼈事業や中⼩企業などのスモールビジネスに携わるすべての⼈が、 じぶんらしく⾃信をもって経営できるように。 ⼤胆にスピード感をもってアイデアを具現化できるスモールビジネスは、 今までにない多様な価値観や⽣き⽅、 新しいイノベーションを⽣み出す起爆剤だと私たちは考えています。 スモールビジネスが⼤企業を刺激し、社会をさらにオモシロク、 世の中全体をより良くする流れを後押ししていきます。 Mission スモールビジネスを、世界の主役に。

　 電子稟議
 経費精算
 債権債務
 管理
 人事労務
 電子契約
 固定資産
 請求管理
 会計
 工数管理
 販売管理 会計‧⼈事労務‧販売管理を核とした統合型経営プラットフォーム

　 02. SRE Platform Delivery と 統合デリバリー基盤


8 Platform DBRE サービスの安定稼働をDBを始めとしたミドルウェアの使いこなしから⽀えるチーム 最近の担当テーマ: データストアミドルウェアの使いこなし‧標準化、運⽤⾃動化 SRE 開発者の⽣産性向上を⽬的としたインフラのセルフサービス化を実現する仕組みの構築 インフラレイヤにおける先端技術の検証と導⼊のための抽象化 最近の担当テーマ: EKS Cluster 管理運⽤の効率化、Kubernetes API を中⼼としたミドルウェアの検証‧導⼊ Enabling Orchestration Solution サービスインフラ運⽤にフォーカスしたツールとセルフサービス機能を提供し開発者の⽣産性 を向上 最近の担当テーマ: ⾃動化の推進、 セルフサービス化推進、構築⾃動化 Cloud Governance freee のクラウド活⽤に 秩序を導⼊ することで、健全かつ効率的な利⽤を促進 最近の担当テーマ: クラウドの管理⽅針策定並びに統制のための仕組みづくり Delivery デベロッパーの開発体験をインフラから改善していくチーム 最近の担当テーマ: EKS向けCI/CD基盤(github self-hosted runner, ArgoCD)、評価環境基盤の設計開発 プロダクトチームに対して開発プロセスの改善、提案、プロダクトチームへの SRE プラクティスの導⼊ 最近の担当テーマ: プロセスの改善、提案、プロダクトチームへの SRE プラクティスの導⼊ freee SRE

9 SRE Platform Delivery ● Mission ○ 開発者が機能を思いついてからユーザに届くまでを最短にする ● やっていること ○ CI/CD 基盤 ■ Argo Family, self-hosted Runnerなど ○ 開発環境(EC2)

10 開発したコードがユーザーに届くまで 開発したコードがユーザーに届くまでのフロー ● image build & push ● staging 環境へのデプロイ ● staging 確認 ○ PR 作成者による動作確認 ○ QA ○ e2e test ● production 環境へのデプロイ ● デプロイ後の監視 ○ DataDog‧Bugsnagなど

11 デリバリーの⽣産性可視化と標準化 デリバリーパフォーマンス 可視化 ● Four keys ○ デプロイ頻度 ○ リードタイム ○ 変更失敗率 ○ MTTR ● staging 確認にかかった時間の可視化 デプロイ基盤の標準化 ● 50以上のプロダクトに適⽤される ● QA/監査プロセスの担保 ● 2デプロイ/⽇ でも avg 50PR 以上のプ ロダクトもある ユーザに届くまでを最短にするデリバリーを実現するために必要なこと

12 デプロイ‧QA‧Four keys を⾃動化×⾒える化する freee の統合デリバリー基盤 統合デリバリー基盤(perfect sutekaku) slack & GUI ベースで開発者が操作できてデリバリーの質 を担保‧計測してくれるサービス ● デプロイ⼿順の標準化 ● QAと監査プロセスの徹底 ● Four Keysの計測‧可視化 ● 障害情報(jiraなど)とデプロイの紐付け ● Staging 確認にかかった時間などデプロイフローの 計測‧可視化 ● デプロイ後の監視通知

13 統合デリバリー基盤を取り巻く環境の全体像 ● インフラ ○ GitHub ○ ArgoCD ○ AWS/EKS ● 障害管理 ○ jira ○ Google doc

14 統合デリバリー基盤の概要 統合デリバリー基盤 ● GCP firebase ● TypeScript 連携ツール ● GitHub ● Jira ● Slack ● ArgoCD

15 統合デリバリー基盤の歴史 歴史 ● 約4年前くらいから運⽤開始 ○ デプロイ⼿順の⾃動化 ○ PR ごとの Staging 確認 ○ QA プロセスの確認 ● 約 1~2 年前から Four Keys のなどの計測と可視化に取り組む ○ Four Keys ○ 障害情報とデプロイの紐付け

　 03. デプロイフローの標準化


17 デプロイ統合基盤の導⼊(1/2) 1.利⽤したいリポジトリでWebhookを設定 2.Slack ch にアプリを追加

18 デプロイ統合基盤の導⼊(2/2) 3.GUIから必要な情報を⼊⼒ ● リポジトリ名 ● branch 構成 ● Slack ch ● 便利機能 ○ QAチームへのメンション ○ Google カレンダーとの連携 ○ etc...

19 実際のデプロイフロー(1/3) 1. GitHub Actions から release tag を作成 a. image の build & push b. k8s の manifest を管理しているレポジトリ に tag 変更の PR を作成し slack で通知 2. ⾃動⽣成された tag 変更の PR をmerge a. ArgoCD から staging 環境(EKS)へデプロイ

20 実際のデプロイフロー(2/3) 3. デプロイされたことを検知してstaging確認リスト を作成 a. PR作成者は⾃分のPRに問題ないかを確認 b. e2e test の実⾏ c. QA プロセス d. デプロイ担当者は確認作業を待つ Staging確認の 進捗確認通知 Staging確認の 終了通知

21 実際のデプロイフロー(3/3) 4. Production 環境の image tag 変更PRを作成 5. PR merge で ArgoCD から production 環境にデ プロイされる 6. 監視通知が slack に届くので監視する ○ デプロイ担当者が Error Rate などが問題 ないことを確認してデプロイ終了

22 統合デプロイ基盤の便利ポイント(1/3) 各プロダクトのデプロイステータスを⼀⽬で確認することができる

23 リポジトリごとのデプロイ状況の可視化 ● デプロイのどのステップか？ ● Staging 確認 ○ ステータス ○ 掛かった時間 ○ Staging確認のリスト ● デプロイ禁⽌⽇などを Google カレン ダーと連携 など 統合デプロイ基盤の便利ポイント(2/3)

24 PR ごとの Staging確認通知のカスタム ● リマインド ○ ⼀定時間 Staging確認されない場合 には再度メンション ● Rollback NG button ○ 特別な要件で Rollback することが できない PR を判別 統合デプロイ基盤の便利ポイント

　 04. Four Keys と Staging確認 の計測・可視化


26 Four Keys とは？ DevOps Research and Assessment（DORA）チームが提唱しているソフトウェアデリバ リーのパフォーマンスを⽰す 4 つの指標のこと Four Keys ● デプロイ頻度 : 変更を本番環境にデプロイする頻度 ● リードタイム : 変更コミットが本番環境で正常実⾏されるまでの時間 ● 変更失敗率 : デプロイによって本番環境で障害が発⽣する割合 ● MTTR: 本番環境での障害から復旧までにかかる時間 Four Keys は組織のパフォーマンス(収益性，市場占有率など)と強い相関がある

27 Four Keys Dashboard(1/2) プロダクトごとに確認することができる Four Keys Dashboard

28 Four Keys Dashboard(2/2) ⽉‧週‧⽇ごとに確認することができる Four Keys Dashboard デプロイ頻度の例

29 Jira 管理の障害とデプロイ情報の紐付け Jira 管理されている情報を統合デリバリー基盤で取得 & 可視化 Jiraで管理されている障害情報を webhook で受け取り、統合デリバリー基盤の GUI から⼀覧 で表⽰される

30 変更失敗率 & 障害復旧時間 Jira 管理されている情報を統合デリバリー基盤で取得 & 可視化 GUI から⼀覧で表⽰されている障害情報に 『デプロイによる障害か？』『どのデプロイで障 害になったか？』『どのデプロイで障害から復旧したか？』などを⼊⼒ 連携

31 障害データのクラスタリングを可視化 障害データをクラスタリングして可視化 ● デプロイによる障害の数 ● 障害の重篤度 ● 障害が発⽣した GitHub レポジトリ

32 staging 確認にかかった時間の可視化 staging の確認作業は ● QA, e2e ● PR担当者の staging 確認 など⼈の作業時間の振れ幅が⼤きいためモニタリングしておく必要がある

　 05. 統合デリバリー基盤の まとめ


34 統合デリバリー基盤のまとめ ● freee の統合デリバリー基盤の歴史 ○ 4年前から運⽤開始: QA/監査プロセスを含むデプロイの標準化ツールとして ○ 1~2年前から Four Keys の取得 & 可視化など役割を広げてきた ● デプロイフローの標準化 ○ ⼤規模なデプロイ基盤を⽀えるプロダクト ○ slackベースでデプロイ‧QA/監査プロセスの⾃動化 ○ プロセスの可視化と各チームの事情に合わせたカスタム機能を設定できるGUI ● Four Keys の取得と可視化 ○ プロダクトごとの Four Keys を可視化 ○ Jira などのツールと連携してデプロイと障害情報を紐づけられる ○ Staging 確認に掛かった時間もモニタリングなど

　 06. Four Keys への
 向き合い方


36 Four Keys のよくあるアンチパターン(1/2) Four Keys のよくあるアンチパターンとしては ● デプロイ頻度 : 変更を本番環境にデプロイする頻度 ● リードタイム : 変更コミットが本番環境で正常実⾏されるまでの時 間 ● 変更失敗率 : デプロイによって本番環境で障害が発⽣する割合 ● MTTR: 本番環境での障害から復旧までにかかる時間 の数字の向上だけを求めてしまう

37 Four Keys のよくあるアンチパターン(2/2) 出典: agile journey by uzabae 『Four Keysを⽤いた改善活動のアンチパターンと、本質的な改善のために必要な「なぜ？」』(url: https://agilejourney.uzabase.com/entry/2023/09/28/103000)

38 Four keys の奨励される使い⽅ Four Keys を⾒る上で気をつけていること ● 数字の背景をみる ● ケイパビリティなどの改善活動そのもの

39 数字の背景をみる(1/2) 例1: MTTR が⻑くなっているが障害の内容がかなり軽度で翌⽇対応した 障害として Jira のチケットが作成されたとしてもユーザ影響がない or ほとんどない場合の MTTR にまでこだわる必 要はないと考えています。 ⾃分たちのルールとして重篤度レベルが低い障害は除外した数値が⾒れるといい..?

40 数字の背景をみる(2/2) 例2: デプロイ数が少ないがPR数も少ないプロダクト 週に5つしか PR が作成されないプロダクトが毎⽇デプロイする必要性があるかに関してはやる必要がないと思いま す。そもそも、『前のリリースからの差分はどれくらいか?』『⼀回のデプロイにどれくらいの PR が⼊っている か？』などを通知‧可視化してます。 release tag から の差分を表⽰ デプロイごとの PR 数を測定

41 ケイパビリティとは ケイパビリティ(組織が保持する能⼒) と は Four Keys を統計的に有意な形で改 善することができるものを⽰してお り、27個が公開されている ● トランクベース開発 ● ⾃動テスト ● ⾃動デプロイ ● ドキュメントの質 etc... 出典: DORA's Research Team 『DORA Core Model』(url:https://dora.dev/research/)

42 ケイパビリティの改善(1/3) 例: トランクベースの推進 トランクベース開発: ソフトウェア開発の⼀つのスタイルで開発者は⾃分の作業を⼩さなバッチに 分割し、少なくとも1回/⽇はトランク(共有 branch)に merge される freee では短命の feature branch & PR を作成し main にmerge される デプロイは release tag によって実⾏される仕組みを採⽤している

43 ケイパビリティの改善(2/3) 例: トランクベースの推進 共通でよく利⽤する CI/CD は⼀つのリポジトリでラップする。プロダクトのリポジトリから利⽤ するようにことで導⼊‧認知負荷を下げている。 ● integration, staging, production 環境へのデプロイフロー ● hotfix のフロー ● etc ...

44 ケイパビリティの改善(3/3) その他ケイパビリティ改善の例 ● ドキュメント整備 ○ リリース時の互換性の担保 ○ Argo Rollout の abort などのコンテナイメージ切り戻し⼿順の整備 ● コード品質 ○ SonarQube を利⽤した静的解析ツールなど ● モニタリングの向上 ○ プロダクトチームの要望や障害からモニタリングすべき項⽬を標準化 ○ DataDog による Dashboard や Alert を愚直に作成

45 まとめ ● Four Keys のアンチパターンは踏まないようにするには ○ 数字の背景をちゃんと⾒ること ○ ケイパビリティの改善活動 ● Platform Delivery の取り組み ○ 数字の背景をみるために⼯夫してきた ○ ケイパビリティの改善 ■ パッケージ化 ■ プロダクトチームにローラー作戦 内製の統合デリバリー基盤を⽤いることで細かい配慮できており、それが改善の成果 に繋がっている

　 07. 課題とこれから


47 課題 ⽣産性向上の取り組みをして⾏く中で組織としての課題に多くぶつかった... ● ケイパビリティが各チームのボランティアになっている -> プロダクトチームでケイパビリティの改善がもっと評価される⽂化に ● ⾃分たちが動かないと変わらない -> プロダクトチームにお願いをして回るだけだとなかなか進まない ● ボトムアップだけだと難しい部分もある -> OKR などにケイパビリティの改善活動などが盛り込まれることで

48 これから ● ケイパビリティ改善などがプロダクトチームの OKR や実施計画に組み込ま れるように働きかける ● 統合デリバリー基盤をアップデートしていくことでより効率的にパフォー マンスの改善活動を⾏なっていく ● 愚直なケイパビリティ改善活動の継続