SREをはじめよう読書メモ

Posted at 2025-09-10

SREの概要と基本的な考え方

SREは、本番環境への適用を起点として考えるエンジニアリングのアプローチです。DevOpsが開発を起点に考えるのとは対照的です。SREは、機能そのものを見るのではなく、「システムが実際にどのように機能するか」を見ることを重視します。

例えば、データセンターで作業員がケーブルにつまずいて抜いてしまう。責任は誰にあるか。100台中14台のサーバーが停止しても問題になるかどうかは場合による、といった視点でシステムを「システムとして理解する」ことを目指します。

SREとしての第一歩は「内面的なもの」であり、脳が反射的にSREのような考え方をするようにすることです。これは、顧客の観点から信頼性を測定する状態を目指し、組織内にフィードバックループを作成することを含みます。

SREの文化を育むためには、以下の要素が重要とされます:

SREとしての進捗を確認するためのキーワードとして、以下のような問いかけがあります:

SREの提唱においては、人間はストーリーを受け取る機械としてできているため、ストーリーで説明することが効果的とされています。

SREになるためには、コーディングの知識が必要です。必要な基礎知識としては、単一/基本システム、分散システム、統計学の知識が挙げられます。ハインリッヒ・ハートマン氏（https://www.heinrichhartmann.com/）も参考として挙げられています。

SREの日常は、様々なモードで構成されます:

トイルとは、以下の特徴を持つ作業を指します:

SREは失敗から学習することを重視します。これには、インシデント後のレビューが含まれ、基本的な振り返り、プロセス、時系列での振り返り、リアルタイムでの見直しが行われます。また、カオスエンジニアリングを通じて失敗から学ぶことも挙げられています。

組織がSREを成功させるためには、複数の要因があります。

何を問題としているか: SREが対処できる可能性のある問題があるかどうか。
組織が何をするか:
- エンジニアリングに割く意思があるか。
- ロードマップに信頼性向上のための特別な作業を加える意思があるか。
- 必要なとき信頼性の問題に集中するために機能的な仕事から人を引き離すことができるか。
- サービスレベル目標が達成されなかった場合、新しいリリースを遅らせることができるか。
- インシデント後のレビューが場当たり的なものにならないように、積極的に取り組んでいるか。
- 彼らのオンコールスケジュールは仕事が持続できるような人道的なものか。
- SREは開発プロセスの早い段階で適切な会議に参加しているか。
- SREはソースコードリポジトリのようなリソースに直接アクセスでき、信頼性向上のための変更を行えるか。
組織には必要な忍耐力があるか。
共同作業できるか。
データに基づいて意思決定を行っているか。
組織は学び、学んだことについて行動できるか。
違いを生み出せるか。
システム内の摩擦を見ることができるか。

一方で、組織がSREを導入する際に失敗する要因も存在します:

ディッカーソンの信頼性の階層構造は、SREを始めるための良い出発点とされています。その構造は以下の通りです:
監視 > インシデントレスポンス > インシデント後のレビュー > テスト/リリース > キャパシティ/スケール > 開発 > UX

SREを組織に取り込むためのモデルには、いくつかの種類があります:

最後に、システムがどのように機能するのだろう。好奇心から始めることがSREの出発点であると示唆されています。