Japan Google Cloud Usergroupfor Enterprise（Jagu‘e’r）sre_o11y分科会第4回イベント 登壇資料 SREのための組織変革

Japan Google Cloud Usergroupfor Enterprise（Jagu‘e’r）sre_o11y分科会第4回イベント 登壇資料

⚫SREのきっかけ-組織のメンバーがスルーしている違和感
⚫多くの違和感はトイルに関連している
⚫トイルの削減から始める
⚫トイル削減を原資にSREを組織に拡大
⚫ふりかえりSREが目指すもの
⚫DevOpsを補完するSRE
⚫SREプラクティス
⚫施策の絞り込み
⚫施策の実行-SREケイパビリティの展開
⚫可観測性（Observability
⚫変革のためのマインドセット

Transcript

1. LT : SREのための組織変革 (15分) Japan Google Cloud Usergroup for Enterprise（Jagu‘e’r） sre_o11y分科会 第4回イベント アクセンチュア株式会社 テクノロジーコンサルティング本部 青柳 雅之
2. Copyright © 2023 Accenture. All rights reserved. 2 登壇者 テクノロジーコンサルティング本部 金融サービスグループ アソシエイト・ディレクター 兼Accenture Google Cloud Business Group(AGBG) ソリューションアーキテクト マイクロソフトのR&D、コンサル部門(MCS)、AWSのコンサルティング部門(Proserve)を経て2017年にアクセン チュアに入社。クラウドのあらゆる領域の業務に従事。 趣味は登山、史跡訪問、旅行 横浜市在住 青柳 雅之（あおやぎ まさゆき） masayuki.aoyagi@accenture.com Twitter:@maoyagi46 Google Cloud Partner Top Engineer Award 2021,2023 Jagu’e’r Award 最優秀賞 2021 AWS APN Partner Top Engineer 2019
3. Copyright © 2023 Accenture. All rights reserved. 3 Agenda ⚫ SREのきっかけ - 組織のメンバーがスルーしている違和感 ⚫ 多くの違和感はトイルに関連している ⚫ トイルの削減から始める ⚫ トイル削減を原資にSREを組織に拡大 ⚫ ふりかえり SREが目指すもの ⚫ DevOpsを補完するSRE ⚫ SREプラクティス ⚫ 施策の絞り込み ⚫ 施策の実行 - SREケイパビリティの展開 ⚫ 可観測性（Observability ⚫ 変革のためのマインドセット ⚫ まとめ
4. Copyright © 2023 Accenture. All rights reserved. 4 SREのきっかけ - 組織のメンバーがスルーしている違和感 SREは特別なことではなく、皆さんが普段感じる不満や課題がいわゆるSREのアジェンダに結び付いている。 組織変革には組織のメンバーがおそらく改善できないと言うあきらめの境地からスルーしている違和感 （不満ともいえる）を意識的に増幅させることが必要。 あきらめの境地にあるゆえに、スルーする違和感（不満）の例 ⚫ チーム数が多いので会議が多すぎる。 ⚫ 同じシステムを複数のチームで見ているので、設計の考慮に玉落としがある(reworkの発生)。 ⚫ 情報が分散されていて必要な情報への到達に時間がかかる。
5. Copyright © 2023 Accenture. All rights reserved. 5 違和感はトイルに関連している 体験上、その違和感の多くは体験上、トイルに関連している。でトイルの削減はSRE Principleの１つであ るが、多くのメンバーの賛同を得られやすい。 Embracing Risk Service Level Objectives Eliminating Toil Release Engineering Monitoring Distributed Systems Evolution Of Automation Simplicity SRE PRINCIPLES SRE Principle Covered Subareas Embracing Risk リスクの管理、サービスリスクの測定、サービスの許容度の リスク、エラーバジェットの動機 Service Level Objectives サービス レベル フレームワーク、SLI、SLO、SLA Eliminating Toil トイルの削減 Monitoring Distributed Systems 監視用, ディスプレイ, アラート Evolution of Automation 自動化の価値、ユースケース Release Engineering リリースエンジニア、継続的なビルドと展開、構成管理 Simplicity コードの複雑さの管理、コードのシンプルさ SRE Principles ⚫ チーム数が多いので会議が多すぎる。 ⚫ 同じシステムを複数のチームで見てい るので、設計の考慮に玉落としがあ る(reworkの発生) 。 ⚫ 情報が分散されていて必要な情報へ の到達に時間がかかる。
6. Copyright © 2023 Accenture. All rights reserved. 6 トイルの削減から始める まずはゆとりを作ります。ゆとりがなければ新しい施策は実行出来ません。そのため、無駄な会議をなくし、手 作業の自動化を促す最適なツールを入れるなど、ゆとりを作る施策を最初に行うべきだと考える。 https://www.accenture.com/jp-ja/blogs/technology-diaries/site-reliability-engineering-sre-applicability ※昔、トム・デ・マルコの「ゆとりの法則」を読み ました。書籍には15パズルの絵が出てきます。15パ ズルは駒を一つ抜くことで、その他の駒を動かせる ことを示しています。もう１つ駒を足す、つまりゆ とりなしで作業をメンバーに実施させると作業は効 率化できますが、変化に対応できなくなるとトム・ デ・マルコは主張しています。
7. Copyright © 2023 Accenture. All rights reserved. 7 トイル削減を原資にSREを組織に拡大 トイルの削減でその原資をSREのための施策に投資し、さらなるトイルの削減でその原資をさらに拡大した 領域に投資する。 顧客満足度の向上 企業の 成長 選択肢の増加 利用量の増加） パートナー企業の増加 低コスト構造への改 善） 値下げ アナロジー：ある小売業のビジネスモデル SRE関連施策の実施 SREの拡大 利益の増加 ユーザーの増加 サービスの価値向上 トイルの削減 施策の原資確保 トイル削減が組織的なSRE拡大の原資に
8. Copyright © 2023 Accenture. All rights reserved. 8 ふりかえり SREが目指すもの 最終的にはDevOpsチームの体制自身に起因する問題を解決し、システムの信頼性を高めるのがゴール。 ソフトウエア改善の遅さ 信頼性回復の遅さ Ops Dev Monitoring / Observing Application Support Long Term Improveme nt Alert Ops Dev Incident Problem Bug Fix User 伝言ゲーム Ops Dev 1st Level 3rd Level Feature Implementation User 2nd Level New Feature Request 新機能リリースの遅さ Ops Dev Change Lead Approves Test Features Release Activation Implement Features
9. Copyright © 2023 Accenture. All rights reserved. 9 DevOpsを補完するSRE 当然ではあるが、前頁のような課題は、DevOpsを補完するSREという観点で施策を考える。 DevOps SLO のVALET ディメンジョン SLI, SLO, SLA エラーバジェット 非難なき ポストモーテム トイル削減 自動化 Volume: 私のサービスはどのくらいのビジネス量を処理できますか? Availability: 必要なときにサービスが稼働していますか? Latency: 使用時にサービスが速く応答しますか? Errors: サービスを使用するとエラーがスローされますか? Tickets: 要求を完了するために、サービスに手動による介入が必要 ですか? 100 % 97,5% 95% SLA SLO SRE E.g., Total Availability 安定性とリスクのバランスをとるための残りのエラー バジェット 反復作業とエンジニアリング作業のバランスを取る 改善とコラボレーションを促進す る非難のない文化を確立する トイルの削減と自動化の 強化により無駄を排除 SLI
10. Copyright © 2023 Accenture. All rights reserved. 10 SREプラクティス トイルの削減で得た原資で、チームの体制を変えるSREのロードマップがど のように作るのか。 Practical Alerting Tracking Outages Adressing Cascading Failures Beeing On-Call Testing Reliability Managing Critical State Effective Trouble- shooting SW Engineerin g in SRE Distributed Periodic Scheduling with Cron Emergency Response Load Balancing at Frontend Data Processing Pipelines Managing Incidents Load Balancing in Data Center Data Integrity Post- mortem Culture Handling Overload Reliable Product Launches SRE PRACTICES Embracing Risk Service Level Objectives Eliminating Toil Release Engineering Monitoring Distributed Systems Evolution Of Automation Simplicity SRE PRINCIPLES SRE Principles ソフトウエア改善の遅さ Ops Dev Incident Problem Bug Fix User
11. Copyright © 2023 Accenture. All rights reserved. 11 施策の絞り込み SREのプラクティスの全体像を俯瞰することは必要だが、優先度は付ける。 Beeing On- Call (41.67%) Tracking Outages (66.67%%) Data Integrity (71.43%) Effective Trouble- shooting (38.41%) Testing Reliability (42.39%) Data Processing Pipelines Post-mortem Culture (84.62%) SW Engineer- ing in SRE (54.27%) Distributed Periodic Scheduling with Cron Practical Alerting (50.89%) Load Balancing at Frontend Managing Critical State (68.48%) Emergeny Response (37.5%) Load Balancing in Data Center (28.13%) Adressing Cascading Failures (50.00%) Managing Incidents Handling Overload (62.5%) Reliable Product Launches SRE Practices Practic e Prio Action Item 1 2 • .例外なく規制を検討する必要がある。 2 2 • KPIによるインシデント管理の有効性の向上 • サーキットブレーカ機能を統合 • チームの規模に応じて、SRE は P1 インシデントと P2 インシデントの両方に関与し、制御エンティティとして機能 する必要がある。 • 影響を受けるシステムは、問題が発生した場合に使用 する独自のフェールオーバースクリプトとともに出荷する必 要がある。 • 5 2 • 一方では、サービスのリスク分類を実行する必要があり、 他方では、応答時間と応答グループを定義する必要が ある。 • 8 2 • 測定可能な実験をタイムボックススプリントに統合する。 • ビジネス目標に対するユーザー満足度、サービス品質、 パフォーマンスの継続的な改善を促進するテスト戦略を 実装する。 11 1 • 負荷分散にはさらに注意を払う必要がある。 ソフトウエア改善の遅さ Ops Dev Incident Problem Bug Fix User どのプラクティスの改善が大きく寄与するか？
12. Copyright © 2023 Accenture. All rights reserved. 12 施策の実行 - SREケイパビリティの展開 SREプラクティスの成熟度モデルから、改善が必要な領域に対応する測定対象を選定し、まず測定可能に する。そこから成熟度を上げるための施策を打っていく。 3.1 エラー予算の合意/SLO の調整 3.2 レジリエンス設計パターンのマッピング SRE の運用モデルと誰も責めない文 化の確立 3.3 SLO に基づくアクションについて合意 する 3.4 Failureを ノーマルとして扱う カオスエンジニアリングを含むセキュリ ティ/ゲームデー 4.4 パイプラインでの継続的なレジリエン ステスト 4.3 AIOpsによる予測インシデント管理 4.1 自動スケーリングによるレジリエンスア ーキテクチャ 4.2 シミュレート &テスト 自動化するトイル 運用手順書の自動化 デプロイの準備手順の最適化とマッピ ング 2.1 2.2 2.3 2.4 最適化された可観測性によるプロア クティブな監視 ツールと自動化 の活用 トイルのバックログへの統合 監視とアラートの強化 価値を測定するための規範的な方 法を定義する 1.2 1.3 1.4 標準化されたツール、不変のインフラパイ プライン、IaCへのオンボード 1.1 測定 SRE 成熟度
13. Copyright © 2023 Accenture. All rights reserved. 13 可観測性（Observability） データとメトリックの収集は SRE にとって重要ですが、サービスに最も関連性の高いメトリックの収集に重 点を置く必要がある。 Traditional With SRE シグナルとノイズ より少ないメトリックではなくより多くのメトリックを収集すること への誤り–これは役立つ場合がありますが、多くの場合、信 号よりもはるかに多くのノイズが発生します 実際の顧客体験に最も近い指標を収集する アグリゲーション 様々なシステムからのデータをまとめるのが 難しい傾向がある 簡単な集計、アラート、およびデータ分析のために特別に 作成された監視ツールを使用してメトリックを公開します フルチューニングと補正 未知のものを監視することは、すぐにモグラたたきのゲームに 変わり、次の問題を予測するための「正しい」メトリックを常 に探します パフォーマンスに悪影響を与えるものをすべてキャプチャする 幅広いメトリックを使用して、重要なユーザージャーニーをイ ンストルメント化します Customer centricity Application focused
14. Copyright © 2023 Accenture. All rights reserved. 14 変革のためのマインドセット プロセスやツールの他、SREに関わる人々はマインドセットを変える必要がある。チーム間の利害を超えるた めに、REに関わる全てのメンバーのマインドセットを担当部品からクライアントに向けるように変えていく。 私のコンポーネントは機械の歯車だ 価値へのマインドセット 私のプロダクトは顧客に独自の価値を提供する プロダクトの戦略、計画、設計、構築、実行、運用を担当して いる 顧客に影響を与える前に問題をプロアクティブに見つけて修正 する チームの外にコンポーネントのライフサイクルを担当する人がたく さんいる オーナーシップ 問題が発生するのを待ってから、問題を解決できることを願って いる 品質へのマインドセット With SRE 「私は顧客に対して責任があります」 Traditional 「コンポーネントを最適化しています」
15. Copyright © 2023 Accenture. All rights reserved. 15 まとめ ⚫ トイルの削減をSRE関連施策の原資とする。 ⚫ 最終的になチームの形が変わるので変革への抵抗は大きい。そのため、チーム間の利害を超えるために、 REに関わる全てのメンバーのマインドセットを担当部品からクライアントに向けるように変えていく。 ⚫ 観測するメトリクスもユーザーの期待に紐づいたものに変えてく。