はじめに
はじめまして。株式会社スタディスト SREチームの@katsuhisa__です。 スタディストでは、システム運用に関わる全般的な業務にはじまり、モニタリングやログ収集基盤の整備などを担当しています。
本記事でお伝えするのは、以下のような内容です。
- SREとは
- これまでのシステム運用やDevOpsと何が違うの?
- SREに取り組む前に考えるべきこと
教科書的な解説から入り、記事後半では、実際の企業内でのプラクティスを取り上げながら、これからSREをはじめたい人が気にかけるべき内容をご紹介しようと思います。
さて、みなさんはSREについて、どのようなことをご存知でしょうか。「Toil」「SLI/SLO/SLA」「ポストモーテム」などSREに関するさまざまな用語を耳にする機会も増えたのではないでしょうか。
しかし、SREそのものの概観に触れている日本語の記事や文献は、まだまだ意外と少ない印象があります。それもそのはず、SREを提唱したGoogleがSREを紹介した初の書籍『Site Reliability Engineering』(通称、SRE本)[1]の日本語版が出版されたのは、2017年8月。まだSRE本が日本国内で発売されてからたったの1年も経っていないのです。そのため、SREに触れた日本語の記事や文献が少ないのはある意味当然と言えるでしょう。本記事では、まずSREの概観について、みなさんと見ていきたいと思います。
[1] 英語版は、オンラインで無料で公開されています。
日本語版は、オライリー・ジャパンより出版されています。
SREとは
SREは、Googleが提唱したエンジニアの役割です。また、Site Reliability Engineeringという名称の通り、システムの信頼性に焦点を置いています。
しかし、この言葉だけでは、一体どのような仕事をしているのかの全貌はつかみにくいでしょう。ここで、SREという言葉の考案者でもある、Google社 VP of EngineeringのBen Treynor氏によるSREの説明を、書籍『Site Reliability Engineering』より引用します。
My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team.(筆者訳:私の説明は簡潔です。SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるものです。)
![書籍『Site Reliability Engineering』](http://cz-cdn.shoeisha.jp/static/images/article/11002/11002_001.png)
どうやらソフトウェアエンジニアリングが鍵を握る考え方のようです。また、ここでは運用チームという用語が登場しました。
では、ソフトウェアエンジニアがシステム運用を設計することで、これまでのシステム運用と具体的にどのような違いが生まれるかについて考えてみましょう。この差分にこそ、Googleが見出した新しいプラクティスが詰まっているはずです。
システム運用とは何か
まずは、システム運用について、みなさんとの共通認識を持ちたいと思います。一般的にソフトウェアは開発して終わり……なんてことはありません。ユーザーが利用し、価値を発揮するまでがソフトウェア開発です。では、この一連の流れを今一度整理してみましょう。
まず、ソフトウェアが稼働するサーバの準備が必要です。また、ネットワークの設定・構築も必要ですね。そして、サーバ内でソフトウェアが稼働する状態を設定しなければなりませんし、ソフトウェアに変更があれば修正を反映する作業も行います。
さらには、障害が発生した場合には、サーバ、ネットワーク、ミドルウェアやソフトウェアのどこに原因があるかを突き止め、解消しなければなりません。また、そもそも障害が発生した状態を把握するためには監視を行う必要もありますね。きっと、読者のみなさんの周りには、より多様なシステム運用に関する業務が存在していることでしょう。
このようにソフトウェア開発の一連の流れには、実際にソフトウェアを開発する以外のさまざまな仕事が存在していることが分かります。俯瞰すると、ソフトウェア開発の一連の流れは、ソフトウェアを開発する役割(Dev)とソフトウェアの価値をユーザーに届け続ける役割(Ops)が存在していると言えるでしょう。後者の役割を担うのが、システム運用です。