この記事は「Gaudiy Advent Calendar 2022」の21日目の記事になります。
こんにちは。Web3スタートアップのGaudiyで、エンジニアをしているhaseyan（@hassey_11）です。
Gaudiyは、この1年で開発組織が倍以上になってきており、来る2023年に向けて組織もプロダクトも加速度的に成長しています。それに伴い、開発〜運用プロセスにおいていくつかの問題が発生していたため、DevOps の CAMS 原則に則ってアラート/不具合対応プロセスの改善に取り組みました。
今回は、その改善プロセスについて一連の流れを振り返ってみたいと思います。スケールする開発組織の課題を抱えているチームの方に参考になれば嬉しいです！
- 1. スケールするプロダクト組織と DevOps の必要性
- 2. 実際に起こっていた問題
- 3. DevOps の CAMS 原則に基づく改善策の検討
- 4. アラート/不具合対応プロセスの改善でやったこと
- 5. おわりに
1. スケールするプロダクト組織と DevOps の必要性
Gaudiy は、Gaudiy Fanlinkという、IPコンテンツホルダー自身がファンコミュニティ-ECプラットフォームを立ち上げることを可能にするサービスを開発・提供しています。
一般的に、人が増えるのに比例して、プロダクトの成長スピードが上がっていくわけでは必ずしもありません。むしろ、人数やサービスの規模が増えるにつれて、これまでは問題にならなかったことが新たな問題として表出してきます。
開発面では、トラフィック増加によるパフォーマンス問題が発生したり、開発の大規模化に伴うリファクタやシステムのリプレイスが必要になる場合もあります。また運用面では、リリースが複雑になりすぎたり、一部のドメイン/サービス領域が属人化するといった問題も生まれるかもしれません。また当然ですが、開発や運用だけでなく、組織面での問題も発生します。
スタートアップがスケール後もその成長スピードを保つためには、こうした問題を可能な限り防ぎ、スケールしても1人1人がプロダクトのアウトカムに貢献できる総量を高く保ち続けることが重要です。
こうした問題の中でも、運用や組織の開発プロセスに関する問題にアプローチする際に役立つ考え方のひとつが、DevOps です。
2. 実際に起こっていた問題
表題の通り、Gaudiyではアラート/不具合対応プロセスに関して、以下の課題を抱えていました。
- アラート/不具合が発生した際に、明確な対応フローが定まっておらず、対応が属人化している
- 不具合の対応状況が運営チームと開発チーム間でうまく同期されていない etc.
これまでは特に仕組みを作らずとも、アラートや不具合が発生した際にメンバーが自発的に対応を行うだけで、問題なく運用できてました。
しかし、開発に関わるメンバーが増えるにつれて対応する/できる領域が属人化していき、いわゆるアジャイルのトラックナンバー 1 が少ない状態になっていきました。また各人が通常のスクラムプロセス外で対応を行うので、報告者及び対応者以外の第三者が状況を把握することが難しくなっていました。
こうした属人化の影響が大きくなると、不具合全体の定量分析によって発見できたはずの、アーキテクチャレイヤの潜在的な問題点を見落としたり、監視として最適なアラートの設計などが遅れるリスクも高まります。2
こうした課題を解決するために、DevOps の考え方に基づき、アラート/不具合対応のプロセスについて改善を行いました。
3. DevOps の CAMS 原則に基づく改善策の検討
DevOps の考え方の重要な要素として、CAMS（culture, automation, metrics, sharing）というものがあります。 システム運用アンチパターンによると、CAMS の各要素は以下のようになっています。
- culture（文化）
- チームが活動する上での基準に影響するもの
- automation（自動化）
- 人的資本を平凡な作業から解放するもの
- metrics（メトリクス）
- 物事がうまく機能しているかどうかを判断するために必要なもの
- sharing（共有）
- 知識は自由であるという考えのもと、文化を強化するために必要なもの
各要素の詳細や DevOps のより具体的な考え方などは上記の書籍などで学ぶことができますが、大まかには、運用を改善していくには「automation によってアンチパターンを避けながらリソースを効率化し、その結果について metrics を用いて判断・フィードバックを行った上で、得られた知見を sharing することで culture が強化されていく」と捉えると理解しやすいかもしれません。
この CAMS に従って、アラート/不具合対応プロセスの問題に対して、以下の流れで改善策を検討しました。
- 関連メンバーに現状のプロセスの概要及び課題感のヒアリング
- プロセス改善の why と改善方針のsharing
- プロセスの automation の実施
- 各種不具合/アラート対応 metrics の可視化と評価
- metrics の結果分かったことと更なる改善方針の sharing
4. アラート/不具合対応プロセスの改善でやったこと
上記の検討に沿って、具体的にアクションを実行していきました。
4-1. 関連メンバーに現状のプロセスの概要及び課題感のヒアリング
Gaudiy には「Be Agile に最大効率を徹底しよう」という行動指針があり、今回の改善でも、小さな改善を繰り返し行っていくことを意識していました。
具体的にはヒアリングをもとに、現状のプロセスの整理と各メンバーの課題感の洗い出しを行い、最も取り組むべき問題を特定することを試みました。
この行動指針ではチームをまたいだ「ちょいコラ」（ちょっとコラボするの略、Gaudiyの社内用語）が推奨されており、どのメンバーも「ちょいコラ」に慣れているので、コラボレーションがとてもしやすい環境になっていると感じています。
プロセスと課題感の整理は miro で行い、以下のような形に整理しました。ヒアリングはプロセスを追いながら課題感を付箋でマークしていく形で行い、課題のある場所とその内容が明確になりました。また、各人がプロセスに関してそれぞれ異なった認識をしていたこともわかりました。
この結果、アラートがわかりづらくて課題を特定しづらい、情報共有がうまくできてないなど、いくつかの開発/運用/コミュニケーションに関する問題が出てきました。特に、現状の一番大きな課題は 「不具合/アラート発生後の進捗管理・対応方法が属人化しており、特定個人の負荷が高まっていること」であると結論づけました。
4-2. プロセス改善のwhyと改善方針のsharing
軽微な仕組みであっても、プロセスの実行主体は常に受け入れる側であるため、その受け入れる側に納得感や理解がなければ仕組みの導入や浸透が難しくなります。また、担当者がいなくなると仕組みがすぐに陳腐化するといったこともあるので、仕組みを作るだけでなく、それを支える文化を醸成していくことも同時に行う必要があります。
今回の取り組みでは、ヒアリングを通じて把握できた現状の課題感と、将来的にアラート/不具合改善のプロセスを改善した結果、どういったことを実現したいかをドキュメントにしてチームに共有しました。
また、その実現に向けた大まかな方針から紐解き足元における改善後のプロセスを示し議論をすることで、納得感を得られるように努めました。方針については最終的な理想系から逆算する形で提案したことで、将来像の議論と共通認識をすることができ、結果としてとても良い議論ができました。
| Why/方針の共有 | 改善後プロセスの共有 |
|---|---|
  |
 |
具体的な改善後のプロセスとしては、個人単位ではなくサービスのオーナー単位で対応を行い、そのリソースもチーム内で管理するという方針で合意しました。 3
4-3. プロセスの automation の実施
DevOps の中でも個人的に重要だと考えているのが、この automation の部分です。人力での作業/属人性を減らし、プロダクトのアウトカムにリソースを集中できるかの多くは、このautomationの度合いに依存します。
上述の改善後プロセスの画像内の黒い四角の1つ1つは、各プロセスで出てくる Slack bot のスクリーンショットになっています。このプロセスの図は一見すると少し複雑になっていますが、ほぼ全てがSlack上で完結するようになっています。
| 不具合・アラートの検知 | サービスオーナーのアサイン |
|---|---|
 |
 |
| 解決済みの不具合・アラート | 次スプリントで解決 | ignore済みの不具合・アラート |
|---|---|---|
 |
 |
 |
この Slack bot は TypeScript/Node.js で作成し、 Cloud Function 上の1つのエンドポイントで動作しています。Slack の API はとてもリッチで、簡単にインタラクティブな bot を作成することができます。DevOpsを推進する上では非常に強力なツールになるので、興味がある方は是非試してみてください。
また、手動による不具合報告とサーバやSentryなどの3rdパーティツールから送られるアラートは、zapierを利用して一つのチャンネルに集約され、全て統一されたプロセスで対応できるようになっています。zapierもかなり自由度が高く、おすすめのツールです。
4-4. 各種不具合/アラート対応 metrics の可視化
上記のプロセスにて運用を開始してからしばらくしたのち、いくつかの指標を用いて当初の課題が解決されているかを確認しました。
1つ1つのアラート/不具合のデータは全て Notion に蓄積されているようにしているため、そのままダウンロードし、Google Spreadsheet で可視化することができました。Notion はドキュメント管理だけでなく、DevOps 観点では簡易 DB としても利用できるため、非常に重宝しています。
【確認したい課題1】個人単位の負荷は減ったか？
こちらの課題は、どれくらいアラート/不具合対応の担当領域が分散しているか、という観点で、発生したアラート/不具合のサービス領域の割合を確認しました。
この図から、特定の領域でのみ対応が発生しているということはなく、個人に大幅な負担がかかっている状況は解消されつつあるのかなと判断しています。また、データだけでなく、メンバーにヒアリングした際にも、問題の解消が確認できました。
【確認したい課題2】対応方法は標準化されているか？
こちらは、発生したアラート/報告された不具合のうち、改善後のプロセスでは、属人的に解決される=プロセス外で解決or対応漏れが発生していないことを確認しました。結果としては、約1ヶ月で37件の対応が発生し、そのうちの34件はその日のうちに適切なプロセスでチーム内タスクへの統合や根本対応が行われ、丸2日以上放置される件数は0となっていました。
この結果から、個人で対応するのではなく、チームで対応するという仕組みが実現できたと判断しました。
Gaudiy の社内用語には「チャレオン」（人のチャレンジに乗っかるの意）というものがあり、こうした新しい仕組みにも積極的に乗っかってくれる人が多く、非常にスムーズに導入が進みました。
4-5. metrics の結果わかったことと、さらなる改善方針の sharing
ここまでのCAMSの一周目の取り組みを通して、
- 不具合/アラートが起きやすい箇所やその原因の分析
- 発生したときに対処しやすい意味のあるアラート設計の方針
など、metricsを取ったことで得られた新しい知見が得られ、さらなる改善方針などをより解像度高く考えられるようになりました。
これらは現在、teamごとのDevLeader（選挙で選ばれる任期性の開発リーダー）と週次で共有・振り返りをしており、ネクストアクションを制定したり、必要に応じてチームや横断的な改善チームに相談しながら、改善に向けて動いています。
また、このプロセス自体にもいくつかのさらなる改善ポイントがあり（開発JiraチケットとNotionの連携automationなど）、随時2周目となるアップデートを行っていく予定です。
開発チーム全体には、週報として Slack でサマリを展開しています。
5. おわりに
こうした DevOps の取り組みは、やりたいけど時間がない、という方は多いと思います。
ありがたいことにGaudiyでは、平日のアウトカムを高めるために、毎週水曜日に横断的な課題を解決するために時間をとる「EMPOWER-DAY」という仕組みがあります。今回の取り組みはほぼ全てこの水曜日に行ったものであり、 組織全体でこうした取り組みに時間を割くことを許容する文化があるので、非常に進めやすかったです。
あらゆる課題は、代表Dev（選挙で選ばれる任期性の開発全体のリーダー、所謂CTOポジション）などと適切に合意を取れば、手を挙げれば誰でもどんな課題でも取り組むことができ、課題解決が好きな人は楽しい環境かなと思います。
私自身DevOpsの考え方は大好きですし、スケールする開発組織には必須だと考えているので、引き続きプロダクト開発と並行して改善を進めていこうと思います。
- 特定の人物がトラックに轢かれるなど何かしらの要因で突発的に離脱することで、プロジェクトが立ちゆかなくなったり、継続して開発が困難になる人数↩
- 不具合の報告の際にはランダムにメンバーがアサインされる形でしたが、FE/BE といった領域や、サービスに関係なくアサインされるため、人によってはキャッチアップコストが高かったり、ユーザ影響が小さく優先度が低い場合に通常のタスクの後回しになり、対応漏れが発生するといった問題もありました。こうした対応漏れもメンバーの自主的な動きによって解決されていましたが、プロダクトのスケールとともに各人が持つコンテキストが複雑になっていき、負荷が高まっていました。↩
- 元々はチーム単位で、という提案でしたが、この改善の最中にサービスオーナー(各ドメインのオーナー)という概念が生まれ、そのほか各種プロセスに利用されたので、今回の改善でもその流れを汲むこととなりました。↩
