「SREをはじめよう」を読んで世界が変わった話
🌟 はじめに
本記事は CyberAgent Group SRE Advent Calendar 2024 の13日目 の記事になります。
本記事では SWE（Software Engineer）である私が 『SREをはじめよう―個人と組織による信頼性獲得への第一歩』 を読んで、SREについての理解を深めた経験を共有します。エンジニア・非エンジニア・社会人・学生など、さまざまなバックグラウンドを持つ方にとって「必ずどこか心に刺さる部分があるのではないか...！」と思い、是非皆さんにも読んで頂きたいというという思いを込めて執筆しました。
私は普段、SWE として働いていますが、以前から SRE に強い興味を抱いていました。
今年は SRE Next 2024 に足を運び実際に SRE の方々とお話しする機会を得たり、Cloud Native Days Winter 2024 の資料を拝見したりする中で、「もっと SRE のことを知りたい」 という気持ちが強くなりました。
そんな中で 『Becoming SRE: First Steps Toward Reliability for You and Your Organization』の日本語訳である『SREをはじめよう―個人と組織による信頼性獲得への第一歩』が出版されました。
書籍の前書きには下記のような記載があります。
SREという技能/概念をゼロから学びたい人、SREを目指すエンジニア、またSREを組織に導入することを検討している、導入したけれど思ったより上手く行っていない組織や企業にとって、多くの発見のある書籍となるでしょう。
本書は私を含めた以下のような方にもぴったりな内容だと感じ、真剣に拝読させていただきました。
- 正直 SRE についてあまりよく分かっていない
- SWE だけど SRE に興味を持ち始めた
そして、読了後に以下の観点で考えたことをピックアップし、まとめています。
- 重要だと思ったこと
- 今の自分はどうだろう？と考えたこと
- 今すぐに実践できると思ったこと
特に、これらの観点の中で自分に響いた点を中心に取り上げてまとめました。
※ 実際には、40〜50個程度の付箋を貼り付け（重複もあります）、重要だと思うポイントをじっくり噛み締めながら読み進めました。
※ 🟨：重要だと思ったこと
※ 🟦：今の自分はどうだろう？と考えたこと
※ 🟪：今すぐに実践できると思ったこと
その中で、何が大切であるかは、皆さんの状況や環境によって異なると思います。
ですので、実際に書籍を手に取って読んでみることを強くお勧めさせていただきます。
📖 対象読者
- 正直 SRE についてあまりよく分かっていない方
- SWE だけど SRE に興味を持ち始めた方
- 『SREをはじめよう―個人と組織による信頼性獲得への第一歩』を読みたいと思っている方
🌟 重要だと思ったこと 5選
SREについて理解を深める中で、特に心に残った点や実践に活かせると感じたことを5つピックアップしました。これらのポイントは、書籍を通して得られた学びや気づきを基にしています。それぞれの内容が、日々のエンジニアリングや組織との連携において重要な視点を提供してくれるものです。
SRE の起源
これは 第1章「はじめに」で語られています。
ここでは『SREを始めよう』の著者である David N. Blank-Edelman氏が「SREに対する理解」を深めるためのスライドについて紹介しています。
What makes SRE, SRE?
Simple:
- Hire only coders
- Have an SLA for your service
- Measure and report performance against SLA
- Use Error Budgets and gate launches on them
- Common staffing pool for SRE and DEV
- Excess Ops work overflows to DEV team
- Cap SRE operational load at 50%
- Share 5% of ops work with DEV team
- Oncall teams at least 8 people, or 6×2
- Maximum of 2 events per oncall shift
- Post mortem for every event
- Post mortems are blameless and focus on process and technology, not people
※ 下記の講演より引用させていただきます。
※ 動画の 5:26 部分から説明があります。
※ 書籍には日本語での説明もあるのでそちらも是非参照してください。
各指標には、雇用、エラーバジェット、SLA、計測、オンコール、ポストモーテム、等 SRE に深く関係する項目に対する考え方や指標が掲載されています。
最初にこのスライドを見たときの感想は「んー...そうなのか」でしたが、『SREをはじめよう』を読み終えた後に再度このスライドを見たときの感想は、「理解できる点もあるし、まだ分からない点もあるな」というものでした。
これは、おそらく人や状況によって考え方が変わるということだと思います。
ただ、確実に言えるのは、これから自分がエンジニアリングを進めていく中で、このスライドに対する理解がさらに深まる だろうということです。そして、このスライドが、その時の 自分の考えをぶつける壁として立ってくれる存在 になると感じています。
これは、多くの人にも当てはまるのではないかと思います。私自身、このスライドを要所で振り返りたいと思ったため、非常に重要なスライドだと感じました。
失敗やエラーは敵ではないという考え
これは 第2章「SREの心構え」で語られています。
エンジニアとして仕事をしていると、広く失敗やエラーに誰もが遭遇するものだと思います。「失敗してはいけない」と感じたり、「エラーが起こらないようにしなくては」と考えたりした経験は、誰にでもあるのではないでしょうか。
本章では、「エラーは必ずしも敵ではない」という心構えを持つことが重要であると記されています。さらに、システムがどのように機能し、どのように失敗するのか を考え続けることが大切であることも学びました。
自分の管理しているシステムが、何となく動いているだけかもしれないという可能性を、完全には排除できないと改めて感じました。この章を通じて、失敗やエラーはそれらを顕在化してくれる重要な要素であり、エラーが発生したときこそ、何となくという曖昧さを解消する絶好のチャンスだと捉え、全力で取り組むべきだと強く感じました。
非難すべきは人ではないと言う話
これは 第10章「失敗から学習する」や 第16章「SRE組織の進化段階」で紹介されています。
先ほど触れた「失敗やエラーは敵ではない」という考え方と近い部分があるかもしれません。ここでは、インシデント後のレビューやゲートキーパーの存在について、人を非難してしまう可能性への警告が記されています。
まず、インシデント後のレビューについては、ミスをした人が恥をかいたり責められたりするようなプロセスが存在するかもしれません。しかし、そうではなく、失敗した人を称え、その失敗から何を学んだかをチーム全体で共有し、他のメンバーがその経験から利益を得られるようにするべきです。
次に、ゲートキーパーに関する話では、ゲートキーピングを行う人が非難されることがあるかもしれません。しかし、そうではなく、ゲートを通れなくなった原因を特定し、その問題を解決することに集中すべきです。
このように、人を（意図せずに）非難してしまいそうになるケースは、至る所に存在するように思います。そのような場面では、「本当に非難すべき対象は何か」「他にやるべきことは何か」を常に考えるマインドセットを持ち続けたいと感じました。
SREとビジネスの話
これは 第13章「ビジネス視点からのSRE」で語られています。
この章では、プロダクトマネージャーや財務担当者といったビジネスに関わる方々との連携について述べられています。その中で、ビジネスに関わる方との関わり方で、特に重要だと感じた点がありました。
本書では、SREが彼らと関わる際の役割について、「彼らが望んでいることを実現するためにどのような条件が必要かを伝えること」と記されています。そして、このとき、話している相手が「本当に気にしている観点で数値化する必要がある」ということを学びました。
これを読んだとき、私は自分が関わっているビジネスチームのメンバーを想像しました。彼らがプロダクトの存続に必要だと考えていることは何かを改めて考えました。ちょうど大規模な負荷試験を終え、その結果をチーム全体に共有する機会があったので、「ビジネスに関わる方が何を気にしているのか」「その気にしていることに対して結果はどうだったのか」「その結果にどういう条件で満足できるのか」「プロダクトがスケールして満足できなくなった場合に何が必要か」といったポイントをすり合わせることができました。これにより、何が重要かについての認識をチーム全体で共有することができ、個人的にも、またチーム全体にも良い影響を与えたと感じています。
本書全体を通じて「SREはあくなき共同作業」という言葉が頻繁に登場します。
※ ちなみに、第8章「SREのある一日」でも大きく取り上げられており、ここもぜひ紹介したい内容でした...！
今後も、私はビジネスに関わる方々とあくなき共同作業を続けていきたいと強く感じました。
SRE にとってのメトリクスの話
これは 第14章「Dickerson の信頼性の階層構造（良い出発点）」で語られています。
この章では、「Dickerson の信頼性の階層構造」を用いて、各階層についての解説が記されています。その中でも、「階層1：監視/オブザーバビリティ」が特に重要だと感じました。
この部分では「鏡」という節があり、監視システムが組織の鏡の役割を果たすという点が述べられています。具体的には、何が監視されているのか、その情報がどのように扱われているのかが、組織の在り方を大きく表しているという考え方です。この点には非常に共感しました。
また、第8章「SREのある一日」でも関連する話題が登場します。SREはどのように顧客の声に耳を傾けるのでしょうか。それは「監視業務を通じて」という形で行われています。適切に監視の仕組みを構築することは、強力な情報源を得ることであり、この考え方にも強く共感しました。
これらを踏まえ「メトリクスの乱れはサービスの乱れである」という言葉を肝に銘じ、今後も継続的に監視の力を高めていきたいと感じました。
🤔 今の自分はどうだろう？と考えたこと 5選
SREに関する書籍を読み進める中で、自分の現状やこれまでの経験を振り返りながら考えたことを5つにまとめました。それぞれのポイントは、これまでの私自身の経験や、今後どのように成長していきたいかを見つめ直すきっかけにもなりました。
これを通して、現状の課題や目指すべき方向性が明確になり、さらにSREとしての成長に対する意欲が高まりました。
自分にはどんなストーリーがあるのか
これは 第4章「SREについて語る（SREの提唱）」で語られています。
SREを組織に導入したい場合、あるいはSRE組織に所属したい場合、「SREについて語る力」が重要になると感じました。
前者の場合は「SREとは何か、どのようなことをするのかを説明できる力」、後者の場合は「SREとして何を意識し、どのようなことを行ってきたかを説明できる力」が求められるのではないかと思います。
では、自分自身がそれを語れるかどうかを考えたとき、「そもそも自分はどんな経験をしてきただろうか？」「その経験をしたときにどのような立ち回りができただろうか？」「その動き方を（SRE的な用語として）言語化できているだろうか？」といった疑問が浮かびました。
私自身、社会人として約3年間の経験の中で、いくつかのインシデントやポストモーテムに関わってきましたが、そのたびに考えさせられることが多くありました。
皆さんはどのような経験をお持ちでしょうか？ぜひ教えていただけると、私自身も大変参考になり嬉しく思います。
採用時の逆質問に自分は答えることができるか
これは 第7章「SREとして採用されるためのヒント」で語られています。
この章では「SREの面接で何を聞くか」について以下のような質問が記載されています。
- 監視システムに対する質問
- インシデント後のレビュープロセスに関する質問
- SREの存在価値に関する質問
これらの項目に加え、さらに詳しい質問内容も書かれています。
※詳細は書籍をご参照ください
ここで私が考えたのは「今所属しているチームでこれらの質問に適切に答えられるか？」という点です。いくつかは答えられそうですが、一部は難しいと感じ、危機感を覚えつつも、ワクワクする気持ちにもなりました。
これらの質問に即座に答えられる人は、日頃からこれらの項目に対して細心の注意を払っている方なのでしょう。一方で、自分が答えられない部分については、まだ細心の注意を払えていなかったり、経験が浅かったりする部分だと気づきました。これに気づいたことで、自分の成長の可能性が見え、ワクワクする気持ちが生まれました。
さらに、これをきっかけにチーム内での共通認識の重要性を改めて実感しました。この章を読んだ翌日、さっそくチームの開発責任者に共有し、後日、チーム全体で認識のすり合わせを行う予定です。このミーティングが、私たちの結束をさらに強めてくれると考えると、ここにもワクワクしています。
皆さん自身や皆さんのプロダクトはいかがでしょうか。もしかしたら、同じようにチーム内ですり合わせを行うことが、有益な気づきを生むかもしれません...！
ある種の人格とはなんだろうか
これは 第10章「失敗から学習する」のコラムで紹介されています。
このコラムでは、「ファシリテーターとしてのSRE」について言及されています。エンジニアとして活動する中で、ポストモーテムやインシデントレビューの場でファシリテーションを担う人の存在は必須だと思います。そして、そのファシリテーションを行うことがSREの重要な役割の一つである、と記されています。
その際、ファシリテーターには「強い人間力」と「SREの心構え」の組み合わせが必要であると述べられています。どちらも何となく理解はできるものの、特に「強い人間力」について、「具体的には何を指すのだろう...」と考えさせられました。
私自身、一つの答えとして「チームメンバーの特性を理解し、その長所を引き出せる力」ではないかと考えています。過去に20〜30人のエンジニアと共に開発を行った経験の中で、人によって長所は本当に様々であると感じました。
- 経験値が豊富で、どんな問いに対しても自分なりの正解を持っている方
- 好奇心旺盛で、話を発散させていくことが得意な方
- 低姿勢で接し、同調する力に長けていて、周りが意見をぶつけやすい雰囲気を作れる方
- 基本的にフラットな姿勢でいて、人に影響されずに意見を言ってくれる方
- 問題解決に長けており、今必要なことや正しさを優先できる方
- 場の雰囲気を察する力に優れ、どんなときでも和ませてくれる方
これらのように、チームメンバーの特性は千差万別です。また、同じチームにこれらすべての特性を持つ人が集まることは無いと思います。そのため、私自身はその時々のメンバーに合わせて、「この場面では、この人の意見をぜひ聞きたい」と思い、話を振ることが多いです（もちろん、これが必ずしも最適に作用するとは限りませんが…）。
これらの経験から、必要なときに必要な力を引き出して議論を促進できる力、そしてそのためのメンバー理解やコミュニケーションが「強い人間力」の重要な要素なのかも知れないと想像しました。
皆さんは「強い人間力」や「SREの心構え」についてどうお考えでしょうか？ぜひご意見を教えていただけると、私自身も大変嬉しく思います。
丸暗記ではダメだという話
これは 第12章「SREはいかにして失敗するのか」で語られています。
この章では、タイトルの通り「SREの失敗」について書かれています。その中でも、特に「丸暗記によるSRE」についての注意点が印象的でした。
私自身、SREに関する書籍を読み、感動し、その内容を周りに普及し、プラクティスを実践したいと考えている立場です。しかし、書籍に書かれていることをそのまま実践するだけでは、十分ではないと感じています。
冒頭にも書いた通り、自分自身の価値観や環境、状況は人それぞれ異なるものです。そのため、自分に合ったプラクティスを選び、実践することが最初の一歩であると考えています。
また、先に触れた「自分にはどんなストーリーがあるのか」や後に出てくる「他の人のストーリーを溜めておく」というアプローチを、自分の引き出しとして蓄えていくことも大切だと感じました。それを基に「今の自分に最適なプラクティスは何か」を常に考えることが重要だと思います。
皆さんは今どのフェーズにいて、どのような（固有の？）アプローチで動いているのでしょうか？そんなお話をお聞きして、私自身も学びを深めたいと思っています。
ローテーション制度が普及してほしいという話
これは 第11章「成功のための組織的要因」と 第15章「SREを組織に組み込む」で語られています。
この章では、開発メンバーがSREの組織で働いたり、SREメンバーが他の部署で働いたりする期間を設ける「ローテーション制度」について述べられています。
また、このローテーション制度を「SWEとSREが『相手の靴を履いて1マイル歩く』ことを可能にする時間枠（1ヶ月、3ヶ月、6ヶ月）」と定義している点が印象的でした。
私はこの制度にとても魅力を感じ、「ぜひ体験してみたい」と強く願っています。現在の私のフェーズ（あるいは趣向）としては、特定の言語やクラウドプロバイダ、チーム規模、ドメインにとらわれず、多様な経験を積みたいと思っています。今所属しているチームには全く不満はありませんが、他のチームの優れた点や改善点を吸収し、"個人として成長" し、自分が元いた）"チームとしての成長" に繋げる幅を広げたいと願っています。こうした思いを抱いたことがある方は、きっと多いのではないでしょうか。
もちろん、組織が大きくなるほど、ローテーション制度の実現には多くの課題が伴います。受け入れ側の理解と体制、事業に対するオーナーシップ、成果の評価方法など、さまざまな難しさがあるでしょう。しかし、長期的に "個人として強い" 人材が楽しんで活躍し続けられる組織は、何らかの形でこうした課題をクリアしているのではないかと感じます。
皆さんの組織では、ローテーション制度や類似の取り組みはどのように行われているでしょうか？成功体験や失敗体験など、ぜひお話を伺えると嬉しいです。
🔥 今すぐに実践できると思ったこと 5選
SREに関する知識や考え方を実際の業務や日常にどう活かせるか。ここでは、書籍の中から「すぐに取り組むことができる」と感じたアイデアを5つ選びました。これらは、個人のスキル向上やチームの成長に繋がるだけでなく、SREとしてのマインドセットを養うための第一歩となるものばかりです。
他の人のストーリーを溜めておく
これは 第4章「SREについて語る（SREの提唱）」で語られています。
「自分にはどんなストーリーがあるのか」の部分でも触れましたが、SREについて語る力を身につけることは非常に重要です。そして、自分自身の経験を言語化しておくことが、その一助になると感じています。
その際に役立つのが、他の人の経験やストーリーを知ることです。他の人の話を聞くことで、「ああ、自分も似たような経験をしたな...」「その視点は初めて知った...！」「そんな動き方ができるのか...！」といった気づきや発見があります。それによって、自分自身を振り返り、新しい学びを得る機会が生まれるのです。
これらの経験を蓄積し、自分の引き出しを増やしておくことはとても大切だと考えます。その引き出しを使う日が来ないことを願いつつも、もしその時が来たら、それを最大限に活用し、状況を楽しめる自分でありたいと思っています。これらの経験を新たな「武器」として貯めていきたいと強く思います。
別のSRE本・その他資料を読む
これは書籍の全体で語られています。
「SREをはじめよう」を読んだことで、更に別の書籍を読みたいという気持ちが強くなってきてます。
特に読みたいなと思った書籍や資料を紹介します。
1. 「SREの探求」
これは 第6章「...からSREになる」で紹介されています。
ここでは「SREを対象とした良いドキュメント」について何が「良い」かが問われていました。
私自身、現状では「何が良いのだろう...」という形で終わってしまっていますが、その解説が「SREの探求」では記載されているようであるため、読みたいなと思いました。
2. 「サイトリライアビリティワークブック」
これは 第7章「SREとして採用されるためのヒント」で紹介されています。
ここでは「NALSD（非抽象的な大規模なシステム設計）」について紹介されていました。
もし SRE 職として活動することになる場合 Google が名付けた NALSD という分野の知識を付けておくことに越したことは無いようです。私自身この分野の知識はないため、勉強したいなと思いました。
3. 「SRE サイトリライアビリティエンジニアリング」
これは 第9章「トイルとの関係性を築く」で紹介されています。
「SREを始めよう」では、他のSRE本とは違い「トイル」との関わり方が記載されているようでした。
その文章への理解を更に深めるためには「トイル」に対する理解や頻繁に議論されている点について理解しておく必要があるようです。これらに対する良書として「SRE サイトリライアビリティエンジニアリング」が紹介されていたため、こちらの書籍も読んでみたいなと思いました。
※ また「サイトリライアビリティワークブック」も同じ文脈で取り上げられていました。
4. 「Care and Feeding of SRE」
これは 第11章「成功のための組織的要因」で紹介されています。
2017年の SREcon EMEA で語られたこの講演は、「SREを始めよう」の著者である David N. Blank-Edelman氏 が「SREと組織の適合について考える上で形成的なものになった」講演だったようです。正直私が書籍を読んでいて、一番付箋を貼れなかったのが 11章でもあります。自分が理解を深めることが出来なかったという悔しさもあるという意味で、この講演を見てみたいと思いました。
ヒューマンエラーはチームの問題かもと言う話
これは 第10章「失敗から学習する」で紹介されています。
この章では、「インシデントレビューの際の罠」について、いくつかのアンチパターンが紹介されています。その中で、特に「ヒューマンエラー」への言及が印象的でした。
具体的には、インシデントの原因としてヒューマンエラーを単に挙げるだけではなく、その背景にある問題を掘り下げることの重要性が語られています。ヒューマンエラーは個人の問題として片付けるのではなく、チーム全体の問題として捉える視点が求められるのです。
もちろん、ヒューマンエラーが発生することは避けられない場面もありますし、私自身もこれまでにヒューマンエラーを犯したことが無いとは言えません。そのため、仮にヒューマンエラーが起きた際には、「どうすればもっと良くなるか」を考えるべきだと、この章は教えてくれます。
この考え方に私は大いに感銘を受け、さまざまな改善の余地があると感じました。たとえば、新しいメンバーがチームに加わった際にヒューマンエラーを犯した場合、以下のような観点から振り返ることができるのではないでしょうか。
- 分からなかったことがあったのではないか
- 判断に迷った点はどこだったのか
- 不明点があった場合、周囲に相談しやすい環境だったか
これらの視点に立てば、エラーを個人の責任ではなく、チームとして改善すべき課題として捉えることができます。
「失敗やエラーは敵ではない」や「非難すべきは人ではないと言う話」の部分でも記載しましたが、今回も何が本質であるかを考えることの重要性を改めて感じました。ここから得られる学びを大切にし、成長の糧にしていきたいと思います。
チームで困難を乗り越える
これは 第13章「ビジネス視点からのSRE」と 第3章「SREの文化」からインスピレーションを受けた話になります。
第13章では、「SREグループの成功を他者に証明する」というテーマが語られています。その中で、ある程度成熟したSREチーム向けに、「以前発生した障害」と「その障害を防ぐ、もしくは影響を小さくするために行った変更」を保存するプラクティスが紹介されています。
私自身、「これは成熟したSREチームでなくても取り入れられるのではないか？」と考えました。インシデントへの対応そのものも重要ですが、インシデントが発生しづらくなっている、または対応時間が短縮されているといった点も、チームの成果として評価されるべきだと思います。こうした成果をビジネス陣に共有することで、チームの成長や強化を証明することができるのではないでしょうか。
一方、第3章では、「SREを支援する文化をどう作るか」という話が記されています。特に、「小さな成功を手に入れた際には、経営陣や組織内の他の人たちに大いに喜んで報告する」ことの重要性が述べられていました。
誰しも、褒められたり、賞賛されたりすることは嬉しいものです。私も、チームの取り組みや成果を賞賛し合う文化を作りたいと強く感じました。それは、チームとして成功を共有し、喜びを分かち合う文化を育むことにつながると信じています。
SWE としての基礎を大切にする
これは 第7章「SREとして採用されるためのヒント」や 付録「若きSREへの手紙」で紹介されています。
ここでは、SREやSWEに関係なく、コンピューティングの基礎力がいかに重要であるかが述べられています。特定のプログラミング言語やOSの知識、ネットワークの知識、システム設計やデバッグ力など、汎用的な知識や経験は業務を遂行する上で必ず必要となる、という内容が記載されています。
私自身、現在の業務だけでなく、特定の言語やクラウドプロバイダにとらわれない汎用的な知識を身につけていくことの重要性を改めて感じました。また、書籍や動画で学ぶだけでなく、実際にアプリを作ったり、自宅サーバーを運用したりと、遊びを通じて実践的な知識を吸収していくことも大切だと思います。
「千里の道も一歩から」基礎力を養うことは時間のかかる取り組みですが、今後も継続して学び続けていきたいと考えています。
🎄 最後に
いかがだったでしょうか。今回は "SREをはじめよう―個人と組織による信頼性獲得への第一歩" を読んで、下記の 3つの項目に対してまとめてみました。
- 重要だと思ったこと
- 今の自分はどうだろう？と考えたこと
- 今すぐに実践できると思ったこと
冒頭にも述べた通り、この内容は人それぞれ感じ方が異なると思います。「分かる分かる...！」と思われる方もいれば、「どういうことだろう...?」「もっとこうしたら良さそう！」と感じる方もいらっしゃるでしょう。
少なくとも、私にとってこの記事を書いた経験は、SRE領域に興味や関心を持つ方々と会話するための準備になったと実感しています。これは大きな成長の一歩だと感じています。
『SREをはじめよう―個人と組織による信頼性獲得への第一歩』 には、今回ご紹介した以外にも多くの素晴らしい内容が詰まっています。中には、私がまだ十分に理解しきれなかった（特に第16章、第17章の組織関連の部分など...）トピックもありますが、それもまた学びの余地として楽しんでいます。
この記事をきっかけに、書籍を手に取ってみたいと思う方が一人でも増えれば幸いです！
最後に、『SREをはじめよう―個人と組織による信頼性獲得への第一歩』 の出版に携わったすべての皆様、書籍の引用に関して丁寧に対応してくださったO'Reillyの皆様、そしてその皆様を支えている方々に心より感謝申し上げます。
それでは、良い SRE ライフを！
Discussion