『SRE サイトリライアビリティエンジニアリング』を読んで
初はてなブログです。都内でインフラエンジニアをしています。よろしくお願いします。
オライリー・ジャパンから発刊されている『SRE サイトリライアビリティエンジニアリング』を読みました。昨年末に購入してようやく読み終わったので、備忘録も兼ねて気になった内容や雑感などを記したいと思います。
なぜ読んだのか
最近（もっと前からか？）SRE（サイトリアイアビリティエンジニア）という言葉がエンジニア界隈で多く聞かれるようになりました。セミナー講師の職種でもインフラエンジニアとか開発エンジニアではなく、SREという方がちらほらいて、SREってなんだろう？どういった仕事をするんだろう？と興味を持ったのがきっかけです。ググっていくうちにオライリーの本を発見し、購入してみたという流れです。
概要・雑感
まず本の紹介ですが、公式HPによると
サイトリライアビリティエンジニアリング（SRE）とは、Googleで培われたシステム管理とサービス運用の方法論です。GoogleのSREチームの主要メンバーによって書かれた本書は、ソフトウェアのライフサイクル全体にコミットすることで世界最大規模のソフトウェアシステムがどのように構築、導入、監視、維持されているのかを解説します。 はじめにリスク管理やサービスレベル目標、リリースエンジニアリングなどSREの行動の基礎となる原則について解説し、次にインシデント管理や障害の根本原因分析、SRE内でのソフトウェア開発など大規模分散コンピューティングシステムを構築し運用するSREの実践について詳述します。さらにSREのトレーニングやコミュニケーションなどの管理について紹介します。 急速にスケールするサービスを高い信頼性で運用する方法を解説する本書はエンジニア必携の一冊です。
と紹介されています。実際に読んだ感想としては、これはエンジニア向け「だけ」の本ではなく、万人受けする「ビジネス書」だなと。34章（！）、500ページ超とボリュームに圧倒されますが、随所に名文や金言が多くあり、非常にためになります。オライリー社の本ということもありITエンジニア向けですが、技術よりの難しい記述は少なく、チームビルディングや仕事の効率化など、IT業界以外の多くのビジネスマンに役に立つ内容だと感じました。
気になった部分を章ごとに羅列していきたいと思います。さらっとしか読んでいない章は飛ばします。本の読み方は千差万別かと思いますが、私にとっては、自分が日常にやっている「運用」との違いを重点的に見ています。なので、あまりにも自分の業務とかけ離れる様なところは完全に飛ばしたりしています。
このブログを読んで、特に、自分と同じ様に運用をメインでやっている人に実際に本を読んでみようかなあと気になっていただければ幸いです。
前提として
最近日本でも職種として増えてきたSREですが、Google社は2003年に初めてSREチームが出来たそうです。本書はその2003年から原著が発刊された2016年までの膨大なGoogleのSREの記録です。Googleのような巨大な世界規模のサービスが止まらずにいつでもどこでも利用できるのは、何故なのか。いったいどのような運用を行っているのか（または行っていないのか）が分かります。
本書では従来のシステムエンジニアリングの概念を覆す理念が次々に紹介されていて、ページをめくる度に「やっぱりGoogleはすごい」という思いが滲み出てきます。Google特有（もしくは自分が知らない）用語も数多く出てきますが、折に触れて解説や脚注が丁寧についていて、読者が置いていかれるようなことはありません。
第Ⅰ部 イントロダクション
１章 イントロダクション
Google内で規定されることになったサイトリライアビリティエンジニアリングとは、いったい何なのでしょうか。（中略）SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。 P.5
SREの構成の半分はソフトウェアエンジニアで、もう半分は85%から90%ソフトウェアエンジニアのスキルセットを持ち、かつUNIXシステムの内部とネットワーキング（L1〜L3）に関する専門知識を持ったメンバーで構成されているそうです。これは複雑で巨大なシステムをいかに人間の手で運用することを少なくするかという課題に答えるには、ソフトウェアエンジニアリングで自動化するしかないからでしょう。
自分も完全にこの意見には同意します。ただ、そうはわかっているけど、日々の運用に追われてしまう。ということも往々にしてあると思います。そこで、GoogleのSREは「チケット」「オンコール」「手作業」といった「運用」業務の合計を50%以下にする様に上限を決めたそうです。
これにはかなり衝撃を受けました。チーム全体としてこういった目標を立てることが、如何にメンバーの負担を減らすかという目標設定に繋がり、それはとても健全だと思います。
他にもSREの信条や信頼性の考え方、モニタリングやプロビジョニングの考え方など、SREの仕事についてやDevOpsとSREの違いなども書かれています。
第Ⅱ部 原則
3章 リスクの許容
サービスのエラー率がバックグラウンドのエラー率よりも低くできるなら、サービスのエラーはユーザーのインターネット接続のノイズに紛れることになります。 P.33
コスト効率を損わず満たす方法の一つは、そのインフラストラクチャを分割し、複数の独立したレベルのサービスとして提供することです。 P.34
これも自分としては衝撃でしたが、GoogleのSREは100%の信頼性を追うために（必要以上に信頼性を高める様に）仕事をすることはしない。と明確に記されています。可用性を1桁上げるためにどれくらいのコストがかかるのか、という視点で業務のコストと可用性のバランスをとっています。
信頼性と収入との関係性の例として、ISPの典型的なエラー率との兼ね合いで許容できるエラー率を決める。という点も自分にはなかった視点でした。
4章 サービスレベル目標
言うまでもないことですが、サービスを適切に管理するには、サービスの中で特に重要な振る舞いがどれかということと、そういった振る舞いの計測と評価の方法を理解しなければなりません。 P.39
GoogleのSREはサービスレベル指標 (service level indicators = SLI)、サービスレベル目標 (service level objectives = SLO)、サービスレベルアグリーメント (service level agreements = SLA)を定義しています。
SLIは重要な指標としてリクエストのレイテンシを考慮します。また、他にはエラー率（受信したリクエストに対する比率）やシステムスループット（毎秒のリクエスト数）などを指標としているそうです。また、「可用性」や「耐久性」についても同様に重要であることが記されています。
SLOはSLIで計測されるサービスレベルのターゲット値またはその範囲を表しています。SLOの自然な構造はSLI <= ターゲットあるいは下限 <= SLI <= 上限となります。例えばある検索を高速に返すのであれば、検索リクエストに対するレイテンシを100ミリ秒いかにする様にSLOを設定します。 これは "Speed Matters"に詳細が書いてあるそうで、近々この記事の翻訳もやろうと思っています。
この章を読む前はSLOとSLAの違いがよくわからなかったのですが、
SLOとSLAの違いをはっきりさせる最も簡単な方法は、「SLOが満たされなかった時にはどうなりますか？」と尋ねてみることです。特に明確な規定がないのであれば、それはほぼ間違いなくSLOです。 P.42
と明確に違いが書いてありました。ちなみに、SLAはビジネス的な指標なので、SREはSLAの構築には携わらない様です。そうは言ってもSLIをどう定義したら良いかわからないという方もいると思います（自分もそうです）。この章の後半ではその定義や例にも触れています。
5章 トイルの撲滅
SREは、運用作業よりも、長期間にわたるエンジニアリングプロジェクトの作業に時間を使おうとします。運用作業という言葉は誤解を招きかねないので、私たちはトイルという言葉を使います。（中略）トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。 P.51
Weblioによると、「トイル」とは、「骨折る、骨折って働く、骨折って進む、難渋しながら歩く」という意味だそうです。先述した通り、SREではトイルの比率を50%以下に抑える様に目標が掲げられていて、50%以上は「トイルの削減やサービスに機能を追加するエンジニアリングプロジェクトの作業に費やされるべきなのです。」とあります。
「機能開発の焦点は、信頼性、パフォーマンス、利用率の改善に置かれることが普通です」。とさらっと書いてあり、「トイルを減らし、サービスをスケールさせる作業が、サイトリライアビリティエンジニアリングにおける「エンジニアリング」です。」といまさにこの点がGoogleが次々と新しいサービスや機能を提供できる思想の一部なのかと思いました。ただしトイルは多少は避けられないもので、トイルが有害になるのは大量になった時だということも補足されています。
ちなみに、「サイトリライアビリティエンジニアリングにおける「エンジニアリング」」の詳細ですが、そのうちの一つの「ソフトウェアエンジニアリング」の中には、「自動化スクリプトの作成、ツールやフレームワークの作成、サービスへのスケーラビリティや信頼性のための機能の追加、インフラストラクチャのコード修正による頑健性の改善などがあります。」とのことで、この本を通じてずっと出てくる「自動化」と言った思想がはっきりと分かります。
6章 分散システムのモニタリング
GoogleのSREがモニタリングで注視しているのは、「レイテンシ」「トラフィック」「エラー」「サチュレーション」の4つとのことです。それぞれの 概要を簡単にメモしておきたいと思います。
- レイテンシ: リクエストを処理してレスポンスを返すまでにかかる時間です。特にエラーの場合のリクエストのレイテンシも追跡することが重要としています。また集計にはパケットしたリクエストカウントを収集して、0から10ms、10から30msなど、といった区分でそれそれいくつだったかを分けてヒストグラムにすれば、リクエストの分散の様子が可視化できる。
- トラフィック: システムに対するリクエストの量です。
- エラー: 処理に失敗したリクエストのレートです。プロトコルのレスポンスコードだけでは障害の状況をあらわすのには不完全なので、エンドツーエンドで補足すべきです。
- サチュレーション: サービスがどれだけ「手一杯」になっているかを示します。最も制約のあるリソース（例えばメモリに制約があるシステムであればメモリ、I/Oに制約があるシステムであればI/O）に重点を置いて、システムの利用率を計測します。
ここでも自動化における記述があります。
もしも根本的な解決ができないのであれば、アラートへの対応を完全に自動化するべきです。（中略）今日発生している一つ一つのページに人が対応するということは、それだけ明日のためのシステムの改善に充てる時間がなくなるということです。 P.67
7章 自動化の価値
今まで折に触れて出てきた自動化についてここで章立てで出てきます。普段の業務でも、「毎回これやるのは面倒だし、手動でも簡単だからつい毎回手作業でやってしまう。自動化する方が面倒だしな。。」と思ってしまうことがあるかもしれません（自分はあります）。その「自動化するべきか」という基準について、どう判断すべきかが書かれています。
しばしばエンジニアは、自動化をしたりコードを書いたりする時に、それによって省略できる手作業と、それを書くのに必要な労力とを比較して、十分な価値があるのか、迷うことになります。見逃されやすいのは、タスクをいったん自動化でカプセル化してしまえば、そのタスクは誰でも実行できる様になるということです。したがって、時間の節約の効果は、その自動化を使うかもしれない全員に及びます。オペレータを運用から分離することには、大きな価値があるのです。 P.73
本当に大規模なサービスの場合、自動化による一貫性、素早さ、信頼性というメリットが非常に大きくなるので、自動化を行うことのトレードオフについては議論するまでもありません。 P.74
これも優れたソフトウェアエンジニアリングスキルと地球規模にまたがった巨大なシステムを運用しているGoogleならではかもしれませんが、全ての会社・組織に言えることではないかと思います。
なお、この章で書かれている自動化のユースケースとしては以下が挙げられています。
- ユーザーアカウントの作成
- サービス用のクラスタのターンアップ及びターンダウン
- ソフトウェアあるいはハードウェアのインストールの準備や撤去
- 新しいバージョンのソフトウェアのロールアウト
- ランタイムの設定変更
- ランタイムの設定変更の特殊なケース：依存対象の設定変更
また、自動化においては以前はシェルスクリプトを利用していた様ですが、サービスの依存対象の利用可否や、設定とパッケージの同一性、例外的な設定が意図的な動作になっているかの確認が煩雑といった問題から、Pythonのユニットテストのフレームワークを拡張し、実際のサービスをユニットテストできる様にしたそうです。インフラストラクチャのテストに関しては、個人的に興味があるテーマなので、今後しっかり学んでいきたいと思います。
第Ⅲ部 実践
11章 オンコール対応
ちなみに第Ⅲ部は10章からです。
SREチームが純粋な運用のチームと大きく異なるのは、問題に対するアプローチにおいて、エンジニアリングの活用に非常に重きを置いているとことです。そう言った問題は通常は運用の領域に属するものですが、規模を考えればソフトウェアエンジニアリングによるソリューション無くしては扱うことが難しいのです。 P.131
最低でもSREの時間の50%はエンジニアリングに費やされるように努めています。オンコールは残りの時間の25%以上にならないようにして、他の25%はプロジェクトの作業ではない、他の種類の運用業務のために残せるようにします。25%のオンコールルールを使えば、24/7のオンコールローテーションを維持するのに必要なSREの最小人数が割り出せます。 P.133
運用のエンジニアにとって最適な人数とは？というのは難しい課題ですが、ここではその人数についての一つの考えが記載されています。章の後半でも、全てのエンジニアが四半期に一度や二度はオンコールを担当できるようにチームのサイズを調節すべきとあります。
また、対応についてですが、経験から言っても、オンコールの対応は非常に切迫していて、かつ時間帯によっては冷静な判断ができないことが多いと思います。その点については以下のように書かれています。
素早いリアクションは深く習慣に根差しているものであり、習慣から来る反応は思慮に欠けるものであり、大失敗を引き起こすかもしれないものです。インシデント管理における理想の方法論は、妥当な判断を下せるだけのデータが揃った時点で望ましいベースで手順を踏むことと、並行してその推定を批判的に検証することの間で完全なバランスをとるようにすることです。 P.135
最も重要なオンコールのリソースには以下のようなものがあります。
- 明確なエスカレーションパス
- しっかりと規定されたインシデント管理の手順
- 非難を伴わないポストモーテム文化
ポストモーテムについては15章で詳細に出てきます。
12章 効果的なトラブルシューティング
初心者のパイロットは、緊急時における一番の責任は飛行機を飛ばし続けることだと教わります。飛行機と搭乗者全員を無事に地上に降ろすことに比べれば、トラブルシューティングの優先度は低いのです。 P.143
12章では実際のケーススタディが描かれていて、リアルなトラブルシューティングが記載されています（負荷のグラフまでついている）。トリアージという節もあり、確かにトリアージという考え方はトラブルシューティングにぴったりだなと感心しました。本当に危機的な状況をまずは回避して、根本原因の調査や解決は後から行うというのは、基本そのものだと痛感しました。
13章 緊急対応
本書はやたら名文のようなものが多く、この章では特にそうです。内容は横に置いて、まずはその名文だけを拾っておきます。
壊れないものなど存在しません。それが人生というものです。 P.157
（システムが壊れた際に行うこととして）何よりもまず、パニックを起こしてはいけません。あなたはひとりぼっちではなく、この世の終わりというわけでもありません。 （中略）通常、誰も物理的な危険にさらされることはありません。危機的状況に陥るのは、不運な電子くらいのものです。本当に最悪の状況でも、インターネットの半分がダウンするくらいでしょう。ですから、まずは深呼吸して、それから先に進みましょう。 P.157
障害の対応について、「テストによって引き起こされた緊急事態」「変更が引き起こした緊急事態」「プロセスが引き起こした緊急事態」に分けて説明しています。そして過去の障害から学び、それを歴史として残すことと、予防的なテストの重要性について記されています。
14章 インシデント管理
インシデントで重要なのは準備だと個人的には思います。そして影響範囲が大きければ大きいほど、情報伝達の重要性が増すため、部署や組織を超えた連携が必要になることもあります。Googleのインシデント管理のシステムは、FEMAのIncident Command Systemに基づいています。 負荷が大きすぎるインシデントは、一人で解決しないので、同僚に任せ、以下のような役割を明確にすべきだとしています。
- インシデント指揮者
- 実行作業
- コミュニケーション
- 計画
また、どこに行けばインシデント指揮者とやり取りできるのかを明確にしておく必要があるとされています。
インシデントかどうかの境目は難しいと思いますが、その基準についても書いています。
- その問題を修復するために別のチームに関わってもらう必要があるか？
- サービス障害がユーザーに影響しているか？
- 集中して分析を１時間行っても、まだその問題は解決していないか？
後の章ではインシデントの訓練についても書かれています。この超巨大規模のGoogleですら、訓練をしているのをしっかりと覚えておかないといけません。
15章 ポストモーテムの文化：失敗からの学び
ポストモーテムの概念は、IT業界ではよく知られています。ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。 P.175
大事なことは非難を行わないこと。ポストモーテムで批判を行わないことは、SREの文化における信条です。
チームの「間違った」行いに対する指弾と不名誉の文化が広がってしまえば、人々は処罰を恐れて問題を公表しようとしなくなります。
非難のない文化は、ミスが致命傷となりうるヘルスケアや航空電子工学の業界に端を発するものです。これらの業界は、すべての「ミス」をシステムを強化する機会と見なす環境を育んできました。ポストモーテムが、責任のなすりつけ合いノバから、個人やチームが不完全または誤った情報を得るに至ったシステム上の原因を調査する場へと移行することで、効果的な予防策を導入できます。人を「修正」することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援するようにはできます。 P.177
これらの引用から全てが始まり、GoogleのSREはポストモーテム文化を育むために継続的な投資を行っていて、それによりサービス障害は減っているそうです。その中の一つに、効果的なポストモーテムを書くことは報われ、称賛される文化もあるということです。ポストモーテムの価値が高いことは、ラリー・ペイジまでもが語っていることです。
18章 SREにおけるソフトウェアエンジニアリング
SRE内での完全なソフトウェア開発プロジェクトは、SREに対してキャリア開発の機会をもたらすと共に、コーディングのスキルをさび付かせたくないと思っているエンジニアに力を発揮する場をもたらします。長期的なプロジェクトに携わることによって、強く求められる割り込みとオンコールのバランスをとることができると共に、自身のキャリアにおけるソフトウェアエンジニアリングとシステムエンジニアリングとのバランスを取りたいエンジニアは、仕事に対する欲求を満足させることができます。 P.214
SREはゼネラリストであることが多いものです。これは、深さ優先よりも幅優先で学びたいという意欲があることから、広い視点からの理解に向いていることによります（そして現代的な技術インフラストラクチャの複雑な内部動作ほど広い視点が求められるものは滅多にありません）。（中略）ユーザーが直接利用するソフトウェアの開発に馴染みがあるエンジニアのTPM、PMと組めば、ソフトウェアプロダクトの開発と実践的なプロダクション環境の経験の両方の良い面を併せ持つチームソフトウェア開発の文化を構築する役に立つことでしょう。 P.228
SREが推し進めるソフトウェアプロジェクトについての恩恵は計り知れないとあり、SREがソフトウェア開発に時間を割くことのメリットは最終的にはGoogleそのもの、SREの組織、そしてSRE自身が享受することになるのです。と記されています。例としてAuxonというGoogleにおけるインテントベースのキャパシティプランニングとリソース割り当てのソリューションについて紹介されています。
19章 仮想IPアドレスでのロードバランシング
この章では衝撃的だった一文だけ紹介します。いったいどういう仕組みになっているのかよく分かりませんが、大陸間でもバランシングするというスケールがすごいな、と思いました。
現在の私たちのVIPロードバランシングのソリューションは、パケットのカプセル化を使っています。ネットワークロードバランサーは、フォワードされたパケットを汎用ルーティングカプセル化 (Generic Routing Encapsulation = GRE)を使って別のIPパケットに格納し、バックエンドのアドレスを送信先として使います。（中略）お互いの間に経路さえ存在していれば、それぞれが別の大陸にあってもかまわないのです。 P.239
23章 クリティカルな状態の管理：信頼性のための分散合意
この章は個人的にとても興味があるので、どこかで別の機会にしっかりまとめようと思っていますのでここでは簡単に。
私が運用しているシステムではまだまだハートビートによる高可用性を用いているシステムが多く、グループ単位で分散を合意しながら信頼性と高可用性を維持する仕組みについては導入に至っていません。サーバーは２つ用意してリーダーとフォロワーをそれぞれ役割として与えると、システムのリーダー選択の基準は単純なタイムアウトになります。かといって人間へのエスカレーションを介すとスケールしないという問題があります。問題のあるグループメンバーシップの例では、ネットワークがそのクラスタを２分する障害が起こったときに、双方がマスターを選択してしまい、競合が起きてしまいます。
この章では、そういった課題に解決するべく、GoogleのSREが関心を持っているのは非同期分散合意です。厳密には非同期分散合意を有限時間内で解決することは不可能なため、平常時に信頼性を保って処理を進めるのに十分な数の健全なレプリカやネットワーク接続を確保することで、有限時間内での分散合意の問題にアプローチしています。
レプリカ数の話ですが、合意ベースのシステムは過半数のクォーラムを使って処理を行います。2f + 1個のレプリカからなるグループはf個の障害には耐えることができます。3つのレプリカがあれば、1つのレプリカがメンテナンスでダウンしていてもシステムは通常通りに運用できます（もちろん残りの2つのレプリカが負荷を許容できることが前提です）。合意システムがレプリカの多くを失い、過半数を構成できなくなったら理論的にはそのシステムは回復不可能になってしまいます。そのレプリカをどのように地球規模で分散するかも書かれており、非常に興味深い内容になっています。
本章から最低限学んでほしいのは、どういった問題が分散合意を利用することで解決できるかということと、分散合意の代わりにハートビートのような場当たり的な手法を取った場合にどういった問題が生じうるのかということです。リーダー選択、共有されるクリティカルな状態、分散ロック等を扱う場合には、分散合意について考えてみてください。分散合意に劣るアプローチを取るなら、それはシステム中に爆発のときを待つ爆弾を埋め込むことになるのです。 P.331
また、次の24章ではcronを分散合意システムで分散して可用性を担保することについて記されています。
26章 データの完全性：What You Read Is What You Wrote
GmailやGoogleドキュメントの内容が突然消えたらどれだけパニックになるか分かりません。Googleのデータの完全性の厳格な要求は、かなり強いものです。
データの完全性とはクラウドのサービスがユーザーからアクセス可能であること。ユーザーからのデータアクセスは特に重要なので、このアクセスは完全な形を保っていなければならないと言えるでしょう。 P.359
ユーザーの観点から見れば、期待通りに常にデータが利用できなければ、データの完全性が保たれていようと実質的にそのデータは存在していないも同然だということです。 P.363
この章では、論理削除についての重要性についても述べられています。また、バックアップは取っていてもそれがリストアできなければ取っていないのと同じだというドキッとするようなことも書かれています。
後半では2013年にGoogle Musicで発生したデータ消失がケーススタディで描かれています。このケーススタディは読み物としてかなりスリリングで、この部分だけでも一見の価値ありです。
第Ⅳ部 管理
第28章 SREの成長を加速する方法：新人からオンコール担当、そしてその先へ
ここまでこの本を読み進めてきて、GoogleのSREは極めて有能で、いったいどうやって育成しているのか？ということがずっと疑問でした。その答えがこの章に書かれています。P.412の表28-1 SREの教育の方法はこのたった一つの表が以下にGoogleが育成に力を入れているかが分かります。また、個人的にはこの章が一番、万人に通じる、人材育成のベストプラクティスなのではないかと思っています。
（新人SREに）厳しい試練を与えることで教えられるのは、実際に行わせていることだけに限られ、チームが担うほとんど全ての側面を根拠立てて教えることはできません。
それまでの会社や大学から飛び出して、仕事の役割を（従来のソフトウェアエンジニアやシステム管理者から）この漠然としたSREという役割に変えることが、自信を打ち砕くのに十分であることは珍しくありません。 P.415
育成にはある程度順序を持たせ、目の前の道筋が見えるようにすることが必要で、意識的に理論と実践をバランスを持って適切に組み合わせてバランスを取る必要があることが書かれています。カリキュラムの例としては以下が紹介されています。
また、優れたリバースエンジニアリングの仕組みや障害試験（ディザスタロールプレイング）、ポストモーテムの読み込みと共有など、育成の手法だけでなく、既存のメンバーにもメリットがあるメソッドについて詳細に書かれています。この章も非常に有益な情報の宝庫なので、何度も読み返したいと思っています。
29章 割り込みへの対処
働いていて、集中しようとし始めているとき、もしくは切れかかっているとき、アラートやメッセージが来ることで、気持ちが切れることはありませんか？この章では、人間は不完全なマシンで、割り込みをいかに整理してフロー状態を作り出すか、また、そのフロー状態がエンジニアリングにとってどれだけ有益かを紹介しています。
個人的に感銘を受けたのは、プライマリのオンコールエンジニアは、オンコールの作業だけに集中すべきという部分で、確かにそうすれば他のメンバーは割り込みに悩まされることも少なくなるな、と思いました。30章では、逆に過負荷に対する対応が紹介されています。ここでもポストモーテムとドキュメンテーションによる重要性が書かれています。
31章 SREにおけるコミュニケーションとコラボレーション
最高の設計と実装は、お互いを尊重する雰囲気の下でプロダクションとプロダクトに対する関心が1つになったときに生まれるもので、それこそがSREが約束するものです。 P.448
SREに取ってコミュニケーションは欠かせない要素です。では、そのコミュニケーションはどのように行うのか、例えば、ミーティングはどのように実施すべきか、について書かれています。ここもエンジニアだけではなく、万人にとって有益な情報かと思います。
第Ⅴ部 まとめ
第33章 他業界からの教訓
この章では、IT業界とは関係がない経歴をもつSREについて紹介されています。例えば軍人であったり、ライフセーバーであったり、通報システムの経験があったりと、様々な業界からの知見をGoogleが取り入れているのが良く分かります。業界によってはIT業界より遥かに厳しい品質管理を行っていたりそういった方からの知見で、より自社の品質が改善されることもあるだろうなと思いました。この辺りの柔軟性は、さすがだと思います。
まとめ
以上、大変長くなりましたが、気になった章などを紹介していきました。個人的にこの本は永久保存版で、折に触れて読み返してみようと思いました。今まで記載したどれか一つのキーワードだけでも引っ掛かったら、購入することをお勧めします（高いですが。。。）
最後までお読みいただき、ありがとうございました。
