『SREをはじめよう』の忘れたくないポイントまとめ

はじめに

『SREをはじめよう―個人と組織による信頼性獲得への第一歩』 を読んで、個人的に忘れたくないなって思ったポイントを書き残そうと思い、本記事を執筆しました。
何か間違った認識があれば、ご教示いただけると幸いです。

https://www.oreilly.co.jp/books/9784814400904/

Webシステムの信頼性は、いまや企業と組織の信頼性にも大きな影響を及ぼしています。そのシステムの信頼性を確保するのがSRE、つまり「サイトリライアビリティエンジニア」と呼ばれる職種、あるいは「サイトリライアビリティエンジニアリング」という技能、活動です。
本書は、自身もSRE/DevOps/システム管理の分野で40年のキャリアを持つ筆者による、個人がSREになるための、また組織がSREを導入し、発展させるための指針を平易かつコンパクトにまとめた書籍です。
「SREとはどのようなものか」「SREになるには何をすればよいのか」「SREを導入するにはどのように始めればいいのか」「するべきこと、避けるべきこと」といった、SREにまつわるさまざまなトピックを幅広く解説します。
SREという技能/概念をゼロから学びたい人、SREを目指すエンジニア、またSREを組織に導入することを検討している、導入したけれど思ったより上手く行っていない組織や企業にとって、多くの発見のある書籍となるでしょう。

SREとは何か（１章）

本書には以下と示されていました。

サイトリライアビリティエンジニアリングは、組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野である。

特に重要なキーワードは、「信頼性」「適切」「持続的」で以下を意識する必要があります。

• やみくもに100%の信頼性を目指すのではなく、適切な信頼性レベルを定義しそれに向けて努力すること。
• 持続可能でなければならないこと。（組織の人々が燃え尽き、疲弊してしまっていては信頼できるシステムは構築できない）

プロダクトチームと議論を重ねて適切なSLI/SLOを設定し、それをいかに疲弊せずに継続して守り続けられるかを考えないといけない、と個人的に解釈しました。

また、本書では「SREに対する理解」を深めるために以下スライドについて紹介しています。

What makes SRE, SRE?

Simple:

• Hire only coders（コードを書く人のみ採用する）
• Have an SLA for your service（サービスにSLAを設定する）
• Measure and report performance against SLA（SLAに対するパフォーマンスを計測し報告する）
• Use Error Budgets and gate launches on them（エラーバジェットを用いてリリースの制御をする）
• Common staffing pool for SRE and DEV（SREと開発チームで共同の人材プールを持つ）
• Excess Ops work overflows to DEV team（余計な運用作業は開発チームにオーバーフローさせる）
• Cap SRE operational load at 50%（SREの運用作業を全体の50%に制限する）
• Share 5% of ops work with DEV team（運用作業の5%を開発チームと共有する）
• Oncall teams at least 8 people, or 6×2（オンコールチームは最低8人、もしくは6人✖️2チーム）
• Maximum of 2 events per oncall shift（オンコールシフト中は最大でも障害2つまで対応）
• Post mortem for every event（各障害にはポストモーテムを書く）
• Post mortems are blameless and focus on process and technology, not people（ポストモーテムは非難のないものとし、人ではなくプロセスや技術に焦点を当てること）

完璧に上記を満たすことは難しそうですが、必要なものを取り入れる努力をしようと思いました。

SREの心構え（２章）

SREとして活動する上で忘れてはいけない考え方についての記述がありましたので、いくつかピックアップします。
※一部意訳して単語を変えています。

• 顧客目線で考える。システム目線のモニタリングでは障害時の影響がわかりにくいため、顧客目線のモニタリングが最重要。
• 失敗やエラーは敵ではなく学ぶ機会。システムがどのように機能し、どのように失敗するのか、を考えて知れるチャンス。
• SREはあくなき共同作業。開発チームやビジネスチームと協力しなければ仕事は成り立たない。
• 信頼性はフィードバックループを通じて改善される。SREをそのループを作って育てる役割。

SREの提唱（４章）

自分の成し遂げたいストーリーや経験してきたストーリーを語れるようにしておく

「組織内にSREの文化を取り入れたい時」や「SREチームに採用してもらいたい時」などに語れるようにストーリーを言語化してメモしておく必要があると感じました。

他の人のストーリーをたくさん見る/聞く

普段から技術ブログを読んだりカンファレンスに参加したりすることで、自分にはなかった発想を取り入れることを大事にしたいと思いました。

SREになるために必要なもの（5章）

• コーディングの知識（信頼性を高めるにはソフトウェアの中身を知ることは必要不可欠）
• CSの知識（OS、NW、パーミッション、プロトコル、、）
• 分散システムの知識（マイクロサービス、フォールトトレランス、プライマリ/セカンダリ）
• 統計学（データの集計、可視化）
• 説明力（インシデント後のレビューやポストモーテム作成時に同僚や上司に正確に伝える）
• おまけ
  • 非抽象的な大規模システム設計（NALSD）
  • レジリエンス工学
  • カオスエンジニアリングと性能工学
  • MLとAI

ただの運用担当からSREになるための意識改革（6章）

アンチパターン

肩書きのフリップ

ミッションや目標を変更せずに、ただ役職やチーム名をSREやSREチームに変える。

考え方の転換

• 「あらゆるものを監視する」→「コンポーネントの観点ではなく、顧客の観点から信頼性を測定する」
• 「24時間365日すべてを稼働させる」→「適切なレベルの信頼性」
• 「トランザクション的なシステム管理」→「組織内のフィードバックループを育成する」

SREの成功要因（11章）

※意訳して少し理解しやすいようにしました。

1. SREが解決すべき課題が見つけられており、解決に向けてアクションを起こせている
2. 成果が出るまで時間がかかるが、それまで待つ準備ができている
3. 開発チームやビジネス関係者と共同作業できるくらいの関係性が気づけている
4. 信頼性に関するデータ（SLOや監視データ）に基づいて意思決定を行えているか
5. インシデントから学び、学んだことに基づいて行動できているか（そのプロセスが建て付いているか）
6. インフラやコード、ドキュメント等を修正する権限を持っているか

ただし注意点として、ここに記載してある項目がすべての組織にとっての正解とは限らない点です。自身で考えた上で取捨選択が必要なことは意識する必要があります。

Dickersonの信頼性の階層構造（14章）

特に意識したい点としては、「監視/オブザーバビリティ」がすべての根底にあるという点です。
監視はシステムの信頼性に関する客観的なデータとなり、行った変更がシステムの信頼性にどう影響を与えているのかやどう改善していくべきなのかを判断するために必要です。
ここは特に意識したいと思いました。

さいごに

こんなすばらしい本を書いてくださった筆者や翻訳者に感謝です！