
【ブックレビュー】SREをはじめよう
SRE(Site Reliability Engineering、サイト・リライアビリティ・エンジニアリング)。ウェブサイトやアプリなどのインターネットサービスを、安定して使える状態に保つための専門家集団です。エンジニアリングの力を使って、システムの監視、障害対応、パフォーマンス改善などを行い、ユーザーが快適にサービスを利用できるように裏側で支えています。僕が現在の会社に転職したのは2019年ですが、当時「SREの役割を担ってほしい」と言われた時には「なにそれ?」状態でした。 SREという用語を生み出したのは天下のGoogleで、Googleでは必要に迫られ当然のようにSRE的な業務を2000年代より社内で行っていましたが、それを体系化して書籍としたのが2016年の書籍「Site Reliability Engineering: How Google Runs Production Systems」(日本語訳は2017年発売)が出版されたことで、SREの考え方が広く知られるようになりました。この書籍は、SREの原則、プラクティス、ツールなどを網羅的に解説しており、SREの普及に大きく貢献しました。
このブログはセキュリティを主題としたブログですが、SRE(Site Reliability Engineering)とセキュリティは密接に関連しています。SREは、システムの信頼性、可用性、パフォーマンスなどの維持・向上を目的とした手法です。システムの信頼性を確保するためには、セキュリティが不可欠であり、逆に、セキュリティを確保するためには、システムの信頼性が基盤となるからです。
具体的には、SREは以下のような方法でセキュリティに貢献します。
- 自動化による人為的ミスの削減: SREは、運用作業の自動化を推進することで、人為的なミスによるセキュリティインシデントのリスクを低減します。
- 監視とアラート: SREは、システムの挙動を常に監視し、異常があれば迅速にアラートを発することで、セキュリティインシデントの早期発見と対応に貢献します。
- インシデントレスポンス: SREは、インシデント発生時の対応手順を整備し、迅速な復旧と再発防止に努めることで、セキュリティインシデントによる影響を最小限に抑えます。
- 脆弱性管理: SREは、システムの脆弱性を定期的に評価し、適切な対策を講じることで、攻撃のリスクを低減します。
システムの安定稼働や、データの暗号化や保護もSREの役割の一つです。近年では、DevSecOpsという、開発(Development)、セキュリティ(Security)、運用(Operations)を統合した考え方が注目されています。DevSecOpsでは、開発段階からセキュリティを考慮し、運用段階でも継続的にセキュリティを評価することで、より安全性の高いシステムを実現することを目指しています。SREは、DevSecOpsの実現においても重要な役割を担っています。
とまあ、AIがいろいろ説明してくれたわけですがw今の会社の業務のスタートラインだったSREは、現在の僕のセキュリティ担当としての基礎になっています。
GoogleがSRE本を出してから、SREという職業が認知され、それから時は経つことで多くのSREの知見が溜まり、コミュニティも作られ活発な活動が行われています。この本は多くの本や文書、人々の経験をもとに改めてSREについて語った本となります。最新かつ整備された情報を基にSREを始めることができます。 そのため、この本はSREをはじめたい人に向けた本となっていますが、それのみならず、自分のように今一度SREとは何たるか、をアップデートしたい人や、SREとして今まさに活動している人向けの本にもなっています。SREとして働いている人にとっては、昔最初に読んだ本で学んだ内容が大半でしょう。しかし、現場というリアルの中でいつしか理想の形から遠く離れてしまっていることもあると思います。今一度初心に帰るためにも読む価値はあります。
今一度What makes SRE , SRE?(なにがSREをSREたらしめるか)を考えましょう。上記をGoogleで検索すると、AWSが考えるSRE、Wikipediaが定義するSRE、IBMが語るSREなど定義は千差万別です。この本の著者は以下のように定義します。
** SRE(サイトライアビリティエンジニアリング)は、組織がシステム、サービス、製品において、適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野 **
そしてその三本柱は
- 信頼性
- 適切
- 100%ではない、SLI/SLOを作る
- 持続的
久々に「トイル」という言葉を聞きました。そして意味を忘れてしまっていました。SREにとって「トイルの撲滅」こそが最重要、最優先事項だったのに。ただ自分のこの考えも本質からは少しずれていまして、トイルはSREが撲滅するべき敵だですが、トイルの撲滅がSREの仕事の目的ではなく手段であることを忘れてはいけません。SREのミッションは最初に書いたように信頼性の持続的な達成を継続することで、トイルはその障害の1つに過ぎません。 SREの仕事の目的、達成するべきミッションは
- 運用・障害対応は短く
- システムが機能し続けることでグローバルな展開を促進する
- 企業の信頼を保ち企業価値を守る = セキュリティ
であることを忘れず、今やっていることは上記に繋がっているかを胸に手を置いて行動したいところ。
SREが何を生業とするかについて明確に説明した後は、SRE的な人材が守るべき文化
- 「コードを書かぬもの、SREにあらず」
- 「文書化されるまでは実行しない」
- 「計測したデータを基に行動する」
などが力強い文章で説明されます。また、「英雄的なストーリーを語りたくなるが、SREの活動にヒーローを求めてはならない」「SREの仕事は自動車の整備士のようなもの。自動車が快調に走っているときに運転手が整備士の存在を忘れているようにならねばならない」と地味で地道な縁の下の力持ちの存在であることを説きます。この本にはGoogleのSREとして活動した人のインタビューも掲載されていますが
- 「SREの成功を他人に証明することがゴールではない」
- 「むしろSREはSREの専門知識を長期間必要としないシステムを望んでいる」
- 「優れたSREは自分の存在を正当化しようと会話には臨まない、そのサービスのために仕事をし続ける必要がない道を考えようとする、『自分が最終的に必要となくなる目標に少しでも近づいているのか』
- これはトイルの撲滅によりなされる
つまり、自分が必要とならなくなるために活動する(現実的な話、企業が健全に成長し続ける限りSREという仕事が不要になることはないのですが)意識を持っていたと。これは確かにその通りなのですが、実際その心づもりで働くのは凄いですよね。
また、この本の持つ他の本と異なる特徴として、「企業にSREとして採用される際、企業側の何を重視するべきか」「企業がSREメンバーをそろえた組織を作る場合、何を気を付けるべきか」が載っている点と思います。特に後者は、企業が成長するにあたりSREの規模が0から1、1から4、4から16と拡大するフェーズにおいて考慮するべきことが書いてあるのが興味深いです。