サービスのReliabilityはチームから！Enablingを通じて実現する、信頼されるサービスづくり / Cloud Operator Days Tokyo 2025

Cloud Operator Days Tokyo 2025オンデマンドセッションで利用したスライドです。
https://cloudopsdays.com/ondemand/

Transcript

1. Copyright © Henry, Inc. All rights reserved. 株式会社ヘンリー SRE & VP of Engineering Kengo TODA Cloud Operator Days Tokyo 2025 サービスのReliabilityはチームから！ Enablingを通じて実現する、 信頼されるサービスづくり
2. Copyright © Henry, Inc. All rights reserved. 可用性あるサービスは、信頼性あるサービスだと言えるか？ 2 Platform SREとして信頼性（reliability）を追い求めています
3. Copyright © Henry, Inc. All rights reserved. 3 突然ですが、弊社のサービス、可用性高いです！ https://mangasozai.com/archives/1176
4. Copyright © Henry, Inc. All rights reserved. 4 完
 弊社の信頼されるサービスづくり
5. Copyright © Henry, Inc. All rights reserved. 5 完
 弊社の信頼されるサービスづくり とはならない……
6. Copyright © Henry, Inc. All rights reserved. 6 信頼性（reliability）の観点からは、可用性は基礎にすぎない 可用性、高性能 サービスとしてのあたりまえ 機能 サービスの存在意義 信頼 継続的な満足
7. Copyright © Henry, Inc. All rights reserved. 7 本日の主張 ユーザの期待を持続的に満たすことが信頼に繋がる ユーザが期待する振る舞いを 持続的に満たせているかどうか 非機能系 （安定稼働） Four keysや設計など 組織・サービス横断 アプローチ 機能系 （User Journeyを満たせるか） 運用による ユーザによる
8. Copyright © Henry, Inc. All rights reserved. 8 本日の主張 ユーザの期待を持続的に満たすことが信頼に繋がる ユーザが期待する振る舞いを 持続的に満たせているかどうか 非機能系 （安定稼働） Four keysなど 組織・サービス横断 アプローチ 機能系 （User Journeyを満たせるか） 機能による ユーザによる 業務用システム
 として期待される振 る舞い
 
 Platform SREで対 処も容易
 「業務が回るか」どうか
 
 Platform SREだけでの
 対処は難しい
 → 他チームの巻き込みが必要
 今日のフォーカスはここ！
9. Copyright © Henry, Inc. All rights reserved. ゲームを自作するためにプログラミングを学び、それが面白かったのでそのまま 飯の種にした系ITエンジニア。国産基幹システム開発会社で研究から企画、保守 まで幅広く担当。趣味では開発ツール関係のOSS活動を続けている。 2022年、医療機関向けのクラウドネイティブな基幹システムを開発する 株式会社ヘンリーにひとりめのPlatform SREとしてジョイン。運用を通じて、 医療DXならびにそのサイバーセキュリティ対策に貢献している。 2025年よりVP of Technologyとして体外的なサービスにまつわる 技術情報の発信に、VP of Engineeringとしてエンジニアリング 組織づくりに携わっている。 9 自己紹介
10. Copyright © Henry, Inc. All rights reserved. 1. 「業務が回る」とは 2. 「業務想定」はどこだ！ 3. 事例紹介 4. まとめ 10 アジェンダ
11. Copyright © Henry, Inc. All rights reserved. 「業務が回る」 とは 信頼性の獲得には、サービスを使っ た業務が継続的に回ることが不可 欠。 では「業務が回る」とは具体的には 何を指しているのか？ 11
12. Copyright © Henry, Inc. All rights reserved. 医療機関向けシステムの開発において「業務が回る」とは？外来診療ができる？ 12 たとえば医療機関向けシステムの場合 処方箋が出せる カルテが 読み書きできる 1割負担も3割負担も 計算できる ヤバそうな処方に 警告してくれる 会計ができる ご家族の連絡先が わかる とにかく安全！
13. Copyright © Henry, Inc. All rights reserved. 外来と入院だけでなく、経営や制度改正への対応など多様な業務がある 13 掘れば掘るほど業務が出てくる 処方箋が出せる カルテが 読み書きできる 1割負担も3割負担も 計算できる ヤバそうな処方に 警告してくれる 会計ができる ご家族の連絡先が わかる 未収金管理が できる 2年に1度の制度 改正を混乱なく 乗り越えられる 部門システムと 連携できる 厚生労働省が出す マスターを即座に 取り込める 国の要求に 合理的な負担で 対応できる 薬と食物の アレルギーが わかる とにかく安全！ シフトが急に 変わっても 運用が回る ラウンドに必要な 情報がひとめで わかる 夜勤と日勤の 引き継ぎが スムーズになる 提出を求められる 資料がサクッと 出せる 土日だけの スポットバイトの ユーザや権限を 院長が つかまえられる とにかくこの 赤字をなんとか してくれ！
14. Copyright © Henry, Inc. All rights reserved. 1. レスポンスの99%ileがステータスコード500系ではない 2. レスポンスレイテンシーの99%ileが1秒以内に収まっている 14 「業務が回ってる」状態をSLOとして定義できるか？
15. Copyright © Henry, Inc. All rights reserved. 1. レスポンスの99%ileがステータスコード500系ではない →あるはずのマスターデータが存在しない（404）場合は？ →GraphQLだとそもそも全部200なんですが？ →印刷など、HTTP関係ない操作は？ 2. レスポンスレイテンシーの99%ileが1秒以内に収まっている →ファイル生成処理も1秒以内必須？WebSocketは？ →すべての業務で1秒も待ってもらえるんだっけ？ 15 定義できるかもしれないが、一筋縄ではいかない……
16. Copyright © Henry, Inc. All rights reserved. 1. レスポンスの99%ileがステータスコード500系ではない →あるはずのマスターデータが存在しない（404）場合は？ →GraphQLだとそもそも全部200なんですが？ →印刷など、HTTP関係ない操作は？ 2. レスポンスレイテンシーの99%ileが1秒以内に収まっている →バッチ処理も1秒以内必須？WebSocketは？ →すべての業務で1秒も待ってもらえるんだっけ？ 16 定義できるかもしれないが、一筋縄ではいかない…… つまり…… 業務想定による
17. Copyright © Henry, Inc. All rights reserved. 「業務想定」は どこだ！ 業務が回っていることを継続的に確 認するためには、業務想定への理解 が必要そう。 では業務想定ってどこの誰が持って いるのだろうか？ 17
18. Copyright © Henry, Inc. All rights reserved. Team Topologiesにおいては、stream-alignedチームが顧客に価値を届け、サー ビスとしてのアウトカムに責任を保ちます。stream-alignedチームはドメインに 対する理解を持ち、顧客の業務想定にもとづいたデザインや実装を行います。 18 業務想定はstream-alignedチームが持っている https://teamtopologies.com/key-concepts
19. Copyright © Henry, Inc. All rights reserved. 19 Platform SREは業務想定をすべて把握することは難しい 弊社では次の理由から、SREで業務想定を持つことは難しいと考えました。 • 複数のstream-alignedチームが変更を毎週デプロイしている • 少なくとも2年に1回の頻度で業務のルールが変わる • 「レセプトコンピュータ」「オーダー」といった構成要素は理解しても、 その詳細や、どう組み合わせてどう業務を回しているかまでは難しい
20. Copyright © Henry, Inc. All rights reserved. デプロイをPlatform SREの許可制にすることには利点と欠点がある。全ての変更 をレビューするのは現実的ではなさそう。 • 利点 ◦ stream-alignedチームでは漏れがちな観点を補える ◦ 明らかな欠陥を抱えたサービスや機能が出ていくことを防げる • 欠点 ◦ Platform SREがボトルネックになる ◦ パフォーマンスが落ちる（State of DevOps 2019 “Heavyweight change process” 参照） 20 ひらめいた！デプロイをSREの許可制にすればいいんじゃね！？
21. Copyright © Henry, Inc. All rights reserved. 21 デプロイをPlatform SREの許可制にすることには利点と欠点がある。全ての変更 をレビューするのは現実的ではなさそう。 • 利点 ◦ stream-alignedチームでは漏れがちな観点を補える ◦ 明らかな欠陥を抱えたサービスや機能が出ていくことを防げる • 欠点 ◦ Platform SREがボトルネックになる ◦ パフォーマンスが落ちる（State of DevOps 2019 “Heavyweight change process” 参照） おいしいところだけ欲しい Platform SREがボトルネックにならず、 stream-alignedチームで漏れがちな観点を補えて、 業務想定にもとづく信頼性向上ができる方法がほしい
22. Copyright © Henry, Inc. All rights reserved. デプロイをPlatform SREの許可制にすることには利点と欠点がある。全ての変更 をレビューするのは現実的ではなさそう。 • 利点 ◦ stream-alignedチームでは漏れがちな観点を補える ◦ 明らかな欠陥を抱えたサービスや機能が出ていくことを防げる • 欠点 ◦ Platform SREがボトルネックになる ◦ パフォーマンスが落ちる（State of DevOps 2019 “Heavyweight change process” 参照） ◦ 22 Enablingでstream-alignedが信頼性を向上できるようにする Platform SREがボトルネックにならず、 stream-alignedチームで漏れがちな観点を補えて、 業務想定にもとづく信頼性向上ができる方法がほしい 業務想定を持つ stream-alignedチームが SREの助けを得ながら 信頼性向上の施策を行う
23. Copyright © Henry, Inc. All rights reserved. 事例紹介 業務想定を持つstream-aligned チームをどう助けたら信頼性向上の 施策が行えるようになるのか？ このenablingのために実施した事例 をいくつか紹介します。 23
24. Copyright © Henry, Inc. All rights reserved. 課題 Sentryを導入したが重要な issueとそうでないissueの区別をつ けることが難しく、SREから stream-alignedチームに確認依頼を 持って行く形になっていた。 コードの持ち主が不明瞭でSentryの auto assign機能が使えず、誰にもア サインされないissueが多数あった。 24 事例① Sentry Issues棚卸し 施策 各チームでSentry棚卸しの機会 を継続的に持ってもらうようにし た。Slackに通知されるissueもオー ナーシップを持って対応してもらう ようにした。 またauto assignが使えるように、地 道な調査と設定をした。将来的には GitHubのcode owner機能との連携 を用いて根本解決を図りたいと考え ている。
25. Copyright © Henry, Inc. All rights reserved. 評価 Issue棚卸しがstream-aligned チームであたりまえに行われるよう になった。定期的にチームで開催さ れ、内容がSlackで共有されるため、 ひろく開発の状況を知らせる一助と なっている。 また全開発チームがSentryを使って おり、Issueの再アサインをチーム間 コミュニケーションとして使えてい る。対応のヌケモレがなくなり、生 産性にも寄与している。 25 Sentry Issues棚卸しをやって嬉しかったこと
26. Copyright © Henry, Inc. All rights reserved. 課題 サービスはモジュラモノリスに なろうとしている過程にある。まだ APIやモジュールをチームごとに切れ ていない。 ちいさな変更でも他のモジュールに 影響を与えてしまうことがあり、コ ンパイルやモジュール単位のテスト で気付けないこともあった。 26 事例② デプロイ計画会 施策 デプロイする変更をリグレッ ションテスト用環境に反映する際 に、全チームで膝つき合わせて変更 内容を確認し評価する。デプロイ前 後のオペレーションについて認識を 合わせ、危険な変更が含まれないこ とを確認する。 stream-alignedチームによる自律の 観点からは好ましくなく、モジュラ モノリス化を完了した暁にはなくし たい施策だが、現時点では非常に重 要な働きをしている。
27. Copyright © Henry, Inc. All rights reserved. 評価 SREや他チームのエンジニアが リスクを発見できることもある。す べてのチームが主体的に関わりリス ク対応を進めるきっかけとして多く の実績を残してきた。 計画会には数名だけが参加している が、そこからリアルタイムに他メン バーを巻き込んで即対応している。 基本的には少ない工数で回し、有事 には集まって短時間で解決する”サー バーレス的”なアプローチであり、維 持コストも払いやすい。 27 デプロイ計画会をやって嬉しかったこと
28. Copyright © Henry, Inc. All rights reserved. 課題 DatadogやHoneycombなどの オブザーバビリティ基盤は、導入だ けではなくその運用も重要である。 特に新しい基盤を導入する際は既存 のものと思想が異なるため、普段の 延長で使うと失敗しやすい。 28 事例③ HoneycombやDatadogなどのオンボーディング 施策 基本的な思想や操作についてオ ンボーディングを行う。オンボー ディングはGoogle Meetで実施し、 録画を今後の新入社員でも見られる ようにする。 たとえばHoneycombはspanとTrace を組み合わせて検索・分析できると いう思想がユニークである。spanに 属性を入れるとこんなに嬉しいこと がある、というのを実業務でたとえ て紹介する。
29. Copyright © Henry, Inc. All rights reserved. 評価 もともと技術勉強会が好きな会 社ではあるが、これらのオンボー ディングは特に反応が良かった。 とくにHoneycombは一度使うと手放 せなくなるエンジニアが多かった。 ログではなくスパンの属性に情報を 入れることで、分析がやりやすくな り、課題解決を加速させられた。 導入から1年経ち、SREチームと stream-alignedチームでこれらの画 面を囲むのが普通になっている。 29 HoneycombやDatadogなどのオンボーディングをやって嬉しかったこと
30. Copyright © Henry, Inc. All rights reserved. 30 課題 新しく発生した課題は既存の監 視では発見できないことが多い。 また新しい機能やテナントに関する メトリックはstream-alignedチーム に主体的に動いてもらわなければ、 課題を認知できない・原因を特定で きない可能性が高い。 事例④ パフォーマンス分析会 施策 隔週でパフォーマンス分析会を 実施、全チームの有志で集まって ダッシュボードを囲み、運用ごと・ テナントごと・APIごとのメトリック を眺めるなどしてパフォーマンスな どの変化を確認する。 DBの索引漏れやデータ量による性能 変化など、開発中に気付けなかった 潜在的な課題を発見することも多 い。また普段の状態について共通理 解を作り、アーキテクチャ改善や チーム分割の下敷きにする。
31. Copyright © Henry, Inc. All rights reserved. 31 評価 分析会由来の高速化施 策がほぼ毎月デプロイされ た。SREでのリソース最適化 施策も隔月程度で出ている。 「なぜこのスロークエリが急 に出てきたんだ？」「今月の 新しいお客様、アクセス多い ね！」といった発見もあり、 チーム間の話題づくりにも有 効。 パフォーマンス分析会をやって嬉しかったこと https://dev.henry.jp/entry/2025/performance-analysis-meeting-introduction-for-mid-to-long-term-service-monitoring
32. Copyright © Henry, Inc. All rights reserved. 新規機能をリリースする際に、現地 でお客様とコミュニケーションをす るエンジニアとリモートでメトリク スを見ながら使われ方を確認するエ ンジニアとに分かれて仮説検証を 行った。Platform SRE関与なし！ 想定よりよく使われたAPI、想定ほど 使われなかったAPI、体験改善のため にレイテンシの見直しが必要そうな 機能、などをヒストグラムやヒート マップを使って洗い出した。 現地に行けなかった社員も現場と協 働し、リモートの人が盛り上がりや 使われ方を感じられる。ユーザの息 遣いを感じられる貴重な機会。 32 これらのenabling事例を踏まえた、stream-alignedチームの現在地
33. Copyright © Henry, Inc. All rights reserved. まとめ 信頼性向上施策が行われる組織を作 るために、業務想定を持つ stream-alignedエンジニアを enablingする方法を事例を通じて 見てきました。 33
34. Copyright © Henry, Inc. All rights reserved. SREから道具やプラットフォームを提供 するだけではなく、どのように課題解決 へ繋げるか共にドメインに向き合い考え てきました。 SREがstream-alignedチームと机を並べ て仕事をすることでenablingが促進さ れ、stream-alignedチームが顧客の息遣 いを感じられるようになりました。 まずPlatform SREがやれるようになる ことは大切ですが、enablingを行うこと もまた重要だと確認できました。 34 信頼性を実現するうえで、enablingは有効だし、とても大切です リリース 仮説検証 現状理解 改善 顧客 stream aligned Enabling
35. Copyright © Henry, Inc. All rights reserved. 会社ブログ 採用サイト Thank you 技術ブログ Podcast 35