Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

SREって何? これまでのシステム運用やDevOpsとは何が違うの?

結局、SRE って僕たちに関係あるんですか? 第1回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 近年、何かと話題に上がるSRE(Site Reliability Engineering)。しかし、「自分たちのチーム・組織に関係する話なのかよく分からない」「具体的に何をやればいいの?」といった感想を持つ方は多いのではないでしょうか。本連載では、そういった方に向けて、自社でSREチームの立ち上げを行った筆者が、SREの考え方 をご紹介します。また、連載の後半では、SREをいち早く取り入れた企業に導入背景などもインタビュー形式でお伝えする予定です。第一回となる本記事では、「SREって何?」「SREをやりたいが、どこからはじめればよいのか分からない」 方に向けて、SREの概観をご紹介します。

目次

はじめに

 はじめまして。株式会社スタディスト 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年も経っていないのです。そのため、SSREに触れた日本語の記事や文献が少ないのはある意味当然と言えるでしょう。本記事では、まず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』
書籍『Site Reliability Engineering

 どうやらソフトウェアエンジニアリングが鍵を握る考え方のようです。また、ここでは運用チームという用語が登場しました。

 では、ソフトウェアエンジニアがシステム運用を設計することで、これまでのシステム運用と具体的にどのような違いが生まれるかについて考えてみましょう。この差分にこそ、Googleが見出した新しいプラクティスが詰まっているはずです。

システム運用とは何か

 まずは、システム運用について、みなさんとの共通認識を持ちたいと思います。一般的にソフトウェアは開発して終わり……なんてことはありません。ユーザーが利用し、価値を発揮するまでがソフトウェア開発です。では、この一連の流れを今一度整理してみましょう。

 まず、ソフトウェアが稼働するサーバの準備が必要です。また、ネットワークの設定・構築も必要ですね。そして、サーバ内でソフトウェアが稼働する状態を設定しなければなりませんし、ソフトウェアに変更があれば修正を反映する作業も行います。

 さらには、障害が発生した場合には、サーバ、ネットワーク、ミドルウェアやソフトウェアのどこに原因があるかを突き止め、解消しなければなりません。また、そもそも障害が発生した状態を把握するためには監視を行う必要もありますね。きっと、読者のみなさんの周りには、より多様なシステム運用に関する業務が存在していることでしょう。

 このようにソフトウェア開発の一連の流れには、実際にソフトウェアを開発する以外のさまざまな仕事が存在していることが分かります。俯瞰すると、ソフトウェア開発の一連の流れは、ソフトウェアを開発する役割(Dev)とソフトウェアの価値をユーザーに届け続ける役割(Ops)が存在していると言えるでしょう。後者の役割を担うのが、システム運用です。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 北野 勝久(株式会社スタディスト)(キタノ カツヒサ)

     印IT企業でインフラ・ミドルウェアエンジニアとして勤務した後、スタディスト入社。マニュアル作成・共有プラットフォーム「Teachme Biz」の新規機能開発を担当の後、SRE チームの立ち上げを行う。信頼性に関わる一連の実装、運用を担当する。

All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5