はじめに
エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。
SREの探求『Becoming SRE』の内容紹介
私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(otterbook)氏による「Becoming SRE」が 2024年2月にリリースされました。
本書では、SREの基本的な考え方や文化について解説し、SREになるために必要なスキルや知識、実際の仕事内容を紹介しています。また、組織にSREを導入するために必要な要件やうまく定着させるためのポイント、SREと他部門との協働について言及し、組織の中でSREを成長・成熟させていくための方法論を提示しています。
- はじめに
- 『Becoming SRE』の構成
- Part I: Introduction to SRE
- II. Becoming SRE for the Individual
- Part III. Becoming SRE for the Organization
- Chapter 11. Organizational Factors for Success
- Chapter 12. How SRE Can Fail
- Chapter 13. SRE from a Business Perspective
- Chapter 14. The Dickerson Hierarchy of Reliability (A Good Place to Start)
- Chapter 15. Fitting SRE into Your Organization
- Chapter 16. SRE Organizational Evolutionary Stages
- Chapter 17. Growing SRE in Your Org
- Chapter 18. Conclusion
- おわりに
これらの内容は、SREを目指す個人だけでなく、組織としてSREを取り入れようとする企業にとっても、大変参考になるのではないでしょうか。「なれる!SE」に感化されて書いた拙い文章とは異なり、「Becoming SRE」は、SREという職種について、より深く理解するための良書になると期待しています。2024年2月に出版されたのですが、SREに関心のある方は、ぜひ一読してみることをおすすめします。翻訳本が出版されるのが今からとても楽しみです。
『Becoming SRE』の構成
『Becoming SRE』は、Site Reliability Engineering (SRE) の入門書であり、個人と組織の両方を対象に、SREをどのように始めるべきかを解説しています。著者は、SREに関する豊富な知識と経験を持ち、多くの人々との対話を通じて得た洞察を本書に凝縮されています。本書は大きく3つのパートに分かれており、それぞれが独立した内容となっているが、全体を通して読むことで、SREの本質的な理解が深まる構成になっています。
Part I: Introduction to SRE
第1部では、SREを始めるにあたって必要な基礎知識が提供されている。特に、第2章ではSREのマインドセットについて詳しく解説されており、SREの根底にある考え方や価値観を理解することができる。この章は、SREに関する議論を進める上で欠かせない土台となるため、第2部と第3部を読む前に必ず読むべき内容となっている。また、SREに関連する重要な概念や用語についても丁寧に説明されているため、初学者にとっても分かりやすい内容になっている。
Part II: Becoming SRE for the Individual
第2部では、個人としてSREを始めるための具体的な方法論が述べられている。SREに必要なスキルセットや知識、学習方法などが詳細に紹介されており、SREを目指す人にとって実践的な指南書となっている。また、SREの日常業務やキャリアパスについても言及されているため、SREという職種をより深く理解することができる。著者自身の経験や、他のSREエンジニアとの対話から得た知見も随所に盛り込まれており、生きたアドバイスが得られる内容になっている。
Part III: Becoming SRE for the Organization
第3部では、組織としてSREを導入・発展させるための指針が提示されている。SREの導入に必要な要件や、組織文化との適合性、他部門との協働など、SREを組織に定着させるためのポイントが詳しく解説されている。また、SREチームの構築や育成、SREプラクティスの継続的な改善についても言及されており、組織としてSREを成功させるためのヒントが数多く提供されている。さらに、実際にSREを導入した企業の事例も紹介されているため、具体的なイメージを持ちながら読み進めることができる。
第2部と第3部は、読者の関心に応じてどちらを先に読んでも構わないが、個人と組織は密接に関連しているため、両方を読むことで理解がより深まるだろう。また、最後に収録されているベテランSREエンジニアからの助言は、SREの本質を捉えた良い内容になっており、SREを志す人にとって大きな励みになるはずだ。
本書の特徴の一つは、SREに関する他の優れた書籍や情報源を数多く参照していることだ。著者は、自身の知見だけでなく、SREコミュニティの集合知を積極的に取り入れることで、読者により広い視野を提供している。また、SREの実装や解釈は組織によって異なり得ることを認めた上で、SREについての対話を促していることも重要なポイントだ。著者は "SRE should be a conversation, not a doctrine."（SREは教義ではなく、会話であるべきだ）というメッセージを発しており、SREをめぐる活発な議論の重要性を呼びかけている。
『Becoming SRE』は、SREの入門書でありながら、奥深い内容を含んだ一冊だ。初学者から経験者まで、幅広い読者に対して、SREについての理解を深め、実践するための指針を提供してくれる。SREに関心を持つ全ての人にとって、必読の書と言えるだろう。
Part I: Introduction to SRE
Chapter 1. First Things First
SREの定義と3つの重要な単語
本章は、SREについての理解が深めるための章。著者が提示したSREの定義、「Site reliability engineering is an engineering discipline devoted to helping organizations sustainably achieve the appropriate level of reliability in their systems, services, and products.」は、SREの本質をよく捉えていると感じた。
この定義の中で特に重要な3つの単語として、著者が挙げたのは "Reliability(信頼性)", "Appropriate(適性)", "sustainable(持続可能性)" です。システムの信頼性は、組織の収益、評判、従業員の健康などに直結する重要な要素であり、SREの中核をなすものです。また、100%の信頼性を目指すのではなく、SLI/SLOを用いて適切な信頼性のレベルを見極めることが肝要だと説く点も納得できる。そして、信頼性の追求は、人的リソースの持続可能性とのバランスを考慮しなければならない。過度な信頼性の追求が、エンジニアの疲弊を招いては本末転倒です。
SREとは何か
2014年のSREconで行った講演では、SREの要諦が端的に表現されており、現在でも色褪せない洞察に満ちている。Ben Treynor Sloss氏によれば、SREとは次のような特徴を持つ組織だという。
コーダーのみを雇用し、サービスに対するSLAを設定する。そして、そのSLAに対する性能を測定・報告し、エラー予算を活用してゲートローンチを行う。SREチームとDEVチームの間で人材を共有し、SREチームの運用負荷は50%に抑えつつ、運用作業の5%をDEVチームと共有する。オンコールチームは少なくとも8人、できれば6×2の体制を取り、1シフトあたりのイベント数は最大2件までとする。
イベントが発生した際には、必ずポストモーテムを行う。ポストモーテムでは非難を避け、プロセスと技術に焦点を当てた議論を行うことが重要です。
つまり、SREとは、高い信頼性を持つシステムを構築・運用するための体系的なアプローチであり、エンジニアリングと運用のベストプラクティスを組み合わせたものと言えるとおもいます。
SREとDevOpsの関係性
SREとDevOpsの関係性については、本書で提示された3つの見方がそれぞれ示唆に富んでいる。
1つ目の「SREはDevOpsの一実装である」という見方は、SREとDevOpsが共有する理念や手法に着目したものです。両者はともに、開発と運用の協調を重視し、自動化やツールの活用を推進する点で共通している。ただし、著者が指摘するように、DevOpsが特定の方法論やツールを規定しないのに対し、SREはより規範的（prescriptive）なアプローチを取る傾向があります。
2つ目の「SREの信頼性に対するDevOpsのデリバリー」という対比は、両者の目的の違いを浮き彫りにしている。SREが systems の信頼性（reliability）の確保を最重要視するのに対し、DevOpsはソフトウェアのデリバリー（delivery）に主眼を置く。もちろん、信頼性の高いシステムを迅速にデリバリーすることは、両者に共通する目標ではあるが、力点の置き方が異なります。
3つ目の「SREとDevOpsでは、関心の方向性が異なる」この言葉はSREとDevOpsの関心の方向性の違いを鮮やかに描き出している。SREは本番環境から出発し、「本番環境の信頼性を確保するために、開発者は何をすべきか」という観点から、開発の方向へと関心を向ける。一方、DevOpsは開発者の環境から出発し、「開発者が書いたコードを、いかにして本番環境に迅速かつ安全にデリバリーするか」という観点から、本番環境の方向へと関心を向ける。
この違いは、両者が重視するツールや手法にも反映される。例えば、SREはモニタリングやインシデント管理、カオスエンジニアリングなどの運用面のツールを重視するのに対し、DevOpsはCIツールやコンテナ技術などのデリバリーを加速するツールを重視する傾向があります。
ただし、著者が強調するように、SREとDevOpsは二者択一ではなく、むしろ補完的な関係にあると捉えるべきだろう。組織の規模やビジネス特性、技術的成熟度などに応じて、SREとDevOpsの手法を適切に組み合わせることが肝要です。このへんは可視化されているDevOps Topologiesを参考にしても分かりやすいかもしれないです。
例えば、スタートアップのような小規模な組織では、DevOpsの手法を全面的に採用し、エンジニア全員がデリバリーと運用の両方に携わるのが適切かもしれない。一方、大規模なシステムを運用する組織では、SREの手法を導入し、信頼性の確保に特化したチームを設置することが有効だろう。
いずれにせよ、SREとDevOpsのどちらか一方を選ぶのではなく、両者の長所を活かし、組織の文脈に合わせて柔軟に適用していくことが重要です。そのためには、両者の理念や手法を深く理解し、自組織の目的や制約に照らし合わせて、最適な方法論を構築する必要があります。
本書の第1章で提示されたSREとDevOpsの関係性に関する考察は、そのための出発点として大変良いものだった。今後は、本書で得た知見を土台に、SREとDevOpsの実践方法を探求するときに活用していきたい。。
つまり、SREとは、高い信頼性を持つシステムを構築・運用するための体系的なアプローチであり、エンジニアリングと運用のベストプラクティスを組み合わせたものと言えるとおもいます。
Chapter 2. SRE Mindset
SREにとって大切な問いかけ
本章は、著者自身の経験と、他のSREとの対話から得られた洞察を基に、SREのマインドセットを形作る大切な要素について分かりやすく説明されていました。最初に出てくる "システムはどのように動作しているのか？どのように失敗するのか？" という問いかけは、SREの思考法の根っこにあるものだと感じました。システムの信頼性を追求するには、その動作原理と障害パターンを徹底的に理解する必要があります。著者が強調しているように、SREにとって大切なのは "どのように動作すべきか" ではなく "実際の本番環境ではどのように動作しているのか" なんですよね。
システムを理解するためには、ミクロなレベルからマクロなレベルまで、あらゆる粒度でシステムを観察して、分析しなければいけません。著者が例に挙げているデータベース接続の話は、一見些細なことのように思えるかもしれませんが、**SREはそこから派生するいろんな問題を想定して、システム全体への影響を考えなくちゃいけないんです。システムを理解する例として最近公開された ブラウザからDBに行き着くまでをただまとめる のような取り組みを自サービスで行うと効果的と考えています。システムの動作を自身で調べながら書き出していくという点でSREの探求20章でアクティブラーニングで紹介された事例に近いものがあります。
著者が "Understanding a System as a System" というコラムで紹介しているシナリオは、SREにとってのシステム思考の重要性をよく表していました。データセンターで電源ケーブルが切れるという一つの出来事が、いくつもの要因が絡み合って、最終的にお客さんの購買機会の損失につながっていく流れが描かれています。このシナリオは、システム障害の責任を特定の個人に押し付けるのではなく、システム全体の問題として捉えることの大切さを教えてくれています。
SREのマインドセットで大事なのは、お客さんの立場に立つことだと著者は指摘しています。システムの信頼性は、コンポーネントの視点ではなく、お客さんの視点から測定されるべきなんです。100台のWebサーバーのうち14台が故障した場合のシナリオは、このことをはっきりと示していました。SREは常に、システムがお客さんからどう見えているのかを意識して、お客さんの期待に応えることを目指しているんですよね。
SREのマインドセットの特徴の一つは、フィードバックループの重要性を理解していることだと著者は述べています。信頼性の向上は、継続的なフィードバックループを通じて達成されるんです。SREの役割は、システムのあらゆる場所でフィードバックループを見つけ出して、育てていくことにあります。
それから、SREは他者とのコラボレーションを大切にするという点も印象に残りました。信頼性の追求は、絶対に一人では成し遂げられません。SREは、開発者、運用チーム、マネージャー、そしてお客さんを含むいろんな関係者と協力しながら、システムの信頼性を高めていくんです。特に、お客さんとのコラボレーションについて著者が提示した "お客さんと一緒に信頼性を高めるためにどうやって協力できるだろう？" という問いは、SREのあり方を考える上でとても示唆に富んでいると思いました。
SREの反脆弱性を高める営み
SREの失敗(failure)や障害(error)に対する姿勢も興味深かったです。SREは、失敗をネガティブなものとしてではなく、学びのチャンスとして捉えるんです。障害は、システムについての理解を深めるための貴重な情報源なんですよね。対話から得た "障害をシグナルとして扱う" という著者の学びは、SREのマインドセットをズバリ表していると感じました。この考え方は、『反脆弱性――不確実な世界を生き延びる唯一の考え方』で提唱されている "反脆弱性" の概念とも通じるものがあります。著者は、不確実性や変動性、ストレスに晒されることで、かえって強くなる性質を "反脆弱性" と呼んでいます。SREが障害を学びの機会と捉えることは、まさにシステムの反脆弱性を高める営みだと言えるでしょう。失敗から学び、その経験を糧にしてシステムを進化させていく。そういうレジリエントなマインドセットこそが、SREに求められているのかもしれません。
さらに、SREのマインドセットは、長期的な視点を持っているという点でも特徴的です。スケーラビリティ、運用負荷の軽減、より多くの人々への信頼性の提供など、SREは常に将来を見据えて行動しているんです。システムが時代遅れになる前に、より良い代替案を用意することも、SREの重要な役割の一つだと著者は指摘しています。
第2章で紹介されたSREのマインドセットは、技術的な側面だけでなく、倫理的・文化的な側面も含んだ、多面的なものだと感じました。著者が "neurodiversity" について触れていたように、SREという職種は、多様なバックグラウンドを持つ人々の力を結集することで、より高い信頼性を達成できるのだと信じています。
SREのマインドセットを実践していくことの難しさ
SREのマインドセットという、一見つかみどころのない概念を、具体的な事例と洞察に基づいて解き明かしてくれる、良い内容でした。システムの信頼性を追求するためには、技術的なスキルと知識に加えて、SRE特有の思考法と姿勢が欠かせないことを、改めて認識させられました。特に、システムの動作を理解し、障害を検知・分析するためには、オブザーバビリティが重要な役割を果たします。オブザーバビリティの概念と実践について、SREの視点から解説した良書です。この本は、オブザーバビリティを単なるモニタリングの延長ではなく、システムの動作を理解するための能動的なアプローチとして捉えています。時系列データ、ログ、トレースを駆使して、システムの振る舞いを可視化し、問題の根本原因を究明していく。そのようなオブザーバビリティ・エンジニアリングの手法は、SREのマインドセットを体現するものだと言えるでしょう。
私自身、ソフトウェアエンジニアやSREとしての経験を積む中で、システム思考の大切さを痛感してきました。複雑化する現代のシステムにおいては、個々の要素を深く理解するだけでなく、それらが相互に作用して生み出す振る舞いを俯瞰的に捉える力が求められるんです。
システム思考とは、システムを構成する要素間の相互作用や、システムとその環境との間の相互作用に着目し、システム全体の振る舞いを理解しようとするアプローチです。部分の最適化ではなく、全体の最適化を目指すのがシステム思考の特徴です。複雑なシステムでは、ある要素の変化が予想外の連鎖反応を引き起こし、システム全体に影響を及ぼすことがあります。そのような非線形な因果関係を見抜くには、システムを俯瞰する視点が欠かせません。さらに、システムの目的や境界条件を明確にし、外部環境の変化に適応していく力も求められます。SREにとって、システム思考は障害対応や信頼性の向上に直結するスキルだと言えるでしょう。障害が発生した際、表面的な症状だけでなく、根本原因を追究するためには、システム全体の挙動を理解する必要があります。
また、信頼性を継続的に改善していくには、ボトルネックを特定し、フィードバックループを回していくことが重要です。それに加えて、お客さんの視点に立って、システムの価値を最大化するという姿勢も、SREにとって欠かせないものだと感じています。システムの究極的な目的は、お客さんに価値を届けることです。お客さんの要求や期待を理解し、システムの機能や性能、信頼性を進化させていく。そのようなお客さん志向のマインドセットは、システム思考と表裏一体をなすものだと言えます。
第2章で紹介されていた "no haunted graveyards" というSREの格言は、私の心に強く残りました。過去の負の遺産から目を背けるのではなく、それを掘り起こして、改善していく。それがSREの使命なんだと。障害や失敗を恐れるのではなく、それを糧にしてシステムを進化させていく。そういう姿勢こそが、SREのマインドセットの真髄なのかもしれません。
もちろん、SREのマインドセットを身につけて、実践していくのは簡単なことじゃありません。技術的な学習はもちろん、経験を積み重ねて、他者との対話を通じて考えを深めていくことが欠かせません。
Chapter 3. SRE Culture
SREの文化を育むことの重要性
本章は、SREという職種に特有の文化について理解が深まりました。著者は、SREの文化を育むことの重要性を強調しつつ、その具体的な方法論について、自身の経験と洞察に基づいて解説しています。本章を読んでいてSREには最初からスタッフエンジニア的な立ち振舞いが必要だと強く思いました。
SREの文化を育むことが重要な理由は二つあると著者は指摘しています。一つ目は、SREがその能力を最大限に発揮するためには、SREに適した環境と条件が不可欠だからです。新しい熱帯魚を飼育する際に、水温や水質、餌などに気を配るのと同じように、SREを雇用する組織は、SREが力を発揮できる文化を意識的に作り上げていく必要があります。著者は、SREの文化を育むことを "keep SREs happy" と表現していますが、これは単にSREを満足させるというだけでなく、組織にとっても重要な意味を持つのです。
二つ目の理由は、SREの文化が組織全体の変革の原動力になり得るからです。著者は、SREの文化を "Culture as a Vehicle or a Lever" と表現し、SREの文化が組織や個人を望ましい方向へと導く「乗り物」あるいは「てこ」になると述べています。例えば、SREが重視する "it isn't done until it is documented" という考え方は、ドキュメンテーションの充実を組織全体に浸透させる力になります。SREの文化は、reliability（信頼性）という目に見えにくい価値を、組織の隅々にまで行き渡らせるための強力な手段なのです。
では、SREの文化を意図的に育むにはどうすればよいのでしょうか。著者は、第2章で解説したSREのマインドセットを出発点にすることを提案しています。SREのマインドセットを形作る要素を一つ一つ取り上げ、それを支える条件や前提条件を考えていく。そのようなボトムアップのアプローチこそが、SREの文化を育む第一歩になると著者は説いています。
また、著者は、Carl Saganの "If you wish to make an apple pie from scratch, you must first invent the universe.:アップルパイをゼロから作りたい場合は、まず宇宙を発明する必要があります。" という言葉を引用し、文化を構築するためには、それを構成する要素を細分化し、それらを組み合わせるプロセスに着目することが重要だと指摘しています。例えば、"信頼できる開発環境を提供するために何が必要か" という問いを立てると、そこから自己サービス化、ドキュメンテーション、拡張性、オブザーバビリティなど、SREの文化を特徴づける様々な要素が浮かび上がってきます。これらの要素を一つ一つ紐解いていくことで、SREの文化の全体像が見えてくるというのです。
ただし、著者も認めるように、"What do I want SRE to be here?" という問いに答えを出すのは容易ではありません。SREに何を期待し、どんな役割を担ってもらいたいのか。組織によって、その答えは千差万別だからです。しかし、その困難な問いに向き合うことなくして、SREの文化を意図的に育むことはできません。著者は、その問いへの答えを模索するためのヒントとして、インシデント対応に注目することを提案しています。
SREの文化を育むための具体的な方法としては、インシデント対応とその振り返りに注力することが有効だと著者は述べています。インシデントの検知、対応、分析、再発防止のプロセスを丁寧に分解し、そこに潜む問いに真摯に向き合うこと。それこそが、SREがシステムの信頼性を高めるために不可欠な営みであり、SREの文化の根幹をなすものだというのです。
インシデント対応は、しばしば "fruit trees" を育てる営みに喩えられます。インシデントという "種" を丁寧に観察し、その理由や背景を "土壌" として分析する。そこから得られた学びを "肥料" にして、再発防止という "果実" を実らせる。そのようなプロセスを地道に積み重ねていくことが、SREの文化を根付かせ、組織の信頼性を高めていくのだと著者は説いています。
ただし、インシデント対応をSREだけの仕事にしてしまうと、かえって望ましくない状況を招く恐れがあると著者は警告しています。インシデント対応を通じて得られた知見は、組織全体で共有され、活用されてこそ意味があります。もしSREだけがインシデントから学び、その知見が組織に還元されないようであれば、それは "車輪の脱落したショッピングカートを押している状態" だと著者は表現しています。つまり、SREの文化が組織を望ましい方向に牽引する力を発揮できなくなってしまうのです。
その意味で、著者が "Who is getting smarter and what are we doing about it?:誰がより賢くなっているのでしょうか?それに対して私たちは何をしているのでしょうか?" と問いかけているのは示唆に富んでいます。インシデント対応から得られた教訓は、誰のものになっているのか。そして、その教訓を組織の信頼性向上にどう活かしているのか。その問いに常に意識的でいることが、SREの文化を健全に保つために不可欠なのです。
SREの文化を組織に根付かせるためのもう一つの方法は、"読書輪読会" や "ローテーション" だと著者は述べています。"読書輪読会" とは、ポストモーテムやシステム設計書、書籍などを題材に、SREの視点から議論を重ねる場のことです。一方、"ローテーション" とは、SREと他の職種の間で一定期間、互いの役割を交代するという取り組みです。これらの活動を通じて、SREの考え方や価値観を組織全体に浸透させていくことができます。
特に "ローテーション" は、SREの文化を組織に根付かせる上で強力な手段になり得ます。SREがソフトウェアエンジニアの役割を体験することで、開発者の視点や課題を肌で感じることができます。逆に、開発者がSREを経験することで、信頼性の重要性や、運用の現場で何が起きているのかを理解することができます。そのような相互理解が、SREと他の職能の間の "cultural exchange" を促進し、組織としての一体感を醸成するのです。
『Becoming SRE』の第3章は、SREの文化という、一見捉えどころのない概念を、具体的な方法論と結びつけて解説した、良い内容でした。著者の主張で特に印象に残ったのは、SREの文化は、意図的に育まなければ根付かないというものです。組織の価値観や行動様式を変えていくことは容易ではありません。しかし、著者が提示したような地道な取り組みを積み重ねていくことで、SREの文化は確実に花開いていくはずです。
SREの文化を育むためのプロセス
それは、新しい熱帯魚を迎え入れる時のようなワクワク感と、果てしない可能性に満ちたプロセスなのかもしれません。水槽の環境を整え、エサを与え、そっと見守る。SREの文化を育むことは、そんな愛情深く、辛抱強い営みなのだと感じました。
もう一つ、私が共感を覚えたのは、SREの文化の中核には "curiosity（好奇心）" があるという指摘です。システムの信頼性を追求するためには、その仕組みや振る舞いを深く理解したいという欲求が不可欠です。著者が "Any SRE culture you create (intentionally or unintentionally) has to support curiosity.:あなたが作成する SRE 文化は (意図的か非意図的かにかかわらず) 好奇心をサポートするものでなければなりません。" と述べているように、好奇心こそがSREの文化を支える最も重要な要素なのです。
そして、好奇心は "novelty（新奇性）" とも密接に結びついています。SREにとって、新しい技術や手法に触れ、学び続けることは、好奇心を刺激し、モチベーションを高める上で欠かせません。SREの文化は、そのような好奇心と新奇性を尊重し、奨励するものでなければならないのです。
また、著者が "culture overlays most everything" と述べているように、SREの文化は、技術的側面だけでなく、組織のあらゆる側面に影響を及ぼし得るものです。それは、人と人との関わり方、コミュニケーションの取り方、意思決定のプロセスなど、組織の文化的な基盤を形作るものでもあるのです。だからこそ、SREの文化を意図的に育んでいくことが重要なのだと改めて感じました。
SREの文化を育む困難さと重要性
SREの道のりは決して平坦ではありません。しかし、SREの文化を大切に育んでいくことは、その旅を意義あるものにしてくれるはずです。変化への抵抗や、既存の価値観との軋轢に直面することもあるでしょう。でも、複雑なシステムを動かすためには、てこを見出し、フィードバックループを形成し、粘り強く働きかけ続けることが肝要なのです。
本章を読んで、私は自身のSREとしての経験を振り返ってみました。確かに、私が所属するチームでも、SREの文化を意識的に育んできた面があります。例えば、障害の振り返りの場では、個人の責任を追及するのではなく、システムの課題を浮き彫りにすることを大切にしてきました。また、開発チームとのローテーションを通じて、互いの理解を深める取り組みも行ってきました。
しかし、著者の指摘を踏まえると、まだまだ改善の余地があるようにも感じました。例えば、インシデント対応から得られた知見を、もっと組織全体に浸透させていく工夫が必要かもしれません。また、SREの文化の中核にある "好奇心" を、もっと大切にしていく必要があるようにも思います。
自分なりのSREの文化を育んでいく。お客様に価値を届け続けるというSREの使命を全うするために、仲間とともに今日も一歩一歩前へ。
Chapter 4. Talking About SRE (SRE Advocacy)
SREについて語ることの重要性
本章は、SREについて語ることの重要性と、そのための実践的なアドバイスについて理解が深まりました。著者は、SREの価値を組織内外に伝えるためのストーリーテリングの技術について、自身の豊富な経験に基づいて解説しています。ちなみに、私が以前読んだ『ダイアローグ 価値を生み出す組織に変わる対話の技術』でも、必要なのはただのコミュニケーションではなく対話であることが強調されていました。SREについて語る際にも、この点は意識すべきポイントだと思います。
著者によると、SREについて語ることが重要な理由は大きく二つあるそうです。一つ目は、SREという職種や考え方に対する理解を深め、その存在意義を組織内で認めてもらうためです。特に、SREを新しく導入する際や、その影響力を拡大していく段階では、効果的なアドボカシー（支持獲得活動）が欠かせません。
二つ目の理由は、SREとしてのアイデンティティを形成するためだということです。著者は "the stories we tell ourselves are a major way identity is formed." つまり、「私たちが自分自身に語る物語は、アイデンティティを形成する主要な方法である」と述べ、自分たちが語るストーリーがアイデンティティの形成に大きな影響を与えると指摘しています。SREについて語ることは、単に他者の理解を得るためだけでなく、自分自身がSREとは何かを深く理解するためにも重要なのです。
では、SREについてどのようなストーリーを語れば良いのでしょうか。著者は、SREの定義や効果、評判、可能性など、様々な切り口からストーリーを構成することを提案しています。例えば、「SREの取り組みによって、あるチームの信頼性が目に見えて改善した」といった "効果の物語" や、「有名企業がSREを取り入れた」といった "評判の物語" は、SREの価値を伝える上で説得力のあるストーリーになるでしょう。
また、著者は具体的なストーリーの例も挙げています。障害対応の際の謎解きのプロセスや、SREの専門家の問題解決アプローチを描くことで、SREという仕事の面白さや奥深さを伝えることができるはずです。
一方で、SREについて語る上での課題についても、著者は良い指摘をしています。"吠えなかった犬" の例え話から分かるように、SREの価値は、しばしば "何が起きなかったか" という点に表れます。障害が発生しなかったことや、データ損失が防げたことなど、ネガティブな事象を語るのは容易ではありません。そのためには、"対比" の技法を活用し、SREの取り組みがなかった場合に起こり得た事態を想像させることが重要だと著者は述べています。
また、"ヒーロー文化" を美化するストーリーには注意が必要だと著者は警告しています。個人の英雄的な努力を称賛するあまり、過剰な負荷や無理な働き方を正当化してしまうことがあるからです。インシデント対応でのヒーローの活躍を語る際には、組織としての課題を浮き彫りにし、改善点を提示することが肝心だと強調されています。
著者が提示したストーリーの例は、SREの価値を伝える上で参考になるものばかりでした。特に、"ある日のSREの物語" のように、SREの日常業務を具体的に描くことで、その仕事の醍醐味や面白さを伝えられるアイデアが印象的でした。
ただし、著者自身も認めるように、SREについて語るのは思ったより難しいことがあります。信頼性向上への取り組みは決して一直線ではなく、試行錯誤の連続だからです。その複雑な現実を、聴衆に分かりやすく伝えるためには、スキルと経験が必要不可欠だと感じました。
また、SREのストーリーには、技術的な要素だけでなく、人的な要素も欠かせません。著者が "all of our systems are sociotechnical" と指摘しているように、信頼性の追求には、技術と人、両方の視点が不可欠なのです。
効果的なストーリーを語るための心構え
改めて振り返ってみると、SREについて語ることは、単なるアドボカシーの技術ではありません。それは、自らのアイデンティティと、組織としての使命を見つめ直す営みでもあるのだと気づかされました。著者が "my best talks are those that changed me during the preparation or presentation" と述べているように、SREについて語ることは、語り手自身をも変容させる体験になり得るのです。
本章で提示された多様なストーリーのアイデアを参考に、私もSREについて語る機会を増やしていきたいと思います。自分の経験を言語化し、他者と共有することで、SREとしての自覚と誇りを深めていく。そのような語りの積み重ねが、SREの文化を組織に根付かせ、ひいては社会にも良い影響を与えていくのだと信じています。
第4章は、SREという職種の意義を伝えるためのヒントに満ちた一章でした。SREについて語ることは、自分自身と、自分が関わるシステムを見つめ直すための強力な方法論なのだと実感しました。
とはいえ、効果的なストーリーを紡ぐのは容易ではありません。著者が "Collecting stories as you go" と述べているように、日々の業務の中で、ストーリーのタネを見つける感度を磨いていく必要があります。そして、それを言葉にする作業を丁寧に積み重ねていくことが肝要だと感じました。
また、著者も触れているように、他者のストーリーを語る際には、倫理的な配慮も欠かせません。関係者の許可を得ることは大前提ですが、それ以上に、ストーリーの背景にある文脈や、登場人物の心情に思いを馳せることが大切だと感じました。型にはまったストーリーではなく、現場の息吹が感じられるような生々しいストーリーを、誠実に語ることが求められているのだと思います。
もう一つ、著者が "Give up your airtime" で述べているように、多様な語り手を登用することも重要な課題だと感じました。SREについて語る機会が、一部の立場の人々に偏ることのないよう、自分自身も意識していきたいと思います。
第4章を読んで、改めてSREの魅力と可能性を感じました。システムの信頼性を追求するというミッションは、決して華やかなものではありません。しかし、著者が紹介してくれたような力強いストーリーを通じて、その意義を伝えていくことはできるはずです。
お客様に平穏と信用を届け、自分のプロとしての役割を成就するために。SREに関して語ることを通じて、自身の業務の意義を再び確かめ、新たな一歩を踏み出すための決心を固めたいものです。日頃の仕事の中で信用を積み重ね、丁重な説明を怠らず、相手に応じた意思疎通を図るなど、円滑なコミュニケーションのためには並々ならぬ労力が必要不可欠です。
しかしながら、コミュニケーションのコストを払いたくない、責任を背負いたくない、嫌われたくない、それでいて自分が考案した仕組みにみんなが同意し、ついてきてほしいというのは、どこまでも絵空事なのです。いかに「正しくて能率的」なアイデアでも、そこに人間が関与する以上、人間の心理や感情を考慮せざるを得ません。
本来は課題解決に注力したいのに、人間関係の調整に手間を取られるのは、本質から外れているように思えるかもしれません。しかし、他者と協働しなければならない以上、それは避けられない現実なのです。SREという仕事も、究極的には人と人とのつながりの中で成り立っているのだと、改めて認識させられました。円滑なコミュニケーションを築くことは容易ではありませんが、それなくしてSREの使命を果たすことはできないのです。
II. Becoming SRE for the Individual
Chapter 5. Preparing to Become an SRE
SREになるために必要な基礎知識
本章は、SREになるために必要な知識やスキルについて理解が深まりました。著者は、SREへの道のりに唯一無二の正解はないと断りつつも、SREとして活躍するために身につけておくべき基礎知識を丁寧に解説しています。
まず、「コーディングができる必要があるか」という問いに対して、著者は 「Yes」 と明確に答えています。システムの信頼性を追求するSREにとって、ソフトウェアがどのように作られているかを理解することは不可欠だからです。また、コーディングを学ぶことで、アルゴリズムの効率性、エラーハンドリング、抽象化、設計、分解、統合、依存関係、ドキュメンテーションなど、SREに必要な多くの概念を自然と学べると著者は指摘しています。これらについては自分も似たような課題感を持っていてブログにしました。
一方で、「コンピュータサイエンスの学位が必要か」という問いに対しては、必ずしもそうではないと著者は述べています。ただし、学位がない場合は、アルゴリズム解析やBig O記法など、コンピュータサイエンスの基礎概念をある程度理解している必要があるそうです。
次に、著者は 「基本的なシステムと、その障害モード」 と 「分散システムと、その障害モード」 の理解の重要性を強調しています。現代のSREは、マイクロサービスアーキテクチャや地理的に分散したシステムを扱うことが多いため、分散システム特有の障害モードを理解し、レイテンシ、コンセンサスアルゴリズム、分散タイムキーピング、データの一貫性などの概念に精通している必要があるのです。
また、著者は 「統計とデータの可視化」 のスキルも重要だと述べています。モニタリングとオブザーバビリティはSREの基盤であり、そのためには、パーセンタイル、傾向分析など、統計の知識が欠かせません。さらに、データを効果的に可視化する能力は、信頼性について客観的な議論をする上で極めて重要だと著者は指摘しています。
意外に感じたのは、「ストーリーテリング」 がSREの基礎スキルの一つとして挙げられていたことです。インシデントレビューやポストモーテムは本質的にストーリーであり、そのストーリーをうまく伝えることがSREの重要な仕事だと著者は述べています。人間はストーリーを通じて情報を受け取るようにできているため、SREはストーリーテリングとストーリーリスニングのスキルを磨く必要があるのだそうです。
また、著者は 「良き人であれ」 という一節で、SREにとって、プライバシー、倫理、インクルージョン、平等などの価値観について学び続けることの重要性を説いています。SREは地球上で最も重要なシステムの一部を任されているからこそ、常に自己研鑽に励み、最高の自分でいる必要があるのです。
そのほか、著者は、すぐには必要ないかもしれないが、いずれSREの前に立ちはだかるであろう話題として、「大規模システム設計」「レジリエンスエンジニアリング」「カオスエンジニアリングとパフォーマンスエンジニアリング」「機械学習と人工知能」 などを挙げています。特に、機械学習によって、システムの振る舞いがデータに依存して確率的に変化するようになったことは、信頼性を考える上で大きなパラダイムシフトだと著者は指摘しています。
SREの本質を追求する姿勢にこそ職責がある
『Becoming SRE』の第5章は、SREに必要な知識やスキルを体系的に整理した、良い内容でした。著者は「SREの仕事の本質は、システムについて深く理解し、その信頼性を追求すること」と繰り返し強調しています。そのためには、コンピュータサイエンスの基礎から、分散システム、統計、ストーリーテリングまで、幅広い知識と経験が求められます。
ただし、著者も認めるように、これらのスキルは一朝一夕には身につきません。大切なのは、自分に足りない知識を認識し、それを少しずつ埋めていく姿勢なのだと感じました。著者が "Worst-case scenario: it is good to know what you don't know." と述べているように、自分の知らないことを知っているだけでも、SREへの第一歩になるはずです。
また、SREとして成長していくためには、技術的なスキルだけでなく、「Are you a curious person?:あなたは好奇心旺盛な人ですか？」「Do you like to solve problems, no matter where they take you?:どこに連れて行かれても、問題を解決するのが好きですか?」「Is a life of service attractive to you?:奉仕生活はあなたにとって魅力的ですか?」といった問いに、心の底から「Yes」と答えられるかどうかも重要だと著者は述べています。SREという仕事に真に向いているかどうかは、スキルではなく、マインドセットにあるのかもしれません。
本章を読んで、私はSREという職種の奥深さを改めて感じました。信頼性の追求という、一見シンプルに見える目標の背後には、実に多様な知識とスキルが求められているのです。それは、コンピュータサイエンスという学問の神髄を問うものであり、同時に、人間の認知や行動、価値観についての洞察も必要とするものだと感じました。
しかし、だからこそ、SREという仕事にやりがいを感じずにはいられません。信頼性を追求するという使命を胸に、謙虚に学び、好奇心を持って問題に立ち向かう。そんなSREの姿勢は、エンジニアとして、人として、大いに魅力的だと感じます。
SREへの第一歩
もちろん、その道のりは平坦ではありません。著者が "aspirational:野心的" と表現しているように、本章で示された知識やスキルは、理想であって、必須条件ではないのです。大切なのは、その理想であり達人SREに向かって一歩ずつ前進していくこと。私も、自分に足りない点を一つずつ埋めながら、SREとしての道を歩んでいきたいと思います。
Chapter 6. Getting to SRE from…
様々なバックグラウンドを持つ人々がSREを目指せる
本章は、著者は、SREになるための唯一の正解はないと断った上で、学生、開発者、システム管理者など、よくある出発点からSREへ移行するためのアドバイスを提示しています。
まず、著者は「あなたはすでにSREなのかもしれない」と問いかけます。組織の中には、正式な肩書きこそないものの、SREのマインドセットを持って仕事に取り組んでいる人が少なからずいるというのです。もしあなたがそうだとしたら、組織内でその価値を認めてもらい、SREとしてのキャリアを歩み始めることが次の一歩になるでしょう。
学生からSREを目指す人へのアドバイスとしては、インフラ関連の仕事を見つけること、クラウドプロバイダーの無料クレジットを活用すること、カンファレンスに参加することなどが挙げられています。また、コンピュータサイエンスを学ぶ学生は、スケーリング、分散コンピューティング、キューイング理論などの授業に注目すべきだと著者は述べています。一方、工学や科学を学ぶ学生は、大規模計算に触れる機会を見つけ、信頼性の高いシステムを構築するために必要なスキルを身につけることが重要だとのことです。
開発者からSREへの移行に関しては、本番環境でのコードの振る舞い、障害モード、オブザーバビリティ、リリースエンジニアリング、ドキュメンテーションなどに注目することが大切だと著者は指摘しています。開発者にとって、「システムを構築するだけでなく、運用することについても考える」ことがSREへの第一歩になるのです。
システム管理者からシステム管理が得意なSREになった
私自身、システム管理者からSREへの道を歩んできました。著者が指摘するように、システム管理者とSREは、人々を助けたいという思いを共有しています。また、トラブルシューティングとデバッグのスキルも、両者に共通する強みだと言えるでしょう。
一方で、SREへの移行には、マインドセットの転換が必要だと著者は述べています。「すべてのものを監視する」から「顧客の視点から信頼性を測定する」へ、「適切な信頼性レベル」を追求し、「フィードバックループを育む」ことが求められます。
この転換を実現するために、著者はチケット管理システムやモニタリングのメールを、信頼性に関する貴重なデータソースとして活用することを提案しています。インシデント後のレビューを非公式に実施することも、SREのマインドセットを身につける良い機会になるでしょう。さらに、「根本原因」ではなく「contributing factors:要因」といった言葉を用いることで、言語がもたらす認識の変化にも目を向けるべきだと著者は述べています。
最後に、著者は他のあらゆる職種の人々に向けて、「信頼性とのつながりを見つけ、その方向に泳ぎ始めること」を勧めています。また、進捗を記録し、前進し続ける原動力にすることの重要性も強調されています。
第6章は、SREというキャリアを目指す人々に、実践的なアドバイスと温かい応援のメッセージを送る内容でした。著者の主張で特に印象に残ったのは、SREへの道に唯一の正解はないという点です。様々なバックグラウンドや経験を持つ人々が、信頼性の追求という共通の目標に向かって歩んでいける。そんな多様性と包摂性こそが、SREという職能の強みなのかもしれません。
本章を読んで、私はシステム管理者時代を振り返ってみました。確かに当時は、可用性の追求に汲々としていた面があります。でも、あの頃培った、ユーザーに価値を届けたいという思いは、今でもSREとしての原動力になっています。著者が述べているように、経験やスキルのギャップを少しずつ埋めていくことで、誰もがSREを目指せるのだと感じました。
SREへの道のりは平坦ではない
とはいえ、SREへの道のりは決して平坦ではありません。新しい知識を吸収し、経験を積み、時にはつまずきながら進んでいく。しかし、その過程で得られる学びと成長は、何物にも代えがたい価値があるはずです。
Chapter 7. Hints for Getting Hired as an SRE
本章は、SREの職を得るためのヒントについて理解が深まりました。著者は、SREの求人情報の評価方法から、面接の準備、面接でのアピール方法まで、SREの仕事を求める人のために実践的なアドバイスを提供しています。また、Github上ではmxssl氏によるSRE 面接準備ガイドがありこちらも一読していただければ良いと思います。
まず、著者は「SREの仕事はすべて同じではない」と断った上で、タイトルだけがSREに変更された職種（title-flip positions）は、本章の対象外だと明言しています。SREの求人を見極めるためには、求人情報に含まれている（あるいは含まれていない）情報に注目することが大切だと著者は述べています。
求人情報に記載されている技術スタックからは、その組織の技術的成熟度や環境の一貫性などが読み取れるそうです。また、チケット管理システムへの言及は、その環境がどれほどトランザクショナルかを示唆しているとのことです。プログラミング言語への言及は、コーディングスキルがある程度重視されていることを意味します。一方、モニタリング技術への言及の有無からは、その職種とモニタリングの関係性が窺えます。
次に、著者はSREの面接対策として、非抽象的な大規模システム設計（NALSD）、モニタリング／オブザーバビリティ、コンピューティングの基礎、トラブルシューティング／デバッグの4つのトピックを挙げています。これらのスキルは、ほとんどのSREの職種で求められるため、事前に準備しておくことが重要だと著者は述べています。
面接で質問すべき内容についても、著者は具体的な提案をしています。「モニタリングシステムについて教えてください」「インシデント後のレビュープロセスについて教えてください」「オンコール体制について教えてください」「SREが解決しようとしている問題は何ですか？」といった質問は、その組織におけるSREの役割や成熟度を知る上で有効だそうです。
答えは用意しておきます
ただし、著者も認めるように、面接での質問は諸刃の剣になり得ます。「あなたが雇用されたら、これらの質問に答えを出してもらいたい」と言われた場合、自分で出した難しい質問に答えなければならなくなるかもしれません。そのような状況に備えて、大まかな答えを用意しておくことが賢明だと著者は述べています。
第7章は、SREの仕事を求める人のための実践的なガイドブックでした。著者の豊富な経験に基づく助言は、SREを目指す人にとって心強い道しるべになるはずです。
本章を読んで、私は自身の経験を振り返ってみました。確かに、SREの面接では、技術的な質問だけでなく、システム思考やコラボレーションに関する質問も多く出されました。著者が述べているように、SREに求められるスキルは多岐にわたるため、幅広い知識と経験が問われるのだと実感しました。
また、面接官としての経験からも、著者の指摘に共感を覚えました。求職者がシステムのボトルネックを特定したり、障害から学ぶ姿勢を示したりするのを見ると、SREとしての資質を感じずにはいられません。逆に、ヒーロー的な振る舞いを美化するような発言には、危険信号を感じることがあります。
SREの面接は双方向のコミュニケーション
本章で特に印象に残ったのは、SREの面接は双方向のコミュニケーションであるべきだという点です。求職者は、自分のスキルをアピールするだけでなく、その組織におけるSREの役割や課題について積極的に質問すべきだと著者は述べています。時には、面接そのものが、SREの実践の場になり得るのかもしれません。
また、著者が 「面接に落ちたら、それを障害対応のように扱ってみよう」 と提案しているのも興味深かったです。確かに、失敗から学ぶ姿勢は、SREにとって不可欠なマインドセットです。面接に落ちたからといって、それで終わりではありません。そこから学びを得て、次のチャンスに生かしていく。そういう前向きな姿勢こそが、SREの真骨頂なのだと感じました。
SREの世界に飛び込むのは、勇気のいることかもしれません。でも、その一歩を踏み出す価値は十分にあるはずです。『Becoming SRE』の第7章は、その一歩を後押ししてくれる、頼もしいガイドだと感じました。
日々の仕事の中で信頼性への意識を研ぎ澄ます
とはいえ、面接対策だけがSREへの道ではありません。日々の業務の中で、信頼性への意識を研ぎ澄まし、技術力を磨いていくことが何より大切なのだと思います。著者も触れているように、SREの面接は、日頃の仕事ぶりの反映に他なりません。だからこそ、普段から「How can I make things better?」という問いを忘れずにいたいものです。
Chapter 8. A Day in the Life of an SRE
SREの多様な役割とコラボレーションの重要性
本章は、SREの日常業務の章であり、SREという職種の多様性と複雑性を浮き彫りにしています。 著者は、SREの仕事を複数のモードに分類することで、その役割の広がりを示しました。インシデント対応、ポストインシデント学習、ビルダー/プロジェクト/学習、アーキテクチャ、マネジメント、計画、コラボレーション、回復とセルフケアなど、SREは常に状況に応じて異なる仕事のモードを切り替えながら、システムの信頼性を維持・向上させていく必要があるのです。
特に印象に残ったのは、コラボレーションモードの重要性についての指摘です。 SREはシステムの信頼性を確保するために、開発者、プロダクトマネージャー、ステークホルダー、ビジネス側の人々など、さまざまな関係者と密接に連携していかなければなりません。SLI/SLOの定義と実装、モニタリングの設計、カオスエンジニアリングの実践など、SREの主要なタスクの多くはコラボレーションを抜きには語れません。著者が強調するように、SREは「容赦なく協調的」であることが求められるのです。
SREのワークライフバランス
また、SREの仕事がときに過酷になりがちだという指摘も重要です。 ヒーロー的な働き方を美化する文化的風潮の中で、SREが過剰なワークロードを抱え込み、バーンアウトしてしまうリスクは常につきまといます。著者は、週60-75時間も働くことを自慢げに語る人がいたら、それはシステムの失敗の表れだと考えるべきだと述べています。燃え尽きた人間は、信頼性の高いシステムを構築することができないのです。SREがサステナブルなオペレーションを実現するためには、適切なワークライフバランスを保つことが不可欠だと言えるでしょう。
SREの業務バランス
SREの業務バランスについての考察も示唆に富んでいました。反復作業と価値ある作業、リアクティブな仕事とプロアクティブな仕事、割り込みの多い仕事と集中できる仕事、個人作業とチームでの作業、危機的状況と平常時など、SREは常に相反する要素のバランスを取る必要があります。 特に新しいサービスを立ち上げる際は、リアクティブな仕事や割り込みが多くなりがちで、エンジニアリング業務に充てる時間を確保するのが難しくなります。状況に応じて柔軟にバランスを取っていく必要がありますが、長期的には業務時間の50%はエンジニアリング業務に充てるべきだというガイドラインは、非常に参考になりました。
本章では、SREという職種の技術的な側面だけでなく、コラボレーション、ワークライフバランス、メンタルヘルスなど、さまざまな角度からSREの仕事の実態に迫っています。 SREに求められるスキルや資質の多様性を考えると、SREという職種の奥深さと面白さを改めて感じさせられました。特に、SREがサステナブルなオペレーションを実現するための職種であるという点は重要で、バランスの取れた働き方を目指すべきだという主張には強く共感しました。
私たちSREは、常に変化し続ける技術的・組織的環境の中で、複数のモードを行き来しながら、コラボレーションマインドセットを発揮し、適切なバランスを保ちつつ、信頼性の高いシステムづくりに取り組んでいく必要があります。 本章で紹介されていたさまざまな知見を胸に、SREとしてのキャリアを歩んでいきたいと思います。
Chapter 9. Establishing a Relationship to Toil
Toilを単に「嫌な仕事」と片付けない
本章は、SREにとって馴染み深いトピックである「Toil」について、より深く掘り下げた章でした。Toil（単純作業）は、SREの文脈でしばしば登場する概念ですが、その定義や特徴、そして私たちがToilとどのように向き合うべきかについては、これまであまり明確に語られてこなかったように感じます。本章では、Vivek Rauが提示したToilの定義を出発点としつつ、より nuancedで健全なToilとの付き合い方を模索しています。
まず印象的だったのは、Toil を単に「嫌な仕事」として片付けるのではなく、より精緻に定義しようとしている点です。 Rauによれば、Toilとは、manual（手作業）、repetitive（反復的）、automatable（自動化可能）、tactical（戦術的）、no enduring value（持続的価値がない）、O(n) with service growth（サービスの成長に比例）といった特徴を持つ作業のことを指します。これらの特徴をすべて満たす必要はありませんが、当てはまる項目が多いほど、その作業はToilである可能性が高いと言えるでしょう。
また、「誰のToilについて話しているのか」という問いも重要だと指摘されています。 通常、SREが対処しようとしているのは、システムの運用に関わるToil（operational Toil）であり、顧客が直面するToil（customer Toil）ではありません。ただし、顧客のToilを軽減することもSREの新しいフロンティアになり得ると著者は示唆しています。運用のToilと顧客のToilの間には、興味深い関連性があるのかもしれません。
Toilに注目する３つの要因
次に、SREがToilに注目する理由について、著者は3つの要因を挙げています。 1つ目は、美的感覚（aesthetics）です。SREは、非効率的で不要なToilを根本的に嫌うという特性を持っているのかもしれません。2つ目は、お金（money）の問題です。高度なスキルを持つSREを雇用するコストは高く、彼らにToilではなく価値ある仕事をしてもらうことが組織の財務的利益につながります。3つ目は、時間の使い方と仕事の満足度です。Toilに費やす時間が増えれば、エンジニアリング業務に充てられる時間が減り、SREの仕事の満足度も下がってしまいます。
さらに、Toil がサービスの成熟度と関連していることも指摘されています。 新しいサービスほど、モニタリングやアラートの調整が不十分であったり、運用に必要なプロセスの自動化が不足していたりするため、Toil が多くなる傾向があります。サービス立ち上げ初期のToil（Early Toil）と、成熟したサービスに付きまとうToil（Established Toil）を区別することが、Toil削減に向けた戦略を立てる上で重要だというのは、良い視点だと感じました。
そして、Toil の削減（あるいは排除）について、著者は興味深い見方を示しています。 よく語られるのは、「Toil を特定し、自動化やセルフサービス化によって排除する」というストーリーですが、著者はこれに疑問を呈しています。Toil は完全に排除できるわけではなく、別の形に姿を変えるだけだというのです。自動化によってToil が減っても、その分、コードの複雑性が増す。セルフサービス化によって運用チームのToil は減っても、その分、Toil が細分化されてユーザー側に分散される。著者はこれを「Toil の保存則」と呼んでいます。 Toil との健全な付き合い方を確立するためには、この保存則を直視する必要があるでしょう。
トイルの削減に向けた取り組みを、単一のシステムレベルから、環境全体のクラスレベルに引き上げることも重要だと著者は指摘しています。例えば、新しいサービスをモニタリングシステムにオンボーディングする作業を大幅に簡略化することで、Early Toil を大きく削減できるかもしれません。さらに、過去のToil（established）、現在のToil（early）、未来のToilのどれに有限のリソースを割り当てるかという、時間軸を意識した判断も求められます。
Toilとの健全な付き合い方
個人的には、「Toil を完全に排除するのではなく、より有害度の低い形に変換していく」という考え方に強く共感しました。 トイルを減らす努力は続けつつも、同時に発生し得る複雑性や、顧客側への影響についても意識しておく必要がありそうです。私自身、SREとして日々Toilと向き合っていますが、それを単に嫌な仕事として捉えるのではなく、サービスの成熟度や技術的負債との関係性を意識しながら、長期的視点でToilの削減に取り組んでいきたいと思います。また、生成AIがこれらの意思決定にどのように影響するのか考える必要があると思っています。本章で得られた知見は、そのための指針になってくれるはずです。
Chapter 10. Learning from Failure
障害からの学びはSREの中核的な活動
本章は、システムの障害から学ぶことの重要性と、その実践方法について深く掘り下げた章でした。SREにとって、障害からの学びは、適切な信頼性レベルを達成するための中核的な活動だと言えます。 モニタリング/オブザーバビリティ、SLI/SLOによる目標設定、そしてインシデント/アウトリッジ対応という3つの実践が交差する地点に、障害からの学びがあるのだと著者は指摘しています。この学びを通じて、現状（what is）と目標（what should be）のギャップを埋めていくことができるのです。
![反脆弱性[下]――不確実な世界を生き延びる唯一の考え方](https://m.media-amazon.com/images/I/51plby84hwL._SL500_.jpg "反脆弱性[下]――不確実な世界を生き延びる唯一の考え方")
まず印象に残ったのは、障害について語る言葉選びが、私たちの思考や行動に大きな影響を与えるという指摘です。 例えば、「root cause（根本原因）」という言葉は、複雑な障害を単一の原因に帰着させようとする思考を助長しがちです。それに対して、「contributing factors（寄与因子）」という言葉は、障害の複雑性を認識し、多面的な理解を促します。著者が強調するように、SREは障害について語る際の言葉選びにも注意を払う必要があるでしょう。
ポストモーテムでも良い
次に、ポストインシデントレビュー（PiR）のプロセスについて、詳細な解説がありました。 あ、本書の中でそう言っているだけでポストモーテムが一般的な用語です。ポストインシデントレビューの目的は、インシデントについて徹底的に調査し、関係者間で共通理解を構築しながら、可能な限り多くのことを学ぶことにあります。そのためには、インシデントの詳細な年表を作成し、関係者全員でレビューすることが重要だと著者は述べています。また、レビューの際は、「なぜ」よりも「何が」「どのように」起きたのかに焦点を当てるべきだと指摘しています。「なぜ」を問うことは、原因の特定や対策の検討に性急に走ってしまう危険性があるためです。
著者は、ポストインシデントレビューでよく見られる5つの落とし穴についても警鐘を鳴らしています。 「human error（人的ミス）」でインシデントを片付ける、反実仮想的な推論に陥る、結果論で判断する、機械の無謬性を前提とする、ポジティブな側面を無視する、といった点です。これらは、障害の本質的な理解を妨げ、学びを狭めてしまう恐れがあります。私自身、これらの落とし穴に無意識に陥っていたことに気づかされました。
レジリエンスエンジニアリングについては、著者が特に重要視している点だと感じました。David Woodsによるレジリエンスの定義は、「不可避な驚きに対応するためにシステムが必要とする能力」というもので、従来のレジリエンス（回復力、耐障害性）の概念を大きく拡張するものです。 レジリエンスを高めるためには、変化や障害に適応するための「適応能力（adaptive capacity）」を、事前に備えておく必要があるのです。
私が特に興味深く感じたのは、レジリエンスを「reboundからsustained adaptabilityまでの4段階」で捉える考え方です。 reboundは「障害からの回復」、robustnessは「複雑性やストレスへの対処」、graceful extensibilityは「想定外の事態への適応」、そしてsustained adaptabilityは「進化し続ける環境への継続的適応」を意味します。多くのSREがreboundからrobustnessあたりを目指しているのに対し、レジリエンスエンジニアリングは、その先のgraceful extensibilityやsustained adaptabilityまでを視野に入れているのだと理解しました。
また、Safety-IIやSafety-IIIといった概念も紹介されていました。 Safety-IIは、「うまくいっているときに何が起きているのか」に着目することで、障害を未然に防ぐアプローチです。Safety-IIIに至っては、「成功から学ぶ」ことで、失敗を防ぐという画期的な発想だと言えます。私たちSREは、障害対応に追われるあまり、普段うまくいっていることの分析を怠りがちです。レジリエンスエンジニアリングの知見は、そうしたマインドセットを変える上でも示唆に富んでいると感じました。
著者も指摘するように、レジリエンスを「動詞」として捉えることが重要だと思います。 レジリエンスは、ただ備わっている特性ではなく、絶え間ない実践によって培われていくものです。障害を避けられない以上、私たちにできることは、レジリエンスを高める営みを続けていくことです。そのためには、レジリエンスエンジニアリングの知見を深く理解し、SREの文脈に適用していく努力が求められるでしょう。
レジリエンスエンジニアリングの知見を吸収し活用する
私自身、これまではレジリエンスを「回復力」程度の意味で捉えていましたが、本章を読んで、その概念の奥深さに気づかされました。システムのレジリエンスを高めることは、SREの本質的な使命だと言えます。 障害から学ぶことは、そのための重要な一歩です。しかし、それだけでは不十分で、平時のシステムの挙動から学ぶことも欠かせません。レジリエンスエンジニアリングの知見を積極的に吸収し、SRE文化に取り入れていくことが、これからのSREに求められているのだと強く感じました。
さらに、カオスエンジニアリングについても言及がありました。 カオスエンジニアリングとは、本番環境で意図的に障害を引き起こし、システムの挙動を理解する取り組みです。単なる「破壊」ではなく、仮説に基づいた意図的な実験であることが重要だと著者は述べています。想定外の事態に備えるための力を養う上で、カオスエンジニアリングは欠かせないアプローチだと感じました。
最後に、ポストインシデントレビューで得られた学びを組織全体に広げるための具体的な方法が紹介されていました。 「ブッククラブ」「ニュースレター」「プロダクションレディネスレビューへの反映」「メタ分析とML」など、どれも良いアイデアだと感じました。せっかく得た貴重な学びを、ドキュメントに埋もれさせてはいけません。組織の隅々にまで浸透させる工夫が求められます。
全体を通して、障害からの学びがSREの中核的な活動である一方で、それを実践することの難しさも再認識させられました。 言葉選びひとつとっても、私たちの無意識のバイアスが入り込む余地があります。学びを最大化するためには、レジリエンスエンジニアリングやカオスエンジニアリングといった周辺領域の知見も積極的に取り入れていく必要がありそうです。
私自身、これまでのキャリアの中でポストインシデントレビューに数多く参加してきましたが、本章で得た学びを胸に、より効果的な障害からの学びを実践していきたいと思います。個人としてだけでなく、チームや組織体としての学びを促すことが、SREに求められる重要なスキルなのだと再認識しました。
Part III. Becoming SRE for the Organization
Chapter 11. Organizational Factors for Success
SREの導入には組織のあり方そのものの見直しが必要な時もある
本章は、SREの導入を成功に導くための組織的要因について、非常に良い考察を提示していました。単に技術的なベストプラクティスを導入すれば事足りるわけではなく、組織のあり方そのものを見直す必要性を説得力を持って訴えかけています。
著者が最初に問いかけるのは、「SREが解決できる問題を組織が抱えているか」という点です。 具体的には、システムの信頼性の低さ、アウテージ対応の非効率、過剰な運用負荷といった、SREのアプローチが真に効力を発揮できそうな課題を特定することが重要だと指摘しています。SREを導入すれば万事解決すると楽観視するのではなく、その手法が組織の痛点に適合するかを見極める必要があるのです。
次に重要な問いは、「その問題を解決するために、組織は実際に何をする覚悟があるか」です。 SREはバズワードとして華やかに語られがちですが、本当の意味で組織に根付かせるには、相応の覚悟と行動が求められます。著者は具体的な問いを投げかけます。信頼性向上のためにエンジニアリングリソースを割けるか。機能開発を後回しにしてでも、インシデント対応の改善に注力できるか。SLOが未達の際、新機能のリリースを躊躇なく延期できるか。ポストモーテムを形骸化させない努力を惜しまないか。オンコール体制は人間的で持続可能なものになっているか。SREがソースコードにアクセスし、信頼性向上に必要な変更を加えられるか。こうした一つ一つの問いに正面から向き合わなければ、SREの真価は発揮できないと著者は警鐘を鳴らしているのです。
SREは技法や手法だけでできたら苦労はしねぇ
また、SREの効果が表れるまでの「忍耐力」も重要だと指摘しています。 DORAのState of DevOps Report 2023 でも示されているように、信頼性向上の取り組みが実を結ぶまでには一定の時間がかかるものです。短期的な成果を求めるあまり、腰を据えた取り組みを続けられなければ、折角の努力も水泡に帰してしまいます。だからこそ、地道な改善を積み重ねつつ、長期的なゴールを見据える忍耐強さが組織に求められるのです。
SREが真に力を発揮するには、組織のあらゆるレイヤーでの「協調性」も欠かせません。 開発チーム、ビジネスサイド、ステークホルダーなどと有機的に連携しながら、信頼性の向上を追求していく必要があります。部署間の壁を越えて協調できる組織文化があるか。SREが他チームのコラボレーションツールに参加できるか。モニタリングやオブザーバビリティのツール選定に SREの意見は反映されているか。そうした具体的な協調性の発露が、SREの成功を左右すると著者は指摘するのです。
また、SREにとって「データ駆動の意思決定」は生命線とも言えます。 モニタリングの重要性を説き、その結果を改善アクションに直結させる。そのためには、データの可視化や分析を習慣づけ、意思決定プロセスに組み込む組織文化が不可欠です。エラーバジェットの概念も、まさにデータに基づく意思決定の具現化だと言えるでしょう。こうしたデータ駆動のマインドセットが組織に根付いているかを見極める必要性を、著者は説いているのです。
失敗から学ぶ姿勢も、SREの生命線の1つです。 形骸化したポストモーテムではなく、真摯に失敗の教訓を汲み取り、改善に活かすサイクルを回していく。それも1つのチームに閉じた学びではなく、組織の壁を超えて知見を展開していく。そうした失敗からの学びを組織の文化として定着させられるかどうかが、SREの成功を分けると著者は指摘します。インシデントの振り返りが義務的なタスクと化していないか。関係者が建設的に議論できているか。導き出された教訓が確実にアクションに結びついているか。こうした具体的な問いを投げかけることで、組織の学習力を見抜くことができるのです。
SREの真価を発揮するための組織体制
そして、SREが真の力を発揮するには、現場レベルでの「変化を起こす力」も欠かせません。 ドキュメントの改善から、コードやインフラの変更、ツールの選定、採用プロセスの見直しに至るまで、SREが信頼性向上のために必要な施策を機動的に実行に移せる環境が整っているかどうか。それは、SREの役割への信頼と、裁量の広さの表れだと言えます。もちろん、すべてを自由に変更できる必要はありません。しかし、SREの専門性を活かして、システムを改善していく力を組織が認めているかは、重要なバロメーターになります。
加えて、システム内の「摩擦」を発見し、取り除いていく感度の高さも重要だと著者は説きます。 障害対応に2時間もかかるのに、サービス可用性の目標値は99.99%といった矛盾。開発者とオペレーション担当者の間の連携不足。旧態依然としたマニュアル作業の残存。そうした非効率や齟齬を嗅ぎ分け、改善を促していく感性がSREには求められます。リスクを放置すれば、いずれ大きな障害を招きかねません。だからこそ、摩擦を見抜き、取り除く意識を組織全体で醸成していく必要があるのです。
結局、組織じゃんって話
そして著者は、SRE導入の成否は結局のところ「組織の価値観」に集約されると結論付けています。 どんなにSREの手法を形式的に取り入れても、組織の根幹にある価値観と融和しなければ、長続きはしません。信頼性を重視する文化、学習を尊ぶ姿勢、協調性、変化への適応力。そうした価値観が組織のDNAレベルで共有されている必要があるのです。Googleでの SREの成功も、同社のエンジニアリング文化と価値観があってこそだったと著者は指摘します。組織の価値観とSREの理念が合致することが、成功の大前提なのです。
SREの導入は、技術的側面だけでなく、組織文化や価値観のレベルでの変革を必要とする壮大な挑戦だと改めて感じさせられました。一朝一夕には成し遂げられない困難な道のりですが、その実現のためには、本章で示された指針に一つ一つ向き合っていく必要があります。SREと真に相性の良い組織を作り上げるには、骨太の問いを自らに投げかけ、その答えを見出す誠実さを業務で体現できればと思いました。
Chapter 12. How SRE Can Fail
SREの失敗は組織全体にネガティブな影響を及ぼしかねない
本章は、SREの導入と実践における失敗のシナリオを赤裸々に描き出した、良い章でした。著者は、SREの失敗が、単なる信頼性向上の取り組みの頓挫にとどまらず、組織全体がSREを拒絶するような深刻な事態を招きかねないと警鐘を鳴らしています。私たちは、SREという"処方箋"を手にしたからといって、安穏としてはいられません。その処方箋の効果を十分に引き出すには、組織の隅々にまで浸透させる地道な努力が欠かせないのです。
印象的だったのは、SREの導入を「肩書の変更」だけで済ませようとする安直なアプローチへの警告です。開発者やサポートエンジニアの肩書をSREに変えるだけでは、役割や文化に実質的な変化は生まれません。むしろ、形骸化したSREチームが、開発現場の足を引っ張るリスクすらあります。SREは、単なる看板の掛け替えではなく、価値観、トレーニング、リソース配分、コミュニケーションの在り方などを根本から見直す覚悟なくして、成功しないのです。
同様の罠は、既存のTier 3サポートチームをそのままSREチームに転換しようとする試みにも潜んでいます。サポートチームの役割は、エスカレーションされた難解な問題を解決することであり、システムの信頼性を根本から高めるフィードバックループを作り出すことではありません。単なる看板の掛け替えでは、開発チームとの建設的な協働は生まれず、SREの真価を発揮できないままに終わるでしょう。著者が指摘するように、SREへの転換は、チームの使命と働き方を抜本的に見直す取り組みでなければならないのです。
SREは失敗をどう扱うのか？
また、SREの役割をオンコール対応だけに矮小化するのも危険だと著者は訴えかけています。確かにインシデント対応は、システムの弱点を学び、改善につなげる重要な機会です。しかし、それだけがSREの存在意義だと誤解されては本末転倒です。開発者の負担を軽減するための「例外処理係」としてSREを使うのは論外ですし、システム改善から切り離されたオンコールでは、SREのポテンシャルを十分に引き出せません。SREは、オンコールから得た学びを、信頼性向上のための施策に着実に結びつけてこそ、真価を発揮できるのです。
組織のトップレベルで、機能開発とSREによる信頼性向上のバランスをコントロールできる体制の欠如も、SREを失敗に導く要因として指摘されています。開発チームとSREチームのリーダーが、同じエンジニアリング責任者の下に位置していれば、feature workとSREの優先順位をその場その場で適切に判断できるはずです。しかし、両者の調整に上層部の決裁が必要になれば、SREの機動力は大幅に削がれてしまいます。組織のヒエラルキーがSREの足を引っ張ることのないよう、意思決定プロセスをシンプルに保つ工夫が欠かせません。
Googleの実践をそのまま自社に当てはめようとする安直なアプローチも、失敗のリスクを孕んでいると著者は指摘します。Googleの書籍から学ぶことは多いですが、自社の文化や特性を無視してそのまま導入しても、うまくいくはずがありません。SREはGoogleの価値観の反映であり、他社が同じことをしたからといって、同じ成果が得られる保証はないのです。大切なのは、Googleの実践に範を求めつつも、自社独自のSREを見出していくこと。時には、Googleとは異なる道を選ぶ勇気も必要になるでしょう。
SREがゲートキーパーと化すことも、大きな落とし穴だと著者は述べています。プロダクションリリースの可否を判断する"門番"としてSREが君臨すれば、開発チームとの対立は避けられません。SREが「get to "no"」の存在になれば、開発者はSREを障害物とみなし、迂回する方法を編み出そうとするでしょう。SREは、開発チームの創造性を阻害するのではなく、reliability-minded cultureを醸成するパートナーとして振る舞う必要があります。
SREの成功が仇となって自滅するケースにも目を向けています。実績を上げたSREチームがあれば、つい何でも任せたくなるものです。しかし、それではSREチームはたちまち疲弊し、モチベーションを失ってしまいます。SREがシステムの面倒を一手に引き受ける"heroもの"になれば、開発チームの当事者意識は薄れ、システムは脆弱化の一途をたどるでしょう。SREはあくまで開発チームとの協働によって真価を発揮する、ということを肝に銘じる必要があります。
また、目に見えづらい改善の積み重ねや、お客様視点の欠如、日々の楽しさの喪失など、些細な障害の集積がSREを衰退させる可能性も示唆されていました。SREの仕事は、日々の地道な努力の積み重ねです。トラブルが減れば減るほど、その存在価値が見えづらくなるのは宿命と言えます。だからこそ、自らの成果を可視化し、社内外にアピールし続けることが肝要なのです。単に社内の評価を高めるためだけでなく、自らの仕事のやりがいを再確認するためにも、これは欠かせない活動だと感じました。
全体を通して、SREの道のりが平坦ではないことを思い知らされる章でした。様々な落とし穴が私たちを待ち受けています。肩書だけの変更、不適切なチーム改編、オンコール偏重、ゲートキーピング、Googleの無批判な模倣、業務の押し付け、目に見えない成果、お客様視点の欠如、楽しさの喪失。どれ一つとっても、SREを脆弱化させ、組織から拒絶されるリスクを孕んでいます。
SREの失敗から立ち直るためのマインドセット
しかし、だからこそSREには果敢にチャレンジする価値があるとも感じました。SREの道は険しいかもしれません。思うように物事が運ばないこともあるでしょう。しかし、SREたるもの、困難から目を背けるわけにはいきません。「SREが組織に拒絶されつつある」という兆候を感じたら、インシデント対応のように、適切なstakeholderを招集し、早期の軌道修正を図る。失敗から立ち直れなかった時は、ポストモーテムのように、徹底的に原因を究明し、教訓を次に活かす。SREのマインドセットとスキルは、まさに逆境を乗り越えるために磨かれてきたのです。
とはいえ、組織の理解と協力なくして、SREの成功はあり得ません。セイリングで「向かい風でも、風を読めば前に進める」と言われるように、私たちは、SREへの"向かい風"を嘆くのではなく、それを追い風に変える知恵を持たねばなりません。失敗の芽を早期に発見し、軌道修正を図る感度の高さ。組織の価値観に働きかけ、開発チームとの信頼関係を築き、お客様の視点を第一に考える粘り強さ。そうした資質を私たち自身が体現することで、自社ならではのSREを根付かせていくことができるはずです。向かい風を利用したダッキングの仕組みは知識さえあればどんな状況も好転する可能性を秘めている例としてとても良いので雑学科学読本 身のまわりのすごい技術大百科から引用させて下さい。
失敗の先にある成功を信じて、これからもSREの旗を高く掲げ続けたい。本章で赤裸々に描かれた数々の失敗シナリオは、SVレベルの人にこそ読んでもらいたい内容だと感じました。システムの信頼性は、一SREチームだけで達成できるものではありません。開発、オペレーション、マネジメントが一丸となってこそ、真の信頼性は生まれるのです。
私たちSREは、荒波にも負けず、組織を信頼性の高い未来へと導く舵取り役でありたいと願っています。ただ単にGoogleが提唱するSREの手法を模倣するのではなく、それぞれの独自性を活かしたSREとしての旅路を歩みたいと思います。この道のりは、組織の隅々にわたってSREの価値観を浸透させることで、目指すべき信頼性という大海原へと進む冒険です。この考え方を共有するために、同僚が『あなたらしくSRE』というテーマでの発表を行い、大変示唆に富む内容でしたので、その資料をここで紹介します。
また、netmarkjpさんによる、現場主導で進化するSREのあり方をテーマにした一連の資料も大変参考になります。具体的には、『現場がさき、プラクティスがあと、原則はだいじに』には、現場のニーズを優先しつつ、SREのプラクティスを展開していく重要性が述べられています。『SREsのためのSRE定着ガイド』では、SREが組織内で定着し、根付いていくための具体的なガイドが提供されています。さらに、『SREこのへんで苦戦しがちじゃないですか？』では、SREが直面しがちな困難に対する洞察と対処法が紹介されています。
これらの資料は、それぞれの組織やチームが直面する独自の課題に対して、柔軟かつ効果的に対応するためのヒントやインスピレーションを提供してくれるはずです。私たち一人ひとりがSREとして成長し、組織全体の信頼性を高めていくために、これらの資料をぜひ活用してください。
Chapter 13. SRE from a Business Perspective
信頼性はサービスの最も重要な機能
本章は、SREという技術的な役割を、ビジネスの観点から捉え直した、良い富む章でした。SREの実践は、単に技術的な信頼性の向上だけでなく、組織の成長や競争力強化にも直結する重要な取り組みだと再認識させられました。
著者が対談したBen LutchとDave Rensinの両氏は、Googleという最先端のIT企業で、SREチームのリーダーを長年務めてきた人物です。彼らの知見は、SREをビジネスの文脈で語る上で、非常に良い章です。
まず印象的だったのは、「信頼性はサービスの最も重要な機能である」という指摘です。顧客がサービスを使い続けるためには、その信頼性が何よりも大切だと言えます。SREは、その信頼性という機能の実現に特化したエンジニアリングチームだと位置づけられるのです。機能開発と信頼性向上は二律背反ではなく、SREという専門チームを設けることで、両者を高いレベルで両立できるというのは、良い視点でした。
また、SREの存在意義を測る物差しとして、エラーバジェットの概念が重要だと指摘されていました。サービスの稼働率を100%にするのではなく、ビジネス上許容できる停止時間を設定し、それを超えない範囲でサービスを運用する。この考え方は、SREが目指す現実的な信頼性の追求方法だと感じました。エラーバジェットの消費率を追跡することで、SREチームの価値を可視化し、経営層を納得させることができるというアイデアは、示唆に富んでいます。
SREチームの予算確保の際は、組織が抱える課題を起点に議論することが肝要だと著者は述べています。漠然と「SREの予算が欲しい」と訴えても、説得力に欠けます。「ここ数ヶ月で発生した障害は許容できないレベルにあります。それを防ぐために、最低限このくらいのリソースが必要だ」といった具体的な問題提起が求められます。また、SREがもたらすインパクトを、顧客体験や機会損失の回避といったビジネス指標に言い換える工夫も大切だと感じました。
一方で、SREチームが陥りがちな落とし穴についても言及がありました。デベロッパーから問題をすべて丸投げされ、単なる「ページャーモンキー」と化してしまう。改善活動がおろそかになり、問題対応に明け暮れる「トイルバケツ」になってしまう。こうした事態に陥らないよう、常にSREの役割と価値を組織に示し続ける必要があるのだと実感しました。
また、SREチームのヘッドカウントについても、良い議論がありました。「開発者を残業から解放したい」といった安易な動機でSREチームを肥大化させるのは賢明ではありません。あくまで、サービスの信頼性目標の達成に必要十分な人員を確保することが肝要です。一方で、疲弊しすぎず、エンジニアリング活動に注力できる最低限の人数は確保すべきだとも述べられています。ビジネスの要請とSREの働き方のバランスを取ることの難しさを感じさせられました。
SREの価値を経営層に伝え続けることの重要性
全体を通して、SREの価値を経営層に伝え、組織に定着させていくことの重要性を再認識した章でした。技術的な側面だけでなく、ビジネスの文脈でSREの存在意義を示し続けることが、その役割を確立する上で欠かせません。とはいえ、そこに正解はなく、各組織の状況に合わせて、試行錯誤していくことが求められるのだと感じました。
SREという役割に惹かれて飛び込んできた私たちエンジニアにとって、ビジネスの観点は、ともすれば苦手意識を持ちがちな領域かもしれません。しかし、本章で紹介されていたフレームワークは、経営層とのコミュニケーションを助けてくれる強力な武器になるはずです。SLOに基づくサービス運用、エラーバジェットによるインパクトの可視化、ビジネス課題起点の要員計画。そうした考え方を身につけることで、SREとしてのキャリアをより確かなものにしていけるでしょう。
私自身、まだまだ経験の浅いSREですが、この章で得られた学びを胸に、技術とビジネスの両面でのSREの価値向上に努めていきたいと思います。開発チームと経営層の間に立ち、両者の言葉を翻訳しながら、信頼性というゴールに向かって組織を牽引していく。そんなSREのあるべき姿が、この章を通して見えてきたように感じています。
単に技術的なスキルを磨くだけでなく、ビジネスの文脈でSREの価値を語れるエンジニアになること。それが、これからのSREに求められる資質なのかもしれません。経営層の期待に真摯に向き合いつつ、現場のエンジニアリングにも手を抜かない。 その両立は容易ではありませんが、その先にこそ、SREのやりがいがあると信じています。
著者も述べているように、SREをビジネスの文脈で語ることは、まだまだ探求の余地がある領域だと感じました。一人一人のSREが、自らの経験を言語化し、共有し合うことで、その知見体系はさらに洗練されていくはずです。私も微力ながら、その営みに貢献していければと思います。
技術の力で、ビジネスの信頼を勝ち得る。本章はそんなSREの新たな可能性を感じさせてくれる内容でした。エンジニアリングの高みを目指すと同時に、ビジネスの言葉を学び、組織への貢献を示し続けること。それがこれからのSREに求められる道なのだと感じています。
Chapter 14. The Dickerson Hierarchy of Reliability (A Good Place to Start)
信頼性向上の第一歩としての The Dickerson Hierarchy of Reliability
本章は、SREを導入したばかりの組織が、何から着手すべきかを示してくれる指針を示してくれる章でした。著者のDavid Blank-Edelman氏は、システムの信頼性を高めるための取り組みは山のようにあるものの、その中から成果の上がる一歩を見出すのは容易ではないと指摘します。 そこで、この難題に対する最良の答えとして紹介されているのが、Mikey Dickersonが提唱した「The Dickerson Hierarchy of Reliability」です。ちなみに公式にもサービス信頼性の階層があります。
この階層モデルは、信頼性向上に向けた取り組みを、monitoring/observability、incident response、postincident review、testing/release、provisioning/capacity planningの5つのレベルに分類しています。 そして、マズローの欲求段階説になぞらえて、下位のレベルから着実に積み上げていくことを推奨しているのです。シンプルながらも良いフレームワークだと感じました。
印象的だったのは、最も重要な基盤としてmonitoring/observabilityが位置づけられている点です。 システムの現状を可視化し、改善の方向性を定める上で、モニタリングは欠かせない基盤になります。加えて、チーム内での建設的な議論を促し、SLOの設定を支えるなど、モニタリングが果たす役割の広がりにも気づかされました。
また、著者がpostincident reviewを"transformative"かつ"magical"なプロセスだと称賛している点も印象的でした。 障害対応は、ともすれば時間と労力の無駄になりがちです。しかし、そこから学びを得て、システムを改善につなげられれば、むしろ価値を生み出せるのだと。レジリエンスエンジニアリングの知見を応用し、障害から学ぶ文化を組織に根付かせることの重要性を、改めて感じさせられました。
もちろん、この階層モデルは、SREの業務すべてを網羅しているわけではありません。著者自身、モデルの限界を認めつつ、アーキテクチャやtoil改善におけるSREの貢献にも言及しています。 ただ、SRE導入の初期段階では、まずはこの5つのレベルに注力し、確実な成果を積み重ねていくことが肝要なのだと感じました。
一方で、著者はSRE導入の過程で陥りがちな落とし穴についても警鐘を鳴らしています。 例えば、オンコール対応だけが仕事になり、「ページャーモンキー」と化してしまう。postincident reviewに偏重し、ソフトウェアライフサイクル全体への関与が疎かになる。crisisの対応に明け暮れ、smokejumperに成り下がる。SREがただの「エンジニア」とみなされ、開発チームに引き抜かれる。こうした兆候は、SREの価値を大きく毀損してしまうリスクを孕んでいます。
とはいえ、SRE導入の道のりが平坦ではないことは、私自身、身をもって実感しているところです。大切なのは、地道な改善の積み重ねを通じて、組織にSREの存在価値を示し続けること。 オンコールの引き受けから始まった関係が、pull requestを通じた開発への貢献へと深化していく。モニタリングの指標がチームの共通言語となり、障害が減っていく。そうした目に見えるインパクトを着実に生み出していくことが、SREの評価を高める近道になるのだと感じました。
全体を通して、体系立てて信頼性向上に取り組む上で、The Dickerson Hierarchy of Reliabilityが強力な羅針盤になり得ることを実感した章でした。 網羅的とは言えないまでも、スタートダッシュを切る上での重要な指針が凝縮されていると感じます。
SREの真骨頂は試行錯誤にあり
ただ、マニュアル通りにここまでやればOKというものでもないのがSREの面白さでもあります。 各組織のコンテキストに合わせて、創意工夫を重ねながら、hierarchy外の領域にもフロンティアを広げていく。その探究心こそが、SREたるゆえんなのかもしれません。
私自身、ここ数年、監視基盤の整備や、incident responseの体制づくりに注力してきました。今後は、そこで得た知見を開発プロセスにも反映させつつ、proactiveなケイパシティプランニングにも踏み出していきたいと考えています。その過程では、様々な試行錯誤を重ねることになるでしょう。ただ、その試行錯誤こそがSREの真骨頂だと信じています。 ピラミッドを一歩ずつ登りながら、いつの日か、その頂へと辿り着けるよう、これからも研鑽を積んでいきたいと思います。
著者が最後に投げかけてくれた「SREがうまくいっている兆候」も、私にとって大きな励みになりました。自分たちの存在が当たり前のように受け入れられ、モニタリングの指標が部門の共通言語になり、開発への貢献が目に見える形で認められる。そんな日が来るまで、地道に信頼性向上の階段を上っていきたいと思います。
The Dickerson Hierarchy of Reliabilityは、SREという旅路に不可欠な道標だと感じました。 ただ、その先に広がるのは、各組織が切り拓くオリジナルのロードです。ゴールのない旅だからこそ、一歩一歩を大切にしながら、信頼性というバトンを手渡していく。私もその輪の中で、自分なりの道を見出していけたらと思います。
Chapter 15. Fitting SRE into Your Organization
SREの導入には組織のカルチャーや構造とのフィット感が重要
本章は、SREを組織に導入する際の実践的な指針を提示してくれた章でした。SREの導入は、単なる技術的なプラクティスの適用にとどまらず、組織のカルチャーや構造とのフィット感を意識しながら、戦略的に進めていく必要があるのだと実感させられました。
特に印象に残ったのは、SREの導入に際して、いきなり専任チームを立ち上げるのではなく、まずはSREの考え方や手法を、日々の業務の中で部分的に試してみることを推奨している点です。 例えば、サービスのSLI/SLOを定義してみる、ポストモーテム分析のやり方を見直してみるなど、小さな一歩から始められます。そうした草の根の取り組みを通じて、SREのメリットを組織に示しつつ、本格的な導入への足がかりを作っていく。地に足のついた漸進的なアプローチだと感じました。
もちろん、環境次第では、いきなりSREチームが編成されたり、M&Aを通じてSREが編入されたりすることもあるでしょう。 そうした状況でも、SREの働き方を「実験」と位置づけ、仮説検証を重ねながら、最適解を模索していくマインドセットが大切だと述べられています。完璧なモデルなんてないのだから、試行錯誤を恐れずに、組織にフィットする形を追求していこうと。アジャイル的な考え方に通底するものを感じました。
また、SREの組織的な位置づけについても、良い議論がありました。 中央集権型、分散型、ハイブリッド型の3つのモデルが紹介され、それぞれの長所と短所が丁寧に分析されています。組織の規模や成熟度、過去の前例などを考慮しつつ、自社に合ったモデルを選ぶ必要があるのだと。ただ、どのモデルを選ぶにしても、開発チームとSREチームが協調的に連携し、継続的な改善を推進できる体制を築くことが肝要だと強調されていました。
そして、SREの真価は、組織内にフィードバック ループを張り巡らせ、回し続けることにあると著者は力説しています。 モニタリングや障害分析、カスタマーサポートのチケットなど、あらゆるデータをループの起点にできます。そこから学びを得て、システムを改善する。その改善が新たなデータを生み、さらなる学びにつながる。そんな好循環を生み出し、加速させていくことこそが、SREに期待される役割なのです。そのためには、データへのアクセス性を高め、部署間のコラボレーションを促し、改善業務をロードマップに組み込む努力も欠かせません。地道ながらも着実な一歩を重ねることで、徐々にフィードバックの文化が組織に根付いていくのだと感じました。
さらに、SREがシステム開発の初期段階から関与し、「ゴールデンパス」と呼ばれる信頼性の高い設計を織り込んでいくことの重要性も説かれていました。 開発チームと二人三脚で課題解決に当たれば、SREの存在価値を浸透させやすくなります。単に既存システムの問題を後追いするのではなく、要件定義の段階からSREの知見を活用する。それこそが、本来あるべきSREの姿なのかもしれません。
一方で、著者はSREの導入が軌道に乗っているかを測る「サインポスト」についても言及しています。 SREチームがゲートキーパー的な立場から脱却できているか。開発チームから自発的にSREの関与を求められるようになったか。ロードマップ策定にSREが参画できているか。リアクティブな仕事が減り、プロアクティブな改善が増えているか。そうした兆候は、SREが組織に根付きつつあることを示唆するバロメーターになるはずです。
全体を通して、SREの導入は単なるエンジニアリング手法の変更ではなく、組織文化そのものの変革だと実感させられました。 信頼性を重視する価値観、学習と改善を尊ぶ姿勢、部門の壁を越えた協働。そうしたマインドセットを組織の隅々にまで浸透させていく営みが、SREの真髄なのだと。
気を整え 拝み 祈り 構えて 突く
もちろん、それは一朝一夕で成し遂げられるものではありません。適切なモデル選択に始まり、土壌づくり、フィードバックループの確立、協調的な文化の醸成に至るまで、多岐にわたる課題にじっくりと向き合う必要があります。 技術的なスキルに加え、コミュニケーション力、調整力、課題発見力など、エンジニアリング以外の資質も問われるでしょう。
ただ、だからこそ、SREの可能性は無限に広がっていると感じています。従来の枠を越えて、開発とオペレーション、ビジネスとエンジニアリングの架け橋となる。変化を恐れず、失敗から学びながら、より高い信頼性を追求していく。DX時代のビジネスを支える屋台骨を作り上げていく。 それは、私たちソフトウェアエンジニアに託された、困難だけれどもやりがいに満ちたミッションではないでしょうか。
本章で提示された知見を道標に、自分なりのSREを模索する旅を続けていきたいと思います。技術とプロセスと文化が三位一体となった、真に強靭な組織を目指して。時には試行錯誤を重ねながらも、仲間やお客様とともに一歩ずつ前進していく所存です。
データに基づく意思決定の習慣を根付かせるSREの実践
SREの実践は、組織に新たな風を吹き込む触媒になるはずです。データに基づく意思決定の習慣、継続的な改善のサイクル、部門を越えた活発な議論。そうした文化が根付けば、システムの信頼性を高めるだけでなく、ビジネス全体の俊敏性と回復力を引き上げることができるでしょう。 外的な変化への適応力を武器に、競争を勝ち抜いていく。そんな強靭な組織をエンジニアリングの力で実現する。それこそが、DX時代におけるSREの使命だと感じています。
もちろん、そこに至る道のりは平坦ではありません。従来の仕事のやり方を変えることへの抵抗、部門間の壁、複雑に絡み合ったレガシーシステム。SREの導入を阻む要因は、組織に深く根を下ろしています。それでも、私たちには武器があります。 学習と適応の文化を組織に根付かせる力、データの言葉で説得する力、人と人をつなぎ共感を生む力。SREに不可欠なのは、技術的なスキルに留まらない、そうした総合的な力なのだと信じています。
この章を読み、改めてSREの意義と価値を再認識するとともに、その実現の難しさにも思いを馳せました。とはいえ、困難があるからこそ、そこに果敢に挑戦する意味があるのかもしれません。ソフトウェアエンジニアとして、ビジネスパーソンとして、時にはカウンセラーとして。 様々な顔を使い分けながら、組織にSREの種を蒔いていく。失敗を恐れず、仮説検証を重ねる。その積み重ねの先に、真に信頼性の高い組織と、自分自身の成長が待っているはずです。
それは、GoogleやFacebookの真似をすることでは決して達成できない、自分たちオリジナルのSREへの旅になるでしょう。一筋縄ではいかない難題にも、仲間と知恵を出し合いながら、前向きに取り組んでいきたい。組織への共感を武器に、技術の力でレガシーな体質を変革していく。 そんなSREの理想図を胸に、今日も私は一歩を踏み出します。
Chapter 16. SRE Organizational Evolutionary Stages
SREは組織全体のマインドセットと文化の変革を必要とする
本章は、SRE組織の成熟度モデルを提示することで、各組織がSREの導入と定着においてどの段階にあるのかを見定め、次のステップに進むための指針を示してくれる、良い章でした。SREは、単に技術的なプラクティスを導入すれば完成するものではありません。組織全体のマインドセットと文化を変革していく、息の長い取り組みだと改めて認識させられました。SRE ではないのですがCloud Native Computing Foundation（CNCF）も成熟度に関する「クラウドネイティブ成熟度モデル」のドキュメントをWebサイトで公開したり。Googleさん やサイバーエージェントさんがそれぞれ、公開していたりもします。
※登壇したりしてました speakerdeck.com
SRE組織の5段階の成熟度モデル
私が特に印象に残ったのは、著者が提示した SRE組織の5段階の成熟度モデル です。
- Stage 1: The Firefighter:消防士
- Stage 2: The Gatekeeper:ゲートキーパー
- Stage 3: The Advocate:提唱者
- Stage 4: The Partner:パートナー
- Stage 5: The Engineer:エンジニア
この分かりやすいフレームワークは、自組織のSREの取り組みを客観的に評価し、次のステージに進むための課題を明らかにする上で、強力なツールになるはずです。
Chapter 16 "SRE Organizational Evolutionary Stages"は、SRE組織の成熟度を5つのステージで捉えた、良いフレームワークを提示してくれました。著者のBenjamin Purgasonは、自身の経験から導き出したこのモデルを通じて、SRE組織が辿る進化の道筋を明らかにしています。
まず、ほとんどのチームが通過する ステージ1の「消防士」について、印象深い指摘がありました。 このフェーズでは、SREチームは日々発生する信頼性の問題に追われ、火消しに明け暮れます。重大な障害を食い止めるために、泥臭い努力を重ねる毎日。著者はこの状態からの脱却に、早くて数ヶ月、通常は数年かかると述べています。 つまり、SREチームの多くが不可避的に通る、苦難と忍耐の時期なのです。
ただし、その間もただ受け身になっているだけではいけません。著者は、火事の合間を縫って、システムの理解を深めたり、「自動消火システム」を整備したりすることの重要性を説いています。 例えば、オートスケーリングの導入、負荷分散の最適化、自動フェイルオーバーの仕組み作りなど。泥沼から這い上がるために、地道な改善を積み重ねる。そうした努力なくして、次のステージへの移行は望めないのです。
ステージ2の 「ゲートキーパー」における議論です。 ここでは、SREチームが変更管理の判定者や実行者となり、開発チームとの軋轢を生むリスクが指摘されています。プロダクションを守るためとはいえ、長期的に見れば、SREがゲートキーパーに留まるのは得策ではありません。開発者を不快にさせ、コラボレーションを阻害し、生産性を損なう。 そんな事態を招かないためにも、ゲートキーピングを自動化し、開発者と協調的な関係を築くことが肝要なのだと説かれていました。
ステージ3の 「提唱者」 における「インテリジェントなリスクを後押しするツールの構築」 という発想も印象的でした。ダッシュボードやスコアカードを通じて十分なコンテキストを提供することで、現場の全社員が賢明な意思決定を下せるようにする。管理統制に頼るのではなく、「文脈」を武器に、自律的な判断を促していく。そんなSREの在り方に、大いに共感を覚えました。
ステージ4の「パートナー」では、SREと開発者の関係が、真の協働へと昇華していきます。 単に役割分担するだけでなく、ロードマップや計画策定から一緒に取り組む。SREは信頼性に関わる共通基盤の構築に注力し、開発者はその恩恵に与りつつ、より高い信頼性を追求していく。そこには、対等なパートナーとしての関係性が育まれているのです。SREと開発者が心を一つにして、高い理想に向かって邁進する。そんな姿は、まさにSREのあるべき姿だと感じました。
ステージ5の「エンジニア」の段階になると、SREと開発者の区別はほぼ無くなります。 全てのエンジニアが、システムのライフサイクル全体を通して、信頼性向上に資する活動に自発的に取り組むようになる。もちろん、SREは信頼性に特化した責務を担い続けますが、開発者との間に高度な結束と協調が生まれているのです。理想の姿ではありますが、インセンティブと組織構造のアラインメントによって、現実にも起こり得る。そう信じさせてくれる、野心的なビジョンだと感じ入りました。
一方で、著者が述べているように、これらのステージは直線的なものではなく、行きつ戻りつするものだと肝に銘じる必要がありそうです。 火事は常に起こり得るし、ゲートキーピングの誘惑に駆られることもあるでしょう。重要なのは、理想のステージを意識しつつも、現実と折り合いをつけながら、地道にSREを根付かせていくこと。そのためには、各チームの置かれた状況に即して、適切なステージを見極める眼力も問われるはずです。
全体を通して、SREの組織的な浸透は一朝一夕で成し遂げられるものではなく、泥臭い試行錯誤の連続であることを実感させられました。 技術的なスキルに加え、対人関係力、変革マネジメント力など、エンジニアリング以外の資質も問われる。一筋縄ではいかない難題にも、課題を正面から見据え、仲間と知恵を出し合いながら、一つ一つ解決していく。そうした地道な営みの先に、SREが組織に真に根付いた姿が待っているのだと信じたいと思います。
私自身、まだ駆け出しのSREですが、このモデルを道標として、SREの理想形を模索していきたいと思います。消防活動に明け暮れる日々から脱却し、開発者との建設的な協働関係を築き、いつの日か高度な結束が生まれる段階へ。 そこに至るまでの道のりは決して平坦ではないでしょう。それでも、信頼性の大義を胸に、仲間とともに前を向いて歩んでいく所存です。
SREの真髄は組織文化の変革にある
本章のエッセンスは、「SREは単なる技術の問題ではなく、むしろ組織文化の問題である」という一点に集約されるのかもしれません。 信頼性を重視するマインドセット、学習と成長を称揚する雰囲気、自発的なコラボレーションを促す仕組み。そうした目に見えない基盤を地道に築くことなくして、真のSREは宿らない。だからこそ、私たちには技術者としてのスキルと並んで、文化の耕し手としてのセンスが求められているのだと。この辺は運用技術者組織の設計と運用 / Design and operation of operational engineer organizationやエンジニア組織論への招待を読むと良さそうなので記載しておく。
Chapter 17. Growing SRE in Your Org
SREの成長は「大きいほど良い」とは限らない
本章は、組織の中でSREをどのように成長させていくかについて、著者の豊富な経験と知見に基づいて解説した、良い章でした。SREは、単に技術的なプラクティスを導入すれば完成するものではありません。組織の規模や成熟度に応じて、戦略的に育てていく必要があるのだと改めて認識させられました。
印象に残ったのは、著者が 「SREの規模拡大は、必ずしも『大きいほど良い』とは限らない」 と警鐘を鳴らしている点です。SREチームの規模を際限なく大きくすることが目的化してしまうと、かえって非効率を招く恐れがあります。大切なのは、組織のコンテキストに即して、適切な規模と体制を追求していくこと。 そのためには、チームの分割や再編成を恐れず、フットワークの軽さを保つ柔軟性も求められるでしょう。
SREチームの規模感について、著者は具体的な数字を提示しています。SREが組織に導入された初期段階では、わずか1人から6人程度のチームで始めることが多いそうです。 この時期は、SREの考え方や手法を部分的に試すフェーズ。小さな成功体験を積み重ねながら、徐々に組織への浸透を図っていきます。モニタリングの改善、SLO/SLIの設定、ポストモーテム分析の実践など、できることから着手するのです。
SREの組織の規模による分類
チームの規模が6人から18人に拡大すると、オンコール体制の整備が本格化します。 健全なワークライフバランスを保ちつつ、24時間365日の監視を実現するには、最低でも18人は必要だと著者は指摘しています。この規模になると、役割の細分化も進み、メンバーそれぞれの専門性を活かした活動が可能になります。ただし、チームの一体感を保ち、ナレッジの共有を促進する工夫も欠かせません。
さらにチームが48人規模に拡大すると、SREはもはや1つのチームではなく、複数のチームから成る組織体となります。 ここからは、各チームの役割分担や連携の在り方が問われるフェーズ。サービス領域ごとの専門チーム、共通基盤の開発に特化したチーム、ツール整備に注力するチーム、現地に密着した分散型チーム。 組織のニーズに応じて、最適な体制を模索していく必要があります。同時に、SREの理念や価値観を浸透させ、統一感を保つための仕掛けづくりも欠かせません。
そして、SRE組織が100人を超える規模になると、専門性と融合のバランスを取るハイブリッド型の組織設計が求められると著者は説きます。 機能領域や技術領域ごとの深い専門性を追求しつつ、部門を越えた協調を促す枠組み。プロセス改善を担うSREチーム、全社的なプラットフォームを整備するSREチーム。多様性と統一性を両立する、柔軟な組織マネジメントが問われるフェーズだと言えるでしょう。
この先のさらなる成長ステージでは、SREがプラットフォームエンジニアリングの領域にも踏み込んでいくビジョンが示唆されていました。システムを支える基盤的なライブラリやフレームワークを自ら開発し、組織全体の開発力を底上げしていく。 そこまで至れば、SREは組織のエンジニアリング文化そのものを形作る存在になるはずです。もちろん、それは容易な道のりではありません。でも、その理想に向かって一歩ずつ前進していく。それこそが、志高きSREチームの使命なのかもしれません。
一方で、著者は 「SREは融合と結束の担い手でなければならない」 と強調しています。組織が大きくなればなるほど、分断と分散のリスクは高まります。技術選定の方針、プロセスの標準化、文化的な価値観。チームによってバラバラになってしまっては、SREの真価は発揮できません。だからこそ、differences（違い）は認めつつ、deindividualization（個性の喪失）は避ける。多様性を尊重しつつ、共通の目標に向かって結束する。そんな組織デザインのセンスが、SREリーダーには強く求められるのです。
さらに、著者は 「SREの技術的スケールだけでなく、リーダーシップの規模拡大にも目を向けるべき」 だと訴えかけています。トップマネジメントの意思決定の場に、SREの視点が適切に反映される体制を整えること。それは、SREの組織的な浸透を支える大前提だと。単に人数を増やすだけでなく、価値観を共有し、変革を牽引する存在として、力強くスケールしていく。 そんなSREリーダーの姿が思い描かれていました。
SREが組織の風土に合わせて多様な形で発展していく
本章を読み終えて、私はSREという職能の奥深さを改めて実感しました。技術的な側面だけでなく、組織デザイン、リーダーシップ、文化の醸成など、実に多様な顔を持ち合わせている。 だからこそ、SREのスケールは単線的なものではなく、状況に応じた柔軟な判断が求められるのだと。「組織の成長に合わせて、SREも共に進化していく」。そんな著者の言葉が強く印象に残りました。
もちろん、その道のりは平坦ではありません。SREの価値への理解不足、既存の体制への固執、変化への抵抗。スケールの障壁は数多く立ちはだかるでしょう。それでも、信念を持って粘り強く向き合っていく。泥臭い説得を重ね、地道な実績を積み上げ、仲間を巻き込みながら、少しずつ前に進んでいく。 私はそれこそが、志あるSREリーダーの真の姿なのだと感じています。
本章は、SREの組織的な拡がりについて、体系的な知見を提供してくれる、良い内容でした。単に数合わせでスケールするのではなく、組織のコンテキストを見極め、長期的な視点で育てていく。 技術と組織と文化をバランス良く強化し、全社的な変革を促していく。これからのSREリーダーには、そんな繊細かつ大胆なアプローチが求められているのだと実感させられました。
エンジニアの端くれとして、組織論や文化論に首を突っ込むのは、少し居心地の悪さを感じるかもしれません。でも、それこそがSREの醍醐味であり、やりがいなのだと信じています。技術の力で勝ち得た信頼を武器に、組織に新しい風を吹き込んでいく。 そいう姿勢を問われている気がしました。
Chapter 18. Conclusion
SREの本質はシステムの信頼性という崇高な目標にある
『Becoming SRE』の最終章である第18章「Conclusion」は、読者への感謝と別れの言葉から始まります。著者のDavid Blank-Edelman氏は、SREの本質をコンパクトに凝縮しつつ、読者を新たな旅立ちへと送り出そうとしています。その語り口は、まるで優しい師が弟子に最後の教えを授けるかのようです。
この章で改めて強調されているのは、SREが目指す「システムの信頼性」という崇高な目標です。それは、個人としても、組織としても、他者と協調しながら追求していくべき理想だと。特定のマインドセットと文化を共有し、周到な準備を重ねたSREたちが、組織の支援を得ながら、様々なスケールでその理想を実現していく。SREの真髄は、まさにそこにあるのだと著者は説いています。
SREは素晴らしくやりがいある仕事
そして、著者は 「SREの仕事はfun（楽しい）であり、rewarding（やりがいがある）」 と力説します。もちろん、常にそうとは限りません。難しい局面に直面することもあるでしょう。でも、総じて素晴らしい仕事だと。信頼性という難問に立ち向かい、仲間とともに現実に意味のあるインパクトを残せる。 そのチャレンジは、けして退屈ではあり得ないのだと。読者にSREへの情熱の一端でも伝われば幸いだと、著者の想いが伝わってきます。
おわりに
SREは技術を超え組織文化そのものを変革していく
『Becoming SRE』を読み終え、SREという職能の奥深さと広がりを新たに感じました。David Blank-Edelman氏は、SREが技術を超え、組織文化そのものを変革していく役割を果たすことを鮮明に描いています。本書を通じて、システムの信頼性を追求するミッション、必要なマインドセットとスキル、そしてその知見が組織内に浸透し定着するまでの過程が体系的かつ実践的に語られました。
SREの役割は単に技術的な問題を解決するだけではなく、信頼性という難題に直面し、それに対峙しながら仲間と共に粘り強く取り組むことにあります。これは、エンジニアリングの枠を超えた、大きなやりがいを提供します。
しかしながら、SREへの道は容易ではありません。個人と組織の両方で、多くの障壁に直面することがあります。本書は、フィードバックループの重要性、障害から学ぶ文化、コラボレーションの極意など、困難を乗り越えるための具体的な方法を提供しています。これらの知見は、SREとして成長するためのサポートとなるでしょう。
そして、SREの醍醐味とその意義を再確認することができました。著者が指摘するように、SREの究極の目的はシステムの信頼性を通じて人々に価値を提供することにあります。日々の挑戦と探求の精神が、SREの本質です。
SREsのためのSRE定着ガイドからの引用ではありますが外部リソースの注入は、SREの実践において選択肢の一つとして考えられます。重要なのは、前提として、自分たちでやりきれるならその方が良いということです。『Becoming SRE』の教訓にもあるように、SREは技術的な問題解決だけでなく、組織文化の改善やビジネス価値の向上を目指します。しかし、定点観測のような繰り返しの作業や、組織内変化の促進に際して、内部ではやりきれずに外部エキスパートの助言が必要となる場合もあります。例えば、nwiizoが所属している3-ShakeやX-Tech5、Topotal、などの外部のサービスや専門家を利用することは、新たな視点をもたらし、特定の課題に対して効果的な戦略を実施する支援を提供できます。しかし、これはプロジェクトや組織によっては、改善を目指す一つの方法であることを忘れずに。SREの目指すところは、あくまで内部の力で課題を乗り越え、成長することにあります。外部リソースの活用は、そのプロセスを補助する手段の一つとして考えるべきでしょう*1https://ja.wikipedia.org/wiki/%E5%BA%83%E5%91%8A。
SREの旅に終わりはない
最後に、SREの旅に終わりはありません。著者が贈るメッセージ、「大切なのは、その旅を楽しみ、学び続けること」を胸に、私たちも一歩一歩前進していきましょう。外部リソースの適切な活用は、その旅をより豊かで有意義なものにする一助となるでしょう。
今回の本の内容要約においては、「A. Letters To A Young SRE」「B. Advice From Former SREs」「C. SRE Resources」という付録の部分のはレビューの対象とはしていませんでした。これらの部分には、SREを志す若者への手紙、経験豊富なSREからのアドバイス、SREのための参考資料など、非常に興味深い内容が含まれています。ご紹介できなかったのは残念ですが、本書の中核をなす部分に注力するために割愛させていただきました。 もしこの先SREの道に進まれる際には、ぜひこれらの付録もじっくりと読まれることをおすすめします。きっと、SREとしての歩みを確かなものにしてくれるはずです。
この学びを糧に、今日も信頼性という難問に立ち向かっていきます。「Fun:楽しむ」と「Rewarding:やりがいのある」を胸に、SREの醍醐味を味わいつつ。最後になりましたが、素晴らしい書を生み出してくれた著者のDavid Blank-Edelman氏に、心からの感謝を捧げたいと思います。
みなさん、最後まで読んでくれて本当にありがとうございます。途中で挫折せずに付き合ってくれたことに感謝しています。
読者になってくれたら更に感謝です。Xまでフォロワーしてくれたら泣いているかもしれません。
*1:広告
