SRE 文化の醸成: stream-aligned チームに Enabling するために実施した事例の解説 / Cloud Operator Days Tokyo 2025

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © Henry, Inc. All rights reserved. 前説このセッションでは「サービスの Realiability はチームから! Enabling を通じて実現する、信頼されるサービスづくり」で紹介された以下の事例についてさらに掘り下げていきます ● デプロイ計画会 ● Honeycomb や Datadog などのオンボーディング ● パフォーマンス分析会 2

Slide 3

Slide 3 text

Copyright © Henry, Inc. All rights reserved. 自己紹介 ● 渡辺道和 (nabeo) ● SRE 室の SRE として2023年6月にジョイン ○ オンプレのインフラエンジニアとしてキャリアをスタートし、クラウド側にシフトした ○ Platform SRE としてクラウド基盤や監視基盤の整備を担当している ○ 最近はサービスの可観測性の向上をテーマにして OpenTelemetry の利用推進などを通じた信頼性の向上に興味がある X: @nabeo BlueSky: @nabeo.bsky.social Blog: https://nabeop.hatenablog.com/ 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © Henry, Inc. All rights reserved. ● ヘンリーでは通常のデプロイを毎週実施している ○ hotﬁx など通常のデプロイを待つことができないデプロイはデプロイ計画会を待たずにアプリケーションごとにデプロイを実施している ● 次回のデプロイ対象を統合テスト環境にデプロイするタイミングでデプロイ計画会を実施している ○ 複数のアプリケーションを同時にデプロイすることで相互作用による不具合が紛れ込まないようにする ○ デプロイ計画会では開発チームと SRE チームの担当者がオンラインで集合して、変更内容のレビューなどを実施している ● 本来は準備が整った内容から都度デプロイしたり、Feature Flags などでリリースとデプロイを完全に分離したいが、以下のような事情で通常デプロイはまとめて毎週実施している ○ 統合テスト環境でのリグレッションテストの実施期間を確保する 5 デプロイ計画会

Slide 6

Slide 6 text

Copyright © Henry, Inc. All rights reserved. 1. デプロイするサービスの差分の確認 ○ 本番環境へのデプロイ用 P-R を GitHub Actions で生成する 2. デプロイ中にエラーが発生する変更がデプロイ内容に含まれていないかの確認 ○ DB のスキーママイグレーションでエラーになる内容はないか ○ アプリケーションが使用している API で非互換な変更が含まれていないか ○ GraphQL Schema に非互換な変更が含まれていないか 3. 統合テスト環境へのデプロイ ○ 本番環境へのデプロイ用 P-R で発火する GitHub Actions のワークフローが統合テスト環境のデプロイを実行している ○ 統合テスト環境へのデプロイが成功することを確認する 4. (本番環境へのデプロイ当日) ○ デプロイ計画会以降にデプロイ対象に追加された内容の確認 6 デプロイ計画会の進行と本番環境へのデプロイ

Slide 7

Slide 7 text

Copyright © Henry, Inc. All rights reserved. ● 開発チームはデプロイ計画会への参加を当番制にしている ○ デプロイ計画会での知見がチーム間で共有される ○ リスクが高い変更への解像度が上がる ● 誰でも司会者ができるようにする ● デプロイフローの解像度が上がることで、開発チームによるデプロイフローの改善に繋がる ○ デプロイ計画会と本番環境デプロイが各1時間で各チームから1人以上参加するミーティングなのでコストは高い ■ N人のメンバーが毎週2時間なので週のうち1人日近く消費される会議になっている ■ デプロイ計画会が早く終わるような改善提案が開発チームから出てくる ○ hotﬁx でも同様のデプロイフローなので、デプロイフローの高速化が障害発生時の解消時間の短縮につながる ■ 開発チームのメンバーによる DB マイグレーションの時間短縮 7 デプロイ計画会による変化: デプロイが全てのチームの自分ごとになる

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright © Henry, Inc. All rights reserved. ● ヘンリーでは複数の監視サービスを用途によって使い分けている ○ メトリクス監視: Datadog ○ 分散トレース: Honeycomb ● 以下の理由から積極的に開発チームのエンジニアにもアカウントを払い出している ○ ユーザ数課金ではない ○ Datadog や Honeycomb には要配慮個人情報を保存していない ● Honeycomb はメジャーなツールではなく、分散トレースというメトリクスやログとは異なる概念なので導入時に開発チーム向けの説明会を実施した ○ 説明会の様子は Google Meet で録画しておき、後から参照できるようにしている ● 後述のアプリケーション版のパフォーマンス分析会は Honeycomb の継続的な enabling も兼ねている 9 監視・モニタリングツールのオンボーディング

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright © Henry, Inc. All rights reserved. ● Datadog のダッシュボードで新機能の利用状況を医療機関様ごとに確認できるようにして、利用が芳しくない医療機関様にアプローチできるようにした ● 開発チームで実施する負荷テストや通常時の調査などで Datadog や Honeycomb を確認するようになった ○ 2025年7月は Honeycomb で実行されたクエリの61% が開発チームだった 11 開発チームでの活用事例

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © Henry, Inc. All rights reserved. ● アプリケーションの変更によるインフラ側の変化を中長期で俯瞰し、課題を見つける ○ SRE チームが主体で開催し、各チームから有志が参加している ○ SRE チームだけではアプリケーションの変更内容の解像度が低い ■ インフラ側の変化がアプリケーション側のどの変更か判別できない ■ インフラ側の変化が一時的なものなのか、恒久的な変化なのかを判別できない 13 パフォーマンス分析会

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright © Henry, Inc. All rights reserved. ● SRE チームと開発チームの共通言語として Datadog の指標を使うことでコミュニケーションがスムーズになる ● パフォーマンス分析会はインフラ側に重点が置かれているのでアプリケーション側でも同様の取り組みを始めている ○ Honeycomb を使ったアプリケーション側の課題発見のためのアプリケーション版のパフォーマンス分析会を立ち上げている ○ アプリケーション版パフォーマンス分析会では Honeycomb のダッシュボードを眺めるだけでなく、開発者の気になっている箇所を Honeycomb でどのように調査すれば良いかという知見共有の場としても活用している 15 パフォーマンス分析会の効果

Slide 16

Slide 16 text

Copyright © Henry, Inc. All rights reserved. ● stream-aligned チーム (≒ 開発チーム) が自律的に信頼性向上に取り組めるように enabling する施策の具体について紹介しました ○ 誰でも使える状態にしつつ伴走しつつ、開発チームに自分ごととして捉えてもらえるようにすることが必要 ● すぐに実現できることではないので長い目で調整しつつ進めることが必要 16 まとめ: