『SRE サイトリライアビリティエンジニアリング』を読んだ

いや、夏やん。ってなってる。この勢いで気温が上がるのだけはマジ無理。マジ溶ける。

どんな本か

www.oreilly.co.jp

著者はGoogle社のSREチームの主要メンバー。

サイトリライアビリティエンジニアリング(SRE)とは、Googleで培われたシステム管理とサービス運用の方法論です。

従来のシス管やDevOpsといった概念とは異なる新たな方法論について、Googleの実サービスの例を挙げながら紹介されている。

日本語訳の本書が発売されたタイミングで話題になったが、SRE自体はかなり前から一般用語化しており、先進的なウェッブの会社では早々に取り入れ、SREという職種で採用募集されていたりする。以下をさらっとみて、もっと知りたいと思ったら本書に手を出せば良さそう。

原文は全文がWebで公開されている。英語できるマンはこれ読んでください。解散。

なぜ読んだか

10余年にも渡って取り組んできたSREという体制について、天下のGoogle様が出し惜しみなく赤裸々に語った本ということで、ミーハーだから買った。あわよくばお仕事に活かせることがあればいいなあというかんじ。

インターネッツで英語版を読んでも良かったが、ただでさえ分量が多く英語力が皆無なので、金の力で翻訳版を得た。会社の金で。

全体の感想

情報量がすごい。ページ数もさることながら、濃い。濃密。実質3万ページくらいあるのでゎ。

全34章と細分化されつつも、各章は独立して体系的にまとまっている。ので、章のタイトルを見て、気になるところを拾い読みするのがいいかもしれない。自分もハードウェア構成とかあまり関係なさそうなところは読み飛ばしたりした。

周囲の評判どおり学びが多く、例によって消化しきれていない。ただ読んだだけでは意味がないと思いつつも、単なる技術本とは違い個人が明日すぐに使える知識というわけではない。自分が携わるサービスに対してなにかできないか、SRE的な視点をもって現状を見てみるところからはじめていきたい。

「第9章 単純さ」が好き。なぜなら、シンプルさが好きだから。複雑なのが苦手だから。本章自体シンプルでポエミーで抽象的だが、SREの本質を的確に表現していると思う。重要なのは、本質以外は切り捨てる勇気。

「第12章 効果的なトラブルシューティング」もオススメ。トラブルシューティングは偶発的に起こる作業であるために、属人的、職人的になりがちで、その手順は明文化されていない事が多い。そんな中で、トラブルシューティングの一般的なフローを明記し、汎用的な思考パターンを提示されていて、いろんな場面で判断の材料になりそう。

「第15章 ポストモーテム文化:失敗からの学び」は某社社員にオススメ。捉え方の問題でもあるし、まだまだいくらでも改善の余地があるとポジティブに捉えられた。伸びしろですね。

「第23章 クリティカルな状態の管理:信頼性のための分散合意」は、主に分散合意アルゴリズムPaxosとその亜種について解説されている。自社のサービスで分散合意を直接意識することはないが、個人的に合意アルゴリズムには興味がある。おそらく、日本語でここまでまとまったPaxosの解説はない気がするが、理解できておらず、歯がゆい。自戒を込めてここに記録し、何らかの手段を持って理解し、本書を再読したい。

「第27章 大規模なプロダクトのローンチにおける信頼性」も某社社員にオススメ。というかたまたまいま自分の中でホットトピックだった。仕組みと構造化。やっていき。

「第33章 他の業界からの教訓」はおもしろいアプローチ。過去に他業界*1で働いていた現Google社員にインタビューし、SREの文化とプラクティスがどう適用されるのか、あるいはさらに学べないかを考察している。あらゆる業界において障害対策は本質的な課題であり、ディザスタテストやポストモーテムの文化、自動化、構造化といった考え方は、Google社あるいはITサービスに限定せず、あらゆる業界で有益そう。

各章の最後に「Google SREが推奨する参考文献」が紹介されている。ほぼすべてめっちゃ面白そうだったが、きりがないので涙をのんで追うのを諦めた。実践してみようと思う章があれば、そこの参考文献は目を通すと良いかも。

著者のひとりであるBen TreynorのインタビューがWebで公開されている。本書をひととおり読んだあと、あるいは読む前にさらっとみて意識を高めるといいかもしれない。

細かい感想

気になったところを引用しつつ、感想を書いておく。いま時点での自分が感じたことをオープンな場で記録しておくことに一定の価値がある気がする。知らんけど。

第Ⅰ部 イントロダクション

従来の開発プロセスが抱える問題と、それに対する仕組み、それらを包括するSREという概念について紹介されている。後半はGoogleのプロダクション環境について紹介されているが、いろいろ次元が違って参考になりそうもないのでいったんみなかったことにする。

「好きなものを好きなときに邪魔なしにローンチしたいんだ」対「いったん動いたシステムは一切変更したくないね」(p.4)

この本、というかSREという概念が解決したい課題を端的に示している。従来の組織では、開発チームと運用チームが分断されていて、前者は早くリリースすること、後者はシステムを安定稼働させることをミッションとしており、本質的に目的が対立関係にある。

SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。(p.5)

よくわからない。俺達は雰囲気でSREをやっている。

ソフトウェアエンジニアがソフトウェアを設計する際に一般に意識する拡張性·信頼性·耐障害性などを、運用チームという組織の設計にも適用した場合、ということなのかもしれない。例として、『スケーラビリティ』という概念を運用チームに適用する。サービスの成長やユーザの拡大に伴って、運用メンバー(リソース)が線形に増えていく組織は、スケーラビリティが低いといえる。サービスが成長しても最小限のリソースで運用できる仕組みを構築することが、SRE的なチームの『設計』なのかもしれない。知らんけど。

GoogleではすべてのSREに対して、チケット、オンコール、手作業といった「運用」業務の合計を50%以下にするよう、上限を設けました。(p.6)

SREが従来の運用チームと異なるのは、主業務があくまでもエンジニアリングであること。運用な前述のとおりリソースを追加することによってある意味では達成可能。それに対してSREは、運用業務を最適化するようなエンジニアリングを行う。放っておくとリソース投下に走る力学が働くので、ルールとして明文化しているのだと思う。

ここで問題になるのは、その50%をどうやって計測するのか、ということ。SREに限らず、一般にエンジニアの業務の計測は、コストと精度、その必要性のバランスの中で難しい課題で、実際にうまくいっている例をみたことがない。最も原始的には各自が、自分が何にどれだけ時間をつかったかを記録しておくことだが、個人の裁量に委ねられているが故に、精度もまちまちになってしまう。スクラムやカンバンといった開発プロセスのフレームワークはひとつの解決法になるのかもしれないが、ことSREに関しては、新規機能開発と違ってスコープの不明確性やイテレーションで単純に切れないプロジェクトが大半なため、性質上、そのようなフレームワークとは特に相性が悪いと思える。うまいことやってる方いれば教えてください。

100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っている(p.8)

Google様がおっしゃっておられあそばされますのでそのとおりです。99.999%を100%にするのは労力にわりに対価が乏しいから、他のことやれよ、ってことよ。では信頼性の目標をどう決めるのかというと、それはもうプロダクトごとに特性をみて定義していきましょう、でしかない。どれくらいであればユーザは満足するか。本書においてわりと重要なキーワードである『エラーバジェット』というものがあるが、これは次部ででてくる。

第Ⅱ部 原則

SREとして仕事を進める上で、原則となる考え方や指針を示している。

私たちはリクエスト成功率という観点から可用性を定義しています。(p.29)

可用性=成功したリクエスト数/総リクエスト数 、らしい。ドシンプルすぎて感動した。サービスの可用性は、ユーザ及びサービス運営側にどれだけの不利益を与えたかで定義されるが、計画外の停止時間やシステムの稼働時間など、パラメータが多すぎて難しい。それにしてもすごい。リクエストってそれぞれ価値はことなるはずで、例えば「サービスにログインできない」と「OGP画像が表示されない」を同一のリクエストとして扱っていいのか、など。それをあえてどシンプルに振り切っている。本当にやりたいことに対して最短·最適な効果が出るように設計されている。

エラーバジェットが提供するのは、1つの四半期内でサービスの信頼性がどの程度損なわれても許容できるかを示す、明確で客観的なメトリクスです。(p.37)

第Ⅰ部にも書いてあったとおり、従来の開発/運用チームの課題は、それぞれの目標が対立していることにあった。その間を取り持つ仕組みとして、『エラーバジェット』が提案されている。その名のとおり、四半期内で『損失可能な信頼性』という『予算』を設定する。開発チームは、四半期のエラーをその予算内に収めるようにリリースを行う。これによって、開発とSREとで共通の指標を持つことができる。

これも前述と同じで、指標の単純化にかなり振り切った仕組みになっている。私が関わっている某サービスではNewRelicを使っているが、その中でApdexという指標がある。エラーバジェットとは異なるが、主にパフォーマンスという観点でサービスの可用性を担保するシンプルな指標となっている。基本的には「Apdexがある数値(デフォルトで0.95)を割らないように維持する」だが、とはいえ…みたいなケース(画面)もある。そういった例外的な場合にどう対処するのか、具体例をもっと知りたいと思った。ので、教えてください。

自分たちが計測できることではなく、ユーザが気にすることは何かを考え(あるいは知り)ましょう。(p.46)

サービスの振る舞いに関する目標を設定するとき、ついつい計測可能なものをベースに考えてしまいがち。計測が困難だったり、近似が必要だったりすることも多いが、意味のない指標を追い求めるよりははるかに有益。集計が必要なできるだけシンプルにする。設定した目標を定期的に見直し、修正を加えていく。また、過剰達成を避ける(インセンティブを与えない)。

トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例すると行った傾向を持つものです。(p.51)

toilは、直訳すると「労苦」。本書におけるtoilとは上記の定義。単に「めんどくさい作業」ではなく、自動化できるのにできてない、長期的に価値がない作業のこと。自動化できないということはすなわち『人間がやるべき仕事』ということであり、排除すべき作業とはいえない。GoogleのSREにとって、各エンジニアの作業時間にしめるトイルの割合を50%以下に抑える、という目標があるらしい。逆の見方をすると、Google様クラスのエンジニアでも、放っておけばトイルが50%を超えるということであり、こわい*2。具体的には、割り込み対応、緊急対応、リリース対応の順に多いらしく、これは普段のお仕事の体感とも合致する。自分はわりかしトイルは少ないほうだと思うが、メンバーの中には

トイルの悪い点について、「キャリアの停滞」「モラルの低下」が挙げられていて、意外な角度だと思った。「つまらない仕事からキャリアを生み出すことはできません」エモい。日々の運用作業でついつい仕事をしている気になってしまうが、思考停止にも陥りがち。人間は易きに流れる。運用という性質上、他の業務より優先度が低く設定されて長期的にみると莫大なコストになってしまう。SREという組織がそれを明に目標として持つことで、改善していこうという話。

しっかりと考慮すべきなのは、すべてのページを独立したイベントと捉えるのではなく、ページの全体的なレベルが健全で持続可能なチームと長期的な展望をもたらし、ひいては健全で適切な可用性を持つシステムへとつながることになっているかということです。(p.69)

ページというのはユーザに対する通知=アラートと読みかえてよさそう。ある特定の機能の問題発生時にアラートメールを開発者に飛ばす場合、そのメール単体ではなく、他のアラートメールや機能に対する優先順位などの位置づけを踏まえ、サービス全体として適切なアラートを設計する必要がある。また、長期的に見ればそのアラートメールの根本原因をつぶすことが最適な場合もある。重要なのは、アラートも機能の一部としてきちんと『設計』する、という考え方。

私たちが面倒を見ているプロダクトやサービスは地球全体に及ぶ規模を持っており、他の組織では一般的なやり方でマシンやサービスの面倒を見るような時間が私たちにはないのです。(p.74)

Google様~~~~~~~!!!です。というのは置いておいて、自動化の話。Google規模になると、運営するサービスにおいて自動化による一貫性、素早さ、信頼性のメリットは非常に大きく、もはや自動化 or 手運用の議論が不要なほど。一方で、我々のような一般人の運営するサービスはそのレベルにはなく、自動化のコストを踏まえて本当に適切化を判断する必要がある。重要なのは、サービスも日々成長していく中で、ある時点で自動化が不要となっても、数日後には自動化したほうがいいという判断にもなりうるということ。都度適切かつ客観的な判断をいれること、その計画をたてておくべき。

Googleにおいて、リリースエンジニアリングは明確に一つの職能と位置づけられています。(p.91)

自分や自分の職場にはあまりない観点だと思った。リリース作業はある程度は自動化されているものの、手作業の部分は残っているし、ヒューマンエラーやいわゆるトイルも潜んでいる。ちょうどひとつ前に書いたとおり、最近のリリース頻度をみるに、がんばって自動化するに足る箇所なのかも、と思った。

私がこれまで行ったコーディングで最も満足感を抱いたのは、その時点でもう意味がなくなっていた数千行のコードを削除した時です。(p.103)

わかりすぎる。わかりすぎて泣く。稼働するサービスに追加されるコードは、その一行一行が潜在的に負債といってもいい。何かの機能を実現するためのコードは小規模かつ単純であればあるほど価値がある。拡張性や耐障害性とのトレードオフともなりうるため、どちらかに傾倒しすぎないように、設計時には単純さの観点もようよう含めるべき。

APIが小さくて単純であるということは、問題が十分に理解されているということの証明である。(p.103)

完全にわかりみ。
外部に向けたWeb APIに限定したものではもちろんなく、クラス設計におけるインターフェイスでも同様。インターフェイスに対してプログラミングをする、というオブジェクト指向の設計原則でもいえることだが、インターフェイスをみて何ができるか、どの場面で使うかがイメージできれば、プログラミングの12割は終わったようなものである。頭ではわかっていても、実際やってみるとなかなかうまくいかない。がんばりたい。

第Ⅲ部 実践

だいぶ具体的になってきたものの、実サービス・組織に直接適用できそうな考え方が詰まっている。

サービスの健全性は、Abraham Maslowが人間の欲求を分類した方法と同様に、システムがサービスとして一通り機能するための最も基本的な必要条件から、自己実現を可能とし、問題に樹頭的に対応するのではなく、サービスの方向性を能動的にコントロールするような、より高いレベルの機能に至るまでの段階に分類できます。(p.107)

かの有名なマズローの欲求段階説と同様に、サービスの健全性も段階的に高次になっていく、というおもしろい発想。一番下の層が『モニタリング』になっているのが響いた。まずはサービスの状態、現状を把握してはじめて、どうしたいかを考え始めることができる。また、最上位は『プロダクト』となっている。信頼性を満足なレベルまで高めて初めて、プロダクトは完成する。耳が痛い。

Googleはまた、DiRT(Disaster Recovery Training)と呼ばれる全社規模のディザスタリカバリのトレーニングを年に一度行っています。(p.138)

緊急対応が少ないシステムはいいことだが、運用不可が低すぎると、いざ問題が発生したときに対応できない。エンジニアは厨二病発症者が大半なので、シャカイに対して斜に構えがちで、避難訓練とかをないがしろにするイメージがある*3。そういうのはやめたほうがいい。人もサービスも死んだら取り返しがつかない。避難訓練と同じで、いかに対象者に価値を感じてもらう避難訓練を設計するかはかなり難しい課題だと思う。ここも各社の事例をもうちょっと知りたいところ。

緊急対応の体制についても、みんなどうしてるんだろう。少なくとも本書では、開発チームとSREチームが独立しており、SREチーム内で緊急対応の当番制になっているように読める。別のやり方として、緊急対応を開発チームで受け持つという形もありうる。問題が発生したときに、その機能に詳しい人が担当したほうが、解決までの速度は速いはず。もちろんコストや体制との兼ね合いでもあるので、その組織にとってベストな設計にすべきではある。

否定的な結果が出た実験は決定的なものです。そういった実験は、プロダクションや設計の領域、あるいは既存のシステムのパフォーマンスの限界について、何らかの確実なことを示します。(p.150)

少なくとも、実験したことは、本番でも同条件下で確実に起きうる。否定的な結果を出し尽くすことは、サービスの信頼性を高めるためにとても有益。また、その結果を公開することで、周囲に価値をもたらす。人間はついつい見えを張って、失敗を見せたくなかったり、よく見せようとしてしまう。本当にチームのことを考えるなら公開するべき。

新たなタイプの障害が発生するたびに、対応者たちはその障害の様子を書き記しました。(p.165)

それなりの規模でサービスを運用している組織なら、障害対応ののちに、次に同様の障害が起きないようにどうするべきか、起きたときにどうするべきかを振り返るはず。重要なのは、振り返りをして満足するのではなく、その実効性を担保すること。ヒューマンエラーなどの場合には「気をつける」などのパッション的な結論に陥りがちだが、そこで深掘りし仕組みに落とし込むこと、それを組織に周知·徹底することまでやりきらなければ意味がない。「その対応を書き記す」というのは、何が起きたかをメンバー間で合意し、対応に応らなかったメンバーにも同レベルの理解を確認できるという意味で、その第一歩といえる。記録を取るというのはどうしても優先度が下がりがちだが、大切にしていきたい。

Googleのインシデント管理のシステムは、明快でスケーラブルであることで知られるIncident Command Systemに基づいています。(p.169)

ICSは、災害や事件の現場における標準化されたマネジメントシステムらしい。知らなかった。読んでみたい。しんどい。

うまく設計されたインシデント管理のプロセスは、「責任の再帰的な分離」「明確な司令所」「ライブインシデント状況ドキュメント」「はっきりとした引き継ぎ」という特徴を持つとのこと。まとめると、「人の判断や責任において、あいまいな境界を作らない」ことに尽きる。だれがいつなにをするべきかを明確に規定し、それを共有できていること、お互いに信頼することが必要。システム設計と同じく組織の設計においても、高凝集、疎結合を意識すべき。

レスポンスに対応している間の自分の感情の状態に注意を払いましょう。(p.173)

インシデント対応の大前提として、冷静·客観的に対応を進めることが必須。感情的な判断は被害を拡大させる。インシデント対応に限らず、自分は自身の感情を把握·制御することが苦手なように感じている。感情を把握·制御するのもスキルのひとつだと思うので、別途トレーニングしていきたい。

ポストモーテム文化を育むための継続的な投資によって、Googleのサービス障害は減り、ユーザ体験を改善できています。(p.181)

ポストモーテムとは、インシデント発生時に、そのインパクトと対応、原因、再発防止策を記録するもの。障害報告書とは異なり、社内のエンジニア間で、同様のインシデントを発生させないための学びを得ることを目的としている。以下3点が重要だと感じた。

  • 非難しない: 人間を変えることはできないが、仕組みを変えることはできる
  • レビューする: 下書きを広く公開し、客観的情報の記述や対応内容をレビューし、積極的に共有する(参照できるようにしておく)
  • 称賛する: ポストモーテムを残すことはトイルではなく組織改善に有益なことなので、適切な報酬を得るべき

この点は某社でも大いに改善の余地がありそう。ちなみにGoogleでは大量に蓄積されてきたポストモーテムを機械学習に食わせて弱点の予測などを行っているらしい。さすが。

テスト対象のコンポーネントには、障害が起こるまで負荷をかけましょう。(p.294)

自分はカスケード障害に備えた視点でのテストがあまりできていないと感じた。

カスケード障害((ポジティブフィードバックの結果として、時間と共に拡大していく障害(p.273)))においては、通常の過負荷による障害と異なり、フィードバックという複雑系の中で、(対象のコンポーネントに限らず)システム全体として何が起こるか予測困難である、という前提に立ったテストが必要となる。

そのため、単に想定される負荷をかけて耐えられることを確認するだけでは不十分。障害が起こるまで負荷をかけることにより、実際に何が起こるのかや、その状態を避けるために割くべきリソースとのトレードオフが議論できる。さらに困難なのは、本番環境になるべく近い環境でテストする必要がある。場合によってはプロダクションテストも検討すべき。

データの完全性を考えるにあたって重要なのはクラウド上のサービスがユーザーから利用可能であり続けることなのです。(p.357)

例えデータは無事でも、ユーザからアクセス不可能な状態が長時間続けば、それはデータがなくなったのと同じ。つまるところ、データの完全性は手段であり、目標とするべきはデータの完全性である、ってはなし。

データの損失は、アプリケーションのバグやヒューマンエラー、ハードウェア障害など、様々な原因がある。あらゆるケースを想定して、なるべく早くリカバリ可能なように様々な手をつくしておく。「多層防御」って言葉かっこいい。そのためには、サービスに求められる安定性の要件(SLO)を定義し、それが満たすことを検証する、という過程が必要。明確かつ合理的な目標値がないと、見えない基準に向かってあれこれ手を出し、不安で夜も眠れなくなってしまう。とにかくテスト。

どんなものもいつかはおかしくなるということを認識できれば、それはあらゆる本物の緊急事態に対して備えるための大きな一歩になります。(p.388)

まさか自分が、まさかうちのサービスに限って、と楽観的になりがちであり、障害の予防は優先度が下がりがち。バックアップとか、だれにも感謝されない。障害が起きたときの甚大な被害は、経験していないとなかなか想像しづらいのが現実かもしれない。システムの安定性要件(SLO)が定義されており、そのテストを含めて担当者を適切を評価すべきだし、経験豊富(なはず)の偉い人がそこを整備し、説いていくしかない。セキュリティとかも同じ。

ローンチが失敗するさまざまな形を予測し、ローンチに関わるさまざまなエンジニアリンググループ間の調整を行った結果、SRE内には特別なチームができあがりました。それがローンチ調整エンジニア(Launch Coorination Engineers = LCE)です。(p.390)

サービスのローンチが頻繁であればあるほど、そのプロセス設計には価値がある。LCEはローンチのプロセスの整備や教育をし、実際のリリース時には旗振り役になり、経験と客観的視点を持ってローンチ作業とその後のサービス信頼性を担保する。

Googleは2004年にLCEを設立している。最先端すぎ。そこから10数年の経験がLCEに蓄積されており、そこから見出した、良いローンチプロセスの特徴が興味深い。「軽量」「頑健」「綿密」「スケーラブル」「適応的」。これらを満たすために、Googleでは、「基本を抑えたローンチプロセスを設計しておき、個別の事情に適宜カスタマイズする」という方策をとっている。がっちがちのルールを設計して運用に乗らなければ意味がないが、クリティカルな障害だけは防ぎたい、という本質的な課題に取り組むことになる。おもしろそう。

本章後半では、LCEが解決しなかった問題も紹介しており、興味深い。基本的に変化に対して弱いっぽい。

第Ⅳ部 管理

初期の学習経験:混沌ではなく構造を提供する(p.414)

これですね。SREに限らず。崖から突き落として這い上がらせるシステムは、教育ではなく選別。対象者はその意義を理解できないまま盲目的に作業するだけになり、何も得られない。特にSREの障害対応は、本番を通じて学習する、という機会がなかなかなく、また実際に起きたときは教育している場合ではなかったりするので、単なるエンジニアよりもさらに教育が難しい。

新人をオンコール担当に導くまでの教育プラクティスが紹介されているが、中でも「ポストモーテムの読み込みと共有」は有益だと思った。障害はなかなか一般論では説明できず個別のサービスに条件が絞られる。そこで蓄積されてきた障害とその対応がまとまっている文書は、唯一の教科書となりうる。そのためにも、そのためにもポストモーテムの整備は価値がある。

また、「ディザスタロールプレイング」というミーティングが紹介されていて興味深かった。過去に起きた障害のシナリオをなぞって、どういう行動をするか、そこからどういう情報を得たかなどを会話で進めていく。Googleでは伝統的にこの演習をやっており、「不運の輪」(Wheel of Misfotune)と呼ばれているらしい。いちいちかっこいい。

生産性が継続的に失われるのを避けるには、作業のスタイルの間で時間を二極化しましょう。(p.434)

主にSREが割り込み作業にどう対処すべきかについても言及されている。二極化するというのは、自分のプロジェクト「だけ」をする時間なのか、わりこみ作業「だけ」をやるのかを自分でわかっているようにせよ、ということ。割り込みをシャットアウトし、集中的に取り組む時間も設ける。メリハリきっちりしましょうってはなし。まあこのへんは本質的かつ永遠の課題。それぞれの環境で試行錯誤しましょう。

第Ⅴ章 まとめ

私がGoogleに加わった時点では数百人だったエンジニアの集団だったSREは、今では1,000人を超えて10箇所以上のサイトに広がり、(p.493)

え、でか。もとからでかいんかい。思ってたよりめっちゃでかい。ここまで読んでて想像していたよりでかい。とはいえ、SREの目的のひとつは信頼性観点でのスケーリングであり、規模にかかわらずあらゆるサービスに必要な考え方ではある。信頼性に価値がある文化を根付かせる存在。

GoogleのインフラストラクチャやSREチームが経験してきた変化や成長にもかかわらず、その発想の誕生から10年が経過してもSREという職務は柔軟で古びることがなく、その目標も当初のままです。(p.494)

裏を返すと、Google様ともあろう存在が10年かけても解決しない課題ともいえる。ソフトウェアに限らず、サービスを提供する上で、信頼性のエンジニアリングは本質的な課題ってこと。たぶん。なので、がんばっていきましょう。

*1:航空機やライフセーバー、海軍など

*2:本書記載の時点では33%とのこと

*3:個人の主観です