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 © 2021 eureka, Inc. All Rights Reserved.

Not for Public Distribution - Do Not Copy All Hands Meeting Who is me © 2021 eureka, Inc. All Rights Reserved. Takashi Narikawa   • SRE LOUNGE/SRE NEXT 運営  • Site Reliability Engineer at eureka, inc.  • 好きなもの: サウナ/VR/音楽  • Twitter  ◦ Real: @fukubaka0825  ◦ VR: @wapper0825 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Not for Public Distribution - Do Not Copy All Hands Meeting ドキュメンテーションの品質の定義 © 2021 eureka, Inc. All Rights Reserved. • プロダクションサービスの実行でSREが参照する中核的なドキュメント  ◦ サービス概要  ◦ 手順書  ◦ ポストモーテム  ◦ ポリシー  ◦ SLA  ◦ 成功指標の定義  ▪ ドキュメントの機能品質を計測する方法も定義することが重要 

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

Not for Public Distribution - Do Not Copy All Hands Meeting エンジニアリングワークフローへのドキュメンテーションの統合 © 2021 eureka, Inc. All Rights Reserved. • ドキュメンテーションに関して中核となる原則の概要  ◦ 可能な場合、ドキュメンテーションは関連するコードと一緒にソース管理システムに置く  ◦ ニーズに応える最もシンプルなマークアップ言語を選ぶ  ▪ ex: Markdown 

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

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

SREの探求のすゝめ

SREの探求のすゝめ

More Decks by fukubaka0825

Other Decks in Programming

Featured

Transcript