Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
SRE 文化の醸成: stream-aligned チームに Enabling するために実施...
Search
nabeo
September 05, 2025
Technology
340
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SRE 文化の醸成: stream-aligned チームに Enabling するために実施した事例の解説 / Cloud Operator Days Tokyo 2025
nabeo
September 05, 2025
More Decks by nabeo
See All by nabeo
インフラ側からみた PostgreSQL の Row Level Security (RLS) ~ オーロラ (Aurora) ソースを添えて ~ / Henry Engineer Meetup #8
nabeo
0
100
組織とプロダクトの変化に合わせたクラウド選択 / Henry Engineer Meetup #5
nabeo
0
100
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
3
1.2k
kotlin-lsp を Emacs で使えるようにしてみた / use kotlin-lsp in Emacs
nabeo
0
550
Docker Compose で手軽に手元環境を実現する / Simplifying Local Environments with Docker Compose #CinemaDeLT
nabeo
0
660
OpenTelemetry Collector 自身のモニタリング / Monitoring the OpenTelemetry Collector itself
nabeo
0
650
ヘンリーにおける可観測性獲得への取り組み
nabeo
2
2.4k
AWS CDK (TypeScript) を継続的にメンテ可能にするために取り入れているノウハウ集
nabeo
0
1.5k
AWS Organizations 組織を移動する時に 考えること 100 連発 (AWS Control Tower への組み込みを添えて) / Hatena Engineer Seminar #20
nabeo
2
3.6k
Other Decks in Technology
See All in Technology
作り直せるコードは迅速に 作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話
kinosuke01
0
280
薬剤師(ドメインエキスパート)と一緒に育てる薬局向けAIアシスタント
kakehashi
PRO
2
130
[DroidKaigi 2026] Making UI specifications visible: Android UI development in the AI agent era supported by Compose Screenshot Testing and galleries
syarihu
0
610
Bet AI Day 2026丨AIを「使う」から、AIが「働く」へ ― LayerXが進める「組織AI」の社会実装
layerx
PRO
3
2.9k
When Does a Local Qwen Start to Break
morshoto
0
190
Bet AI Day 2026丨バクラク Autopilot、業務システムの再設計
layerx
PRO
2
1.7k
プロダクトエンジニアに必要な「いい感じ」に作る能力 〜たくさん作れる時代に、どこまで作るかの決め方〜
jnishime_dresscode
2
1.4k
20260912_スクラムにジェネラリストは必要か
ryugen04
0
210
Omarchy Quattro の日本語設定周り
simosako
2
120
AIで仕事のやり方を変える
matsu7874
3
1k
Adaptive Warehouse を今すぐ導入すべき理由と迷ったときの判断基準
__allllllllez__
0
130
深夜のクラウド懺悔室 1:29:300 or 1:0:0
kazzpapa3
1
220
Featured
See All Featured
How to make the Groovebox
asonas
2
2.4k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
310
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.5k
Un-Boring Meetings
codingconduct
0
410
Designing Experiences People Love
moore
143
24k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.7k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
520
Building Flexible Design Systems
yeseniaperezcruz
330
41k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
310
Transcript
Copyright © Henry, Inc. All rights reserved. 株式会社ヘンリー SRE 渡辺
道和 (nabeo) Cloud Operator Days Tokyo 2025 クロージングイベント SRE 文化の醸成 stream-aligned チームに Enabling するために実施した事例の解説
Copyright © Henry, Inc. All rights reserved. 前説 このセッションでは「サービスの Realiability
はチームから! Enabling を通じて 実現する、信頼されるサービスづくり」で紹介された以下の事例についてさらに 掘り下げていきます • デプロイ計画会 • Honeycomb や Datadog などのオンボーディング • パフォーマンス分析会 2
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
Copyright © Henry, Inc. All rights reserved. デプロイ計画会 4
Copyright © Henry, Inc. All rights reserved. • ヘンリーでは通常のデプロイを毎週実施している ◦
hotfix など通常のデプロイを待つことができないデプロイはデプロイ計画会を待たずにアプ リケーションごとにデプロイを実施している • 次回のデプロイ対象を統合テスト環境にデプロイするタイミングでデプロイ 計画会を実施している ◦ 複数のアプリケーションを同時にデプロイすることで相互作用による不具合が紛れ込まない ようにする ◦ デプロイ計画会では開発チームと SRE チームの担当者がオンラインで集合して、変更内容の レビューなどを実施している • 本来は準備が整った内容から都度デプロイしたり、Feature Flags などでリ リースとデプロイを完全に分離したいが、以下のような事情で通常デプロイ はまとめて毎週実施している ◦ 統合テスト環境でのリグレッションテストの実施期間を確保する 5 デプロイ計画会
Copyright © Henry, Inc. All rights reserved. 1. デプロイするサービスの差分の確認 ◦
本番環境へのデプロイ用 P-R を GitHub Actions で生成する 2. デプロイ中にエラーが発生する変更がデプロイ内容に含まれていないかの確 認 ◦ DB のスキーママイグレーションでエラーになる内容はないか ◦ アプリケーションが使用している API で非互換な変更が含まれていないか ◦ GraphQL Schema に非互換な変更が含まれていないか 3. 統合テスト環境へのデプロイ ◦ 本番環境へのデプロイ用 P-R で発火する GitHub Actions のワークフローが統合テスト環境 のデプロイを実行している ◦ 統合テスト環境へのデプロイが成功することを確認する 4. (本番環境へのデプロイ当日) ◦ デプロイ計画会以降にデプロイ対象に追加された内容の確認 6 デプロイ計画会の進行と本番環境へのデプロイ
Copyright © Henry, Inc. All rights reserved. • 開発チームはデプロイ計画会への参加を当番制にしている ◦
デプロイ計画会での知見がチーム間で共有される ◦ リスクが高い変更への解像度が上がる • 誰でも司会者ができるようにする • デプロイフローの解像度が上がることで、開発チームによるデプロイフロー の改善に繋がる ◦ デプロイ計画会と本番環境デプロイが各1時間で各チームから1人以上参加するミーティング なのでコストは高い ▪ N人のメンバーが毎週2時間なので週のうち1人日近く消費される会議になっている ▪ デプロイ計画会が早く終わるような改善提案が開発チームから出てくる ◦ hotfix でも同様のデプロイフローなので、デプロイフローの高速化が障害発生時の解消時間 の短縮につながる ▪ 開発チームのメンバーによる DB マイグレーションの時間短縮 7 デプロイ計画会による変化: デプロイが全てのチームの自分ごとになる
Copyright © Henry, Inc. All rights reserved. 監視・モニタリングツール の Enabling
8
Copyright © Henry, Inc. All rights reserved. • ヘンリーでは複数の監視サービスを用途によって使い分けている ◦
メトリクス監視: Datadog ◦ 分散トレース: Honeycomb • 以下の理由から積極的に開発チームのエンジニアにもアカウントを払い出し ている ◦ ユーザ数課金ではない ◦ Datadog や Honeycomb には要配慮個人情報を保存していない • Honeycomb はメジャーなツールではなく、分散トレースというメトリクス やログとは異なる概念なので導入時に開発チーム向けの説明会を実施した ◦ 説明会の様子は Google Meet で録画しておき、後から参照できるようにしている • 後述のアプリケーション版のパフォーマンス分析会は Honeycomb の継続的 な enabling も兼ねている 9 監視・モニタリングツールのオンボーディング
Copyright © Henry, Inc. All rights reserved. • 自分以外のユーザが実行したクエリの履歴が見れる ◦
他の人のクエリを真似したり、ユースケースを知ることができる • Slack で URL を共有した時のメッセージにクエリの内容が確認できる 10 Honeycomb: オンボーディングで重宝している機能
Copyright © Henry, Inc. All rights reserved. • Datadog のダッシュボードで新機能の利用状況
を医療機関様ごとに確認できるようにして、利 用が芳しくない医療機関様にアプローチできる ようにした • 開発チームで実施する負荷テストや通常時の調 査などで Datadog や Honeycomb を確認する ようになった ◦ 2025年7月は Honeycomb で実行されたクエリの61% が開発チームだった 11 開発チームでの活用事例
Copyright © Henry, Inc. All rights reserved. パフォーマンス分析会 12
Copyright © Henry, Inc. All rights reserved. • アプリケーションの変更によるインフラ側の変化を中長期で俯瞰し、課題を 見つける
◦ SRE チームが主体で開催し、各チームから有志が参加している ◦ SRE チームだけではアプリケーションの変更内容の解像度が低い ▪ インフラ側の変化がアプリケーション側のどの変更か判別できない ▪ インフラ側の変化が一時的なものなのか、恒久的な変化なのかを判別できない 13 パフォーマンス分析会
Copyright © Henry, Inc. All rights reserved. • API エンドポイントごとのレイテンシや処理負荷、エラーの発生状況
• 医療機関様ごとのエラーの発生状況 • DB の Slow Query の発生状況 • Cloud Run や Cloud SQL のインフラ負荷 14 パフォーマンス分析会: 確認している内容
Copyright © Henry, Inc. All rights reserved. • SRE チームと開発チームの共通言語として
Datadog の指標を使うことでコ ミュニケーションがスムーズになる • パフォーマンス分析会はインフラ側に重点が置かれているのでアプリケー ション側でも同様の取り組みを始めている ◦ Honeycomb を使ったアプリケーション側の課題発見のためのアプリケーション版のパフォー マンス分析会を立ち上げている ◦ アプリケーション版パフォーマンス分析会では Honeycomb のダッシュボードを眺めるだけ でなく、開発者の気になっている箇所を Honeycomb でどのように調査すれば良いかという 知見共有の場としても活用している 15 パフォーマンス分析会の効果
Copyright © Henry, Inc. All rights reserved. • stream-aligned チーム
(≒ 開発チーム) が自律的に信頼性向上に取り組める ように enabling する施策の具体について紹介しました ◦ 誰でも使える状態にしつつ伴走しつつ、開発チームに自分ごととして捉えてもらえるように することが必要 • すぐに実現できることではないので長い目で調整しつつ進めることが必要 16 まとめ:
Copyright © Henry, Inc. All rights reserved. 17 ヘンリーブースでもっと話しましょう!! 採用情報
募集中の採用ポジションや募集要項などがご確認いた だけます。 オープンポジションのカジュアル面談も募集していま すので、お気軽にお申し込みください。 技術ブログ ヘンリー製品開発チームが運営する技術ブログです。