devとopsを分断することによって起きるコスト

直接的なコストは、サービスの成長やトラフィックの増加による人的コストの増加

間接的なコストはバックグランド、スキルセット、動機づけがdevとopsで異なってくること

devはなるべく早リリースして、ユーザーに使ってもらいたい、opsはサービスに問題が起きないようにしたいという思いがぶつかることで、軋轢を生む

SREとはソフトウェアエンジニアに運用チームを設計させたときに出来上がるもの

UNIXシステムの内部とネットワーキング(レイヤー1から3)に関する知識がSREには必要

GooleのSREではチケット、オンコール、手作業などの運用業務を50%以下にするというルールを設けた

SREの採用は、コーディングとエンジニアリングの両面で優れている人が必要なので難しい

運用タスク50%以上になった場合は、プロダクト開発チームに差し戻す??
そうかープロダクト開発チームとSREチームは別だった
これはプロダクト開発チームの協力が大きく必要そう

文中のページャーってなんだ??

大きなインシデントに関してはポストモーテムを書くべき

エラーバジェット
100%の信頼性を目標とすることは、基本的にいかなる場合にも間違っている

• プロダクトの利用方法を踏まえ、ユーザーが満足する可用性はどの程度か
• プロダクト可用性に満足的なったユーザーにどのような代替案があるか
• 可用性のれべるを 変更したとして、ユーザーのプロダクトの利用の仕方に何が起きるか

特定な値をモニタリングして、値が閾値を越えたらアラートを出すと行った方法は効果的ではない
そのメールを読んで対応している時点で欠陥を抱えるアプリケーションである

• アラート
  即座に人間が対応
• チケット
  即座に人間が対応する必要はない
• ロギング
  人間が見る必要がないもの

平均修復時間が短いシステムは良い
緊急対応の効率を評価する場合は平均修復時間を見る

70%のサービス障害は動作中のシステムへの変更で起きる

• 漸進的なロールアウトを実装
• 高速かつ正確な問題の検出
• 問題が生じた際の安全なロールバック

3章リスクの許容

信頼性を得るためのコストには2つ

• 冗長的なコンピュートリソースのコスト
• リスクを減らすためのエンジニアリソースコスト

必要以上に信頼性を得るためにコストを掛けない

可用性ターゲットは下限であり上限でもある

Googleでは時間を元にした可用性メトリクスはとっていなく、リクエスト成功率で可用性を定義している

エンドユーザーへの応答に直接寄与しないシステムに対してもこの可用性メトリクスを適用しやすくなる。

Qレスポンスの成功、失敗を正しく取る方法って？どうとるのか

コンシューマサービスのリスク許容度明確化

可用性のターゲットレベル

• ユーザーが期待するサービスのレベル
• サービスが直接的に収入につながっているか
• 有料か無料か
• 競合があるか、あれば競合のサービスレベル
• コンシュマ向けか、企業か

企業向けの場合、可用性が低いと使っている企業に問題になるため高めにする
守れなかった場合はペナルティを明記する

Youtubeのようなコンシューマ向けの場合、開発速度を優先するために可用性を低くするということも考える

障害の種類

画像が表示されない、他のユーザーの情報が見れてしまう。
では、後者のほうがリスクが大きい。

サービスを止めてでも修復したほうが良い場合も

コスト

99.9を99.99に高めるときにコストに見合う価値を生み出せるかを考えよう
だけど、0.09高めたところで、ビシネス的にどれだけ利益を生み出せるかを計測するのは難しい。
なので、インターネットサービスプロバイダのエラー率よりエラーを低くすることができればプロバイダのエラーにまぎれてサービスの信頼度はさがりにくい。
ISPのエラー率は一般的に0.01~1%だ。

他のメトリクス

レイテンシなどがあります。
体感速度が重要なサービスではレイテンシをメトリクスとして組み込み、レイテンシが必要とされない場合はコストやリソースを削減できるか考えてみる。

インフラストラクチャサービスのリスク許容度明確化

可用性のターゲットレベル

コンシューマサービスにくらべサービスの性質によって大きく変わってくる
信頼性orスループット？

両方得たいなら、エンジニアリングリソースをめっちゃかければいい。
でもそんなことしたらコストかかりすぎるよね？
なので、サービスの性質を見極めよう

障害の種類

これもサービスによって障害と呼ぶものが大きく異なってくる

コスト

上記のような性質の違うサービスをコスト効率を損なわず満たす方法はサービスを分割すること。
信頼性を高めるデータは、高可用性データストアに保存し、付加的なデータは結果整合性のあるデータストアに保存するようなやり方

フロントエンドインフラストラクチャ(リバースプロキシ、ロードバランシング)はリクエストが届かないとロストしてしまうので、極めて高いレベルでの信頼性を提供しなくてはならない。

エラーバジェットの活用

開発チームとSREチームで食い違いが発生する

• ソフトウェア障害の許容度
• テスト
• プッシュの頻度
• カナリアテストの期間と規模

エラーバジェットを形成していく

• PMがSLOを規定する。稼働時間の設定
• 中立なモニタリングシステムで計測
• 決めた稼働時間とモニタリング結果の差異が、損失可能な信頼性
• その分プッシュしていく

エラーバジェットのメリットは、開発とSREで共通のインセンティブを提供しバランスが取れること
SLOが底をつきそうであれば、リリースの速度を遅くするか、ロールバックをする
テストをどれだけ書くかの指針にもなってくれる
SLOに抵触した場合、SREチームでリリースを取り止められる権限があることが大切(受託開発でこれば難しそう)

4章 サービスレベル目標

サービスレベル指標(SLI)

SLIとしてサービスのレイテンシを考慮する
もう一つは可用性

サービスレベル目標(SLO)

SLIで計測されるターゲット値

QPS【クエリ毎秒 / Queries Per Second】

SLOを設定することはユーザーとの期待度調整でもある

アグリーメント(SLA)

ユーザー間で結ぶ明示的あるいは、暗な契約
また契約が守られた場合、守られなかった場合の規定が含まれている

ビジネスに大きく関わるので、SREはSLAの構築には関わらない

SLIにすべき代表的な指標

• サーバーシステム
  可用性、レイテンシ、スループット

• ストレージシステム
  レイテンシ、可用性、耐久性

• ビッグデータシステム
  スループット、E2Eレイテンシ

• 正確性
  どれでも気にしろ

集計

メトリクスの計測に関してはバックエンドで計測が一般的

だが、JavaScriptの問題等で表示が遅くなる場合があるので、その場合はページ表示までの時間を計測する必要がある

ほとんどのメトリクスは平均より分布で考えよう
指標としてパーセンタイルを使えば分布の様子と属性検討がしやすい
ユーザーはレスポンスタイムのばらつきがあるサービスよりも、安定しているが遅いサービスを好むので高いパーセンタイルをSREは指標にしていくほうが良さそう。

また、1から考えるの大変なので、SLIの定義を標準化していこう

目標の実際

ターゲットを選択するときはSREが参加して助言をしたほうが良い

• 現在のパフォーマンスに基づいてターゲットを選択してはならない
• シンプルさを保つ
• 絶対は避ける
• SLOは最小限に
• 最初から完璧は求めない

計測値のコントロール方法

SLIのモニタリングを行う
SLOに対しSLIを比較し、アクションが必要か判断
必要ならターゲットを満たすために実現しなければならないことを明らかにする
行動

SLOの期待値調整

内部のSLOを外部公開しているSLOより厳しくすることで安全マージンをとる
過剰達成をすることで、実際のサービスパフォーマンスが基準となってしまうため、公開しているSLOより過剰に達成しない

あとから変えることが難しいので、あまり考えられいないSLO,SLAは公開しないほうが良い

5章トイルの撲滅

運用作業をトイルと呼ぶ

トイルとは
手作業で繰り返し行われ、自動化が可能、長期的な価値を持たず、作業量がサービスの成長に比例するもの

トイルはすぐに100%を埋め尽くしてしまう傾向にある。

SREの活動はいかに分類できる
ソフトウェアエンジニアリング
システムエンジニアリング
トイル
オーバーヘッド

SREは50%以上をエンジニアリングに当てなければなりません

トイルは低リスクでストレスが少ないので楽しむ人もいるかもしれません。
キャリアの停滞
→プロジェクトに使う時間が取れなくなり、つまらない仕事が多くなる
モラスの低下
→トイルの耐えられる量は人それぞれ

また、トイルに時間を使いすぎると
混乱の発生
→SREがエンジニアリング組織ではないと思われてしまう
進捗速度の低下
→トイルが多すぎると、生産性が下がる
習慣づけ
→トイルを多くやってしまうと、ほかからトイルが回ってくる悪循環が発生する
摩擦の発生
→チーム内のトイルへの認識のズレで摩擦が発生する
信義違反
→新しくSREチームに入るときに思ってたんと違うってなる

7章 Googleにおける自動化の進化

12章 トラブルシューティング

トラブルシューティングでつまづく点

• 手法の理解
• システムの知識

12.1 理論

障害の原因を考え、仮設を立て仮設を検証するというサイクルである

仮設の検証方法は2つ

• 観測されたシステムの状態と仮設を比較する。そこで仮設を支持するかしないかを決める
• とにかく手当をしてみる

仮設を検証し、ポストモーテムを作成するのが大事

システムへの理解がかけていることで落とし穴に落ちることがる

• 関係ないところやメトリクスを見てしまう
• 安全かつ効率的に必要なシステムや入力、環境の変更方法を誤解している
• 見当違いな仮設、過去の対処法への固執
• 間違った関係性を追求してしまう

1,2に関しては経験でどうにかなる、3はすべての障害の発生確率が同一ではないということがわかっていれば良い。単純な障害だと思うべし。4は相関関係は因果関係ではないということを覚えておく。

12.2 実践

トラブルシューティングの始まりは問題のレポートです

効果的なレポートは期待される動作と実際の動作を示すとともに可能であれば再現方法も出しておくほうが良い。

直接人へのレポーティングは品質低下、負荷の集中を生んでしまいます。

システムがその環境下でできる限りうまく動作し続けるには何を優先するかを決めることをトリアージと呼びます。

まず止血をしてから、治療をするようにしよう。

飛行機が墜落しそうとなったときに、故障の根本原因を追求せず皆を無事に着陸させることを優先すると同じようなこと。

検証するためには適切なログが必要になる。

コンポーネント間を流れるデータを見て、正しく動作しているかを診断する

テストデータを与えて返される結果が正しいかを検証するのが良い。

そのような対応が取れない場合は分割統治法を使う

コンポーネントを最初から調べていく？

二分法をすれば効率的に調べることができる

→コンポーネントを調べるってのがあまりイメージわかない

何が、どこで、なぜを調べることで障害が理解できる

直前の修正は問題を特定する上で効率的な出発点となります。

診断ツールを自分で作成するのも有効

根本原因を追求していく、一つずつステップ実行していって、リアルタイムチャット等に残せば作業ログが時間とともに残るのでポストモーテムの作成にも約立ちます。

12.3 否定的な結果の素晴らしさ

否定的な結果が出た場合は、無視せず公開しよう

2つ案があり、どちらか選べない場合は一つを実行してみると、どちらが優れているか見えてくる

そのまま応用できなくても、失敗から、ドキュメントを作る、ポストモーテムを作成することで役に立つ

そういったものは、都度検証をするよりも効率的である。

また、否定的な結果を公表することでデータドリブンになる。

12.5 トラブルシューティング

観察のためのしくみをいれる

メトリクスと構造化されたログ

13章 緊急対応

インシデントの具体的な例を示す

テストによっておこされた

スコープ等は適切であったが、依存関係が把握できていなかった

ロールバック手順はちゃんと手順かされていない

14章 インシデント管理

14.1 管理されていないインシデント

あなたはMaryです。

ビジネス側は激怒、無碍にできないアドバイス、最後には死ぬんかい

14. 2 詳細分析

技術的な問題への極端な集中を行ってしまった

問題を大きく捉える人がいなかった。

明確なコミュニケーションを取ることができなかった

良かれと思って勝手に変更を加える

14.3 インシデント管理のプロセスの構成要素

役割を分け、責任分岐点を作ることで各々の作業を把握することができる

自分の負荷が大きくなりすぎたら、他の人に任せる

役割構成

• インデント指揮者

必要性と優先順位に応じて責任を割り当てる。事実上、すべての役割を担う。

• 実行作業

インシデントに対応する。システムの修正は実行作業テームに限る。

• コミュニケーション

フロントマン。定期的に最新情報を発信し続ける

• 計画

長期的な課題を扱い実行チームを支援する。

バグの登録、夕食の発注、引き継ぎの調整など

インシデント時には一箇所に集まる

slackのようなチャットがインシデント時には有効

作業ログにもなるし、ポストモーテムの作成にも有効

インシデント指揮者の最も重要な責務はインシデントのドキュメントを常に最新に保つことである。

数人で同時に編集できる方が良い

付録Cにはインシデントドキュメントのサンプルがある

引き継ぎ時には次の指揮者が誰かということを明確にし、メンバーにも共有する

14.4 ちゃんとできたときの世界線

すべてうまくいっている

14.5 インシデントと宣言すべき場合

• その問題を修復するために別チームに関わってもう必要があるか
• サービス障害がユーザーに影響しているか
• 集中して分析を行って1時間以内に解決できるか

インシデント管理フレームワークは複数のタイムゾーンやチームにまたがる運用上の変更にも適応できる

インシデント管理は行わないと手順を忘れてしまうので、ロールプレイなどをして予め慣れておこう

インシデント管理のベストプラクティス

• 優先順位:止血しサービス回復
• 準備:手順をドキュメント化する
• 信頼:役割を割り当てて、信頼する
• 自己観察:自分の感情が荒ぶったときは応援を呼ぼう
• 代案の提案:選択肢を定期的に模索し、今やっていることが正しいのかを考える
• 訓練:プロセスを定期的に訓練する
• 持ち回り: インシデントの指揮者は持ち回りにしよう。属人化しないために。