Google に学ぶ、安全性を高める信頼性設計 / Reliability Design for Enhanced Safety: Lessons from Google SRE

@AoToLog_ #安全性向上セミナー 25th Feb, JASA 安全性向上セミナー in 2025 Speaker: Kento
Kimura(Datadog Japan) Google に学ぶ、安全性を高める信頼性設計〜Google SRE はなぜ STAMP/STPA をシステム開発運用に取り入れたのか？〜

@AoToLog_ #安全性向上セミナー自己紹介 • 所属： Technical Solutions / Sales Engineering
• 担当：パブリッククラウドのアーキテクト知識を活かした　 Datadog の導入技術支援 • 登壇： IT/クラウド技術系カンファレンス・イベント「CloudNative Days Summer 2025」「Google Cloud Next Tokyo 2025」「Observability Conference Tokyo 2025」 • コミュニティ： • 専門領域：クラウド・仮想化・ネットワーク・監視・コンテナ・サーバレス・アプリケーション開発木村健人 (Kento Kimura) Datadog Japan GK

@AoToLog_ #安全性向上セミナー 01 Google が提供するソフトウェアサービス 04 Google SRE が注目した STAMP/STPA
03 SRE のプラクティスと構造的不足点 02 Google が提唱する SRE 05 まとめお話しすること

@AoToLog_ #安全性向上セミナー Google が提供するソフトウェアサービス

@AoToLog_ #安全性向上セミナー Google の提供するサービス Google は2026年現在、数多くのソフトウェアサービスを提供する企業 • 世界中で数十億人のユーザーが常に利用するサービス •
過去25年間で提供するサービスの爆発的な成長 • 規模が拡大してもシステム障害を減らす必要がある

@AoToLog_ #安全性向上セミナーシステム規模の拡大とシステムの複雑性サービスとユーザーの増加 = 規模の拡大は、それを支えるシステムの複雑さを指数関数的に増大させる入力出力システム
! ! !

@AoToLog_ #安全性向上セミナーシステム規模の拡大とシステムの複雑性サービスとユーザーの増加 = 規模の拡大は、それを支えるシステムの複雑さを指数関数的に増大させる？？？
？

@AoToLog_ #安全性向上セミナーソフトウェアを中心としたアプローチ大規模システムを開発するソフトウェアエンジニアに、運用チームの設計を依頼するアプローチ

@AoToLog_ #安全性向上セミナーソフトウェアを中心としたアプローチ大規模システムを開発するソフトウェアエンジニアに、運用チームの設計を依頼するアプローチ 1. 複雑なモノを作るアプローチを守るアプローチに導入 2. 人的リソースの投入から自動化への転換 3.
障害対応からサービスの信頼性に責任を負う 4. 運用で得られた改善点を素早く開発に活かす

@AoToLog_ #安全性向上セミナーソフトウェアを中心としたアプローチ大規模システムを開発するソフトウェアエンジニアに、運用チームの設計を依頼するアプローチ 1. 複雑なモノを作るアプローチを守るアプローチに導入 2. 人的リソースの投入から自動化への転換 3.
障害対応からサービスの信頼性に責任を負う 4. 運用で得られた改善点を素早く開発に活かす IT システムに携わる組織的な開発と運用(作る人と守る人)の分断を、ソフトウェアエンジニアリングで調和するアプローチ

@AoToLog_ #安全性向上セミナー Google が提唱する SRE(Site Reliability Engineering)

@AoToLog_ #安全性向上セミナー SRE(Site Reliability Engineering) とは日本語で… 「サイト信頼性エンジニアリング」
IT システムに携わる組織的な開発と運用(作る人と守る人)の分断を、ソフトウェアエンジニアリングで調和するアプローチ

IT システムに携わる組織的な開発と運用(作る人と守る人)の分断を、ソフトウェアエンジニアリングで調和するアプローチオンラインで本番環境のユーザーが実際に使うサービス・プロダクト

IT システムに携わる組織的な開発と運用(作る人と守る人)の分断を、ソフトウェアエンジニアリングで調和するアプローチオンラインで本番環境のユーザーが実際に使うサービス・プロダクトユーザーの期待通りにサービスが動き続ける

IT システムに携わる組織的な開発と運用(作る人と守る人)の分断を、ソフトウェアエンジニアリングで調和するアプローチオンラインで本番環境のユーザーが実際に使うサービス・プロダクトユーザーの期待通りにサービスが動き続ける科学や数学の知見による実践的な技術と仕組み

@AoToLog_ #安全性向上セミナー SRE の信頼性階層信頼性階層とは？システムの信頼性を担保する、実践的なアプローチの階層階層の基礎的な部分から、より高度なアプローチへそれぞれのアプローチで、
エンジニアリングの手法を用いて定量的に信頼性を測る製品・UX 開発キャパシティ計画テスト・製品リリース事後検証・根本原因分析インシデント対応監視・オブザーバビリティ

@AoToLog_ #安全性向上セミナーオブザーバビリティとはオブザーバビリティとは、外部シグナルからシステムの内部状態を推測できる能力システム？外部シグナルシステムの内部状態
入力出力 “ “

@AoToLog_ #安全性向上セミナーオブザーバビリティとは入力出力システム計装転送バックエンド保存・
可視化オブザーバビリティとは、つまり… システムの外側から何が起こっているかを知れる “ “

@AoToLog_ #安全性向上セミナーとは入力出力システム計装転送バックエンド保存・
可視化 Datadog = オブザーバビリティのソフトウェアサービスシステムに実装し・監視データを収集・可視化するサービス “ “

@AoToLog_ #安全性向上セミナー可視化から定量的な信頼性の評価標準的なツール SLO(Service Level Objective) = サービスレベル目標：数値化された信頼性の目標値
Error Budget = エラー予算：許容できるエラーの発生数 Postmortems = 事後検証：障害発生後の事後分析

Error Budget = エラー予算：許容できるエラーの発生数 Postmortems = 事後検証：障害発生後の事後分析方法論とアプローチ帰納的推論：過去の経験からパターンを学習依存関係分析：依存関係の管理とシステムの分離自動化の推進：手作業を減らし、コードで解決

Error Budget = エラー予算：許容できるエラーの発生数 Postmortems = 事後検証：障害発生後の事後分析方法論とアプローチ帰納的推論：過去の経験からパターンを学習依存関係分析：依存関係の管理とシステムの分離自動化の推進：手作業を減らし、コードで解決人命に関わらないからこそ、実験的な取り組みを推進できる

@AoToLog_ #安全性向上セミナー SRE のプラクティスと構造的不足点

@AoToLog_ #安全性向上セミナー ①大規模サービスの責務

@AoToLog_ #安全性向上セミナー ①大規模サービスの責務単なるサービス提供企業でなく、社会的な生活基盤としての責務を負う必要が発生する例えば… • Google Map
が利用できず、救急車が現場に到着できない • Android 端末の脆弱性で、国家的な機密情報が漏洩する • Google Cloud の障害で、医療サービスが提供できない

@AoToLog_ #安全性向上セミナー ①大規模サービスの責務単なるサービス提供企業でなく、社会的な生活基盤としての責務を負う必要が発生する例えば… • Google Map
が利用できず、救急車が現場に到着できない • Android 端末の脆弱性で、国家的な機密情報が漏洩する • Google Cloud の障害で、医療サービスが提供できない人命に関わるほどの責務を SRE の方法論では賄えない

@AoToLog_ #安全性向上セミナー ②実践的な手法の形式知不足理論で形式化されたものではなく、プラクティスの集合体である SRE 経験則からの暗黙知 ex) サービスレベル目標の決め方

@AoToLog_ #安全性向上セミナー ②実践的な手法の形式知不足理論で形式化されたものではなく、プラクティスの集合体である SRE SRE のプラクティスを適用する根拠として、 STAMP/STPA の理論を取り入れる経験則からの暗黙知
ex) サービスレベル目標の決め方理論による形式知 ex) STAMP/STPA による安全制約 SRE への STAMP/STPA の適用

@AoToLog_ #安全性向上セミナー ②実践的な手法の形式知不足 • サービスレベル目標の定め方の根拠を安全制約で説明できる • 障害発生後の分析だけではなく、障害発生前の再設計を促す • 安全でない制御アクション(UCA)を考慮したキャパシティプランニング経験則からの暗黙知
ex) サービスレベル目標の決め方理論による形式知 ex) STAMP/STPA による安全制約 SRE への STAMP/STPA の適用

@AoToLog_ #安全性向上セミナーシステムの信頼性 ≒ 利用者の安全性 SRE の文脈で使われる用語を STAMP/STPA へ当てはめると…

@AoToLog_ #安全性向上セミナーシステムの信頼性 ≒ 利用者の安全性 SRE の文脈で使われる用語を STAMP/STPA へ当てはめると… インシデント：
ユーザー体験に影響を及ぼすシステムの障害・事故事故(アクシデント): 望まれない・計画されていないイベントで損失に至るものサービスレベルの低下：定義したサービス品質(可用性やパフォーマンス)を損なう状態ハザード: 最悪の環境下でアクシデントに至るシステムの状態 - UCA(安全でない制御アクション): ハザードを引き起こす条件、安全な制御アクション以外根本原因：事後分析で発見する、システム障害の原因となった過去の原因 HCF(ハザード要因): ハザードが引き起こされる要因(事前/事後的な分析) - 安全制約: ハザードを防止するために必要となるルール

@AoToLog_ #安全性向上セミナーシステムの信頼性 ≒ 利用者の安全性 SRE の文脈で使われる用語を STAMP/STPA へ当てはめると… インシデント：
ユーザー体験に影響を及ぼすシステムの障害・事故事故(アクシデント): 望まれない・計画されていないイベントで損失に至るものサービスレベルの低下：定義したサービス品質(可用性やパフォーマンス)を損なう状態ハザード: 最悪の環境下でアクシデントに至るシステムの状態アラートの根拠：監視要件として定義する数値の根拠 UCA(安全でない制御アクション): ハザードを引き起こす条件、安全な制御アクション以外根本原因：事後分析で発見する、システム障害の原因となった過去の原因 HCF(ハザード要因): ハザードが引き起こされる要因(事前/事後的な分析) サービスレベル目標の根拠：信頼性として定義する数値の根拠安全制約: ハザードを防止するために必要となるルール

@AoToLog_ #安全性向上セミナー Google SRE が注目した STAMP/STPA

@AoToLog_ #安全性向上セミナー STAMP のおさらいシステムを「コントローラー」と「非コントロールプロセス」の相互作用に着目し、アクシデントの発生を説明した事故モデル現代の複雑化したシステムの障害・事故原因を説明するための
理論化モデルコントローラーアルゴリズムプロセスモデル被コントロールプロセスコントロールアクションフィードバックデータ

@AoToLog_ #安全性向上セミナー Google SRE の直面した事例システムの目的： Google の大規模システムが、利用者に応じて最適なリソースを割り当てシステムの構造：
サービスがリソース上限(クォータ)を使い切っていない場合、上限値を削減し効率的にリソースを活用最適リソース維持機能アルゴリズムプロセスモデルリソース上限(クォータ)サービスクォータの削減指示現状のリソース使用量

サービスがリソース上限(クォータ)を使い切っていない場合、上限値を削減し効率的にリソースを活用ハザードの見落とし：クォータの削減を保留する仕組みを導入していたが、誰も気付かずに過剰にリソースを制限最適リソース維持機能アルゴリズムプロセスモデルリソース上限(クォータ)サービスクォータの削減指示現状のリソース使用量

サービスがリソース上限(クォータ)を使い切っていない場合、上限値を削減し効率的にリソースを活用ハザードの見落とし：クォータの削減を保留する仕組みを導入していたが、誰も気付かずに過剰にリソースを制限最適リソース維持機能アルゴリズムプロセスモデルリソース上限(クォータ)サービスクォータの削減指示現状のリソース使用量クォータの削減を保留する状態をハザードとして認識することで、インシデント発生前に対処できる

@AoToLog_ #安全性向上セミナー STPA のおさらい STAMP を前提として、「いかにして事故が起きるか」を解析する手法「ハザードシナリオ」を作成して原因を探り、ハザードを引き起こす
原因を UCA として特定 STEP⓪ STEP⓪ STEP① STEP② アクシデント・ハザード・安全制約の識別コントロール構造の構築 UCA の抽出 HCF の特定対策検討

@AoToLog_ #安全性向上セミナー STPA のおさらい STAMP を前提として、「いかにして事故が起きるか」を解析する手法「ハザードシナリオ」を作成して原因を探り、ハザードを引き起こす
原因を UCA として特定 Not Providing (指示が出ない) Providing Incorrectly (誤った指示) Timing： Too early/late, wrong order (タイミング・順序) Duration： Stopping too soon (アクションの長さ)

サービスがリソース上限(クォータ)を使い切っていない場合、上限値を削減し効率的にリソースを活用ハザードの見落とし：クォータの削減を保留する仕組みを導入していたが、誰も気付かずに過剰にリソースを制限 Not Providing (指示が出ない) Providing Incorrectly (誤った指示) Timing： Too early/late, wrong order (タイミング・順序) Duration： Stopping too soon (アクションの長さ) 過剰にリソースを制限

@AoToLog_ #安全性向上セミナープロアクティブな改善へ「Google SRE の直面した事例」は氷山の一角にすぎない Google では STAMP/STPA
を適用し、数百の潜在的なハザードを発見し、システム停止を避ける迅速な応急処置とソフトウェアエンジニアリングを組み合わせることで、影響を軽減できた

@AoToLog_ #安全性向上セミナーまとめ

@AoToLog_ #安全性向上セミナー SRE への STAMP/STPA の適用背景 • 複雑な大規模システムの構造を理解するための抽象・標準化が必要 •
実験的な取り組みや変更による悪影響が許容されない大規模システム

@AoToLog_ #安全性向上セミナー SRE への STAMP/STPA の適用背景 • 複雑な大規模システムの構造を理解するための抽象・標準化が必要 •
実験的な取り組みや変更による悪影響が許容されない大規模システム適用 • 理論に裏付けされた、暗黙知から形式知への転換 • 障害発生後の事後検証だけではなく、障害発生前の事前分析 ◦ 障害検知アラートの根拠としての UCA ◦ サービスレベル目標の根拠としての安全制約 ◦ 事後検証の手法としての STPA

@AoToLog_ #安全性向上セミナー SRE への STAMP/STPA の適用適用 • 理論に裏付けされた、暗黙知から形式知への転換 •
障害発生後の事後検証だけではなく、障害発生前の事前分析 ◦ 障害検知アラートの根拠としての UCA ◦ サービスレベル目標の根拠としての安全制約 ◦ 事後検証の手法としての STPA STPA による分析よりよい SLO 安全なシステム運用

@AoToLog_ #安全性向上セミナーまとめ • 大規模・複雑になるソフトウェアシステムの開発・運用では、 SRE と呼ばれるプラクティスが培われてきた • 暗黙知を元にした SRE
は社会生活基盤としてのサービスを支えるには不十分で、理論による形式知化やモデルによる標準化が有効 ◦ STAMP による SRE のプラクティスの根拠づけ ◦ STPA による事前分析による安全性 ≒ 信頼性の向上 • Google SRE チームはいち早く STAMP/STPA を取り入れて、大規模・複雑な Google サービスの安全性を高めた • 大規模なシステムだけでなく、あらゆるソフトウェアシステムの品質向上のために、STAMP/STPA は有効で SRE のプラクティスを補強できる

@AoToLog_ #安全性向上セミナー Thank you!!

Google に学ぶ、安全性を高める信頼性設計 / Reliability Design f...

Google に学ぶ、安全性を高める信頼性設計 / Reliability Design for Enhanced Safety: Lessons from Google SRE

Resources

Google が実践する最先端の SRE

The Evolution of SRE at Google

安全性向上セミナー in 2025

More Decks by Kento Kimura

Other Decks in Technology

Featured

Transcript