SRE サイトリアイアビリティエンジニアリング 5章まとめ

前章はこちら

www.te-nu.com

5章 トイルの撲滅

トイルの定義

• 運用作業という言葉は誤解を招きかねないため、Googleではトイルという言葉を用いる、これは「やりたくない仕事」ではなく、汚れ仕事など単純に言い換えられるものでもない
• トイルとは以下の傾向を持つ、1つ以上当てはまればトイルの度合いは高い
  • 手作業
    • 自動で作業をするスクリプトも、手作業で叩いていればトイルの時間
  • 繰り返し行われる
    • 0~数回目、もしくは新しい問題を解決していればトイルではない
  • 自動化できる
    • マシンが人間同様にできる作業
    • 人間の判断が必要ならトイルではない
  • 戦術的
    • ページャーのアラートの対応はトイル
  • 長期的な価値を持たない
    • あるタスクを追えたあとでも、サービスが同じ状態であればトイル
  • サービスの成長に対してO(n)
    • サービスのサイズやトラフィック・ユーザの量に比例してスケールするタスク

トイルは少ないほうが良い理由

• GoogleのSREの組織はトイルを各人の作業時間の50%に抑えるという目標がある
• 各人は作業時間の50%を将来のトイル撲滅や機能追加するプロジェクトの作業に費やされるべきである
• 機能開発の焦点は信頼性やパフォーマンスの改善に置かれることが普通で、これでトイルを削減できることもある
• 50%に目標を定めている理由はトイルは確認せずにいると知らない間に拡大し、急速に100%になってしまう傾向があるためである、トイルを撲滅し、サービスをスケールさせる作業がSREにとってのエンジニアリングである
• これを守ることで、採用する際に運用の組織では無いことを約束するし、運用の組織に退化させないようにしなければならない

エンジニアリングであるための条件

• エンジニアリングの作業とは、新しいことをするものであり人間の判断を必要とする。更には恒久的にサービスに改善を加え戦略によって導かれる
• 典型的なSREの作業は以下に分類できる
  • ソフトウェアエンジニアリング
    • コードの作成・修正
    • 設計のドキュメント作成
    • 例：自動化スクリプト作成・ツールの作成
  • システムエンジニアリング
    • プロダクションシステムの設定
    • システムに関するドキュメント作成
  • トイル
  • オーバーヘッド
    • サービス稼働に直結していない作業
• SREは四半期（または1年）を通して平均して見た時に最低50%をエンジニアリングの作業に割り当てないといけない

トイルは常に悪なのか？

• 必ずしも全員を不幸にするわけではない、量が少ない場合は特に
• 予測可能な繰り返しタスクは穏やかで、達成感を生んでくれる
• トイルは常に悪いものではなく、エンジニアリングを行うほぼ全ての職務にとって多少のトイルは避けられないことを認識しておく必要がある
• 少量で楽しめる程度であれば気にしなくても良いが、大量にある場合は有害となる
  • キャリアの停滞
    • つまらない仕事からキャリアは生まれない
  • モラルの停滞
    • 多すぎるトイルは燃え尽き、倦怠、不満を生む
• 更にトイルに時間を使いすぎるとSRE組織に以下のダメージを生む
  • 組織の混乱
    • トイルに集中しすぎるとSREという組織について混乱が生まれる
  • 進歩速度の低下
    • 消火活動ばかりしていると開発速度は下がる
  • 習慣づけ
    • トイルに取り組むのに必死すぎると、開発側はもっと多くのトイルを回したくなり、開発側の運用タスクもSREに回し始めるかもしれない
  • 摩擦の発生
    • 個人的にトイルに不満がなくとも、周りや将来のチームが好きではないかもしれない
  • 信義違反
    • 新しくSREチームに入った人が騙されたと思う

まとめ

• 毎週少しずつトイルをなくしていけば、徐々にサービスをクリーンアップできる。
• 全体の労力を生産性のあることにシフトしていける
• イノベーションを増やし、トイルと減らそう

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリアイアビリティエンジニアリング 4章まとめ

前章はこちら

www.te-nu.com

4章 サービスレベル目標

サービスレベルに関する用語

• サービスを適切に管理するためには、サービスの中で重要な振る舞いがどれかということと、その計測と評価の方法を理解する必要がある
• Googleでは以下を定義している
  • サービスレベル指標（service level indicators=SLI）
  • サービスレベル目標（service level objectives=SLO）
  • サービスレベルアグリーメント（service level agreements=SLA）
    • サービス品質保証と言われていることもある
• これらを適切に設定し、計測することで何かあった際に適切なアクションを取れるし、サービスが健全であるという確信にもつながる
• SLIはサービスのレベルの性質に関して定義された計測量で、多くのサービスではリクエストのレイテンシを考慮する、他にはエラー率やシステムスループットがある
  • サービスの性質に応じて計測するものが変わる
• これは直接計測することが理想だができない場合は代用の値を計測することがある、フロントで計測したいがサーバサイドでしか出来ない場合はサーバサイドでの計測値を使うケースがある
• SREにとって重要なもう一つの項目が可用性である。これはサービスを利用できる時間率やリクエスト率で表される100%はありえないため、99%（2ナインズ）や99.999%（5ナインズ）といった"9"の数で表現する
• SLOはSLIで計測されるサービスレベルのターゲット値、あるいはその範囲であり、SLOの自然な構造はSLI <= ターゲットあるいは下限<=SLI<=上限となる
• 検索結果を高速に返したい場合は、検索結果に対する平均レイテンシを100ms以下にするようSLOを設定する
• 適切なSLOを設定するのは複雑な作業である。全リクエストを100msにすることは現実的ではないが、平均を100msにするということは可能であり、こういったゴールを設定することは、低レイテンシのためのアプローチに対する良い動機づけになる
• SLOを設定し、ユーザーに公表することはサービスの挙動に対する期待を設定するということである、これによって隠れた不満を減らせる
• 明示していない場合、ユーザは独自の考えを持ち、過剰な信頼もしくは信頼の損失を引き起こす要因となる
• SLAはユーザとの間で結ぶ契約であり、SLOを満たした場合やそうでなかった場合に関する規定が含まれる。金銭やペナルティがわかりやすい例だがそれ以外もある
• SLOとの違いをはっきりさせるためには「SLOが満たされなかった場合はどうなるか」という問いが効果的で、明確な規定があればSLA、そうでなければSLOである
• SREはビジネスに密接に関係するSLAの構築には関わらない。SLOを達成することや、SLIを策定することに関わる

指標の実際

• モニタリングできるメトリクスの全てをSLIにすべきではない、ユーザがシステムにもとめていることを理解すれば、賢明に選択はできる。逆に少なすぎても重要な挙動を検証できなくなってしまう
• サービスの障害はいくつかに分類ができる
  • ユーザとやりとりをするサーバシステム
    • 可用性
    • レイテンシ
    • スループット
  • ストレージシステム
    • レイテンシ
    • 可用性
    • 耐久性
  • ビッグデータ
    • スループット
    • E2Eのレイテンシ
  • 全て
    • 正確性
• 多くの指標はサーバサイドで収集するのが自然で、500レスポンスの比率などといったものを定期的なログ分析を使って行う。しかし、javascript問題から生じるレイテンシの低下などを見落とす恐れもあるため、クライアント側での収集が必要なこともある
• 単純さと使いやすさのために生の計測値が集計されるが、単純そうに見える集計値でも本当に必要なものが隠れている場合があり、注意が必要である。１分毎の平均リクエストを集計していれば、そのうち数秒だけバーストしていても隠されてしまう
• ほとんどのメトリクスは平均よりも分布で考えるほうが良く、SREは優先的にパーセンタイルを用いて分布の様子と様々な属性について検討を行う
• 一般的なSLIに対しては定義を標準化し毎回最初から考えずに済むようにしておくことをすすめる
  • 例
    • 集計のインターバル：1分
    • 集計の対象領域：クラスタ内の全てのタスク
    • 計測の頻度：10秒
    • 計測方法：モニタリングシステムを通じて、サーバで計測

目標の実際

• まずはユーザが気にすることがなにかを考え（または知る）必要があり、それが数値化し辛いものであれば他の数値で近似しなければならない。単純に計測のしやすさで決めてしまうと適切ではないSLOが生まれることになる
• 定義を明快にするため、SLOは計測の方法と計測値が適正である条件を指定するべきである
  • GetRPC呼び出しの99%(1分間での平均)が100ms以下で完了すること
  • GetRPC呼び出しの99%が100ms以下で完了すること
• パフォーマンスカーブの形が重要であれば、SLOのターゲットを複数指定することもできる
  • GetRPC呼び出しの90%が1ms以下で完了すること
  • GetRPC呼び出しの99%が10ms以下で完了すること
  • GetRPC呼び出しの99.9%が100ms以下で完了すること
• スループットが重要になる処理とレイテンシが重要になる処理といった具合に異なるワークロードを持つユーザがいるのであればそれそれに対して目標を設定することが良いかもしれない
• SLOを常に満たし続けるのは望ましくない、それはイノベーション・デプロイメントの速度の低下、高価で過剰に保守的なソリューションにつながる。それよりもSLOを満たせない比率を示すエラーバジェットを認めて、日毎・週毎で追跡するのが良い。SLOの未達成率はユーザから見たサービスの健全性の指標になる
• SLOの選択は純粋に技術的な活動では無く、ビジネスの事情（スタッフ・資金など）がSLI・SLOどちらにも反映されるはずであり、SREもその選択の議論に参加しアドバイスを行うべきである。その議論を生産的に行う上で役立つことを経験から学んだ
  • 現在のパフォーマンスに基づいて決めてはいけない
    • 満たすために超人的な努力が必要なケースがある
  • シンプルに
  • 絶対を避ける
    • 常に無限スケールして利用できるシステムを求めたくなるが、ユーザが満足するレベルを超えていることになる
  • SLOは最小限に留める
    • 業務の優先順位に関与したことがないSLOには価値がない、しかし全てのプロダクトの属性がSLOの下にあるわけではない
    • ユーザの感動をSLOで規定することは困難
  • 最初から完璧でなくともよい
    • 見直していく
    • 緩め→厳しめが良い
  • SLOはユーザの関心事が反映されるため、開発者の仕事の優先順位に大きく関与する。
  • よく考えられていないSLOは超人的な努力を強いることになったり、甘すぎるSLOのせいでプロダクトの質が落ちたりするため賢明に利用することが大事
• SLIとSLOはシステム管理のサイクルに欠かせない
  • 計測する
  • SLOとSLIを比較、アクションが必要か判断
  • 必要なら何が必要かを定義
  • 実行
• SLOがなければアクションが必要かどうかも判断できなくなる
• SLOを公開することでシステムの挙動に対する期待について定まる、現実的な期待をユーザのために設定するには以下の戦略を検討すると良い
  • 安全マージンの確保
    • 公表するSLOを内部のSLOより少し厳しくしておく、ユーザの失望を招かずに行動が取れる
  • 過剰達成を避ける
    • 公表されているSLOよりはるかに提供しているものの方が優れていた場合、ユーザは後者に依存するようになる

アグリーメントの実際

• SLAを工夫するにはビジネス及び法務が違反のペナルティを適切に選択する必要がある
• SREの役割はSLAに含まれるSLOを満たせる可能性をビジネス及び法務に理解してもらうことを支援すること
• 顧客が幅広くいる場合はSLAの変更や削除が難しくなるので、ユーザに公表する情報は控えめにしておくのが賢明

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリアイアビリティエンジニアリング 3章まとめ

前章はこちら

www.te-nu.com

3章をざっくりとメモしました。こってりした本なので全然進まないです……。

リスクの受容

• Googleは決して障害を起こすことがないサービスを目指していると思われているかもしれないが、実際にはある一線を超えるとサービスやユーザにとってむしろマイナスであることが分かっている

• コストは劇的に増大する一方でユーザは99.99%と99.999%の可用性の違いについてはわからない

• このことを念頭に置き、SREは可用性におけるリスクとイノベーションの速度・サービス運用の効率化のバランスを取り、最適化を図る

• 信頼性のないシステムは急速にユーザの信頼を失うため、障害の可能性は減らさなければならない

• しかし信頼性とコストの関係は比例ではない。ある信頼性を上げるための改修は前回に比べて100倍のコストがかかる場合もある

• このコストには2種類の特徴がある

  • 冗長なマシン/リソースのコスト。冗長化にコストをかけることで、メンテの際に一部をオフラインにしたりできる
  • 機会のコスト。リスク回避のためにエンジニアリソースを割り当てるため、新機能の開発などができなくなる

• 信頼性を高めるためにエンジニアリングを見出すことと、サービスの障害許容レベルを定める事は等しく重要で、ゴールはサービスの取るリスクと、ビジネスが許容できるリスクの歩調を合わせることである

• 最適化したいシステムの特徴を表す客観的なメトリクスを見出すことは非常に有益であり、Googleにおける標準的なプラクティスである

• 潜在的な要素の全てを1つのメトリクスにまとめる方法は一見わからない、そのためGoogleでは扱いやすくするため「計画外の停止時間」に注目している

• リスクの許容度を単純明快に表す方法は計画外の停止時間の許容レベルで見ることである。これは99.9%なのか99.99%なのかといった、達成したい「9」の数で示し、9の追加の度に1桁の改善が必要になる

• これは 可用性=稼働時間/稼働時間+停止時間という式で求めていたがGoogleのようなグローバルに分散されたサービスではあまり意味を持たない

• そのためリクエスト成功率という観点で可用性を定義している、計算方法は 可用性=成功したリクエスト数/総リクエスト数である

• これは直接クライアントに関係しないシステムでも最小限の変更で適応ができる

• Googleは可用性のターゲットを四半期単位で設定し、それに対して月・日単位で追跡する。この方策のおかげで、修復価値のある特異点を見つけ追跡、修復することで高レベルの可用性の目標を掲げてサービスを管理できる

• Googleのコンシューマサービスにはプロダクトマネージャーが存在し、信頼性について議論する相手はそのプロダクトチーム、もしくは構築したエンジニア達になることが多い

• リスク許容度の評価に対しては多くの要素がある

  • 必要な可用性のレベル
  • 障害の種類の違いによるサービスの影響の差
  • リスク曲線上において、サービスコストはどのように利用できるか

• サービス可用性のターゲットレベルは提供する機能と市場におけるサービスの位置づけに依存する

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

• Gsuiteの場合は問題発生時にはGoogleだけでなく関連企業への影響も強いため高めのものに設定し、対してYouTube買収時には機能開発の速度に重点を置くべきだったため低めに設定した

• 予想される障害がどのようなものかも重要な検討事項である、低い発生率で障害が続くことと、時々完全にシャットダウンすることとではエラーの絶対数が同じでもビジネスに対するインパクトは大きく異なるかもしれない

• コストは可用性のターゲットを適切に設定する主要な要素である。可用性を1ケタ改善すると収入はどのような増加するか、その増加はコストに見合うかということを分析する

• このようにシンプルに計算できない場合は、インターネットサービスプロバイダのエラー率を考え、そのエラーに紛れられるかどうかで考えると良いかもしれない（0.01~1%の間）

• リスク許容度を検討する際に可用性以外のメトリクスも合わせて考えると有益であり、リスクを取る際に様々なメトリクスの重要性を知っておくことで自由度が増す

• （Bigtable[Cha06]を例に具体的な考え方を書いていたがここでは省略）

• プロダクト開発チームとSREチームは評価軸が開発スピードと信頼性とで大きく異なり、それが両者に緊張を生んでいる

• 緊張で典型的なものとしてはソフトウェア障害の許容度・テスト・プッシュの頻度・カナリアテストといったものがある

• そしてこのバランスは政治や恐怖や願望によって決められているかもしれない(Google SREの非公式のモットーは「希望は戦略にあらず」)

• 対してチームのゴールは交渉を生産的な方向へ導くための客観的なメトリクスを用意し、両者に合意をもらうことである。判断はデータに基づいている程良い

• そのためにSLO（4章で説明）に基づく四半期のエラーバジェットを規定する。これは四半期内でサービスの信頼性が損なわれる許容範囲を示し、このメトリクスは開発者とSRE間の交渉から政治を取り除く

• Googleのやり方はPMがSLO、期待される可動時間を制定する。そして中立的なモニタリングシステムにより計測を行い、期待する稼働時間との差分をエラーバジェットの予算とする、そしてまだ残っていれば新しいリリースをプッシュが可能となる

• エラーバジェットのメリットはプロダクト開発者とSREの間で共通のインセンティブを定期用し、両者がイノベーションと信頼性のバランスに対して注力できるというところにある

• エラーバジェットが底をつきそうなら、リリースの速度を下げたり、ロールバックを行うといった方法がとれる

• エラーバジェットが消費されると開発者が自分で行うテストを増やすといった自己統制を行うこともある

• エラーバジェットは増やしてイノベーションを加速させるという選択肢を取ることもできる

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリアイアビリティエンジニアリング 2章まとめ

前章はこちら

www.te-nu.com

2章をざっくりとメモしました。

2章 SREから見たGoogleのプロダクション環境

• Googleのデータセンターは一般のものと大きく異なり、従来では見られなかった問題や機会を生み出したので、これらの解説と本書で使う用語を紹介する

• GoogleのコンピュートリソースのほとんどはGoogleが設計したデータセンターにある、これらのハードウェアはデータセンター名で統一されている

• 用語

  • マシン：1つのハードウェア（または1つのVM）
  • サーバー：サービスを実装しているソフトウェア

• マシンは任意のサーバーを動作させることができるので、あるマシンをあるサーバ専用にする必要はない

• 代わりにGoogleのクラスタオペレーティングシステムであるBorgがリソースの割当を行う

• Googleにおけるサーバーという言葉の違いは通常とは異なるが慣れてしまえば妥当たと明らかになるだろう

• Googleのデータセンターは数十台のマシンが1つのラックに配置され、それら複数が1列に並び、1~数列でクラスタを構成する。そして1つのデータセンターの建物は複数のクラスタを格納する。データセンターの建物複数はキャンパスを構成する

• データセンター内のマシン群はお互いに通信出来なければならないため、数万のポートを持つ高速な仮想スイッチをGoogleは開発した

• Googleのハードウェアはスケーラビリティが高いソフトウェアで管理されている、これによって注意しなければならないことの一つがハードウェアの障害である

• Googleの管理しているマシンはとても多いため、障害の数はとても多い。その中でもユーザやチームに影響を与えないようにしている。各データセンターキャンパスには専門のチームがいる

• マシン群の管理はBorg（Kubernetesの先祖）という分散クラスタオペレーティングシステムで行っている

• Borgはクラスタ単位でジョブの管理を行い、ユーザからのジョブの実行を受け持つ。ジョブには同一タスクが一つ以上含まれることがあるが、これには2つ理由があり、信頼性の担保と、単一プロセスではクラスタにきたトラフィックを処理しきれないためである

• Borgはタスクを実行させるマシンを見つけて実行させ、モニタリングを行う。異常があればkillして再起動を行う

• タスクはマシン間で流動的に割り当てられるため、IPやポートで参照できない。そのためタスク開始時にBorg Naming Service(BNS)を使い名前とインデックス番号を割り当てる

• Borgはリソースの割り当ても行うので全てのジョブはリソースの指定も行わなければならない。また、障害ドメインも考慮に入れ全タスクを同じラックで行わないようにもしている

• タスクはローカルディスクをスクラッチパッドとして使うことができ、永続化ストレージとして使えるクラスタのストレージも複数用意されている（ListreやHDFSに相当）

  • スクラッチパッドメモリ：Scratchpad memory、CPUの近くに配置された高速なメモリのこと。

• ストレージレイヤーはクラスタで利用できるストレージへ高い信頼性の元容易にアクセスできるようにする、ストレージには多くのレイヤーがある（図を使って細かく説明していたがここでは省略）

• Googleのネットワークハードウェアは複数の方法で制御されている。低価格な「ダム」スイッチングハードウェアを集中コントローラと合わせて使いネットワーク間の最善経路を事前に計算している

• こうすることでルータにルーティングの判断をさせずに済み、シンプルなスイッチングハードウェアを使える

• 他にも重要なコンポーネントがある（ここでは省略するが、ロックサービス、モニタリングなどがあった）

• Googleは開発の速度を重要視しているため、Googleのインフラストラクチャを最大限に活用できる完全な開発環境が構築されている

• Googleのほとんどのソフトウェアエンジニアは単一のリポジトリを使って作業を行う、これはワークフローについて重要な影響を及ぼす

  • 自分のプロジェクト外の問題に遭遇した場合に、問題を修正して変更の提案をそのプロジェクトの人にレビューしてもらい、メインラインに投入してもらうことができる
  • 自分のプロジェクト内のソースに変更を加える際にはレビューをしてもらわなければならない

• ソフトウェアのビルドはデータセンターにリクエストを送って行ってもらう、テストの際にも使われ他プロジェクトに影響が出る時は通知が飛ぶようになっている

• （サンプルがあったがここでは省略）

感想

「Googleの環境はすごいんだぜ」って章でした（笑）。規模が大きいのでそのまま参考にすることは出来なさそうでしたが、実際の環境を紹介しながら背景や理由などを説明してくれているので、それは参考にできそうでした。

次の章

www.te-nu.com

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング 1章まとめ

最近SRE本を読み出しました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

内容が濃いし、ページ数も多いのでSlackのThreadにまとめながら読んでおります。

社内の人から反応をもらえたりして良い感じです。

上記のように箇条書きでざっくりまとめたものをブログに貼って備忘録にしたいと思います、読み進める上で誰かの参考になると幸いです。

1章 イントロダクション

• 以前は巨大なシステムを保守する人（ops）と開発する人（dev）で組織を分けていたが、コスト面やコミュニケーションなどでリスクが大きかった

• GoogleのSREチームではソフトウェアエンジニアを採用することに注力し、シスアド（管理者）が手作業でやっていたこともシステム化させた

• SREのチーム編成は50~60%がソフトウェアエンジニアであり、残りの40%がソフトウェアエンジニアの要項を85~99%を満たしつつ更にUNIXシステムとネットワーキングなどの知識を持ったエンジニアである

• 結果手作業を自動化するスキルセットを持ち、それを実行することをいとわないチームができた

• サービスの拡大に伴う運用の負荷を抑えるには、コードを書かなければならない。GoogleのSREチームでは運用業務の上限を50%にし、残りの時間を開発を行うためのものとした。超過した時間の文のタスクは開発チームへと差し戻す

• このルールを実行するには計測をする必要があり、これができれば開発ができていないチームの習慣を変えることができる

• GoogleのSREチームのアプローチには多くのメリットがある

• 直接コードの修正を行うので、素早い変更を広く受け入れることが可能であり、開発/運用の分断を回避し、開発チームの改善も行う。更には開発とSREチームの異動も用意なので相互にトレーニングも可能である

• 課題は人材の採用で、高いスキルセットが必要な上にユニークな業種なので取れる人は少ない

• SREの伝統的ではないアプローチにはマネージメント層のサポートが不可欠

• SREの基本的な責任はどのチームでも共通で、主にサービスの可用性・レイテンシ・パフォーマンス・効率性・変更管理・モニタリング・緊急対応・キャパシティプランニングである

• SREは運用と開発の対立をエラーバジェットの導入を行うことで解決をした。

• エラーバジェットとは100%の信頼を目標とすることは基本的にいかなる場合にも間違っているという所見から生じたものである。可用性のターゲットを1から引いたもので（可用性が99.99%は0.01%が利用できないということになる）計算し、許容する0.01%をこのプロダクトのエラーバジェット（予算）という

• SREと開発者は機能のリリース速度の最大化のためにエラーバジェットを使うことを目標にする。障害は悪いことではなく、SREは障害をゼロにすることを目標にするのではなく、開発者と共に障害をコントロールするようになる

• モニタリングは健全性と可用性の追跡のための主要な手段の一つであるり、方針は十分に検討する必要がある。

• これまで一般的だったモニタリングのアプローチである、しきい値を超えた際にアラートを発するというものは効果的なソリューションではない。なぜなら人間がアラートを読み、アクションが必要化を判断しなければならないからである

• アラートの領域のどの部分をとっても人間の解釈は必要であってはならない。代わりにソフトウェアが解釈を行い、人間のアクションが必要な時にのみ通知を受けとるようになっているべきである

• 効果的なモニタリングの出力は3つの種類がある

  • アラート：即座にアクションが必要であることを知らせる
  • チケット：システムが対応できないためアクションが必要であるが、即座ではない
  • ロギング：アクションは必要でなく、見る必要も無い。何かが起きた時に読むもの。

• 信頼性は平均故障時間（MTTF）と、平均修復時間（MTTR）の関数である、人が関わればレイテンシが生じるため、障害が多くても人間の介入を必要とする事態を避けていれば高い可用性を持つことになる

• 人間が関わる場合もベストプラクティスを考えておき、手順書にまとめることで「即興で行く」方針よりMTTRは3倍の改善が見られた

• GoogleのSREはオンコール手順書を使い、練習も行う

• SREは70%の障害は動作中のシステムの変更によって生じていることを発見した。この領域におけるベストプラクティスは、漸進的なロールアウト・高速かつ正確な問題の検出・問題時の安全なロールバックを自動化することである

• これらのプラクティスから人手を除外することで、慣れからの軽視、不注意といった問題を回避し、リリースの速度と安全性が高まる

• 需要予測とキャパシティプランニングは予想されている未来の需要に対して必要な可用性を提供できる十分なキャパシティと冗長性を保証することである

• 特別な概念では無いが、これを確認する手順を踏まないサービスやチームが多い

• キャパシティプランニングでは自然な成長と突発的な成長の双方を考慮に入れておくべきである

• キャパシティプランニングにはいくつかのステップが必要である。

  • 自然な需要の正確な予測
  • 需要予測に突発的な需要の発生源を織り込む
  • 計算リソースのキャパシティ（サーバのスペック）とサービスのキャパシティ把握のための定期的な負荷テスト

• プロビジョニング（必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと）は、変更管理とキャパシティプランニングの双方の組み合わせである。キャパシティは高価なので、プロビジョニングは必要な時にのみ正確にすばやく行うべきである。さもないと必要な時にキャパシティが活用できなくなる

• 大抵の場合キャパシティの追加には新インスタンスの立ち上げが必要になり、既存システムをかなり変更する必要がありリスクが高い

• リソースの効率的な活用はサービスで費用を考えるには重要で、最終的にプロビジョニングをコントロールするSREは利用率に関係する仕事にも携わらなければならない

• リソースの負荷は需要・キャパシティ・ソフトウェアの効率性によって決まり、SREはこれらすべてに関わる。そしてこの3つの要素はサービスの効率性の大部分を占める

• SREと開発者はパフォーマンス改善のためにモニタリングと改修に務めなければならず、キャパシティを追加して効率を改善する

• SREは大規模かつ複雑なサービスの管理においてこれまでの業界のベストプラクティスからは逸脱している。一連の指針・プラクティス・動機づけ・ソフトウェアエンジニアリングという広大な領域の中の注力分野となった

次の章

www.te-nu.com