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

by Henry Inc.

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © Henry, Inc. All rights reserved. 8 本日の主張ユーザの期待を持続的に満たすことが信頼に繋がるユーザが期待する振る舞いを持続的に満たせているかどうか非機能系（安定稼働） Four keysなど組織・サービス横断アプローチ機能系（User Journeyを満たせるか）機能によるユーザによる業務用システム  として期待される振る舞い    Platform SREで対処も容易  「業務が回るか」どうか    Platform SREだけでの  対処は難しい  → 他チームの巻き込みが必要  今日のフォーカスはここ！

Slide 9

Slide 9 text

Copyright © Henry, Inc. All rights reserved. ゲームを自作するためにプログラミングを学び、それが面白かったのでそのまま飯の種にした系ITエンジニア。国産基幹システム開発会社で研究から企画、保守まで幅広く担当。趣味では開発ツール関係のOSS活動を続けている。 2022年、医療機関向けのクラウドネイティブな基幹システムを開発する株式会社ヘンリーにひとりめのPlatform SREとしてジョイン。運用を通じて、医療DXならびにそのサイバーセキュリティ対策に貢献している。 2025年よりVP of Technologyとして体外的なサービスにまつわる技術情報の発信に、VP of Engineeringとしてエンジニアリング組織づくりに携わっている。 9 自己紹介

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © Henry, Inc. All rights reserved. 外来と入院だけでなく、経営や制度改正への対応など多様な業務がある 13 掘れば掘るほど業務が出てくる処方箋が出せるカルテが読み書きできる 1割負担も3割負担も計算できるヤバそうな処方に警告してくれる会計ができるご家族の連絡先がわかる未収金管理ができる 2年に1度の制度改正を混乱なく乗り越えられる部門システムと連携できる厚生労働省が出すマスターを即座に取り込める国の要求に合理的な負担で対応できる薬と食物のアレルギーがわかるとにかく安全！シフトが急に変わっても運用が回るラウンドに必要な情報がひとめでわかる夜勤と日勤の引き継ぎがスムーズになる提出を求められる資料がサクッと出せる土日だけのスポットバイトのユーザや権限を院長がつかまえられるとにかくこの赤字をなんとかしてくれ！

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright © Henry, Inc. All rights reserved. 1. レスポンスの99%ileがステータスコード500系ではない →あるはずのマスターデータが存在しない（404）場合は？ →GraphQLだとそもそも全部200なんですが？ →印刷など、HTTP関係ない操作は？ 2. レスポンスレイテンシーの99%ileが1秒以内に収まっている →ファイル生成処理も1秒以内必須？WebSocketは？ →すべての業務で1秒も待ってもらえるんだっけ？ 15 定義できるかもしれないが、一筋縄ではいかない……

Slide 16

Slide 16 text

Copyright © Henry, Inc. All rights reserved. 1. レスポンスの99%ileがステータスコード500系ではない →あるはずのマスターデータが存在しない（404）場合は？ →GraphQLだとそもそも全部200なんですが？ →印刷など、HTTP関係ない操作は？ 2. レスポンスレイテンシーの99%ileが1秒以内に収まっている →バッチ処理も1秒以内必須？WebSocketは？ →すべての業務で1秒も待ってもらえるんだっけ？ 16 定義できるかもしれないが、一筋縄ではいかない…… つまり…… 業務想定による

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright © Henry, Inc. All rights reserved. Team Topologiesにおいては、stream-alignedチームが顧客に価値を届け、サービスとしてのアウトカムに責任を保ちます。stream-alignedチームはドメインに対する理解を持ち、顧客の業務想定にもとづいたデザインや実装を行います。 18 業務想定はstream-alignedチームが持っている https://teamtopologies.com/key-concepts

Slide 19

Slide 19 text

Copyright © Henry, Inc. All rights reserved. 19 Platform SREは業務想定をすべて把握することは難しい弊社では次の理由から、SREで業務想定を持つことは難しいと考えました。 ● 複数のstream-alignedチームが変更を毎週デプロイしている ● 少なくとも2年に1回の頻度で業務のルールが変わる ● 「レセプトコンピュータ」「オーダー」といった構成要素は理解しても、その詳細や、どう組み合わせてどう業務を回しているかまでは難しい

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © Henry, Inc. All rights reserved. 21 デプロイをPlatform SREの許可制にすることには利点と欠点がある。全ての変更をレビューするのは現実的ではなさそう。 ● 利点 ○ stream-alignedチームでは漏れがちな観点を補える ○ 明らかな欠陥を抱えたサービスや機能が出ていくことを防げる ● 欠点 ○ Platform SREがボトルネックになる ○ パフォーマンスが落ちる（State of DevOps 2019 “Heavyweight change process” 参照）おいしいところだけ欲しい Platform SREがボトルネックにならず、 stream-alignedチームで漏れがちな観点を補えて、業務想定にもとづく信頼性向上ができる方法がほしい

Slide 22

Slide 22 text

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の助けを得ながら信頼性向上の施策を行う

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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機能との連携を用いて根本解決を図りたいと考えている。

Slide 25

Slide 25 text

Copyright © Henry, Inc. All rights reserved. 評価 Issue棚卸しがstream-aligned チームであたりまえに行われるようになった。定期的にチームで開催され、内容がSlackで共有されるため、ひろく開発の状況を知らせる一助となっている。また全開発チームがSentryを使っており、Issueの再アサインをチーム間コミュニケーションとして使えている。対応のヌケモレがなくなり、生産性にも寄与している。 25 Sentry Issues棚卸しをやって嬉しかったこと

Slide 26

Slide 26 text

Copyright © Henry, Inc. All rights reserved. 課題サービスはモジュラモノリスになろうとしている過程にある。まだ APIやモジュールをチームごとに切れていない。ちいさな変更でも他のモジュールに影響を与えてしまうことがあり、コンパイルやモジュール単位のテストで気付けないこともあった。 26 事例② デプロイ計画会施策デプロイする変更をリグレッションテスト用環境に反映する際に、全チームで膝つき合わせて変更内容を確認し評価する。デプロイ前後のオペレーションについて認識を合わせ、危険な変更が含まれないことを確認する。 stream-alignedチームによる自律の観点からは好ましくなく、モジュラモノリス化を完了した暁にはなくしたい施策だが、現時点では非常に重要な働きをしている。

Slide 27

Slide 27 text

Copyright © Henry, Inc. All rights reserved. 評価 SREや他チームのエンジニアがリスクを発見できることもある。すべてのチームが主体的に関わりリスク対応を進めるきっかけとして多くの実績を残してきた。計画会には数名だけが参加しているが、そこからリアルタイムに他メンバーを巻き込んで即対応している。基本的には少ない工数で回し、有事には集まって短時間で解決する”サーバーレス的”なアプローチであり、維持コストも払いやすい。 27 デプロイ計画会をやって嬉しかったこと

Slide 28

Slide 28 text

Copyright © Henry, Inc. All rights reserved. 課題 DatadogやHoneycombなどのオブザーバビリティ基盤は、導入だけではなくその運用も重要である。特に新しい基盤を導入する際は既存のものと思想が異なるため、普段の延長で使うと失敗しやすい。 28 事例③ HoneycombやDatadogなどのオンボーディング施策基本的な思想や操作についてオンボーディングを行う。オンボーディングはGoogle Meetで実施し、録画を今後の新入社員でも見られるようにする。たとえばHoneycombはspanとTrace を組み合わせて検索・分析できるという思想がユニークである。spanに属性を入れるとこんなに嬉しいことがある、というのを実業務でたとえて紹介する。

Slide 29

Slide 29 text

Copyright © Henry, Inc. All rights reserved. 評価もともと技術勉強会が好きな会社ではあるが、これらのオンボーディングは特に反応が良かった。とくにHoneycombは一度使うと手放せなくなるエンジニアが多かった。ログではなくスパンの属性に情報を入れることで、分析がやりやすくなり、課題解決を加速させられた。導入から1年経ち、SREチームと stream-alignedチームでこれらの画面を囲むのが普通になっている。 29 HoneycombやDatadogなどのオンボーディングをやって嬉しかったこと

Slide 30

Slide 30 text

Copyright © Henry, Inc. All rights reserved. 30 課題新しく発生した課題は既存の監視では発見できないことが多い。また新しい機能やテナントに関するメトリックはstream-alignedチームに主体的に動いてもらわなければ、課題を認知できない・原因を特定できない可能性が高い。事例④ パフォーマンス分析会施策隔週でパフォーマンス分析会を実施、全チームの有志で集まってダッシュボードを囲み、運用ごと・テナントごと・APIごとのメトリックを眺めるなどしてパフォーマンスなどの変化を確認する。 DBの索引漏れやデータ量による性能変化など、開発中に気付けなかった潜在的な課題を発見することも多い。また普段の状態について共通理解を作り、アーキテクチャ改善やチーム分割の下敷きにする。

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Copyright © Henry, Inc. All rights reserved. 新規機能をリリースする際に、現地でお客様とコミュニケーションをするエンジニアとリモートでメトリクスを見ながら使われ方を確認するエンジニアとに分かれて仮説検証を行った。Platform SRE関与なし！想定よりよく使われたAPI、想定ほど使われなかったAPI、体験改善のためにレイテンシの見直しが必要そうな機能、などをヒストグラムやヒートマップを使って洗い出した。現地に行けなかった社員も現場と協働し、リモートの人が盛り上がりや使われ方を感じられる。ユーザの息遣いを感じられる貴重な機会。 32 これらのenabling事例を踏まえた、stream-alignedチームの現在地

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright © Henry, Inc. All rights reserved. SREから道具やプラットフォームを提供するだけではなく、どのように課題解決へ繋げるか共にドメインに向き合い考えてきました。 SREがstream-alignedチームと机を並べて仕事をすることでenablingが促進され、stream-alignedチームが顧客の息遣いを感じられるようになりました。まずPlatform SREがやれるようになることは大切ですが、enablingを行うこともまた重要だと確認できました。 34 信頼性を実現するうえで、enablingは有効だし、とても大切ですリリース仮説検証現状理解改善顧客 stream aligned Enabling