hbstudy #74 https://hbstudy.connpass.com/event/61687/ で話をさせていただいた、SREに関するスライドです。

1. Site Reliability Engineering
（サイトリライアビリティエンジニアリング）
- Googleが提唱するシステム運用者のあり方を体系化した “SRE“について -
2017/7/25
玉川竜司@翻訳者

2. 簡単に自己紹介
• 某社の開発チーム所属です
• 本業とは別に、オライリージャパンからコンピュータ関係の技術書を翻訳出版しています
• 8月出版予定の最新刊が「サイトリライアビリティエンジニアリング」

3. 既刊

4. 今年の予定

5. 本日の内容
• The SRE Bookの出版と日本での動き
• Site Reliability Engineerとは？
• 速度と信頼性、そしてデータに基づく業務判断
• 技術の話
• 育成・採用の話

6. はじめにご承知おきいただきたいこと
• 本日お話しすることは、ほぼすべて出版される書籍に書かれていることです
• 私自身がSRE的なポジションで実際に働いているわけではないので、お話でおきる
ことはほぼすべて「伝聞」のようなものです
• とはいえ、SREという役割が生まれた背景や解決しようとする課題は、ソフトウェ
アの開発やサービス、運用にかかわる方なら十分理解できる（というか身につまさ
れる）ことであり、今日のお話、そしてSRE本からお持ち帰りいただけることもた
くさんあると考えています
• 質問は随時していただいて結構です

7. The SRE Bookの出版と
日本での動き

8. 始まりはこの本：The SRE Book
「Google の社員たちは彼らがたどってきたプロセスを、つまずきも含めて
本書で明らかにしてくれている。Google のサービスが巨大な規模と素晴ら
しい信頼性を共に実現できたのは、このプロセスによるものだ。統合され
たサービス群を生み出し、それらをスケールさせたいと考えている方々に
は、本書を読むことを強くおすすめする。本書は、メンテナンス性の高い
サービスを構築するための、現場の方々に向けたガイドである」
- Rik Farrow, USENIX
「Gmail のような大規模なサービスを書くのは難しいことだ。高い信頼性の
下でそれらを動作させるのはさらに難しいことであり、ましてやそれが
日々変化するのであればなおさらだ。包括的な「レシピ本」である本書は、
Google がそれをどう成し遂げているのかを教えてくれる。
読者の皆さんは、自分で間違いを犯すよりも、私たちの間違いから学ぶ方
が負担が少ないことに気づくだろう」
- Urs Hölzle, SVP テクニカルインフラストラクチャ、Google

9. 日本でも続々誕生
• メルカリ
http://tech.mercari.com/entry/2015/11/18/153421
• スマートニュース
https://www.slideshare.net/NobutoshiOgata/introducing-
inhouse-paas-in-smartnews
• サイボウズ
http://blog.cybozu.io/entry/2016/09/01/080000

10. 翻訳しました
• ほんと大変でした…
• とにかく分量が多い（文字だらけ）
• 監訳者の皆様超熱心
• 翻訳開始から発売までほぼ一年
• なお、全体に「カタカナより」の翻訳になって
います
ワード数 価格 ワード単価
SRE 188,971 4,800円 0.0025
Docker 104,767 3,600円 0.0034
しかし、歴史的な名著であることは間違いないと思います！
SREの原則はデータの計測に基づく判断。
高いと言われるSRE本ですが、ワード単価で計測すれば大変お得です

11. 日本語版ではサブタイトルを変更
• 英語版：How Google runs production systems
（Googleはどのようにプロダクションシステムを動作させているか）
• 日本語版：

12. 見るべきは、技術論よりも組織論
• なぜGoogleは次々と信頼性の高いサービスを投入･運用できるのか？
• もちろんGoogleが気づき上げた技術の蓄積もあるが、組織としての考え
方が果たしている役割が大きい
本書はあらゆる規模のサービスの運用にさまざまな形で関わるすべての人に向けて書かれています。大規模で多数のユー
ザーがいるサービスの運用者はもちろんのこと、まだ信頼性が第一のフォーカスでないようなサービスの運用にあたっても
手間やコストを下げてより開発の速度を上げるのに役立つ情報が得られるでしょう。個人でサービスを開発や運営されてい
る方にも実践できる内容が数多くあります。
また、普段運用に直接は関わる機会の少ない方々にもぜひ読んでいただきたく思っています。ソフトウェア開発者にも、
SRE の視点を得ることで設計や実装に活かせる新しい発見が数多くあることでしょう。サービスの運用コストはその設計や
実装に大きく依存していますし、サービスの運用と開発の協調もSRE の重要なポイントの1 つです。SRE チームのマネー
ジャーや、新しくSRE組織を立ち上げたいと考えているCTO にも、SRE のコアバリューについての理解を深める一助となる
ことでしょう。
（監訳者まえがきより）

13. 目次
1. イントロダクション
2. SRE の観点から見たGoogle のプロダクション環境
3. リスクの受容
4. サービスレベル目標
5. トイルの撲滅
6. 分散システムのモニタリング
7. Google における自動化の進化
8. リリースエンジニアリング
9. 単純さ
10. 時系列データからの実践的なアラート
11. オンコール対応
12. 効果的なトラブルシューティング
13. 緊急対応
14. インシデント管理
15. ポストモーテムの文化：失敗からの学び
16. サービス障害の追跡
17. 信頼性のためのテスト
18. SRE におけるソフトウェアエンジニアリング
19. フロントエンドにおけるロードバランシング
20. データセンターでのロードバランシング
21. 過負荷への対応
22. カスケード障害への対応
23. クリティカルな状態の管理: 信頼性のための分散合意
24. cron による分散定期スケジューリング
25. データ処理のパイプライン
26. データの完全性
27. 大規模なプロダクトのローンチにおける信頼性
28. SRE の成長を加速する方法
29. 割り込みへの対処
30. SRE の投入による運用過負荷からのリカバリ
31. SRE におけるコミュニケーションとコラボレーション
32. 進化するSRE のエンゲージメントモデル
33. 他の業界からの教訓
34. まとめ

14. （余談） SREの皆さんの仕事っぷり
• Google Docsのヘビーな活用
• 必要なドキュメントを非常に手早く、しかも適切な集計／自動
化を施して作成
• いわゆるOffice系ツールの活用能力もとても大事
• ちなみに最終の校正はdropboxでした…

15. （余談）三人称単数の’They’
• Theyが単数形として使われている（動詞が三単現のs付き）文
がある
• 誤植かと思いきや…
• Gender neutralな表現として、性別を持たない「人」を表す代
名詞としてtheyが使われるようになっているとのこと

16. Site Reliability Engineerとは？

17. Site Reliability Engineerという職種/チーム
• 基本的には運用サイド（Ops）の職種
• スキルとして、インフラに加えてプログラミングが必須
• Googleの開発職に要求されるプログラミングスキルの8～9割が必要
• 仕事は大きく分けて運用の業務（オンコールなど）と「改善」のためのエンジニアリング
（Googleのインフラストラクチャ）
（サービスごとに担当はあるものの、SRE自体は全社横断的な組織）
開発チーム 開発チーム 開発チーム
SREチーム SREチーム SREチーム
サービスA サービスB サービスC

18. SREの原則
• 信頼性にフォーカスを置く
• ソフトウェアエンジニアリングによって運用を自動化し、スケールできるように
する
• 手作業 → 自動化 → 自律化
• SREチームの規模はサービスの規模に比例してはならない（サービスの複雑さには影響を
受ける）
• 「トイル」の撲滅
• 「トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、
自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例すると
いった傾向を持つもの」
• 英雄的な献身に頼るのではなく、組織としての仕組みづくりを重視する

19. 速度と信頼性、
そしてデータに基づく業務判断

20. 重要視していること：速度と信頼性
• ここでの「速度」は新しい機能やサービスを投入するペースのこと
• 「信頼性」は（主に）SLO（Service Level Objective）のこと
• 開発者（Devs）は速度を、運用者（Ops）は信頼性を重視する傾向
がある
開発チーム 運用チーム
新機能を
リリースしたい
動いているものは
変更したくない
緊張関係

21. 計測されたデータに基づく業務判断
• エラーバジェット
• 50%ルール
以下はGoogleでの例ですが、あくまでこれは「Googleでは」こういう実施方法を取ってい
るということであって、肝心なのは
・品質を示すデータの定義
・定義されたデータの計測
・計測されたデータに基づいて業務判断をしていくこと
だと思います。

22. エラーバジェット
• SLO（サービスレベル目標）：計測するデータの定義
• Googleの場合は「完全に落ちる」ことはほぼないので、
成功したリクエスト数 / リクエスト数
などを指標としている
• エラーバジェット = 1 – SLO
• （Googleでは通常四半期単位でデータを計測）
• エラーバジェットが残っている限り新機能をリリースできる（業務判断）
• エラーバジェットがなくなった場合、リセットがかかるまで（緊急のセ
キュリティ対応などを除き）新機能のリリースは禁止

23. 100%は目指さない
• たとえばコンシューマ向けのサービスであれば、99.99%の可用性と
99.999%の可用性の違いはユーザーにはほぼ分からない（デバイス
の故障、回線の問題など、他の要因で事実上マスクされる）
• この場合、0.009%の可用性向上のためのコストは無駄
• サービスの性格に応じたSLOの定義が非常に重要
• 「航空機やペースメーカーの信頼性の話はまったく異なる」

24. 50%ルール
• SREはその作業時間（計測データの定義と計測）の50%以上をエンジニア
リング業務に当てなければならない
• SREが運用業務（含む障害対応）に当てる時間が50%を超えた場合、50%
以下に戻るまでは開発チームがSREの支援に時間を当てる（業務判断）
データに基づいて業務判断を行うことをルール化することによって、
開発チームとSREチームが同じ方向を向いて業務に当たれるようにする

25. 技術の話

26. 「魔法」の話はあまり出てきません
• 本書に出てくるのはある意味で「地味」な話です
• Googleのインフラがなければ意味のない話なのか？→そんなこ
とはありません
• ソフトウェアでコントロールできる範囲の話であれば、学べる
ことはたくさんあります

27. 計測と改善の仕組み作り
• 必要なメトリクスを得るための仕組みをインフラに作り込む
• 収集したメトリクスをモニタリングするための仕組みを作り込む
• 基本的なメトリクスの取得の仕組みがすべてのマシンに共通して組み込ま
れている
• たとえばPythonあたりでスクリプトが書けるなら、自分たちの環境でも
できることは多いはず

28. 徹底した自動化志向
• 自動化のメリットは「複利」
• 手動 （トイル）→ 自動化 → 自律化
• 「トイルとは、プロダクションサービスを動作させるこ
とに 関係する作業で、手作業で繰り返し行われ、自動化す
ることが可能であり、戦術的で長期的な価値を持たず、
作業量がサービスの成長に比例するといった傾向を持つも
の」

29. 採用・育成の話

30. SREの採用はたいへん
• Googleの開発エンジニアに求められるスキルの80-90%
• 加えてインフラ周りの知識が必要
• 基本的に需要に対して供給不足
（Googleのインフラストラクチャ）
（サービスごとに担当はあるものの、SRE自体は全社横断的な組織）
開発チーム
SREが開発したライブラリ
サービス
SREという「人」ではなくSRE
のノウハウを詰め込んだライ
ブラリを使ってもらう

31. 教育とオンコール
• オンコール対応になることはキャリアの1つのマイルストーン
• そこに至るまでの教育システムもきちんと整備する
• 「千尋の谷に突き落とす」ようなやり方はしない
• ドキュメント→ポストモーテム→シャドウ→オンコール

32. 障害対応とトレーニング
• 年に一度、全社的な障害対応のトレーニング
• 「たまにしかやらないことは身につかない」ことを受け入れる
• 障害対応時の手順を日常業務に組み込んでおく
• できないことを精神論でかたづけない

33. まとめ

34. • 自動化によってスケーラビリティの向上、トイルの撲滅、そし
て更なる自動化のための時間をつくること
• ソフトウェア開発によって運用を改善していくこと
• データ（SLO）の定義、データを計測する仕組みづくり、計測
されたデータに基づく業務判断によって、開発チームとSRE
チームが同じ方向を向けるようにすること

35. 質問をどうぞ！