運用できる開発組織の作り方 ― kintone開発組織のストーリー

DevOpsDays Tokyo 2025での発表資料です。
https://confengine.com/conferences/devopsdays-tokyo-2025/schedule/rich#session-33399-info

Transcript

1. 運用できる開発組織の作り方 kintone開発組織のストーリー サイボウズ株式会社 上岡 真也 / @ueokande
2. はじめに サイボウズのクラウドサービス「kintone」は、近年までサービス運用を専用の運用部署が担当。事業拡大 とシステムの複雑化により、開発組織と運用組織が別にあることの課題が見えてきた。 以前までは技術的な制約によってDevOps体制に近づけることが難しかった。しかし近年、社内のクラウド プラットフォームを作り直して技術的な課題をクリア。運用権限を広く渡せる状態となった。 運用業務が定着していない製品開発チームに、単に「運用よろしく」では、サービスの信頼性維持が難しい。 運用できる開発組織を作るために様々な準備が必要。本日はkintone開発組織に運用業務を定着させるまで のストーリーを紹介。 概要 2
3. はじめに サイボウズ株式会社 開発本部 2016年にサイボウズに入社。社内のクラウド環境 （プライベートクラウド・パブリッククラウド）や、 バックエンドサービスの開発・運用を経験。 2023年からマネージャー。 自己紹介 上岡 真也 う え お か し ん や X/GitHub: @ueokande 4
4. サイボウズという会社 5
5. サイボウズという会社 チームワークあふれる 社会を創る サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿ってチームワークを支えるソフトウェアを 開発し続けてきました。
6. 主力製品 開発の知識がなくても 業務に合わせたシステムを かんたんに作成できる クラウドサービス
7. サイボウズという会社 サイボウズのクラウドサービスは、国内DCのプライベートクラウドで構築。ベアメタルサーバー上に自社 で仮想化基盤を構築して、アプリケーションを展開。近年は、パブリッククラウドを活用した新機能開発も 取り組む。 クラウドサービスの運用環境 9
8. サイボウズのクラウドサービスの運用 10
9. サイボウズのクラウドサービスの運用 サイボウズのクラウドサービスは、長らくサービス運用は専用の部署が担ってきた。 • 運用チームは、インフラ基盤、ミドルウェア（MySQL、L7LB、etc）の構築、製品の運用までカバー。 • 製品開発チームは、成果物を運用チームに受け渡すまでが責務、本番環境の権限を保たない。 これまでの開発・運用体制 本番環境 VM基盤 MySQL L7LB Blob FTS kintone Garoon .... 製品開発 チーム 運用チーム エスカレーション オペレーション・調査依頼 11
10. サイボウズのクラウドサービスの運用 課題1: 運用難易度の向上。システム規模の拡大によって、運用チームの認知不可の向上や、オンボーディ ングの課題が顕著に。 • インフラ、VM基盤、L7LB、MySQLなどを運用する知識が要求される。 • 異なる技術スタックを採用（Javaアプリケーション&Jettyサーバー、PHP&CGI、等）した製品の運用。 課題2: 製品の開発チームと運用チームが、組織構造上の距離がある。 • 本番環境のオペレーション実施は製品開発チームはできない。メトリクスの追加や運用ツールの導入など の運用改善は依頼ベース。 • 運用業務が開発プロセスに組み込まれていない。開発チームが運用環境からフィードバックを得られる動 機の減少。 運用体制の課題 12
11. サイボウズのクラウドサービスの運用 kintoneローンチ当時のアーキテクチャは、サービス運用者にインフラや製品の運用知識を求める設計。本 番環境の管理権限は限られたメンバーが持ち、 製品ごとの運用権限は分離しない。 そのため製品開発チー ムに広く展開できなかった。 ログやメトリクスは徐々に開発チームに展開してきたが、運用に必要な権限は運用チームのみが持つ。 DevOps実現する上での技術的制約 VM基盤 MySQL L7LB Blob FTS kintone Garoon .... kintoneのオペレーション権限を付与すると、 他の製品やインフラ基盤の管理権限もついてくる 13
12. サイボウズのクラウドサービスの運用 事業規模の拡大に伴い、インフラ面・組織面でスケーラビリティの課題が出てきた。長期的な事業継続のた め、VMベースからKubernetesベースのアーキテクチャに刷新。 権限モデルを見直して、各製品やコンポーネントごとに名前空間を設定。各チームは名前空間内のリソース に責任を持ち、他チームの名前空間内にあるリソースは書き換えができない。 新プラットフォームへの移行 Kubernetes MySQL L7LB Blob FTS kintone Garoon VM基盤 MySQL L7LB Blob Blob kintone Garoon 他チームのリソースには アクセスできない デプロイや運用は各チームの 名前空間内で自由に実施可能 14
13. サイボウズのクラウドサービスの運用 新しいアーキテクチャによって開発チームに運用権限を渡せるようになった。製品開発チームが運用するた めには、いくつかの準備が必要。 • 運用スキルの課題。製品開発チームでは運用経験が少ない。 • 運用に携わるチームが増える。障害解決のためにチーム間の連携が必要。 大前提として体制やアーキテクチャは変わってもサービスの信頼性は変えない。 新たなアーキテクチャ上 で、開発組織が運用できる体制を作る。 仕組みは揃ったが... 15
14. 運用できる開発組織に 16
15. 運用できる開発組織に 製品開発チームを運用できる開発組織にするために、「仕組み」と「体制」の二軸で考える。 • 「仕組み」 ... 運用容易性を担保するための技術的アプローチ。モニタリングやアラート。 • 「体制」 ... 運用を実行可能にするための人やプロセスの設計。 製品開発チームと今の運用チームから人を集めて、以下の狙いを持って部署横断のプロジェクトを発足。 • 今までの運用プラクティスのスキルトランスファー。 • 開発チームと運用チームの両者の業務を円滑に変更できる。 • 他のマネージャーからのスポンサーシップを得やすい やったこと 17
16. 運用できる開発組織に 新しいアーキテクチャやツールを知ってもらうための勉強会を実施。社内のマルチテナントアーキテクチャ やオブザーバビリティ、Kubernetesエコシステムのツールや製品のトラブルシュート事例を紹介。 • kintoneのアーキテクチャ • ログ、メトリクス、オブザーバビリティ • Kubernetesエコシステム • kintoneのトラブルシュート事例 • 社内運用ルール 取り組み1 | インフラ知識のインプット 18
17. 運用できる開発組織に 新しいプラットフォームでは、開発チームがモニタリング・アラートを設定して自分たちで運用改善する。 製品チームが旧アーキテクチャと同等の水準で監視できるようガイドラインを定義。 例 • サービスの正常性。Kubernetes Deploymentが正しくレスポンスを返すか。 • ロールアウトの正常性。Podが再起動を繰り返してないか。正しいReplica数か。 • SLO/ユーザービリティに基づく監視。応答時間やエラー率。 • OSやJVMのリソース監視。ディスク使用率の上昇など放置すると障害につながるもの。 取り組み2 | モニタリングの標準化 19
18. 運用できる開発組織に 設定したアラートそれぞれに対応する、障害対応手順書を準備する。アラート発生からスムーズに障害対応 を始められるように、アラート本文に手順書へのリンクを貼る。対応者のレベルに依存せず、緊急時に焦ら ず手順を実行できる狙い。 障害対応手順書には以下の事項を含む • 原因切り分け手順。ダッシュボードへのリンクやメトリクスの説明。 • 障害を是正する手順。オペレーションや切り戻し手順。 取り組み3 | 障害対応手順書の準備 kintone タイトル: エラー率向上 サービス: Worrker Runbook: https://...... 監視 通知 対応者 20
19. 運用できる開発組織に 各サービスのインシデント発生状況を、単一のダッシュボードで可視化。他チームのサービス稼働状況やイ ンシデント発生元の特定に役立てる。ためらうことなくエスカレーションをしやくすして、チーム間で連携 して障害対応に取り組める狙い。 取り組み4 | 社内ダッシュボード 21
20. 運用できる開発組織に サイボウズの組織構造: 製品開発とプラットフォーム開発をする部署が組織的に異なる。前者は各製品やコ ンポーネントごとのチーム。後者はKubernetes基盤、データベース、ストレージなど、製品の運用に必要 な仕組みを提供。 従来は運用チーム（プラットフォーム開発）で製品の障害対応、オンコール体制を回していた。製品チーム も巻き込んだ24/7オンコール体制を考える必要がある。 取り組み5 | オンコール体制の設立（1/2） kintone 認証基盤 バックエンド Storage Database Kubernetes ・・・・ ・・・・ 22
21. 運用できる開発組織に チーム単位、チーム合同、部署合同など様々なオンコール体制を評価。最終的に部署単位のチーム合同でオ ンコール体制を設立。 • チーム単位のオンコール: 開発と運用をするメンバーが一致するので、運用環境のフィードバックが最も 得やすい。小さなチームではシフトを回すのが難しく、過剰な体制となる。 • 部署合同: 小さなチームをカバーできて運用負荷が低い。技術スタックが全く異なるチームの成果物を運 用をすることの技術的・心理的ハードルが大きい（例:製品チームがインフラ運用をできるか）。 取り組み5 | オンコール体制の設立（2/2） チーム単位 部署合同 チーム合同（部署単位） 23
22. 運用できる開発組織に 障害対応の教育や訓練には様々なやり方がある。 • 関係者全員を含めた訓練 • 対応手順の確認のためのドリル • 実際に障害を起こす訓練 • 障害対応シナリオのロールプレイ 障害対応を始めて行うメンバーがほとんどだったので、障害対応シナリオのロールプレイを実施。 取り組み6 | 障害対応ロールプレイ（1/2） 24
23. 運用できる開発組織に ロールプレイは事前に準備した障害シナリオに則って障害対応を実施。 ２つの役割に分かれて実施。 • ナビゲーター: ロールプレイの案内役。シナリオの読み上げやインシデント発生状況を伝える。 • 対応者: ロールプレイのシナリオに沿って障害対応を行う。 取り組み6 | 障害対応ロールプレイ（2/2） 障害が発生しました。PagerDuty確認してSlackで応答してください。 （PagerDutyでAcknowledge、Slackで返答） 障害対応手順に従って対応を開始ます。まずはGrafanaでメトリクスを確認 してSlackで観測報告を報告してださい。 （Slack「本番環境でエラー率が上昇してます」） 本番環境でお客様影響があります。社内連絡と社外告知の準備を進めてくだ さい ナビゲーター 対応者B ナビゲーター ナビゲーター 対応者A 25
24. まとめ 26
25. まとめ 2025年Q1に、製品開発チームが、オンコールや運用業務をスタート。それから実際の障害対応や運用業務 を経験したが、完全な定着までは時間を要する。これから答え合わせのフェーズ。 これまで開発に集中していたチームに運用業務が割り込む事象が増える。開発チームが運用環境からのフィ ードバックを活かせるには時間がかかる。メトリクスを取得はこれから。 実は運用スタートしたのはkintoneとそのサブシステムのサービスのみ。これから新アーキテクチャに移行 するプロダクトもある。その体制を含めた、真の開発組織の運用体制はこれから。 運用体制の結果...！？ 27