「理論と実践からSREを再考する」というイベントで司会進行とパネルディスカッションのモデレーターをやる #SREGaps

はじめに

本日、2021年9月9日19時30分より『SRE Gaps「理論と実践からSREを再考する」』というイベントがあります。私、nwiizoはそこでパネルディスカッションのモデレーターを行うことになりました。

forkwell.connpass.com

500名以上も参加登録されていてかなり注目されていると思います。SRE という概念を導入する日本企業の開発組織も増えてSREの考え方は多くの場所で取り入れられ、実践されています。 しかし、SRE の実践方法はプロダクトの性質や組織の規模、チーム構成によって異なるほか、 文化としても各企業それぞれ異なる解釈をしている場合が多く存在しており有効に活用されていない現状が見られます。とりあえず、流行っているので「インフラエンジニア」という役職名だけ「SRE」にしており実務としては変わらないままみたいなことが聞こえてきて悲しいです。SREはyaml 管理者のことを指していうわけではないです。ここでインフラエンジニアとSREの違いについて三つ紹介したいと思います。

1.業務範囲

1つ目は、インフラエンジニアは「インフラのみ」が業務範囲であるのに対して、SREは「信頼性を高める活動全て」が業務範囲である点です。

インフラエンジニアは、アプリケーション開発チームが開発したサービスが、「高いパフォーマンスで安定的に稼働する」ための環境を構築し運用することが役割です。よって、インフラの構築・運用・改善は行いますが、アプリケーション側には責任は持ちません。

これに対してSREは、「サービスの信頼性を高めるための全ての活動」を行います。具体的には、インフラだけでなくアプリケーション側も業務範囲となるため、アプリケーションのプログラムの修正までSREチームにより行われる場合もあります。また、開発や運用のみならず、組織や文化の醸成といった部分まで責任を持って取り組まれる例が多いのも特徴です。

2.スキルセット

2つ目は、業務範囲の違いからくる、求められるスキルの違いです。インフラエンジニアは「ITインフラに関する知識や技術力」が求められますが、SREはインフラエンジニアが持つ知見に加えて「アプリケーション開発を行う技術力」や「当該アプリケーションに関する深い知見」が求めれます。

求められるスキルの違いは、SREチームの構成にも反映されています。SREを提唱したGoogle は、「SREチームの約半分はGoogle の正規のエンジニアで構成される」としています。つまり、SREチームの半数はアプリケーションエンジニア(または経験者)により構成されるべきとしています。そして残りの半数は「Google の正規エンジニア『予備軍』だが、他のメンバーが持っていないスキルがある」ことを条件としています。ここで指す他のメンバーが持っていない具体的なスキルとしては、「UNIXシステムの内部構造」と「ネットワーク(レイヤー1からレイヤー3)」の専門知識であることが圧倒的に多いです。この辺は2011年に発売されたウェブオペレーション――サイト運用管理の実践テクニックなどを参考にしていただけると非常に参考になると思います。

言い換えると、SREチームメンバーの半数は、SREからアプリケーション開発チームに異動しても、そのまま業務を行えるレベルで開発力があるメンバー(または直前までアプリケーションチームに所属していたメンバー)で構築されるべきだということです。

一般的なインフラエンジニアの多くは、アプリケーション開発チームに異動したとしても、スキルがマッチしないため、その業務遂行が難しいことを考えると、SREチームは技術力の「深さ」だけでなく「広さ」も求められるといえます。

3.方法論

3つ目は、方法論の有無です。「インフラエンジニアとは、なにをどのようにして行うべきか」という方法論は、企業により大きく異なります。これに対して、SREは明確な方法論があります。具体的には、上記で紹介したGoogle が自社のSREの紹介サイトhttps://sre.goole/において、『Site Reliability Engineering』という「SREの原典」ともいうべき本を無償で公開しています。これらには日本語版や他の言語のものもあるので全世界のSREは、この「SREの原典」を理解した上で、記載されている方法論に従ってSREの業務を行っています。もちろん、企業ごとに「どこまで原典を文字通りに取り入れてSREを行うか」の違いはありますが、大まかな方法論や用語、考え方は全ての企業で共通しています。

vs DevOps というおまけ

Webサービスの信頼性や価値の向上に用いられるアプローチ方法としてSRE(Site Reliability Engineering)というものがあります。システム開発側と運用側の溝を埋めるために生まれたこの手法ですが、従来のDevOpsとはどのような違いがあるのでしょうか。

ついでにSREとDevOpsの違いについて見ていきます。

SREとDevOpsの違いや関係性を知るには、Googleが提唱している「class SRE implements DevOps」の考えが最も明解でしょう。

「class SRE implements DevOps」は、「SREはDevOpsというinterfaceの実装である」という意味を表します。「DevOps = 思想」という定義に対し、それを具体化し実装したものがSREであるという考えです。この辺は概念的な面も多く「実際、どのようにSREを導入すれば良いのだろう?」や「専任のSREチームなしでSRE原則を適用する方法がない」と思う担当者の方も多いかと思いますのでぜひ、紹介した本を読んでみましょう!

さいごに

現在、以下の3冊がGoogleから出されています。

  • Site Reliability Engineering
  • The Site Reliability Workbook
  • Building Secure & Reliable Systems

このうち、Site Reliability Engineering と The Site Reliability Workbook は日本語版も出版されております。 sre.google

そして、日本語での新たなSRE関連書籍が9月3日に発売されました。ちなみにGoogle からではないです。この書籍は大規模なプロダクションシステムの運用において、様々な企業や組織がSREをどのように実践しているかについて紹介している書籍になります。その本のタイトルは『SREの探求――様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践』 です。私は6月にSRE特化型コンサルティング事業を運営するスリーシェイク社に転職して1ヶ月程無職期間を謳歌していたので他にもSRE関連書籍を読みましたがその中でも今回のイベントのタイトルでもある理論と実践について深く書かれているので原典を読んだ上で読むとめちゃくちゃ面白い書籍だと思います。イベントに参加できなくとも信頼性に関わる全てのエンジニアは読んでも良いと思いました。

本イベントでインフラエンジニアからSREと名付けられ旅館で迷子になった無垢な子供が救われることを祈ってます。それでは皆様、イベントでお会いしましょう!

また、株式会社スリーシェイクではSRE に関するイベントをやっております。登壇者含めて募集しているので皆さん登録よろしくお願いします。 3-shake.connpass.com

あとがき

SRE Gaps「理論と実践からSREを再考する」は本当に良い発表ばかりだったと思う。自分は本当に何もできずにただただ震えてただけですがなんとかいいイベントになったのではないでしょうか?皆様も感想などありましたらハッシュタグ付けてツイートでもしてください!

twitter.com

完全なる宣伝になるんですけど

「実際、どのようにSREを導入すれば良いのだろう?」や「専任のSREチームなしでSRE原則を適用する方法がない」と思う担当者の方も多いかと思います。

弊社は、金融・医療・動画配信・AI・ゲームなど、特に技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。戦略策定から設計・構築・運用、SaaS提供までSREに必要な要素を統合的に提供可能です。

もし少しでもSREに興味があるという企業様がいらっしゃいましたら、気軽にお問い合わせください。

sreake.com