- 原書：[Seeking SRE [Book]](https://www.oreilly.com/library/view/seeking-sre/9781491978856/) - 邦訳：[O'Reilly Japan - SREの探求](https://www.oreilly.co.jp/books/9784873119618/) ## 目次 第I部　SREの導入 1章　SREにおけるコンテキストとコントロール 2章　サイトリライアビリティエンジニアの面接 2.1　面接の基本 2.2　SRE向けのファネル 2.3　SREの面接について最後に 2.4　参考資料 3章　なるほど、SREチームを作りたいのですね 3.1　SREを選ぶ適切な理由 3.2　データ駆動型アプローチへの志向 3.3　SREへのコミットメント 3.4　SREに関する意思決定 4章　インシデントのメトリクスを用いたSREの大規模な改善 4.1　障害対策の好循環：それを計測しない場合は…… [[SREのvirtuous cycle]] 4.2　メトリクスのレビュー：メトリクスを森の中に落としてしまったら…… [[インシデントの代表メトリクス]] 4.3　代理メトリクス [[インシデントの代理メトリクス]] 4.4　[[修復負債]] 4.5　[[仮想修復負債]]：マシンに潜む亡霊を追い払う 4.6　リアルタイムダッシュボード：SREの必需品 4.7　学び：一言で要約すれば 4.8　参考文献 5章　サードパーティとの協力を円滑に進める重要性 5.1　構築、購入、それとも採用か 5.2　第一級市民としてのサードパーティ 5.3　まとめ 6章　専任SREチームなしでSREの原則を適用する方法 SoundCloudの例 6.1　SREが助けに行く！（も失敗した顛末） - オンコールのローテを考慮するとSREの最少人数は8人 - エンジニアの約10%がSRE - SRE をバックエンドの開発チームに派遣 - you build it, you run it - プラットフォームチームは自給自足 - SysOps チームとプラットフォームチーム => プロダクションエンジニアリング - リリースとめる権限がない - ユーザーが使用するアプリ ケーションに関しては、そもそもページャーを携帯しない - 全く文書化されておらず多くの場合は無意味なアラートによって、ひっきりなしに呼び出されるこ とになりました - 妥当なモニタリングを行うほうがモニタリングを全く行わないより楽だと感じられるように なっています。 - インシデント処理に関する運用タスクはすべて、手順書に文書化しなければなりません。手順書にはアラートごとに1つの項目を立て、少なくともコンテキストと説明を記載しなければなりません。 6.2　自分が構築し自分で実行 6.3　導入の詳細 6.4　まとめ 6.5　参考文献 7章　SREのいないSRE：Spotifyのケーススタディ 7.1　まっさらなキャンバス：2006～2007年 7.2　ベータとリリース：2008～2009年 7.3　成功の呪い：2010年 7.4　ペットと家畜、そしてアジャイル：2011年 7.5　スケールしなかったシステム：2012年 7.6　分隊型運用の導入：2013～2015年 7.7　「自律性」対「一貫性」：2015～2017年 7.8　将来：大規模かつ安全にスピード感をもって 8章　大企業におけるSREの導入 8.1　背景 8.2　SREの導入 8.3　まとめ 8.4　参考文献 9章　25ページでシステム管理者からSREへ 9.1　用語の明確な定義 9.2　内部コンポーネント向けSLAの確立 9.3　外部依存関係の理解 9.4　非技術的な解決策 9.5　可用性レベルの追跡 9.6　特殊なケースへの対応 9.7　まとめ 10章　大企業でSRE導入の道を開く方法 10.1　トイルはSREの敵 10.2　大企業におけるトイル 10.3　サイロ、キュー、チケット 10.4　今すぐ行動を 10.5　出発点はリーンの徹底 10.6　引き継ぎは可能な限りなくす 10.7　残る引き継ぎはセルフサービスに置き換える 10.8　エラーバジェット、トイルの制限、人間に力を与える他のツール 10.9　この動向に参画しましょう 11章　DevOpsの幅広い実践現場で活用されているSREのパターン 11.1　パターン1：Googleにおける自動化テストの誕生 11.2　パターン2：ローンチと引き継ぎに関するGoogleのレディネスレビュー 11.3　パターン3：共有ソースコードリポジトリの作成 11.4　まとめ 11.5　参考文献と原資料 12章　DevOpsとSRE：コミュニティからの声 12.1　本章の背景 12.2　方法 12.3　結果 12.4　回答 13章　Facebookにおけるプロダクションエンジニアリング 第II部　SREの周辺領域 14章　初めにカオスありき 14.1　システムが抱える問題 14.2　複雑さの経済的な柱 14.3　カオスの始まり 14.4　安全のための複雑さのナビゲーション 14.5　カオスの巨大化 14.6　定式化 14.7　詳細な原則 14.8　よくある質問（FAQ） 14.9　まとめ 15章　信頼性とプライバシーが交わるところ 15.1　信頼性とプライバシーが交わるところ 15.2　プライバシーエンジニアリングの一般的な状況 15.3　プライバシーとSRE：共通のアプローチ 15.4　ニュアンス、相違、トレードオフ 15.5　まとめ 15.6　参考文献 16章　データベースリライアビリティエンジニアリング [[Database Reliability Engineering]] 16.1　データベースリライアビリティエンジニアの指導原則 16.2　データベースリライアビリティエンジニアリングの文化 16.3　リカバリ可能性 16.4　継続的デリバリ：開発からプロダクションまで 16.5　コラボレーション 16.6　デプロイメント 16.7　DBREへのご賛同を！ 16.8　参考文献 17章　データ耐久性のエンジニアリング 17.1　レプリケーションは最低保障 17.2　現実の耐久性 17.3　分離 17.4　保護 17.5　検証 17.6　自動化 17.7　まとめ 18章　SREのための[[機械学習]]入門 18.1　SREが機械学習を使う理由 [[Automation and Machine Learning with Site Reliability Engineering]] - トイルを生み出すだけで誰もやりたがらない反復タスクをどのように自動化すればよいか - データを検討して、システムで将来起ころうとしていることを予見するにはどうすればよ いか - 「ソフトウェアエンジニアリングを運用機能に適用する取り組み」をどのように強化すれば よいか [[SREで機械学習が使用できるデータの種類]] 18.2　企業が取り組むべき課題である理由とその方法 18.3　特化型AIの覚醒 18.4　機械学習とは何か 18.5　ニューラルネットワークとは何か 18.6　機械学習の実践 18.7　成功事例 18.8　参考文献 - [GitHub - ricardoamaro/MachineLearning4SRE: Repo used to share the demos used in D.C. Vienna 2017](https://github.com/ricardoamaro/MachineLearning4SRE) - [[Artificial Intelligence - A Modern Approach]] - [Deep Learning | The MIT Press](https://mitpress.mit.edu/books/deep-learning) 第III部　SREのベストプラクティスと技術 19章　ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合 19.1　品質の定義：優れたドキュメントとはどのようなものか 19.2　エンジニアリングワークフローへのドキュメントの統合 19.3　ドキュメント作成業務を改善するベストプラクティス 19.4　ドキュメンテーションの価値の周知徹底 19.5　参考文献 20章　アクティブなティーチングとラーニング 20.1　アクティブラーニング 20.2　学ぼうとしないことの代償 20.3　効果的なSREチームの学習習慣 20.4　行動の呼びかけ：退屈なスライドはお蔵入りに 21章　サービスレベル目標の技法と科学 21.1　目標を設定する理由 21.2　可用性 21.3　SLOの評価に際して 21.4　ヒストグラム 21.5　パーセンタイルが役に立たない場合（とヒストグラムの高度な活用） 21.6　最後に：SLOに対する逆転の発想 21.7　参考文献 22章　成功の文化としてのSRE 22.1　SREが生まれた経緯 22.2　SREにとって重要な価値 22.3　SREの重要なイネーブリング機能 22.4　SRE実施のフェーズ 22.5　成功を呼び込む細部へのこだわり 22.6　参考文献 23章　SREのアンチパターン 23.1　アンチパターン1：サイトリライアビリティオペレーション 23.2　アンチパターン2：画面を見つめる人間 23.3　アンチパターン3：群衆によるインシデント対応 23.4　アンチパターン4：根本原因＝ヒューマンエラー 23.5　アンチパターン5：ページャーの引き渡し 23.6　アンチパターン6：マジックスモークを消すのは私だ！ 23.7　アンチパターン7：アラートリライアビリティエンジニアリング 23.8　アンチパターン8：ペットを散歩させてくれるドッグウォーカーを雇う 23.9　アンチパターン9：スピードバンプエンジニアリング 23.10　アンチパターン10：設計の難所 23.11　アンチパターン11：棒が多すぎてニンジンが不足 23.12　アンチパターン12：プロダクションの延期 23.13　アンチパターン13：リカバリ時間ではなく障害回避の最適化（MTTF > MTTR） 23.14　アンチパターン14：依存性地獄 23.15　アンチパターン15：小回りの利かないガバナンス 23.16　アンチパターン16：不適切な「おやおや」のSLO 23.17　アンチパターン17：ファイアウォール越しにAPIを投げ渡す 23.18　アンチパターン18：運用チームの修復 23.19　最後にもう一言 24章　イミュータブルなインフラストラクチャとSRE 24.1　スケーラビリティ、信頼性、パフォーマンス 24.2　障害回復 24.3　運用の単純化 24.4　起動時間の短縮 24.5　既知の状態 24.6　迷いのない継続的統合／継続的デプロイ 24.7　セキュリティ 24.8　マルチリージョン運用 24.9　リリースエンジニアリング 24.10　ベースイメージの構築 24.11　アプリケーションのデプロイ 24.12　デメリット 24.13　まとめ 25章　スクリプタブルロードバランサー 25.1　スクリプタブルロードバランサー：期待の新手法 25.2　難しいことを簡単にする 25.3　サービスレベルミドルウェア 25.4　ディザスタの回避 25.5　今後の展望と参考文献 26章　サービスメッシュはマイクロサービスの世話人か 26.1　モノリスを撤廃する準備はできていますか 26.2　マイクロサービスのネットワーキングの現状 26.3　状況を打開するサービスメッシュ 26.4　サービスメッシュの実践 26.5　サービスメッシュの将来 26.6　参考文献 第IV部　SREの人間的側面 27章　SREにおける心理的安全性 27.1　成功するチームの最も重要な指標 27.2　参考文献 28章　SREの認知的作業 28.1　はじめに 28.2　SRE担当者の「実際の」仕事 28.3　実務担当者の認知力に配慮すべき理由 28.4　インシデントを巡るSREの認知的作業に関する観察 28.5　キャリブレーション問題 28.6　以上すべてが意味することとは 28.7　次に必要となるのは 28.8　取りうる対策 28.9　まとめ 28.10　参考文献 29章　燃え尽きを超えて 29.1　精神障害の定義 29.2　多様性の議論から抜け落ちている精神障害 29.3　精神機能はビジネスの要件ではない 29.4　思考と祈りはスケーラブルではない 29.5　フルスタックのインクルーシビティ 29.6　誰かのためのインクルーシビティは誰にとっても助けとなる 29.7　精神障害に関するリソース 30章　オンコール反対論 30.1　オンコールの根拠 30.2　人間がオンコールを行うコスト 30.3　現実の解決策 30.4　必要なのはアプローチの根本的な変更 30.5　まとめ 31章　複雑なシステムのためのエレジー 31.1　コンピュータのシステムと人間のシステムは分離できない 31.2　デコヒーレンスとカスケード障害 31.3　常に部分的な障害がある状態 31.4　目新しいことを優先するのが正しいとは限らない 31.5　調整のオーバーヘッドを誰も想定しない 31.6　healthcare.govは他人事ではない 31.7　参考文献 32章　運用と社会運動が交わるところ 32.1　行動前、行動、行動後 32.2　ロングテール：行動から変革をもたらす 32.3　まとめ 33章　まとめ