SREの探求のすゝめ

1
© 2021 eureka, Inc. All Rights Reserved.
CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy
All Hands Meeting
「SREの探求」のすゝめ
SRE Lounge #13 
2021/11/19

View Slide

2
All Hands Meeting
Who is me
Takashi Narikawa  
● SRE LOUNGE/SRE NEXT 運営 
● Site Reliability Engineer at eureka, inc. 
● 好きなもの: サウナ/VR/音楽 
● Twitter 
○ Real: @fukubaka0825 
○ VR: @wapper0825 

View Slide

3
All Hands Meeting
SRE 本/ワークブックを読んだ人 ✋

View Slide

4
All Hands Meeting
SREの探究を読んだ人 ✋  

View Slide

5
All Hands Meeting
SREの探究を読んだ人 ✋  
Today’s Topic

View Slide

6
All Hands Meeting
SRE LOUNGE #6 - Reading “The Site Reliability Workbook”

View Slide

7
All Hands Meeting
● まだ読んでいない方へは読むきっかけを提供 
● もう読んでいる方へは押しの章などについて、SNSなどでの対話のきっかけを提
供 
この発表のゴール

View Slide

8
All Hands Meeting
この本の立ち位置

View Slide

9
All Hands Meeting
● 通称SRE本 
● Googleで培われたシステム
管理とサービス運用の方法
論の紹介

View Slide

10
All Hands Meeting
● SRE本に実施の詳細をさらに追
加し、SREが「Googleの規模」や
「Googleの文化」でのみ実施でき
ることだという誤解を晴すことを目
的とした本

View Slide

11
All Hands Meeting
● Google以外の企業でSRE
の導入がどのように行わ
れているのかを記したエッ
セイ集 

View Slide

12
All Hands Meeting
● ”そして最後に、もしも本書の感想が受動的に読むだけなら面白いと
いうことであれば、それを部分的な成功と取るか部分的な失敗と取る
かは読者ご自身の性格によるでしょう。どうひいき目に考えても、本
書のサービスレベル目標が満足されたことにはなりません。しかし、
この読書体験を会話への参加（および、それによってSREという分野
をさらに前進させるための貢献）が意図された招待と取っていただけ
るのであれば、本書の目標は達成されたことになります。” 
この本のゴール
(引用: O’Reilly|SREの探求はじめに)
 
本書の目標
= 読者に、本書の読書体験が会話への参
加を意図された招待であると取ってもらえる
こと

View Slide

13
All Hands Meeting
● 1章　SREにおけるコンテキストとコントロール  
● 2章　サイトリライアビリティエンジニアの面接  
● 3章　なるほど、SREチームを作りたいのですね  
● 4章　インシデントのメトリクスを用いたSREの大規模な改善  
● 5章　サードパーティとの協力を円滑に進める重要性  
● 6章　専任SREチームなしでSREの原則を適用する方法  
第I部 SREの導入
● 7章　SREのいないSRE：Spotifyのケーススタディ  
● 8章　大企業におけるSREの導入  
● 9章　25ページでシステム管理者からSREへ  
● 10章　大企業でSRE導入の道を開く方法  
● 11章　DevOpsの幅広い実践現場で活用されているSREのパターン  
● 12章　DevOpsとSRE：コミュニティからの声  
● 13章　Facebookにおけるプロダクションエンジニアリング  
スタートアップ~大企業までのSRE
導入について
(SoundCloud,Spotifyの専任
SREチームがないパターンも)

View Slide

14
All Hands Meeting
● 14章　初めにカオスありき  
● 15章　信頼性とプライバシーが交わるところ  
● 16章　データベースリライアビリティエンジニアリング  
● 17章　データ耐久性のエンジニアリング  
● 18章　SREのための機械学習入門  
第II部 SREの周辺領域
「SRE本」や「ワークブック」であまり
触れられなかったSRE関連の各種
手法についての紹介

View Slide

15
All Hands Meeting
 
● 19章　ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合  
● 20章　アクティブなティーチングとラーニング  
● 21章　サービスレベル目標の技法と科学  
● 22章　成功の文化としてのSRE  
● 23章　SREのアンチパターン  
● 24章　イミュータブルなインフラストラクチャとSRE  
● 25章　スクリプタブルロードバランサー  
● 26章　サービスメッシュはマイクロサービスの世話人か  
第Ⅲ部 SREのベストプラクティスと技術
SREにおけるソフトスキルとアーキテ
クチャの紹介

View Slide

16
All Hands Meeting
● 27章　SREにおける心理的安全性  
● 28章　SREの認知的作業  
● 29章　燃え尽きを超えて  
● 30章　オンコール反対論  
● 31章　複雑なシステムのためのエレジー  
● 32章　運用と社会運動が交わるところ  
● 33章　まとめ 
第Ⅳ部 SREの人間的側面
SREのみならず組織全体にも適応できそう
な文化的側面についての考察が多数

View Slide

17
All Hands Meeting

View Slide

18
All Hands Meeting
👉

View Slide

19
All Hands Meeting
 
● 19章　ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合  
● 20章　アクティブなティーチングとラーニング  
● 21章　サービスレベル目標の技法と科学  
● 22章　成功の文化としてのSRE  
● 23章　SREのアンチパターン  
● 24章　イミュータブルなインフラストラクチャとSRE  
● 25章　スクリプタブルロードバランサー  
● 26章　サービスメッシュはマイクロサービスの世話人か  
第Ⅲ部 SREのベストプラクティスと技術
👉

View Slide

20
All Hands Meeting
4章　 
インシデントのメトリクスを用い
たSREの大規模な改善 

View Slide

21
All Hands Meeting
● SRE改善のためデータの検討  
　 → 対象となるデータソースがあまりにも膨大　 
　→ 最終的にたどり着いたのは、以下の好循環（virtuous cycle）と呼ばれるシステム 
障害対策の好循環
(引用: O’Reilly|SREの探求第4章インシデントのメトリクスを用いたSREの大規模な改善)
 

View Slide

22
All Hands Meeting
サービス障害の軽減に要する時間の内訳
● 検出時間（Time to Detect＝TTD) 
○ 障害の影響が始まってから運用者がインシデントを把握するまで 
● エンゲージ時間（Time to Engage＝TTE） 
○ 問題を検出してから適切なエンジニアが関与するまでの時間 
● 修正時間（Time to Fix＝TTF） 
○ 対応者が問題の軽減に要する時間 
● 軽減時間  
○ TTD + TTD + TTF 
● 重要なのは？ → 共通の分類法と尺度についてグループで合意すること 
(引用: O’Reilly|SREの探求第4章  
インシデントのメトリクスを用いたSREの大規模な改善)
 

View Slide

23
All Hands Meeting
代理メトリクス
● 代理メトリクス: 最重要のメトリクス(〜時間)に関連する従属メトリクス。より改善の具体的なア
クションアイテムを与えることになるため、改善のスピードと持続性が向上する 
○ ex 
■ DRI Hops (Directly Responsible Individual Hops) : インシデントの解決に要したオ
ンコールエンジニアの数 
■ Outages autodetected (モニタリングで検出されたインシデントの割合) 
● 代理メトリクスを発見するには、データを探索するのが優れた方法 
○ ex 
■ TTE(エンゲージ時間)と# DRIs engaged per Bridgeの相関関係の発見 
■ TTD(検出時間)と自動検出レートの相関関係の発見 

View Slide

24
All Hands Meeting
修復負債
● メトリクスレビューで最も重要なこと 
= バグや改善の機会を特定するたびに必ず、ログに記録し、修復（repair）として追跡 
○ 修復アイテムは技術またはプロセスの修正で、サービス障害の再発を防止するか、その
持続期間を短縮。基本的に短期アイテムと長期アイテムに分解 
○ 修復アイテムを追跡することで、運用上の負債を標準のエンジニアリングプロセスに組み
込み、機能に関する作業と同様に扱えるように 
■ エラーバジェットと組み合わせることで、機能に関する作業に対してサービスの信頼
性に関する作業の優先順位を設定する方法について、チームにシグナルを提供する
のに役に立つ 
インシデントのメトリクスを用いた
 
SREの大規模な改善)
 

View Slide

25
All Hands Meeting
仮想修復負債
● 場合によっては、修復負債の状況が安定しているのに、前月比の信頼性は必ずしも向上し
なかった 
○ 原因: 一部のサービスでは徹底したRCAが行われていないために、RCA完了率が低
いか、RCA(根本原因解析)が十分な修復につながらない結果になっていた 
■ つまり、ポストモーテムの質に、修復負債指標の有効性が依存してしまう 
● そこで、軽減の時間目標が欠落しているインシデントには対応する修復アイテムが設定さ
れならないことに着眼。そこで設定されていない「欠落している修復アイテム」も擬似的な修
復負債として扱えばいいのではないか？と考えた 
○ それを「仮想修復負債」と呼ぶメトリクスを計測してより信頼性の高いものにして改善
を推進する強力なツールとした 
インシデントのメトリクスを用いた
 
SREの大規模な改善)
 

View Slide

26
All Hands Meeting
まとめ
● ”「あらゆるものを計測し、飽くなき好奇心を持ち、取るべき適切なアクションを見出すために
はデータの中でなりふり構わずもがくことを恐れるな」” 
(引用: O’Reilly|SREの探求第4章インシデントのメトリクスを用いた SREの大規模な改善)
 

View Slide

27
All Hands Meeting
19章　 
ドキュメント作成業務の改善： 
エンジニアリングワークフローへのド
キュメンテーションの統合 

View Slide

28
All Hands Meeting
この章の概要
● ドキュメント管理の質を高めたいSRE、SWE、テクニカルライターむけに、内部エンジニアリ
ング情報の品質と可用性を改善する取り組みについて以下の三つを重点的に紹介 
○ ドキュメンテーション品質の定義  
■ SREの業務に重点を置いて説明 
○ エンジニアリングワークフローへのドキュメンテーションの統合 
○ ドキュメンテーションの価値の周知徹底  

View Slide

29
All Hands Meeting
ドキュメンテーションの品質の定義
● 構造品質（structural quality） 
○ ドキュメンテーションがどのようにあるべきか 
○ 表記/文法/スタイル/慣用/構成 
● 機能品質（functional quality)  
○ ドキュメントの有効性(所定の要件を満足するのが機能品質の高いドキュメント) 
● 常に機能品質 > 構造品質 
● SREのドキュメンテーションが提供しなければならない特性 
○ モニタリングとメトリクス/緊急対応/キャパシティプランニング/サービスのターンアップと
ターンダウン/変更管理/パフォーマンス 

View Slide

30
All Hands Meeting
ドキュメンテーションの品質の定義
● プロダクションサービスの実行でSREが参照する中核的なドキュメント 
○ サービス概要 
○ 手順書 
○ ポストモーテム 
○ ポリシー 
○ SLA 
○ 成功指標の定義 
■ ドキュメントの機能品質を計測する方法も定義することが重要 

View Slide

31
All Hands Meeting
エンジニアリングワークフローへのドキュメンテーションの統合
● ドキュメンテーションをシンプルな形式で書き、対象のコードと共にソース管理システムに保
存する 
○ 理由は次の3つ 
■ エンジニアは既存のツールを使い、通常のエンジニアリングワークフロー
の一環としてドキュメンテーションを作成および更新できる 
■ コードの検索やツールのレビュー、さらには統合開発環境（IDE）といった
エンジニアリングのツールチェーンとドキュメンテーションを統合できる 
■ コードとドキュメントの関係が明白になるため、自動化をサポートし、コン
テンツの検索が容易になる 
○ “私たちが学んだ最も重要な教訓とは突き詰めると、可能な限りシンプルに行え
るのであれば、エンジニアはドキュメンテーションを作成および保守するというこ
とです。” 
(引用: O’Reilly|SREの探求第19章ドキュメント作成業務の改善: エンジニアリングワークフローへのドキュメントの統合)
 

View Slide

32
All Hands Meeting
エンジニアリングワークフローへのドキュメンテーションの統合
● ドキュメンテーションに関して中核となる原則の概要 
○ 可能な場合、ドキュメンテーションは関連するコードと一緒にソース管理システ
ムに置く 
○ ニーズに応える最もシンプルなマークアップ言語を選ぶ 
■ ex: Markdown 

View Slide

33
All Hands Meeting
ドキュメントの価値の周知徹底
● ドキュメンテーションに時間とリソースを投資するように同僚のエンジニアや管理層や経営
層を説得したいのなら、ドキュメンテーションの品質、有効性、価値を正確に実証する機能
データを集める 
○ 機能データ: 計測可能な成功/ユーザーの行動/センチメントデータ 
○ ドキュメント作業の影響を語る = 得られる出力のビジネス価値を語ること 
● “機能データには説得力があります。これを収集して、及ぼす影響の根拠を示すためにも、
ドキュメンテーションへの投資は価値があることをチーム、組織、管理層や経営層に対して
説得するため 19.5 参考文献 361 にも活用しましょう。なぜなら実際そうだからです。” 
(引用: O’Reilly|SREの探求第19章ドキュメント作成業務の改善: エンジニアリングワークフローへのドキュメントの統合)
 

View Slide

34
All Hands Meeting
● まだ読まれていなかった方は、これをきっかけに是非読んでみてください 
● すでに読まれている方は、押しの章についてTwitterにてハッシュタグ#sreloungeで是非呟いて”対話”
への参加を！ 
● また、SRE LOUNGE #13も、ここから本書同様ユーザーに対する信頼性を獲得するための手法や組
織作りの試行錯誤の共有がたくさんあるかと思います。それらが皆様のなんらかのヒントになれば幸
いです 
おわりに

View Slide

35

View Slide

SREの探求のすゝめ

SREの探求のすゝめ

fukubaka0825

More Decks by fukubaka0825

Other Decks in Programming

Featured

Transcript