目次
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「SRE のこれまでとこれから」です。（開催日：2020年 6月16日）。本記事は登壇者の古川さんの基調講演から SRE のこれまでとこれからを紹介し、SRE を紐解いていきます。最後には、古川さんが考える SRE の定義をお伝えします。
古川 雅大
株式会社はてな
SRE。2021年夏までMackerel SREチームのテックリードとしてMackerelの運用を担当。 現在はMackerelの運用に加え、CTOと共に社内全体のSRE組織作りに取り組んでいる。
近年、GoogleからSREという考え方が広がり、現在では多くの組織で実践されています。
SREの実践方法はプロダクトの性質、組織の規模、チーム構成などと切り離して考えることは難しいため、組織毎に異なった課題が出てきます。
自分たちの組織にあったSREを設計、実装していくためには、SREの文化を理解することはとても重要です。
そこで、本セッションでは、SLI/SLOの設計方法や実際の監視設定、設計など手法の話ではなく、SREの原理原則、文化を再整理し、組織としてどう取り組んでいくかを紹介します。
今からSREを組織に導入しようと考えている方の参考や実践されている方は再整理することで、新たな解決方法を生み出す一助となれば幸いです。
「SRE の文化と組織」について発表します。
今までは Google のプラクティスだったものが、2012〜2016年にかけて、アウトプットが増えたことで、全体的に Webサービス事業者の中のプラクティスに進化しました。その全体のプラクティス、企業・産業のインダストリアルなプラクティスから、明るい方向へ少しずつ進出し始めているのが、今のフェーズだと思います。
企業や組織は、規模や文化、組織のレベルが多様であり、すべて Google の真似をするのは難しいので、どう考えるかが重要です。これからは多様なやり方や共通のプラクティスがどんどん生まれてくると思います。そこに対応するために、文化主張を学びます。セキュリティ分野は、かなり近い話題が多いので、今も SRE とセキュリティを組み合わせる話はありますが、他の分野との連携も増えると思います。
あとは産業と研究の連携、エンジニアと研究者、勉強会と学会など、それぞれアプローチは違うにしろ、やりたいことは一緒なので、そこが融合して新たな種の発見も出てくると思います。
SRE NEXT 2020 が国内初かな。大規模な SRE カンファレンスがありました。発表の割合は特定技術に関する話と、コミュニケーションの話が半々ぐらいでした。会場アンケート結果を見ると組織のマネジメントや Toil の撲滅、チームの話に興味を持つ人が多そうなイメージでした。
これからに対応するために、組織やコミュニケーション文化の話は難しい課題ですが、ここを抜きには語れません。
これは SRE 本の「はじめに」から抜粋したもので、Google の SRE 創始者は「SRE はソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」といってます。
ここで注目すべきは、運用チームの設計なので、チームの設計になります。文字どおりにとらえれば、チームの設計をソフトウェアエンジニアがしています。Class SRE implements DevOps という言葉もあり、DevOpsという思想をSREが実装していると考えるとソフトウェアエンジニアの方には理解しやすいかもしれません 。
SRE 本を読んでいくと他にもいろんな話題があります。SLI / SLO による意思決定やソフトウェアエンジニアリングによる自動化などです。
IaC は #1 にありましたが、その辺の話題やシステムのモニタリング、オブザーバビリティや DevOps の実装、インシデント対応、障害対応の話。チームマネジメントによるToil撲滅の話も詰まっています。
SREを初めたときに最初、私はこれらすべてが同じ分野なのか疑問でしたが、今は同じ分野だと思っています。その点を読み解いていきます。
読み解くとはいえ、今回は SRE 本の「はじめに」の内容しか喋っていません。その中でも SRE の役割と意味をうまく定義すること。また他の組織も利用できるようにするのが、この本の目的です。再度自分で読んで、考え、整理するのが、いいアプローチの方法かと思います。
SRE はシステムの信頼性に焦点を当てる。これは SRE の内容か？と思ったときは、信頼性に関わることならイエスととらえるようにしてます。信頼性に焦点を当てる = 信頼性を上げるのではなく、信頼性に関わることは、SRE にとって関心事、関連する事項です。
これも SRE 本の「はじめに」から取ってきましたが、「信頼性こそがあらゆるプロダクトの基本的な機能」であり、誰も使えないシステムは有益ではないと述べられてます。
信頼性についても「はじめに」に書いてあり、信頼性とは「システムが求められる機能を、定められた条件のもとで、定められた期間にわたり、障害を起こすことなく実行する確率」と述べられています。
これは1991年に出版された「 Practical Reliability Engineering」 の定義ですが、SRE 本でもこれを信頼性の定義にしています。
ここで注目したのは、システムと定められた条件の2つです。Webサービスのシステムの信頼性をどうするか考えたときに、2つあると思います。
この2つのシステムが合わさって、Webサービスのシステムができています。信頼性工学の話だとヒューマンマシンシステムと呼ばれると思いますが、自動車は運転する人と、車自体があります。この2つが合わさって、Webサービスは動いているので、これらを考慮する必要があります。何かしら1つのコンポーネントの信頼性が低いと、それに引きずられて全体のシステムの信頼性が下がってしまうので、どちらも疎かになってはいけません。
SRE の文脈では、ビジネス的な条件が多いと思います。コストは、人やお金、時間。売上を増加したり魅力的な新機能を開発していかないと競争に勝てないとか、市場の変化への対応。アジャイルやマイクロサービスも組織全体で変化へ対応する必要があるので、そこのスケーリングの話です。
「はじめに」から抜粋してますが、「スケーリングとは機械的なことよりも、むしろビジネスプロセスのスケールに関することのほうが難しい」と書いてあります。当然機械的なスケーリングも重要ですが、人のシステム、ビジネスのスケーリングも大事だと述べられています。組織によって変わるかもしれませんが、大半はビジネス的な話です。
私の考える SRE とは、信頼性のある Webサービスを提供するため、条件を考慮したシステムを設計・実装・運用する。または課題をエンジニアリングで解決していくことが SRE だと思います。
条件とは、さっき話したビジネス上の条件。システムはヒューマンマシンシステムだと思います。ヒューマンマシンシステムは新しい概念ではありません。
たとえば自動車は、最初、走ることが目的でどんどん機能を実装していき、大量生産できるようになってコモディティ化しました。人が使うようになり、事故が多発したので、安全について考えるようになり、信頼性工学や安全工学の分野が入ってきました。
インフラも同じで、たとえば #1 にあった IaC や #2 の Cloud Nativeなどです。機械的なシステムは、昔に比べたら容易にできるようになりました。しかし、本当は人側のシステムを絡めて、安全や信頼性について考える必要があります。
今まではそこを考える余力がありませんでしたが、今では手を出せるようになってきたと思います。自動車は安全基準ができてきたと思いますが、徐々に Webサービス業界のインフラも、人を絡めてシステムの話ができるようになってきたと考えています。
SRE。2021年夏までMackerel SREチームのテックリードとしてMackerelの運用を担当。 現在はMackerelの運用に加え、CTOと共に社内全体のSRE組織作りに取り組んでいる。
