Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mission and Alliance for SRE in 40 (or more) minutes

Seigo Watanabe
October 07, 2021
1.2k

Mission and Alliance for SRE in 40 (or more) minutes

Seigo Watanabe

October 07, 2021
Tweet

More Decks by Seigo Watanabe

Transcript

  1. 40分+で分かった気になる
    SREのミッションとゆかいなSaaSの仲間たち
    - Mission and Alliance for SRE in 40 (or more) minutes -
    クラスメソッド株式会社 アライアンス統括部テックG
    渡辺聖剛
    2021.10.07

    View Slide

  2. SREしてますか!

    View Slide

  3. アジェンダ
    1. SREとは・サイトの信頼性とは
    2. SREのミッション
    3. SREの始め方
    4. SREが駆使するツール
    ○ 可用性の維持と計測
    ○ コストコントロール
    ○ コアバリューへのシフト
    5. まとめ
    3

    View Slide

  4. お断り
    ● 本セッションでは基本を抑えつつ、
    各現場で独自に展開頂くためのヒントをご紹介します
    ● 参加者全員の前提をそろえるために、
    基本的なところから周辺事情まで、幅広く扱います
    ● 少 々 駆け足となりますが、
    疑問点・不明点はお気軽にお尋ねください
    4

    View Slide

  5. 注意:最近(ここ半年程)何回か似た話をしてます
    一部、話やスライドの重複がありますが、
    そこは何卒ご容赦ください(新しい話もします!)
    https://dev.classmethod.jp/news/210609-sre-webinar/
    https://dev.classmethod.jp/news/gremlin-sre-webinar/
    5
    20分+で分かった気になるSREと「速度の時代」 30分で分かった気になるSREとカオスエンジニアリング

    View Slide

  6. 自己紹介 6
    渡辺聖剛 ( Seigo Watanabe )
    ● クラスメソッド株式会社
    アライアンス統括部テックG
    ● 運用/分析/モニタリング
    ● 前職までは
    いわゆるインフラエンジニア
    ● 好きな AWS サービス
    ○ ACM, Route 53
    ○ Amazon CloudWatch
    https://dev.classmethod.jp/author/watanabe-seigo/

    View Slide

  7. 1. SREと「信頼性」

    View Slide

  8. 8
    SRE = サイト信頼性エンジニアリング
    S R E
    Site
    サイト
    Reliability
    信頼性
    Engineering
    技術
    (or Engineer)

    View Slide

  9. 「信頼性(Reliability)」とは?
    ”正確さ(accuracy)・誠実さ(honesty)・実績(achievement)
    などにより、確信をもって頼りにされる・頼られる能力”
    利用者から「ここなら大丈夫だ」と思ってもらえること(性質)
    ブランドといっても良い
    9
    the ability to be relied on or depended on,
    as for accuracy, honesty, or achievement.
    Reliability | Definition of Reliability at Dictionary.com
    https://www.dictionary.com/browse/reliability

    View Slide

  10. 利用者(ユーザー)から信頼を得るには?
    ● 使いたいと思ったときにいつも使える
    ● 使っていてイライラしない
    ○ 欲しい機能がある、得られる内容が正確
    ○ 直感的にすぐ使える、画面遷移などで待たされない
    ● 不具合が放置されない、すばやく修正される
    ● 情報漏洩等のクリティカルな事故がない、もしあっても
    正しく誠実に対応される
    ● 素敵な新機能が定期的に実装される
    ● それらが継続して行われている
    10
    などなど...

    View Slide

  11. つまり...
    どちらか片方だけではダメ!
    ● 究極に安定したシステム → 枯れた「塩漬け」システム
    ○ 新機能は一切追加されない、不具合も放置されたまま
    ○ 周囲の変化に取り残される
    ● 究極に開発が進むシステム → 永遠の「アルファ版」
    ○ いつ止まっても文句は言えない
    ○ そのうち完成する、という期待感があるうちは…
    11
    素早い実装・修正
    《開発》
    安定したシステム
    《運用》

    View Slide

  12. ところで:ちょっと気になる 12

    View Slide

  13. 余談 13
    ほんとうに
    世間の要求性能・速度は加速しているのか?

    View Slide

  14. 本当にユーザーは時間に厳しくなったか?
    2012/11 : “3秒を過ぎると57%のユーザーが訪問を諦める”
    2021/05 : 「LCPは2.5秒以内がGOOD」
    ● LCP (Largest Contentful Paint) :
    ビューポート内に表示される最も大きいコンテンツのレンダリング時間
    概ね「3秒ルール」は変わってない...?
    The Cost of Poor Web Performance - SmartBear
    https://smartbear.com/blog/the-cost-of-poor-web-performance-infographic/
    Google Developers Japan: Core Web Vitals によるビジネス インパクト
    https://developers-jp.googleblog.com/2021/05/core-web-vitals.html
    14

    View Slide

  15. HTTPページの平均サイズの推移(‘10/11 → ‘21/09)
    Total Kilobytes - HTTP Archive: State of the Web
    https://httparchive.org/reports/state-of-the-web#bytesTotal
    ❖ デスクトップ向けで
    約4.7倍、モバイル
    向けは10倍+
    ❖ 何倍もリッチになっ
    たコンテンツを、
    以前と変わらない時
    間内に届けないとな
    らない
    Webサイトに求められ
    る処理性能(bps)は、
    確実に高くなっている
    15

    View Slide

  16. 「速いは正義」という時代
    「赤の女王」仮説
    ● 開発速度 ≒ 変化する/変化に対応する速度
    ● 処理性能(レスポンスタイム)の速さ
    資本主義は「赤の女王」である – アゴラ
    https://agora-web.jp/archives/516141.html
    鏡の国のアリス Through the Looking Glass: And What Alice Found There: Japanese
    https://www.genpaku.org/alice02/alice02j.html
    16
    “ここではだね、
    同じ場所にとどまるだけで、
    もう必死で走らなきゃいけないんだよ”
    ルイス・キャロル “鏡の国のアリス”

    View Slide

  17. 参考:2020年の「変化」by Zoom
    ● 1日あたりのミーティング参加者数が
    4ヶ月で30倍(1,000万 → 3億、‘19/12〜’20/04)
    ● 2020/04〜2020/12まで90回以上のリリース
    ● (おそらく)日本国内での
    利用ユーザー数の推移
    2020年を振り返って - Zoom Blog
    https://blog.zoom.us/ja/2020%E5%B9%B4%E3%82%92%E6%8C%AF%E3%82%8A%E8%BF%94%E3%81%A3%E3%81%A6/
    Zoom Releases By Date – Zoom Help Center
    https://support.zoom.us/hc/en-us/sections/360008531132-Zoom-Releases-By-Date?page=1#articles
    Zoom、GoogleMeetなどオンライン会議ツールの利用実態を調査 - マナミナ
    https://manamina.valuesccg.com/articles/1439
    17

    View Slide

  18. つまり : SREとは
    SRE = サイト信頼性 (Reliability) エンジニアリング
    高いレベルでサイトの信頼性を維持するために
    開発速度とサイトの安定性の両方をバランスさせるための技術
    (あるいは、その役割を担ったエンジニア)
    ● 安定しないサイトは信頼されない
    ● 過剰な安定性は開発速度Down (やっぱり信頼されない)
    ● 開発(機能実装)最優先のサイトはなかなか安定できない
    18

    View Slide

  19. ...とはいえ
    実際にはどうすれば?

    View Slide

  20. ヒント : Ben Treynor Sloss 曰く
    Google Cloud Day: Digital ‘21 セッション「SREの基本と組織への導入」資料より
    https://dev.classmethod.jp/articles/202105-report-gcd21-d3-infra-01/
    20
    ・現Google副社長
    ・2003年に入社しSRE部門やデータセンター部門その他を率いる
    ・SRE本の執筆者のひとり
    https://www.linkedin.com/in/benjamin-treynor-sloss-207120

    View Slide

  21. ソフトウェアエンジニアに運用設計を依頼すると
    いったい何が起きるんだ...?

    View Slide

  22. モダンなソフトウェアエンジニアを取り巻く2つの要素 22
    DevOps
    「永遠の未完成」をささえる技術
    Cloud技術 (X-as-a-Service)
    設備・性能・コストの柔軟化・最適化
    両者とも、「システム開発」を加速させるために誕生・進化してきた
    ○ 開発と運用の密接な連携、迅速な方針決定
    ○ 短いリリース間隔、継続した開発 (CI/CD)
    ○ 心理安全性が高く保たれた組織文化がベース
    ○ ソフトウェアで定義されたインフラストラクチャ
    ○ APIによる高度かつ柔軟なコントロール
    ○ リソースの調達・破棄が短時間で完了
    Cloud技術が成熟してさらに重要に DevOps側の要求に適応した進化
    ChatOps, GitOps, Infrastructure-as-Code
    サービスの全レイヤをAPIコントロール
    サーバーレス, マイクロサービス, 可搬コンテナ
    アプリレイヤとインフラレイヤの明確な分離
    この2つが SRE の土台となる

    View Slide

  23. つまり : SREとは
    DevOpsとCloud技術が先鋭化したなかで生みだされた概念
    ● DevOpsを安定かつ高速に回転させるために、
    ● Cloud技術をはじめ様々なツールを駆使することで、
    ● 信頼性を適切に維持・コントロールする技術 / 役割
    ➢ リリースしても・不具合が生じても止まらないシステム
    ➢ 不具合があればすぐ対処・修正できる運用・開発体制
    ➢ 異常発生を素早く検出、自動的に対処
    ➢ 手戻り・ブロックの少ない俊敏な開発サイクル
    23

    View Slide

  24. 言い換えると
    「ソフトウェアエンジニアに運用設計を
    依頼すると起きること」とは...
    ● 開発現場で行われた「DevOps化」が
    運用の現場に適用されること
    ○ 情報伝達の効率化、手作業領域の極小化・定型作業の自動化
    ○ 運用手順のリファクタリングと
    パフォーマンスチューニング・最適化
    24
    ※当時 (2010年前後〜) のGoogleの基本戦略
     「最高のソフトウェア開発者に(高給払って)オンコール対応させて、
     彼ら自身が嫌にならない環境を爆速で開発してもらおう」

    View Slide

  25. でもそれ、
    Googleさんだからできる事ですよね...

    View Slide

  26. よく言われます(ました?)
    ● 特に最初の翻訳本が出た2017年頃
    (正直、ぼくも思いました)
    ○ オンコール業務を工数50%以下?
    SLOにエラーバジェット?
    上層部にそんなの理解されないし...
    ○ 運用自動化しても使われない、
    作ったひとにメンテナンスが集中
    するだけで楽にならない...
    結果、単に「インフラエンジニア2.0」
    「品質管理2.0」的に扱われる事例多数
    O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
    https://www.oreilly.co.jp/books/9784873117911/
    26
    (※要出典)

    View Slide

  27. その後「実践SRE」的な本もでました (2018年)
    ● いろいろな規模/形態の組織で
    実践されています
    ○ Googleモデル
    ○ Pure SRE
    ○ Embedded SRE
    ○ SREロール etc.
    ● 国内事例もいろいろ載ってます
    少しずつ国内事例も増えてきつつ、
    本来のSREもじわじわと浸透...
    O'Reilly Japan - サイトリライアビリティワークブック
    https://www.oreilly.co.jp/books/9784873119137/
    27

    View Slide

  28. 更に:SREについての最強のまとめ本もでました
    訳 :渡邉了介氏
    監訳:山口能迪氏
    2021/09
    SREの導入など技術論のみならず、
    DevOpsとの比較、アンチパターン、
    周辺領域、組織論から雇用、採用、
    評価からメンバーのヘルスケアまで、
    あらゆる項目を網羅した究極の一冊
    O'Reilly Japan - SREの探求
    https://www.oreilly.co.jp/books/9784873119618/
    28
    NEW

    View Slide

  29. 余録:「SREの探求」目次 29
    本書への推薦の言葉
    監訳者まえがき
    はじめに
    第I部 SREの導入
    1章 SREにおけるコンテキストとコントロール
    2章 サイトリライアビリティエンジニアの面接
    3章 なるほど、SREチームを作りたいのですね
    4章 インシデントのメトリクスを用いたSREの大規模な改善
    5章 サードパーティとの協力を円滑に進める重要性
    6章 専任SREチームなしでSREの原則を適用する方法
    7章 SREのいないSRE:Spotifyのケーススタディ
    8章 大企業におけるSREの導入
    9章 25ページでシステム管理者からSREへ
    10章 大企業でSRE導入の道を開く方法
    11章 DevOpsの幅広い実践現場で活用されているSREのパターン
    12章 DevOpsとSRE:コミュニティからの声
    13章 Facebookにおけるプロダクションエンジニアリング
    第II部 SREの周辺領域
    14章 初めにカオスありき
    15章 信頼性とプライバシーが交わるところ
    16章 データベースリライアビリティエンジニアリング
    17章 データ耐久性のエンジニアリング
    18章 SREのための機械学習入門
    第III部 SREのベストプラクティスと技術
    19章 ドキュメント作成業務の改善:エンジニアリングワークフローへのドキュメンテーションの統合
    20章 アクティブなティーチングとラーニング
    21章 サービスレベル目標の技法と科学
    22章 成功の文化としてのSRE
    23章 SREのアンチパターン
    24章 イミュータブルなインフラストラクチャとSRE
    25章 スクリプタブルロードバランサー
    26章 サービスメッシュはマイクロサービスの世話人か
    第IV部 SREの人間的側面
    27章 SREにおける心理的安全性
    28章 SREの認知的作業
    29章 燃え尽きを超えて
    30章 オンコール反対論
    31章 複雑なシステムのためのエレジー
    32章 運用と社会運動が交わるところ
    33章 まとめ
    コラム SREであることを自覚するのは……
    4章 インシデントのメトリクスを用いたSREの大規模な改善
    6章 専任SREチームなしでSREの原則を適用する方法
    12章 DevOpsとSRE:コミュニティからの声
    19章 ドキュメント作成業務の改善:
    エンジニアリングワークフローへのドキュメンテーションの統合
    22章 成功の文化としてのSRE
    23章 SREのアンチパターン
    27章 SREにおける心理的安全性
    29章 燃え尽きを超えて
    30章 オンコール反対論
    31章 複雑なシステムのためのエレジー(elegy = 悲歌、哀歌)
    https://www.oreilly.co.jp/books/9784873119618/
    SREであることを自覚するのは…… (抜粋)
    ・最初の質問として「それをどのように計測していますか」が口をついて出る時
    ・自分の個人ブログが複数のAWSリージョン障害にも耐えられる時
    ・決まりきった運用作業を自動化するという根拠でロボット掃除機の購入を
     正当化する時
    ・利用している電力会社のSLOがどのようなものか気になる時

    View Slide

  30. これらの本を読むと...
    SREの仕事は非常に多岐に渡り、
    高度な技量と聖人のような精神力が必要に思えますが...
    ● あくまで事例です
    ● SRE (Engineering) の全てをこなせるひとでないと
    SRE (Engineer) になれない、というわけではありません!
    ● 適用組織に対しても同様です
    出来るところだけCherry-Pickして
    出来るところから始めていきましょう!
    30

    View Slide

  31. 31
    ここまでのポイント
    SREとは、以下を「サイト運用」に活用すること
    ● DevOpsのノウハウ
    ● Cloud技術・インフラ
    その目的は、以下を実現すること
    ● 安定したサービス提供・運営
    ● 素早い開発・リリース
    3冊の本はおすすめ、特に3冊目

    View Slide

  32. 2. SREのミッション

    View Slide

  33. 33
    ミッション = 果たすべきこと
    安定な運用と開発
    → 究極に目指す場所
    DevOpsとCloud技術
    → 目の前にある手法
    「目指す場所」にたどり着くために、
    「目の前にある手法」を使って、
    SREは何をすればいいのか。。。
    https://pxhere.com/en/photo/930678

    View Slide

  34. 34
    SREの原則
    SRE本の章タイトルから読み取ると...
    ● リスクを許容しコントロールする (エラーバジェット)
    ● サービスレベル目標 (SLO)
    ● トイルの撲滅
    ● モニタリング・可観測性(オブザーバビリティ)
    ● 自動化 - 手作業の不確かさとオーバーヘッドの除去
    ● 品質の高いリリース(リリースエンジニアリング)
    ● 単純さ = シンプルに保つ
    Part II. Principles - Google - Site Reliability Engineering
    https://sre.google/sre-book/part-II-principles/

    View Slide

  35. 35
    SREの手法のでよくふれられるところ
    SRE本の章タイトルから読み取ると...
    ● リスクを許容しコントロールする (エラーバジェット)
    ● サービスレベル目標 (SLO)
    ● トイルの撲滅
    ● モニタリング・可観測性(オブザーバビリティ)
    ● 自動化 - 手作業の不確かさとオーバーヘッドの除去
    ● 品質の高いリリース(リリースエンジニアリング)
    ● 単純さ = シンプルに保つ
    Part II. Principles - Google - Site Reliability Engineering
    https://sre.google/sre-book/part-II-principles/

    View Slide

  36. 36
    ここに注目
    SRE本の章タイトルから読み取ると...
    ● リスクを許容しコントロールする (エラーバジェット)
    ● サービスレベル目標 (SLO)
    ● トイルの撲滅
    ● モニタリング・可観測性(オブザーバビリティ)
    ● 自動化 - 手作業の不確かさとオーバーヘッドの除去
    ● 品質の高いリリース(リリースエンジニアリング)
    ● 単純さ = シンプルに保つ
    Part II. Principles - Google - Site Reliability Engineering
    https://sre.google/sre-book/part-II-principles/

    View Slide

  37. 37
    トイル(Toil) = 価値を生まない作業
    ● プロダクションサービスに関係
    ● 自動化が可能なのに手作業で行われている
    ● 長期的な価値をもたない・価値を生み出さない
    こういうものを「トイル(toil = 労苦)」と定義
    “トイルとは、プロダクションサービスを動作させることに
    関係する作業で、手作業で繰り返し行われ、自動化することが
    可能であり、戦術的で長期的な価値を持たず、作業量がサービ
    スの成長に比例するといった傾向を持つものです。”
    Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

    View Slide

  38. 38
    トイルの撲滅は結果であり動機である
    トイルの撲滅 = 運用のリファクタリング
    ● DevOpsで「ベストプラクティス」といわれることを
    運用に対しても行う
    ● 運用の改変に伴うリスク = エラーバジェットで吸収
    ○ エラーバジェットの計測にはSLI/SLO
    ○ きちんと計測するために可観測性(オブザーバビリティ)
    ● もちろんDevOpsもきっちり回す
    ○ = リリースエンジニアリング・シンプルさ
    ○ SREとDevOpsはずぶずぶの関係(語弊)
     トイル撲滅のためにあらゆる手段手法を駆使 

    View Slide

  39. トイルの撲滅、といったものの...
    トイルは「最小化」を目標にする
    ● 「無くす」ではない
    ○ 無理に無くしたことで非効率になる場合もある
    ● Google : トイルに費やす時間を 50% 以下にする
    ○ 残りの時間でコードを書く
    ○ 書かれたコードでトイルを減らす
    トイルが多すぎるとメンバーが疲弊することも...
    “チームの仕事の流れにあまりに多くのトイルを組み込んでしまう
    と、それはチーム内の最高のエンジニアに対し、もっと報われる
    仕事を他のところで探すようにすすめているようなものです。”
    Betsy Beyer “SRE サイトリライアビリティエンジニアリング”
    39

    View Slide

  40. 40
    ここまでのまとめ
    ● SREのミッション = トイルの撲滅
    ● SREは「信頼されるサイト」のために、
    あえてトイルの山に飛び込みそれを減らすことを
    ミッションとしている
    ● トイルを減らすための道具がたくさんある
    ○ エラーバジェット、SLI/SLO、可観測性...
    ● SREのヘルスケアも忘れずに!
    ○ トイルの撲滅はSREのミッションだが、
    サービスの運用はチームの仕事です!
    ○ SREは専務しわ寄せられ役ではない、との共通認識を
    あとお給料も上げてあげてください

    View Slide

  41. 3. SREの始め方

    View Slide

  42. 42
    SREの守備範囲
    守備範囲 = 「サイト (Site)」
    ● 「システム (System)」ではない(内包している)
    ○ 狭義でいえばサイト = システムでも誤りではない
    ● インフラから開発体制、サービスまで含む
    ○ ユーザーが使っているのは「サービス」
    ○ サーバー1台、プログラム1本を意識して使っていない
    サービス(プロジェクト)全てがSREの守備範囲の「候補」
    ※必ずしもそうあるべき、というものはない

    View Slide

  43. いろいろなSREのかたち
    Pure SRE
    (Google Model)
    ... SRE専門チーム
    Embedded SRE ... 各開発チームに所属するSRE
    (役割としての) SRE ... 各開発チームのメンバーが
    SREとして働く・兼務する
    43
    ※(もちろん)混在事例も多数
    SRE-iously: Defining the Principles, Habits, and Practices of Site Reliability Engineering
    https://www.slideshare.net/newrelic/sreiously-defining-the-principles-habits-and-practices-of-site-reliability-engineering-112178269
    The Many Shapes of Site Reliability Engineering | by Rob Cummings | Slalom Build | Medium
    https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517
    開発チームとともに歩む SREチームが成し遂げたいこと | メルカリエンジニアリング
    https://engineering.mercari.com/blog/entry/20210129-embedded-sre/

    View Slide

  44. 答えはひとつじゃない
    ● 全体を統括する部署でもいいし、
    各チームに埋め込まれてもいい
    ● 開発者でもいいし運用担当でもいいし、
    単なる助言役でもいい
    既に、SREと呼ばれないままSRE的な役割を担っている
    メンバーがいるのでは?
    ● そのようなひとを正しく評価し後押しすることも、
    広義の「SRE」です
    44

    View Slide

  45. 忘れてはならないこと
    あくまで「エンジニアリング」
    ● 理論に裏打ちされていないうちは、技術ではない
    ● 根性論・精神論は意味をなさない(トイルを増やすだけ)
    SREの仕事は「強制」ではない
    ● 提案の押しつけはトイルの増加を招きかねない
    ● 「銀の弾丸はない」
    ○ その提案が現場にあうかどうかはケースバイケース
    ○ 最初はある程度の権威付け・強制力を持たせたほうが
    スムーズに行くケースも...?
    ● チームが自律できるようにガードレールを設置
    45

    View Slide

  46. 忘れてはならないこと (cont.)
    SREには「発言力」を持たせることが重要
    ● SRE・現場・上層部の相互理解・信頼が大切
    ○ 開発・運用・ビジネスがワンチームであること
    ● SRE自身にも「説得スキル」が必要
    ○ チーム内で目的意識を共有させる技術
    理想 : お互いの信頼の元で提案し、試しに採用する
    ● 良ければ永続化、合わないなら見直し
    ○ クラウド・SaaSは試行がしやすい
    ● 組織内の「心理的安全性」が重要
    参考 : Google re:Work - ガイド: 「効果的なチームとは何か」を知る
    https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/
    46

    View Slide

  47. 47
    思い出して欲しいのが
    SRE = サイト運用の現場にDevOpsを持ち込むこと
    DevOpsのCALMSモデル
    ● Culture
    ● Automation
    ● Lean (IT)
    ● Masurement
    ● Sharing
    ※「SREの探求」にはDevOpsとSREを比較する章があります
    Download our diagram CALMS Model of DevOps | DevOpsGroup
    https://www.devopsgroup.com/insights/resources/diagrams/all/calms-model-of-devops/
    DevOpsでも組織文化が重要
    SREで大切でないはずがありません

    View Slide

  48. SREにとって重要な能力
    ● ソフトウェアエンジニアとしての能力
    ○ コードを読む・書く能力
    ● 全レイヤの知識
    ○ アプリケーション
    ○ OS・ネットワーク
    ○ コスト・ビジネス感覚
    ● コミュニケーション能力・リーダーシップスキル
    ● そのサービスの最適化への情熱
    ※全てを備えた人材はそうそういない!
     という前提に立つことが出発点です
    48

    View Slide

  49. 4. SREが駆使するツール
    ❏ 可用性の維持と計測
    ❏ コストコントロール
    ❏ コアバリューへのシフト

    View Slide

  50. (要は)
    実際どうやるの?

    View Slide

  51. SREのお仕事 = サイトの信頼性の維持
    ● サイト全体の計測
    ● 信頼性が維持されていることを確認
    ● 信頼性を下げそうなこと(トイル)をつぶす
    ○ システムの安定性
    ■ 運用環境の最適化・リファクタリング
    ● 自動化
    ● ドキュメントやランブックの整備
    ■ オンコール対応
    ● 信頼性に直結したフィードバックが手に入る
    ○ 開発速度
    ■ リリースサイクルのコントロール
    ■ リリース環境のチューニング
    ● コードは自分で(も)書く
    道具(ツール)
    ・SLI / SLO
    ・エラーバジェット
    ・Cloud技術
    ・OpEx
    ・言語・SaaS
    51

    View Slide

  52. キーワード
    ● 可用性の維持と計測
    ○ SLI / SLO / エラーバジェット
    ○ 可観測性(Observability)と監視(Monitoring)
    ● コストコントロール
    ● コアバリューへの内製能力のシフト
    以下は話しません
    ● 自動化・DevOpsそのもの
    ● 組織的・人事的な話
    ● 上にあげた項目の細かな内容
    52

    View Slide

  53. 可用性の維持と計測

    View Slide

  54. 「信頼性の保たれている状態」とは?
    ユーザーの信頼に応えられている状態
    二律背反の命題
    100%ではなく、「ここまでなら OK 」というポイントを
    見極める必要がある
    ➡ エラーバジェットを使ってコントロール
    54

    View Slide

  55. エラー予算(エラーバジェット)という考え方
    ● サイトを変化させるために利用できる「予算」
    ○ リリースによる計画停止、見込み不具合
    ○ 発生した障害の回復に必要とした時間(自動・手動)
    ● 設定したウィンドウ(ex: 直近30日)内で「達成率」を計測
    (現在の達成率) - (目標とする達成率)
    ex) 現在 99.95%、目標 99.90%
      → エラーバジェット 0.05%
    Google Cloud Day: Digital ‘21 セッション「SREの基本と組織への導入」資料より
    https://dev.classmethod.jp/articles/202105-report-gcd21-d3-infra-01/
    55

    View Slide

  56. 「達成率」?
    SREでは SLI・SLO という考え方をします。
    SLI
    Service Level Indicator
    何をもって「正常」を定義するか / 何を使えば測れるか
    ex) Webサイトのレスポンス速度、ステータス、応答コード、
    総有効アクセス数における理想的なレスポンスの割合
    SLO
    Service Level Objective
    SLIがどうであった時に「正常」と見なすのか
    SLIと1対1で設定、部内での目標値(達成が目的ではない)
    SLA
    Service Level Agreement
    顧客との約束
    端的には返金基準
    56
    エラーバジェット =
    SLO 違反となるまでに許容できる時間やエラーの量

    View Slide

  57. SLIは利用者目線で設定する
    ● 例1 : CUJ(クリティカルユーザージャニー)から検討
    ○ 「利用者がこのシステムを利用して成し遂げたいことは?」
    ● 例2 : 故障モード(failure mode)・FMEA
    ○ 「どのような状態になったら『異常』となるのか?」
    利用者からすれば、
    CPU利用率が100%だろうがWebサーバが1台落ちてようが、
    目的が達成できるなら「故障ではない」し、その逆も真
    SLO の定義 | Cloud アーキテクチャ センター | Google Cloud
    https://cloud.google.com/architecture/defining-SLOs?hl=ja
    [レポート] 行き先は火星?木星? 移住計画用マイクロサービスを AWS サービスで構築・管理する | DevelopersIO
    https://dev.classmethod.jp/articles/201912-report-reinvent-2019-ent308/
    FMEA(故障モード影響解析 )とは?評価法や実際の流れを解説 | 金属加工の見積りサイト Mitsuri(ミツリ)
    https://mitsu-ri.net/articles/fmea_toha
    57

    View Slide

  58. サービスにあった適切なSLI/SLOを
    ● 過剰品質はコストに反映、結局は顧客のためにならない
    ● 大事なことは、利用者の信頼を落とさないこと
    “SRE では 100% の信頼性は期待されていません。
    失敗は予測済みで、許容されます。”
    “99% の信頼性を持つスマートフォンを使っているユーザーには、
    サービスの信頼性が 99.99% の場合と、99.999% の場合との
    違いは分からない”
    Betsy Beyer “SRE サイトリライアビリティエンジニアリング”
    58
    SRE とは
    https://www.redhat.com/ja/topics/devops/what-is-sre

    View Slide

  59. 59
    参考) ドミナント・ロジック
    2005年頃から
    ● グッズ・ドミナント・ロジック
    ○ 提供される「モノ」に価値を置く
    ○ モノが壊れていたら価値が提供できない
    = 暗黙の可用性100%
    ● サービス・ドミナント・ロジック
    ○ 提供される「サービス」「体験」に価値を置く
    ○ モノだけでなく、提供形態やトータルの「居心地」が重要
    目指すところはこの考え方に近い
    サービス・ドミナント・ロジック:先進企業事例に見る「価値づくり」の世界観
    | 価値共創が生み出す競争優位の源泉| DIAMOND ハーバード・ビジネス・レビュー
    https://www.dhbr.net/articles/-/2698

    View Slide

  60. 参考) Everything fails all the time
    全てのものはいつかは壊れる、という前提に立って、
    壊れたときの影響を最小にする設計と運用を行うことで、
    真に「壊れない」システムを構築する
    60

    View Slide

  61. SLO・エラーバジェットはあくまで目安・目標値
    エラーバジェットが...
    ● ひっ迫 = 新規リリースを一時ストップし調整
    ● 超過  = 原因の確認と改善(コード、運用)
    ● 下回る = 過度・過剰に余裕をもっていないか見直し
    ○ より多くのリリースを実施、挑戦的な機能の実装
    ○ バジェットを減らす方向にSLOの数値を調整
    継続して計測し全体計画に反映させる
    達成することが目的ではありません❗
    61
    信頼性 UP❗

    View Slide

  62. 3 Pillars of Observability
    可観測性(オブザーバビリティ / Observability)
    「システムを総合的・多角的にモニタし継続して分析する」
    そのための機能(性質)をシステムが備えていること
    Metric
    CPU%, Mem Usage,
    Traffic, Counter
    Log
    高コンテキスト
    アプリ/インフラログ
    Trace
    複数箇所からの関連
    するデータを連結
    Blackbox
    外部/インフラスト
    ラクチャからの計測
    Whitebox
    アプリ内部の計測
    データ・APM
    Frontend
    合成(Synthetic)監視
    RealUser Monitoring
    可視化
    グラフ化, 分類, 図示
    ダッシュボード
    分析
    相関, 推移・傾向予測,
    ふるまい検出, Severity
    通知(Action)
    通知(アラート/on-call),
    自動処理(failover/recovery)
    62
    4 Golden Signals
    Latency, Errors,
    Saturation, Traffic
    3 Dimmensions
    Functionally,
    Availability, Speed

    View Slide

  63. 監視(Monitoring)と可観測性(Observability)
    ● 監視 ... 観測地点で異常が発見されたら通知 → 対処
    ● 可観測性 ... 定常状態をひろく観測、備える
    https://flic.kr/p/hRLTUV
    https://stocksnap.io/photo/senior-running-KVQQJKRXZW
    監視
    Monitoring
    可観測性
    Observability
    63
    ・比較的少数の計測
     (痛み、気分、体温)
    ・異常(閾値超え)を検知
     し病院へ
    ・病院で検査
     (血圧、心拍数 ...)
    ・検査結果に基づいて
     対処
     (薬の処方 etc.)
    ・多数の計測ポイント
     (歩数、心拍数 ...)
    ・日常的に状態をモニタ
    ・過去との比較
    ・比較から未来予測
    ・異常を起こさないよう
     先手の対策
     (継続した体調管理)

    View Slide

  64. 監視ではだめなんですか?
    “Monitoring means that
    you already know what is
    important.
    何が重要でどうなったら異常
    なのか、既に分かっている
    場合にのみ監視は有効だ”
    —— Dr. Werner Vogels.
    [レポート] オペレーション、監視 (Monitoring)、可観測性(Observability)… AmazonのCTOは 
    AWS re:Invent 2020のキーノートでどう語ったか? キーワードを拾ってみた #reinvent | DevelopersIO 
    https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/
    64

    View Slide

  65. つまり?
    ● 固定的な閾値設定による異常検知だけでは十分ではない
    ○ 障害の予測ができない・十分な精度を保てない
    ○ 個々の閾値を調整し続ける必要がある
    ● 観測対象が爆発的に増加 → 従来型監視の維持は困難
    ○ サーバーレス / コンテナ (Kubernetes)
    ○ マイクロサービス(疎結合・非同期)
    ○ 外部APIサービス(SaaS) / マネージドサービス
    ○ 単一の事象による大量のアラート
    ● (もちろん) 既知の事象をとらえるためには引き続き必要
    ○ 監視ポイントを見直す必要がある
    https://twitter.com/Werner/status/741673514567143424
    65

    View Slide

  66. 監視と可観測性の使い分け
    (真に)起きてはまずい事象
     監視し即対応アラート
    Root Cause調査、
    周辺事象、
    将来予測
     可観測性(オブザーバビリティ)を高め継続してデータを収集
     予測された事象に対して警告通知
    66

    View Slide

  67. 監視 + 可観測性のイメージ
    LB
    CDN
    Application
    DB
    Storage
    DNS
    Network
    Backend
    Synthetics
    Log
    VM / コンテナ
    APM
    インフラストラクチャ
    Infrastructure
    可観測性
    Observability
    可視化
    分析
    通知(Act.)
    Code Repo
    CI/CD
    JS
    RUM
    67
    Integration
    監視
    Monitoring
    既知の事象
    起こってはならない事象

    View Slide

  68. 【PR】弊社があつかう監視・可観測性プロダクト 68
    見やすく直感的なダッシュボード
    純国産・日本語フル対応
    簡単な導入と豊富な拡張性・URL外形監視
    クラウドインフラ向けインテグレーション
    定番の可観測性プラットフォーム
    強力なAPM
    インフラから合成監視、RUM、Log
    広い無料枠と開始しやすい価格体系
    https://classmethod.jp/partner/mackerel/
    https://classmethod.jp/partner/newrelic/

    View Slide

  69. ところで、 69
    可観測性といっしょに
    カオスエンジニアリングは
    いかがですか?

    View Slide

  70. カオスエンジニアリングとは
    Chaos Engineering
    特定の環境(システム)に意図的に異常を発生させることで、
    その環境がどのような反応をするかを継続的に検証する(実験)
    ● 監視システムは意図した通りに検知したか?
    ● 自動復旧システムは意図した通りに機能したか?
    ● マニュアル通りの対処で想定内に復旧したか?
    ● ユーザー(利用者)への影響は想定の範囲内に収まったか?
    ● 想定していない不具合の引き金にならなかったか?
    70

    View Slide

  71. カオスエンジニアリングはSREを補強する
    ● サイトの信頼性(Reliability)を高く維持するために、
    SREはあらゆる事象を想定して対処しなくてはならない
    ● とはいえ、いわゆる「カバレッジ100%」は実質不可能
    ○ 開発の機動性も落としてしまう
    ● よく聞く言葉「やってみないとわからない」
    ● 実際に「やってみる」ことで、
    意図しない事象の発生をとらえたり、
    意図しない事象が発生しないことを確認する
    71

    View Slide

  72. カオスエンジニアリングの始め方
    1. 「定常状態」を定義
    ○ ex) フロントエンドのリクエスト応答時間(p99)は 500ms
    2. 定常に対する仮説
    ○ プロセスが1つ落ちても、応答時間は影響がないか、
    あるいは 1s 以内に正常値にもどるはずだ
    3. 実験を行う(障害のシミュレート)
    ○ カオスエンジニアリングツールなどを利用
    4. 実験により得られたデータを元に仮説を検証
    フィードバック
    5分で学ぶ: カオスエンジニアリングの説明書 - New Relic公式ブログ
    https://blog.newrelic.co.jp/engineering/chaos-engineering-explained/
    72
    データを得るためには
    可観測性が備わってないとダメ

    View Slide

  73. 監視 + 可観測性 + カオス実験
    LB
    CDN
    Application
    DB
    Storage
    DNS
    Network
    Backend
    カオスエンジニアリング
    Synthetics
    Log
    VM / コンテナ
    APM
    インフラストラクチャ
    Infrastructure
    可観測性
    Observability
    可視化
    分析
    通知(Act.)
    Code Repo
    CI/CD
    JS
    RUM
    73
    Integration
    監視
    Monitoring
    既知の事象
    起こってはならない事象

    View Slide

  74. 【PR】カオスエンジニアリングを実現するツール
    AWS Fault Injection Simulator
    74

    View Slide

  75. Gremlin  とAWS FIS
    Gremlin
    カオスエンジニアリングの先駆者
    AWS FIS(Fault Injection Simulator)
    W-A「信頼性の柱」
    ○ 創業者のコルトンCEOは元Netflix
    (その前はAWS)
    ○ カオスエンジニアリングはNetflixが発祥
    (2012年にChaos MonkeyをOSS化)
    ○ 広い適用範囲と無料枠
    ○ AWS re:Invent 2020にて発表
    2021/03より提供開始
    ○ Well-Architected Framework「信頼性の柱」に
    おいて、可観測性や継続化(CI/CDとの組合せ)が
    語られている
    カオスエンジニアリングツール「 Gremlin」 | クラスメソッドのパートナー
    https://classmethod.jp/partner/gremlin/
    ついにAWSがマネージドなカオスエンジニアリングサービスを発表したぞ #reinvent | DevelopersIO
    https://dev.classmethod.jp/articles/coming-soon-fault-injection-simulator/
    75
    多種多様な障害パターンを網羅 AWS環境に特化・高い親和性
    特にアプリケーション側に強み
    サーバーレスやオンプレ・マルチクラウドに
    AWS Systems Manager等のサービスと統合
    AWSインフラに対する障害注入実験が可能

    View Slide

  76. コストコントロール

    View Slide

  77. コストの最適化もSREの仕事
    適正運営のためにはコストは価格に反映せざるを得ない
    ➡ 過剰にコストをかけることも顧客のためにならない
    ● 余剰コストの削減
    ○ きめ細かな余剰リソースのコントロール
    ○ AutoScaling・サーバーレス・自動化の促進
    ○ 「価値を生まない手作業(トイル)」の削減
    ● 過剰な内製をやめて適切にアウトソーシング
    ○ マネージドサービスやSaaSの利活用
    ○ 開発リソースはコアバリューに集中 → 真の「内製化」
    77

    View Slide

  78. CapEx -> OpEx
    ● CapEx (Capital Expenditure) ... 設備投資
    ○ 資産として購入(オンプレミス)、専門の人員の確保
    ○ 長期的な予測が必要
    ○ ゼロにはできない
    ● OpEx (Operating Expense) ... 運用経費
    ○ サービス利用(クラウドインフラ、SaaS)
    ○ 短いスパンで負荷・需要と利用費を合致させることが可能
    ○ 継続した監視とコントロールが必要
    企業活動における CAPEXとOPEXの定義 | クラウドERP実践ポータル
    https://www.clouderp.jp/blog/what-is-capex-opex
    クラウド費用の最適化 : 成功し続けるための諸原則 | Google Cloud Blog
    https://cloud.google.com/blog/ja/products/gcp/cost-managementprinciples-of-cloud-cost-optimization
    78

    View Slide

  79. 79
    CapExが悪者、というわけではない
    ● 同じ期間で同じ内容なら、一般的にCapExのほうが安い
    ○ 長期利用によるコスト圧縮が効く
    ○ AWSでいうところの RI や SP の活用はコスト削減の定石
    ● OpExの強みは「キメの細かなコントロール」
    ○ 負荷に応じて柔軟に増やし、減らす
    ○ 無駄に起動したままに
    しない
    ○ Auto Scalingに例えるなら
    EC2よりFargate/Lambda
    という議論に似ている
    AWS re:Invent 2019 - Dr. Werner Vogels による基調講演 | AWS (日本語字幕) - YouTube
    https://www.youtube.com/watch?v=NKW-q7FE2rc

    View Slide

  80. 80
    SRE視点からみたコストコントロール
    長期的視点から、要所を押さえた CapEx の利用
    柔軟なコントロールを効かせるための OpEx の活用
    ● 可観測性によりリソース利用の傾向を把握
    ● コストを最適化:必要なところに振り分ける
    ○ どんなインフラが最適か?
    ○ コードに無駄はないか?
    ○ ひとを雇うのとSaaSを活用するのとどちらが得か?
    etc...

    View Slide

  81. コアバリューへの内製能力のシフト

    View Slide

  82. 想像してみて下さい
    仮に、貴方が何か素敵なサービスを作るとなったとき
    82
    Awesome
    Service

    View Slide

  83. インフラ!
    想像してみて下さい (cont.)
    動かすためのインフラも用意する必要がありますが、
    この部分は、今はだいぶ楽になりました(選択肢的な意味で)
    ● パブリッククラウド
    ● FaaS・サーバーレス
    コンテナ・k8s
    83
    Awesome
    Service

    View Slide

  84. 想像してみて下さい (cont.)
    でも、考えなくてはならないものは他にもいっぱいあります
    これらを作り込まないとサービスインできない ...?
    84
    Awesome
    Service
    認証
    管理統制
    コンプライアンス
    モニタリング
    ログ管理
    セキュリティ
    通知
    メール SMS
    サポート
    コミュニケーション
    BI
    データ分析
    コード
    リポジトリ
    テスト
    CI/CD
    プロビジョ
    ニング
    コンテンツ
    再生
    課金
    ログイン

    View Slide

  85. そもそも:何がやりたかったんだっけ?
    提供したい【コアバリュー】は、素敵なサービス!
    できる限りそこに注力したい…
    85
    認証
    管理統制
    コンプライアンス
    モニタリング
    ログ管理
    セキュリティ
    通知
    メール SMS
    サポート
    コミュニケーション
    BI
    データ分析
    コード
    リポジトリ
    テスト
    CI/CD
    プロビジョ
    ニング
    コンテンツ
    再生
    課金
    ログイン
    Awesome
    Service
    Core Value!

    View Slide

  86. そこで : 現状の(弊社が考える)最適解
    内製すべき「コアバリュー」はきっちりと 内製 する
    それ以外は SaaS でカバー!
    86
    認証
    管理統制
    コンプライアンス
    モニタリング
    ログ管理
    セキュリティ
    通知
    メール SMS
    サポート
    コミュニケーション
    BI
    データ分析
    コード
    リポジトリ
    テスト
    CI/CD
    プロビジョ
    ニング
    コンテンツ
    再生
    課金
    ログイン
    Awesome
    Service
    Software-as-a-Service
    SaaS!
    Core Value!

    View Slide

  87. 87
    極端な話
    コンピューターの歴史は
    「汎用部品の共通化・アウトソース」の歴史
    設置場所 マシンルーム → データセンター
    インフラストラクチャ オンプレミス → クラウドインフラ
    OS ハードウェア付属(!) → 汎用OS (→ OSS)
    ミドルウェア パッケージ (→ OSS) → マネージドサービス
    開発言語 専用(!) → 汎用言語
    特定機能 作り込み → ライブラリ → モジュール → SaaS
    Webフレームワーク 内製 → 汎用

    View Slide

  88. クラウドマネージドサービス
    パブリッククラウド各社はインフラ (IaaS) だけでなく
    各種分野向けのマネージド(管理された)サービス群を展開
    ● データベース(RDBMS, NoSQL, GraphQL, 時系列DB ...)
    ● データ分析基盤・DWH・可視化
    ● 機械学習(ML)・AIサービス(自然言語処理, 機械翻訳 ...)
    ● 認証基盤・セキュリティ
    ● 運用・環境管理統制・コストマネジメント 等々
    クラウドベンダーによってラインナップに特色があります
    AWS の製品・サービス一覧 | クラウドなら AWS
    https://aws.amazon.com/jp/products/
    88

    View Slide

  89. SaaS - Software as a Service
    ● 必要な機能を素早く組み込む「ショートカット」
    ○ 一昔前のライブラリやパーツ、ミドルウェア、
    フレームワークのような位置づけ
    ○ クラウドインフラの「マネージドサービス」もその一種
    ● いわば「最新鋭の安定した機能と専属の運用チームの
    両方を、従量課金で利用する仕組み」
    “SaaS を使えば数分で動く仕組みが手に入り、しかも
    始めたタイミングからドキュメントなども手に入ります。”
    Mike Julian “入門 監視”
    89

    View Slide

  90. SREっぽい事例:水曜どうでしょう祭
    ● 開発期間と必要とする機能・セキュリティのバランス
    ● 内製リソースはコアバリューに注力
    ● 有料配信サービスの準備がほぼ 1ヶ月 で整う
    90
    HTB北海道テレビ放送|水曜どうでしょう祭ライブ配信の技術支援|クラスメソッドの事例
    https://classmethod.jp/cases/htb/
    認証:Auth0
    課金:Stripe
    動画再生:THEOplayer
    サーバーレスアーキテクチャ

    View Slide

  91. SaaSに対する懸念と注意
    ● 効果測定
    ○ 開発コスト + 運用コスト(時間、工数)
    ○ 開発チームが本当に開発したいことに注力できる価値
    ○ 本当に価格と見合っているか?を実測する
    ● 過度に避けるのは開発速度を落とす
    ○ 「ロックインを避ける」は永遠の課題
    ○ OS、言語 ... 避けられないロックインもある
    ● どこをオフロードすることが最適かの判断
    ○ その製品のコアバリューを自分たちで持ち、
    その周辺をSaaSでカバーする
    適用されるSLAや規約、法律にも適切な注意を❗
    91

    View Slide

  92. 【PR】弊社で取り扱いのあるSaaS (一部) 92
    お気軽に
    ご相談ください!
    https://classmethod.jp/partner/

    View Slide

  93. 5. まとめ:(改めて) SREとは

    View Slide

  94. 94
    (改めて) SREとは
    ● DevOpsとCloud技術が先鋭化したなかで生みだされた概念
    ○ DevOpsを安定かつ高速に回転させるために、
    ○ Cloud技術をはじめ様々なツールを駆使することで、
    ○ 信頼性を適切に維持・コントロールする技術 / 役割
    ● DevOpsの原則を運用の現場に適用したもの
    ○ 運用のリファクタリング
    ● その守備範囲は「サイト」=サービス提供に関わる全て
    ● そのミッションは「トイルの撲滅」
    ● そのために独自の様々な手段手法を駆使する

    View Slide

  95. まとめ
    SREの一番の目的 :
    開発・リリースのペースを高く保ちつつ信頼性を維持すること
    ● SLI/SLOはユーザー目線でシンプルに設定を
    ● 速度は正義:速度アップのためのツールを効果的に使おう
    ○ DevOps、Cloud技術 (XaaS) 、CI/CD
    ○ 可観測性(Observability)
    ○ カオスエンジニアリング
    ○ SaaS
    基本となる考え方や要素技術は汎用的
    できるところから組み入れていきましょう!
    95

    View Slide

  96. SREを成功させるには
    “短距離ではなくマラソンである”
    “Remember: it's a marathon, not a sprint”
    SRE を成功させるには、まず計画を立てることが大事 | Google Cloud Blog
    https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board
    96

    View Slide

  97. Appendix

    View Slide

  98. 98
    書籍(O'Reilly Japan)
    ➢ SRE サイトリライアビリティエンジニアリング
    ○ https://www.oreilly.co.jp/books/9784873117911/
    ○ https://sre.google/sre-book/table-of-contents/
    ➢ サイトリライアビリティワークブック
    ○ https://www.oreilly.co.jp/books/9784873119137/
    ○ https://sre.google/workbook/table-of-contents/
    ➢ SREの探求
    ○ https://www.oreilly.co.jp/books/9784873119618/
    ➢ 入門 監視
    ○ https://www.oreilly.co.jp/books/9784873118642/

    View Slide

  99. 99
    SRE
    ➢ SRE とは (RedHat)
    ○ https://www.redhat.com/ja/topics/devops/what-is-sre
    ➢ Site Reliability Engineeringとは。
    ○ https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s15/s15-fujisaki.pdf
    ➢ 開発チームとともに歩むSREチームが成し遂げたいこと
    ○ https://engineering.mercari.com/blog/entry/20210129-embedded-sre/
    ➢ Google re:Work - ガイド: 「効果的なチームとは何か」を知る
    ○ https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/
    ➢ SRE を成功させるには、まず計画を立てることが大事 | Google Cloud Blog
    ○ https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board
    ➢ [レポート] SREの基本と組織への導入 | DevelopersIO
    ○ https://dev.classmethod.jp/articles/202105-report-gcd21-d3-infra-01/
    ➢ SRE Gaps「理論と実践からSREを再考する」 - YouTube
    ○ https://www.youtube.com/watch?v=CEn3e8JxgtY
    ➢ SLAに関する7つの誤解とは、Uptime.comが解説:ダウンタイムはゼロにはならない - @IT
    ○ https://www.atmarkit.co.jp/ait/articles/2102/26/news117.html
    ➢ SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ SRE Lounge #12 - Speaker Deck
    ○ https://speakerdeck.com/katzchang/sli-slotokaosuenziniaringu-sositeobuzababiritei-sre-lounge-number-12

    View Slide

  100. 100
    SRE (cont.)
    ➢ クラウド費用の最適化: 成功し続けるための諸原則 | Google Cloud Blog
    ○ https://cloud.google.com/blog/ja/products/gcp/cost-managementprinciples-of-cloud-cost-optimization
    ➢ SLO の定義 | Cloud アーキテクチャ センター
    ○ https://cloud.google.com/architecture/defining-SLOs
    ➢ Download our diagram CALMS Model of DevOps | DevOpsGroup
    ○ https://www.devopsgroup.com/insights/resources/diagrams/all/calms-model-of-devops/
    ➢ 初めてのポストモーテム - Platinum Data Blog by BrainPad
    ○ https://blog.brainpad.co.jp/entry/2020/09/30/141837
    ➢ SRE-iously: Defining the Principles, Habits, and Practices of Site Reliability Engineering
    ○ https://www.slideshare.net/newrelic/sreiously-defining-the-principles-habits-and-practices-of-site-reliability-e
    ngineering-112178269
    ➢ The Many Shapes of Site Reliability Engineering
    ○ https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517
    ➢ Incident Metrics in SRE - Google - Site Reliability Engineering
    ○ https://sre.google/resources/practices-and-processes/incident-metrics-in-sre/

    View Slide

  101. 101
    可観測性・カオスエンジニアリング
    ➢ オブザーバビリティ(可観測性)がなぜ必要だと考えるのか - YAMAGUCHI::weblog
    ○ https://ymotongpoo.hatenablog.com/entry/2019/03/25/084500
    ➢ New Relicを使って、アプリAPIの応答速度を10倍早くしました - GA technologies GROUP Tech
    Blog
    ○ https://tech.ga-tech.co.jp/entry/2019/09/new-relic-helps-to-improve-renosy-app
    ➢ カオスエンジニアリングの原則
    ○ https://principlesofchaos.org/ja/
    ➢ 5分で学ぶ: カオスエンジニアリングの説明書 - New Relic公式ブログ
    ○ https://blog.newrelic.co.jp/engineering/chaos-engineering-explained/
    ➢ カオスエンジニアリングの過去と今(前編)
    ○ https://zenn.dev/hodagi/articles/3ce6ccdb00538c
    ➢ カオスエンジニアリングの過去と今(後編)
    ○ https://zenn.dev/hodagi/articles/abf6a20186f24a
    ➢ The Four Golden Signals - Google - Site Reliability Engineering
    ○ https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals

    View Slide

  102. 102
    事例・参考
    ➢ 突撃!隣のDevOps 【リブセンス編】 | DevelopersIO
    ○ https://dev.classmethod.jp/articles/devops-livesense/
    ➢ HTB北海道テレビ放送|水曜どうでしょう祭ライブ配信の技術支援|クラスメソッドの事例
    ○ https://classmethod.jp/cases/htb/
    ➢ FMEA(故障モード影響解析)とは?評価法や実際の流れを解説 | 金属加工の見積りサイトMitsuri(ミ
    ツリ)
    ○ https://mitsu-ri.net/articles/fmea_toha
    ➢ 【CEDEC 2021】『NieR Re[in]carnation』における負荷試験の効果的な運用方法とは 技術・チー
    ムの両面から実践内容を紹介 | gamebiz
    ○ https://gamebiz.jp/news/333021
    ➢ サービス・ドミナント・ロジック:先進企業事例に見る「価値づくり」の世界観 | 価値共創が生み出
    す競争優位の源泉(1/2)|DIAMOND ハーバード・ビジネス・レビュー
    ○ https://www.dhbr.net/articles/-/2698
    ➢ [レポート] AmazonのCTOはAWS re:Invent 2020のキーノートでどう語ったか? | DevelopersIO
    ○ https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/
    ➢ 企業活動におけるCAPEXとOPEXの定義 | クラウドERP実践ポータル
    ○ https://www.clouderp.jp/blog/what-is-capex-opex
    ➢ 鏡の国のアリス Through the Looking Glass: Japanese
    ○ https://www.genpaku.org/alice02/alice02j.html

    View Slide

  103. セッション後は、チャット欄のURL、または下記QRコードより
    アンケートへのご協力をお願いいたします。
    SNS投稿にはこちらをお使いください:#devio2021
    https://forms.gle/sp41fP9i9AzjZbmr5
    15:20-16:05
    40分+で分かった気になる SREのミッションとゆかいなSaaSの仲間たち
    Mission and Alliance for SRE in 40 (or more) minutes

    Q&A Q&A

    View Slide

  104. View Slide