SREとは
システム開発の手法について、エンジニアの皆さんは学ばれたと思いますが、システム開発と運用は別個のものであると考えている方も少なくないのではありませんか？しかし、本来は開発と運用は両輪で、この2つがしっかり働いて、ITは機能すると考えるべきでしょう。
最近DevOpsという新たな概念や、SREという手法が登場して、これまでのシステム開発と運用の概念が大きく変わりつつあります。この記事では、DevOpsとの違いを見ながらSREについて解説していきます。まだご存じない方は、ぜひSREについて理解をしてください。きっとエンジニアの皆さんには役立つ知識です。
SREはITサービスの信頼性を高めるアプローチ
SREとは何でしょう？SREは'Site Reliability Engineering'の頭文字を取った略語です。直訳すると、「サイトの信頼性を高めるエンジニアリング」ですが、サイトはWebサイトのことではありません。IT全般のサービスと解釈した方が正しいでしょう。すなわち、SREは「ITサービスの信頼性向上のための設計やアプローチ、またはそれを行うチーム」を指します。
従来からソフトウェア・エンジニアリングという、ソフトウェア開発や保守の効率を高めるエンジニアリングがありましたが、SREはITサービスの信頼性向上を主眼にソフトウェアエンジニアリングを用いた新たなアプローチと考えて良いでしょう。
SREが生まれた背景
SREは2000年頃にGoogle社が自社のサービスである、検索エンジンサイト「google.com」の安定稼働を図るために行った取組がその誕生の発端です。
その取り組みでは運用エンジニアではなく、ソフトウェアエンジニアの力を借り、開発と運用の垣根を超えたアプローチを行いました。この時のアプローチである「Site Reliability Engineering」）の頭文字がSREの語源です。
SREの対象は「サイト（Site）」に限ったものではありませんが、Google社の信頼性向上取組みの対象が「google.com」のWebサイトであったことから、「サイト（Site）」の'S'が残され、「SRE」として広まりました。
当時のGoogle社の主なビジネス領域は「google.com」の検索サービス提供でした。そのため「google.com」に対する訪問者の信頼性確保が、ビジネスの成長と拡大にとって必須要件だったのです。
すなわち、当時のGoogle社にとっては、サイトの安定稼働が同社の生命線であり、それは「Google社のサービスに欠くことができない基本機能」であったのです。
現在、SREは「Webサイト」以外にも、広く分散コンピューティングシステムなどのアプローチの1つとなっています。
違いから見たSRE
SREがITサービス信頼性向上へのアプローチの1つということは理解できたでしょうか？それでも、まだ漠然としている点があるかと思いますので、ここではSREによく似た概念、よく似た職種との違いについて明らかにしていきます。
SREとインフラエンジニアの違い
最近では、SRE（エンジニア）募集という求人情報を時折目にしますが、SREという職種はIT業界でも広く認知され始めました。実際に「SRE課」などの部署を設けている企業もあり、サービス向上に向けた取り組みが注目されます。
しかし、その実態はブームに便乗し、従来のインフラチームが名称を変えただけの企業もあり、SREの本領が発揮されるまでには多少時間が掛かるかもしれません。
では、「SRE」と「インフラエンジニア」の仕事は何が違うのでしょうか？
SREとインフラエンジニアの違いは、SREの業務範囲や求められるスキル範囲の広さです。それを比較表にすると、以下の通りです。
職種 インフラエンジニア SRE
▪業務範囲： インフラのみ インフラ+アプリケーション
▪求められるスキル： ITインフラ関連 インフラ+アプリケーション開発や経験
▪方法論： 特に決まったものはない Google社の「※SRE」
【参考】：「Site Reliability Engineering」
※当資料は英文ですので、日本語でお読みになりたい方は、ブラウザの翻訳機能を利用するか、翻訳本などをご利用ください。 【参考書籍】：SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム
SREとDevOpsの違い
SREの概要について紹介しましたが、中には最近話題のDevOpsとの違いが分からなくなった方も少なくないと思います。ここでは、この両者の違いを見ておきましょう。
DevOpsは、システム開発担当と運用担当が協力し合い、主にユーザーに対するより良いサービスの提供を目指すMind（意識）を指します。DevOpsの概念を実現するには、開発担当と運用担当が互いをリスペクトし合いながらコミュニケーションを図り、より良いサービスという共通目標の達成に向けて切磋琢磨し合うことです。
DevOpsはアジャイル開発の1つの手法としても知られ、ソフトウェアの早期開発やリリース、安定稼働によるユーザー満足度の向上に重きを置いています。
SREを生み出したGoogle社は、DevOpsを思想とするなら、SREはその思想に基づく役割であると捉えています。わかりやすく言うと、「DevOpsではチーム同士の連携を文化や哲学的な視点から捉え、SREはその実現に向け、ソフトウェアの活用という手法を用いたチーム体制や機能」を指します。
SREの年収
SRE（エンジニア）になると年収はどれくらいなのか気に掛かる方も少なくないでしょう。SREはインフラに関する知見と、アプリケーション開発に関する知見の両方が必要だということが分かったと思います。
つまり、SREはインフラエンジニアとアプリケーションエンジニアの両方のスキルを有する「エンジニア」であることが求められるのです。
年収については明らかにはなっていませんが、求人情報などから判断すると、SREの年収の中間値は700～800万円前後と推定され、エンジニアの中では高年収の部類に入ります。SREの求人情報に関しては以下を参照してみてください。
【参考】：SE・システムエンジニア(IT／通信／インターネット) 求人一覧
SREのアプローチ方法
SREの概念は理解できたでしょうか？ここでは、SREの具体的なアプローチの方法について簡単に紹介します。大きくは以下の流れになります。
1.SREチームを編成する
Google社ではSREチームの編成を行う際に、チームの50%から60%までは正規のソフトウェアエンジニアとし、残り40%から50%は他のスキルを持つエンジニアを充てています。つまり、エンジニアの垣根を越えて、さまざまな知見を結集し、さまざまな視点からアプローチを行うことが求められるのだと理解できます。
2.SLOを設定する
どんなサービスでも、信頼性は100%であることがベストですが、人命に関わるような仕組みはともかく、大半のサービスで100%の信頼性を確保するのは至難の技であり、現実的ではありません。
この目標値をSLO（Service Level Objective）と言います。よくデータセンターとの契約などで、SLA（Service Level Agreement）という言葉を耳にしますが、SLAは金銭的な補償を伴う「稼働率の保証」であり、SLOは補償を伴わない目標値です。
このSLOの設定は、SLI（Service Level indicator）によって、提供するサービスの実際の計測量を把握することから始めます。
3.自動化や省力化を図る
SREと「インフラエンジニア」との最大の違いは、カバーする役割の範囲が異なる点でした。
SREは運用する開発システムの増大に比例して、保守運用工数が増えることがないよう、自らアプリケーションに関与したり、自動化プログラムを書いたりして、主体的に自動化や省力化を行います。
SREの'E'は言葉通り、まさに「エンジニアリング」なのです。
4.運用の改善を行う
システム運用には、モニタリングや障害対応マニュアルの作成、セキュリティの確保、システムの変更管理、キャパシティプラニング、プロビジョニング（リソース管理）、ポストモーテム（事後検証）などがあります。SREはこれら運用業務の問題点の発見や抽出、改善までを詳細、かつ広範囲にアプローチを行います。そのアプローチはインフラエンジニアの知見だけでは難しく、ソフトウェアエンジニアの要件定義スキル、ソフトウェア開発スキルなどが加わることで実現可能となります。
キャリアパスから見たSRE
SREがインフラエンジニアと比較して、技能の高さや広さが要求されることは理解されたと思います。
現在、「インフラエンジニア」を目指している方は、キャリアパスを描く上で、「インフラエンジニア」としての経験を積み、次のステップとしてSREを目指すのも良いでしょう。もちろん、「インフラエンジニア」として、より専門性を高めるというのも1つの選択肢です。
或いは、システムエンジニアを目指している方が、インフラエンジニアとしてのスキルを身に付けてSREとして活躍するキャリアパスを描くのも良いでしょう。多くのIT企業においてはSREに対する期待が高まり、SREの需要も増加しています。
いずれにしても、SREとして両方のエンジニアスキルを身に付ける事が、皆さんの大きな飛躍にもつながるはずです。キャリアバスの選択肢の1つとしてSREを加えてみてはいかがでしょうか？
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから
