エンジニア必见！厂谤别への第一歩
3 likes1,869 views
Developers Summit 2021 Summer https://event.shoeisha.jp/devsumi/20210730/session/3245/
More Related Content
What's hot (20)
Similar to エンジニア必见！厂谤别への第一歩 (20)
![[Biz reach qa meetup] qa team_build](https://cdn.slidesharecdn.com/ss_thumbnails/bizreachqameetupqateambuild-190719053542-thumbnail.jpg?width=560&fit=bounds)
![[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight](https://cdn.slidesharecdn.com/ss_thumbnails/ctond2019morningsessionsecurity-191027185908-thumbnail.jpg?width=560&fit=bounds)
エンジニア必见！厂谤别への第一歩
- 2. Copyrights?3-shake Inc. All Rights Reserved. 2 自己紹介 自治体やデータベースマーケティング会社でのインフラ設計 /構築 /運用を主に経験し、2018 年 10 月に 3-Shake に Join。 3-Shake Join 後は Google Cloud / AWS / kubernetes / ServiceMesh など様々な技術的アプローチを駆使し、 大手からベンチャー等規模を問わず様々な組織に対して SREの コンサルティングや実践を行っている。 趣味はボクシング観戦 ※ 日曜日の昼間は一人で WOWOW 見ながら一人で熱狂してます ... 手塚 卓也
- 3. Copyrights?3-shake Inc. All Rights Reserved. 3 1. About 3-shake 2. SRE とは? 3. Sreake 流 SRE 実践 4. まとめ アジェンダ
- 5. Copyrights?3-shake Inc. All Rights Reserved. 5 About 3-Shake SRE 支援 / 技術支援 サービス Sreake セキュリティ脆弱性診断 サービス Sreake Security クラウド型 ETL / データ パ イプライン サービス Reckoner ハイスキル フリーランス紹 介サービス Relance Reckoner はクラウド型ETL / データパイプラインサービスで す。 データベース?ストレージ?アプリ ケーションなど、あらゆるデータを 統合?連携することで、データを活 用したビジネス変革に貢献しま す。 Sreake Security は経験豊富な セキュリティ専門家が貴社の課題 に合わせたセキュリティ対策を支 援するサービスです。 Sreake は金融?医療?動画配信 ?AI?ゲームなど技術力が求めら れる領域で豊富な経験を持つ SRE が集まったチームによる 技 術支援サービスです。戦略策定 から設計?構築?運用、 SaaS 提供 まで、幅広い領域をサポートしま す。 Relance は、プロの現役エンジニ ア集団が最適なエンジニアを紹介 するフリーランスエンジニア紹介 サービスです。 技術支援や、 1on1 での定期フォ ローなど、参画後も高いパフォー マンスを維持し続けられる体制 を 提供しています。
- 6. Copyrights?3-shake Inc. All Rights Reserved. 6 Sreake のエンジニアによる技術支援 技術戦略から設計、構築、運用までワンストップ支援する 技術支援サービス 技術戦略 コンサルティング システム 設計 構築 / 実装 支援 アセスメント （パフォーマンス / セキュリティ） 運用支援 Multi Cloud や Cloud Native な先進的技術及び大規模なサービス運用に強みを持つエンジニアによる技術 支援 ベンダー的な役割ではなく「お客様の チームメンバー」という立ち位置で最新技術の提案から運用支援までをトータ ルご支援
- 7. Copyrights?3-shake Inc. All Rights Reserved. 7 Sreake SRE 導入 / 定着化支援 Enterprise を中心に様々な業種/業界でSRE を実践してきたナレッジを活かしたSRE チームの導入及び定着化を行います お客様の組織に適合した SRE の導入を支援 SRE の組成/SRE 文化の定着化の為の支援
- 8. Copyrights?3-shake Inc. All Rights Reserved. 8 本日お話する内容 SRE の概念に関する詳しいお話 SRE についてさくっとしたお話 私達が展開している SRE の実践方法について 話すこと 話さないこと 詳細なシステムアーキテクチャなど
- 9. Copyrights?3-shake Inc. All Rights Reserved. 9 SRE の基本について知りたい方は以下がおすすめです sre.google に掲載されているSRE Book https://sre.google/sre-book/table-of-contents/ https://sre.google/workbook/table-of-contents/ SRE をわかりやすく理解出来るコンテンツ Google Cloud Days SRE の基本と組織への導入 ? サービスレベル目標やエラー予算などサー ビスの信頼性に対する考え方? https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21?talk=d3-infra-01 3-shake SRE Tech Talk #2 (Google Cloud 篠原様による登壇) https://youtu.be/g-WMeetjoRM?t=218
- 10. 2. SRE とは？
- 11. Copyrights?3-shake Inc. All Rights Reserved. 11 SRE とは ~ SRE 本の序章より ~ Googleで定義されるようになった Site Reliability Engineeringとは一体何なのか？ 私の説明は簡単です。 SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです 。 What exactly is Site Reliability Engineering, as it has come to be defined at Google? My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team. By Betsy Beyer https://sre.google/sre-book/introduction/
- 12. Copyrights?3-shake Inc. All Rights Reserved. 12 SRE とは ~ SRE 本の序章より ~ Googleで定義されるようになった Site Reliability Engineeringとは一体何なのか？ 私の説明は簡単です。 SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです 。 What exactly is Site Reliability Engineering, as it has come to be defined at Google? My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team. By Betsy Beyer https://sre.google/sre-book/introduction/ たとえ説明が簡単でも理解が難しすぎる...笑
- 13. Copyrights?3-shake Inc. All Rights Reserved. 13 システム運用において起きている問題 Ops の現場で抱えている問題 煩雑で繰り返し の多い運用作業 日々追われる障害対応 とメンバーへの過負荷 守りを重視するが故に リリーススピードが遅い
- 14. Copyrights?3-shake Inc. All Rights Reserved. 14 システム運用において起きているあるあるな問題 Ops の現場で抱えている問題 煩雑で繰り返し の多い運用作業 日々追われる障害対応 とメンバーへの過負荷 守りを重視するが故に リリーススピードが遅い 3K 的な要素が非常に強い...
- 15. Copyrights?3-shake Inc. All Rights Reserved. 15 SRE の原則について ? リスクの受容 ? SLO の定義 ? 分散システムのモニタリング ? Toil の削減 ? 自動化の推進 ? 適切なリリースエンジニアリング Principles of SRE 参照: https://sre.google/sre-book/part-II-principles/
- 16. Copyrights?3-shake Inc. All Rights Reserved. 16 SRE の原則について ? リスクの受容 ? SLO の定義 ? 分散システムのモニタリング ? Toil の削減 ? 自動化の推進 ? 適切なリリースエンジニアリング Principles of SRE 参照: https://sre.google/sre-book/part-II-principles/ 100% の可用性を目指さず、SLO を元に適切なリスクマネジメントと 業務ハンドリングを行う。 そのためにリスクの評価、管理、お よびエラーバジェットの使用などを 実施していく。
- 17. Copyrights?3-shake Inc. All Rights Reserved. 17 SRE の原則について ? リスクの受容 ? SLO の定義 ? 分散システムのモニタリング ? Toil の削減 ? 自動化の推進 ? 適切なリリースエンジニアリング Principles of SRE 参照: https://sre.google/sre-book/part-II-principles/ 長期的なトレンドの把握や適切な アラートによる問題解決の修復等 を行うために、 各種のモニタリングやアラート設定 を行っていく。
- 18. Copyrights?3-shake Inc. All Rights Reserved. 18 SRE の原則について ? リスクの受容 ? SLO の定義 ? 分散システムのモニタリング ? Toil の削減 ? 自動化の推進 ? 適切なリリースエンジニアリング Principles of SRE 参照: https://sre.google/sre-book/part-II-principles/ サービスの成長に比例して拡大す る永続的な価値を提供しない、あり ふれた反復的な運用作業を自動 化して削減していく。
- 19. Copyrights?3-shake Inc. All Rights Reserved. 19 SRE の原則について ? リスクの受容 ? SLO の定義 ? 分散システムのモニタリング ? Toil の削減 ? 自動化の推進 ? 適切なリリースエンジニアリング Principles of SRE 参照: https://sre.google/sre-book/part-II-principles/ 多くの障害は人の手が加わること によって発生する。 その為、適切な構成管理やリリー スエンジニアリングの仕組みを構 築する必要がある。
- 20. Copyrights?3-shake Inc. All Rights Reserved. 20 SRE の原則について ? リスクの受容 ? SLO の定義 ? Toil の削減 ? 分散システムのモニタリング ? 自動化の推進 ? 適切なリリースエンジニアリング ? シンプルさの追求 Principles of SRE 参照: https://sre.google/sre-book/part-II-principles/ これらの原則を Software Engineering を通じて実現させる運用を行う職務こそが SRE ※ 独自解釈
- 21. 3. Sreake 流 SRE 実践
- 22. Copyrights?3-shake Inc. All Rights Reserved. 22 Sreake 流 SRE Roadmap SRE チームの定義 組織にあったSRE を定義しよう SRE の開始 まずは小さく。 効果が最大限に出るところ からコツコツと始めよう SRE実践 Toil 削減 (自動化推進) SLI?SLO の設定 SRE の発展と継続 SREの文化が浸透する Error Budget を元に 業務をコントロールしていく
- 23. Copyrights?3-shake Inc. All Rights Reserved. 23 組織組成するとき/組織改革するときに失敗するパターン SRE チームに限らずあらゆる組織を立ち上げる時は様々な苦労や困難な壁 にぶつかります。 重要なのは組織組成や改革は当事者や周りが冷めてしまったら終わり だということです。 その為に生まれたての組織は尚更慎重に活動していく必要があります。 組織の役割が曖昧でメンバーに目的が浸透 していない 活動が他のチームや上層部から理解が得ら れない 現実と折り合いを付けずに 到達困難な高すぎる目標を立ててしまう 新しい活動に割けるリソースがなく、 コミット量が少ない
- 24. Copyrights?3-shake Inc. All Rights Reserved. 24 class SRE implements DevOps DevOps SRE Reduce organization silos 組織のサイロ化を無くす Share ownership with developers by using the same tools and techniques across the stack 同じツールやテクニックを使用して、開発者とオーナーシップを共有する Accept failure as normal 失敗を当たり前のように受け入れる Have a formula for balancing accidents and failures against new releases 事故や失敗と新製品とのバランスをとるための公式を持つ Implement gradual change 徐々に変化させる Encourage moving quickly by reducing costs of failure 失敗したときのコストを減らすことで、迅速な行動を促します。 Leverage tooling & automation ツールと自動化の活用 Encourages "automating this year's job away" and minimizing manual systems work to focus on efforts that bring long-term value to the system システムに長期的な価値をもたらす取り組みに集中するために、「今年の仕事を自動化する」ことを奨励 し、手作業によるシステム作業を最小限に抑える Measure everything すべてを測定する Believes that operations is a software problem, and defines prescriptive ways for measuring availability, uptime, outages, toil, etc. オペレーションはソフトウェアの問題であると考え、アベイラビリティー、アップタイム、アウテージ、トイルな どの測定方法を規定しています。 参照: https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends class SRE は DevOps を実装するとありますが ... ※ SRE には、必ずしもDevOps インターフェースの一部ではない、追加のプラクティスや推奨事項が含まれている場合があります。
- 25. Copyrights?3-shake Inc. All Rights Reserved. 25 class SRE implements DevOps DevOps SRE Reduce organization silos 組織のサイロ化を無くす Share ownership with developers by using the same tools and techniques across the stack 同じツールやテクニックを使用して、開発者とオーナーシップを共有する Accept failure as normal 失敗を当たり前のように受け入れる Have a formula for balancing accidents and failures against new releases 事故や失敗と新製品とのバランスをとるための公式を持つ Implement gradual change 徐々に変化させる Encourage moving quickly by reducing costs of failure 失敗したときのコストを減らすことで、迅速な行動を促します。 Leverage tooling & automation ツールと自動化の活用 Encourages "automating this year's job away" and minimizing manual systems work to focus on efforts that bring long-term value to the system システムに長期的な価値をもたらす取り組みに集中するために、「今年の仕事を自動化する」ことを奨励 し、手作業によるシステム作業を最小限に抑える Measure everything すべてを測定する Believes that operations is a software problem, and defines prescriptive ways for measuring availability, uptime, outages, toil, etc. オペレーションはソフトウェアの問題であると考え、アベイラビリティー、アップタイム、アウテージ、トイルな どの測定方法を規定しています。 参照: https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends class SRE は DevOps を実装するとありますが ... ※ SRE には、必ずしもDevOps インターフェースの一部ではない、追加のプラクティスや推奨事項が含まれている場合があります。 こういった手法を受け入れるだけの組織的土壌がありますか？ なければ作れますか？ 他チームから理解を得て協働が可能ですか？
- 26. Copyrights?3-shake Inc. All Rights Reserved. 26 SRE はあらゆるレイヤーに密接に関わります Biz Ops Dev SRE DevOps の 「実装者」 としての役割をもつ SRE は当然 開発 や これまでの運用といったものと密接に関わります。 また、SLO の定義や SLA の定義を行うためには当然 SRE の みで終止するものでは無いため、ビジネスサイドとも密接に関 わります。 SRE は単一組織として自分たちのタスクに終始すれば良いも のではなく、様々な組織や役割と密接に連携し合いながら実 践していく必要があると考えています。
- 27. Copyrights?3-shake Inc. All Rights Reserved. 27 SRE あるある言いたい ? SLI / SLO の定義 = SRE ? 障害対応 = SRE ? 自動化の推進 = SRE ? 振り返りの文化を作る= SRE ? CI/CD の整備 = SRE ? 監視環境の整備 = SRE ? インフラの環境構築 = SRE ? アーキテクトレビュー= SRE SRE チームやること/頼まれること多くなって本質的なこと出来なくなりがち 注: SRE には、必ずしも DevOps インターフェースの一部ではない、追加のプラクティスや推奨事項が含まれている場合があります。 参照: https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-standards-or-close-friends
- 28. Copyrights?3-shake Inc. All Rights Reserved. 28 他チームとの協働の重要性 SRE チームの役割を明確にして理解を得よう SRE は SRE チームだけで成立するものではありません。他 チームとの協働があってこそ成立するものです。 そのためにも SRE の役割を明確にして有機的に協働する必要 があります。 また、Google の SRE のカタチに囚われすぎない事も大事かも しれません。 今の組織やシステム構成にあわせた形で SRE の定義を行わ なければ理想だけで上手く行かないと考えています。
- 29. Copyrights?3-shake Inc. All Rights Reserved. 29 Sreake 流 SRE Roadmap SRE チームの定義 組織にあったSRE を定義しよう SRE の開始 まずは小さく。 効果が最大限に出るところ からコツコツと始めよう SRE の発展と継続 SREの文化が浸透する Error Budget を元に 業務をコントロールしていく SRE実践 SLI?SLO の設定 Toil 削減 (自動化推進)
- 30. Copyrights?3-shake Inc. All Rights Reserved. 30 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応?管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質?脆弱性の検査 ○ DevSecOps ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験
- 31. Copyrights?3-shake Inc. All Rights Reserved. 31 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応?管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps Cloud Operations Cloudwatch
- 32. Copyrights?3-shake Inc. All Rights Reserved. 32 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応?管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps Slack 等の Chat 運用体制構築
- 33. Copyrights?3-shake Inc. All Rights Reserved. 33 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応?管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps
- 34. Copyrights?3-shake Inc. All Rights Reserved. 34 SRE の実践内容 (例) ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質?脆弱性の検査 ○ DevSecOps ● アプリケーションのパッケージ化 ○ コンテナ ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験
- 35. Copyrights?3-shake Inc. All Rights Reserved. 35 SRE の実践内容 (例) ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質?脆弱性の検査 ○ DevSecOps ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験
- 36. Copyrights?3-shake Inc. All Rights Reserved. 36 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応?管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質?脆弱性の検査 ○ DevSecOps ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験
- 37. Copyrights?3-shake Inc. All Rights Reserved. 37 SRE の実践内容 (例) ● 監視基盤導入 ○ Logging ○ Monitoring ○ APM ● SLI / SLO の定義 ● 運用体制整備 ○ インシデント対応?管理 ○ 効果的なアラート ● IaC (Infrastructure as Code) ○ 構成管理の品質チェック ○ GitOps ● CI/CD 導入 ○ デプロイの自動化 ○ コード品質?脆弱性の検査 ○ DevSecOps ● アプリケーションのパッケージ化 ○ コンテナ ● パフォーマンス分析 ○ 分散トレーシング ○ 負荷試験 ○ カオスシナリオ試験 これを複数のサービスにまたがって一気に全部実行するの相当困難。 本音を言うと不可能に近いです...
- 38. Copyrights?3-shake Inc. All Rights Reserved. 38 ひとつのサービスから始める そのためには、多数のシステムを一気に対象としないこと。 まずはひとつのサービスを対象にSRE を始めて徐々に広げていきま しょう。 なお且つ、出来れば新規サービスが望ましい。 理由 ? 新しく SLI / SLO 設定する元となる情報を取得する為の基盤導入が難 しい。 ? 既存の運用がある為、新しい活動への導入が難しいケースがある ? そもそも手を加える前提で作られていない ... 小さく始めてSRE チームとして成功体験を得よう System A ひとつのサービスと それに関わるチームからSRE の活動を始める
- 39. Copyrights?3-shake Inc. All Rights Reserved. 39 あらゆる情報を収集し始めよう SRE を始めるにあたっては、元となるあらゆるデータが揃ってい ることが前提です。 結局はデータドリブンな世界にする必要があり、データがない状 態ではSLI / SLO の設定はそもそも不可能です。 具体的には監視基盤の見直し等を通じてとにかくまずはデータを 収集し、可視化出来るところまで持っていきましょう。 データを元に意思決定が出来る世界へ 闇雲に戦う世界から
- 40. Copyrights?3-shake Inc. All Rights Reserved. 40 Sreake 流 SRE Roadmap SRE チームの定義 組織にあったSRE を定義しよう SRE の開始 まずは小さく。 効果が最大限に出るところ からコツコツと始めよう SRE実践 SLI?SLO の設定 Toil 削減 (自動化推進) SRE の発展と継続 SREの文化が浸透する Error Budget を元に 業務をコントロールしていく
- 41. Copyrights?3-shake Inc. All Rights Reserved. 41 SLI?SLO?SLA について ? SLI (Service Level Indicator) サービスレベル指標 ? 何をもとにシステムの良し悪しを判断するかの指標となるもの ? SLO を定義する時に利用する ? SLO (Service Level Objective) サービスレベル目標 ? サービスレベルに対する内的な目標値 ? SLA (Service Level Agreement) サービスレベル保証 ? サービスレベルに対する対外的な保証値
- 42. Copyrights?3-shake Inc. All Rights Reserved. 42 SLI?SLO?SLA について ? SLI (Service Level Indicator) サービスレベル指標 ? 何をもとにシステムの良し悪しを判断するかの指標となるもの ? SLO を定義する時に利用する ? SLO (Service Level Objective) サービスレベル目標 ? サービスレベルに対する内的な目標値 ? SLA (Service Level Agreement) サービスレベル保証 ? サービスレベルに対する対外的な保証値 上質な SLO を設定するためにもまずは あらゆる指標となりうるあらゆるメトリクスを収集 し、可視化ができるようにしよう
- 43. Copyrights?3-shake Inc. All Rights Reserved. 43 SLO の設定について ? CUJ (クリティカルユーザージャーニー )を検討していく事から始める ? ただ最初のSLO 設定はエイヤーで決めてしまうのも一つ。 ? SLO はサービスの成長に応じて変わっても良い。 ? ただし、SLO 100% はアンチパターンなので、そういう設計はし ない事 ? それより大事なのが、Biz / Dev を置き去りにせず共通認識の 獲得を意識しながら設定していくこと ? 定期的に 振り返りながら組織一丸となって、一緒に高品質なプ ロダクトを目指していく事が大事。 System A
- 44. Copyrights?3-shake Inc. All Rights Reserved. 44 ポストモーテムの実施 ポストモーテムとは、インシデント、その影響、インシデントを軽減または解決するために取られたアクショ ン、根本原因、およびインシデントの再発を防止するためのフォローアップアクションを書面で記録すること です。 参考: https://sre.google/sre-book/postmortem-culture/ https://sre.google/sre-book/example-postmortem/ ? 振り返りから学ぶ文化を作る為にポストモーテムを行います。 ? その為には障害解析に対して追跡が出来るようにしておかな ければなりません。 ? フォーマットについてはまずは SRE 本にて提示されている Example を流用するのがおすすめ。 ? それと何よりも大切なのが 特定個人を非難しない文化 であるこ とです。 ※ あくまで、システムや仕組みの問題であると考えます。
- 45. Copyrights?3-shake Inc. All Rights Reserved. 45 Alerting & Incident Management オンコール機能 ? 適切なオンコール体制を作る為のスケジューリング機能 実践的なAlerting ? EventRule を始めとしたインテリジェンスなアラート制御 インシデント管理 ? 様々なインテグレーションに対応しているので、包括的にインシ デント管理が可能 障害発生時の対応の追跡 ? ユーザーのアクションを自動で記録 ポストモーテム ? 組み込みでポストモーテムの機能があり、失敗から学ぶ文化を すぐに作れる PagerDuty の組み合わせで SRE を加速させる
- 46. Copyrights?3-shake Inc. All Rights Reserved. 46 Alerting & Incident Management 各監視製品群と連携機能 が備わっているため、容 易に設定が可能 Cloud Operations Cloudwatch 監視製品群
- 47. Copyrights?3-shake Inc. All Rights Reserved. 47 Alerting & Incident Management Cloud Operations Cloudwatch 監視製品群 Slack 等の Chat OnCall OnCall や Chat 通知が簡単に 行える。加えて、通知の中身に よって通知のパターンを実装する ことで、ノイズが無い通知が行え る
- 48. Copyrights?3-shake Inc. All Rights Reserved. 48 Alerting & Incident Management Cloud Operations Cloudwatch 監視製品群 Slack 等の Chat OnCall いつ誰がどういうフローで障害 解析にあたったのかを記録し てくれる。組み込みの Postmotem 機能もあり、容 易に振り返りがしやすくなる。
- 49. Copyrights?3-shake Inc. All Rights Reserved. 49 Alerting & Incident Management Cloud Operations Cloudwatch 監視製品群 Slack 等の Chat OnCall Jira 等の Task 管理ツール Jira 等のチケット管理ツールと もインシデント連携可能。スクラ ムや SRE の活動との連携もしや すいため、Toil の測定やエラー 予算の管理にも役立つ
- 50. Copyrights?3-shake Inc. All Rights Reserved. 50 Toil の削減 Toil とは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に 比例して増加する、といった特徴を持つ作業です。 参考: https://sre.google/sre-book/eliminating-toil/ まずはこれらを すべて測定することから ? Dev Team からの依頼対応 ? 障害対応 ? 割り込みタスク ? SRE としての定型業務 ? 定期的に発生する メンテナンス作業 どういう作業がどの程度の頻度発生し、どれだけの 工数をかけてどういう効果が得られたのかを取得する
- 51. Copyrights?3-shake Inc. All Rights Reserved. 51 Toil 削減をするために 振り返り 測定、振り返り、自動化のサイクルを回していく 測定 自動化 Jira 等のプロジェクト管理 ツールを駆使して定形業務 や割り込みタスクを測定す る。 SRE チーム内外含めて定期 的な振り返りを通じてToil 特 定のを行う 振り返りによって特定された Toil を自動化によって削減し ていく
- 52. Copyrights?3-shake Inc. All Rights Reserved. 52 Sreake 流 SRE Roadmap SRE チームの定義 組織にあったSRE を定義しよう SRE の開始 まずは小さく。 効果が最大限に出るところ からコツコツと始めよう SRE の発展と継続 SRE の文化が浸透する Error Budget を元に 業務をコントロールしていく SRE実践 SLI?SLO の設定 Toil 削減 (自動化推進)
- 53. Copyrights?3-shake Inc. All Rights Reserved. 53 SREの発展と継続 ? SRE の文化を浸透させていく ? ひとつの成功体験を得られたら他のサービスにも展開していく ? 定期的な振り返りを通じてさらなる改善を行っていく ? 計測したモノからToil 削減の為の自動化の促進を進めていこう ? Error Budget を元に業務をコントロールする ? そのためには十分な体制やSLI?SLO の定義が必要 ? また、サービスのビジネス的な意味合いによるところもあるので、 現実的に はこの運用は相当難しい....
- 54. 4. まとめ
- 55. Copyrights?3-shake Inc. All Rights Reserved. 55 まとめ ? Google の SRE は素晴らしい見本になる。でも、 SRE はウェットな部分も多いのが現実。 自分た ちの組織やメンバー構成を考えながら組織にあった最適な SRE を ? SRE を実現するにあたって「協働」は不可欠。他のチームと有機的に協働しながら SRE を 実現していこう ? SRE を始める時はなるべく小さく、手を付けやすいところから始めよう
- 56. Thank you