顧客信頼性エンジニアリングを意味するCRE(Customer Reliability Engineering)とサイト信頼性エンジニアリングを意味するSRE(Site Reliability Engineering)の違いをご存じでしょうか。
明確な違いまでは分からなくとも、
- なんとなく顧客に関わる業務内容であればCRE?
- サイトに関わる業務内容であればSRE?
と思っている人は多いのではないでしょうか。
本記事ではCREとSREの明確な違いについて解説していきます。業務内容や役割、必要なスキルセットなどを交えて説明していくのでぜひこの機会に理解してみてください。
関連記事:SREとはなにか [サイト リライアビリティ エンジニアリング]
CREとSREの違い
CREを日本語に略すと「顧客信頼性エンジニアリング」、SREは「サイト信頼性エンジニアリング」となります。両者ともに役職を指す場合もあれば、業務内容自体を指す場合もある言葉です。
またCREとSREは似た部分が多くあります。
- 「信頼性」を担保する役割を持つ
- Googleが提唱した役職ないし業務を指す
- コーディング/調査/問題解決など、業務内容は多岐にわたる
上記のような点でCREとSREと混合して考えてしまいがちです。しかし、CREとSREには明確な違いがあります。以下3つのポイントで違いを詳しく解説します。
「信頼性」を担保する対象の違い
CREとSREの最大の違いです。
CREは「顧客」に対しての信頼性を保つために最善を尽くすのに対し、SREは「サイト」に対して信頼性を保つことに最善を尽くすという点で異なります。
- CRE:「顧客」に対して信頼性を保つ
- SRE:「サービス」に対して信頼性を保つ
「信頼性」を保つと言っても、顧客との関係性を第一に考えるCRE、サイトの継続稼働や安定性という意味で信頼性を保つSRE。これらの違いによって、どこに焦点をおいて業務を遂行するのかは大きく異なります。
スキル面での違いについて
「顧客の信頼性を担保する」と考えると、CREは技術的なスキルを持っていなくてよいのかと言えばそういうわけではありません。「Customer Reliability Engineering」の名の通り、あくまでCREは「エンジニアリング」であり技術的なスキルを持ち合わせていることは必須の条件となります。
GoogleはCREに役職について以下のように述べています。
CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。
引用:https://cloudplatform-jp.googleblog.com/2016/10/google-cre.html
電話やメール・チャットで顧客からの質問に対応する顧客サポートよりは、技術的なアドバイスをする「テクニカルサポート」をイメージすると分かりやすいかもしれません。CREは、顧客が不安に思うことや技術面で不明な点をサポートする役職であるため、「このスキルが無ければ務まらない」という明確な決まりはありません。しかしCREを務めるには、幅広い知識とスキルを要するため、「自社製品サービスに関する知識は前提として、顧客がサービスを活用するうえで必要な技術サポート」を行う力が求められます。
それに対してSREのスキルは「サービス開発を行う技術力」や「当該サービスに関する深い知見」といった物が求められます。CREが顧客のサービス利用環境や企業体制に依存するのに対し、SREは自社のサービスや自社のインフラ環境に依存し、それらに特化したスキルが最重要視されます。なおSREチームは、「コーディングなどのサービス開発スキル」を持つエンジニアを中心に「UNIXシステムの内部構造」「ネットワーク(レイヤー1からレイヤー3)の専門知識」などを持つメンバーで構成されているケースが多いです。
つまり、
CRE:顧客の利用環境に依存して必要なスキルは変わる
SRE:自社のサービスや環境に依存して必要なスキルは変わる
ということが挙げられます。信頼性を担保する方向性が「顧客」と「サービス」というだけで、必要なスキルも大きく異なることが理解できたかと思います。
方法論の違いについて
CREは企業ごとに顧客が異なるため、どこまで顧客に寄り添ってサポートするのかは異なってきます。それに伴い、サポートの方法やゴールとすべき指標も企業によって変わってくるでしょう。
これに対して、SREは明確な方法論があります。具体的には、グーグルが自社のSRE紹介サイト(https://sre.goole/)において、『Site Reliability Engineering』という「SREの原典」ともいうべき本を無償で公開しています。簡単に紹介すると
- SLIを計測しSLOを設定する
- 自動化・省力化
- 運用改善
- モニタリング
- 緊急対応時の手順書の作成
- 変更管理
- 需要予測/キャパシティプランニング/プロビジョニング/効率的なリソース活用
- ポストモーテム
などが挙げられます。もちろんSREも企業によって取り組むべきポイントを取捨選択して行っていくケースが多いですが、「SREの原典」をしっかり理解した上で、記載されている方法論に従ってSREの業務を遂行することが非常に大切なのではないでしょうか。
SREの導入支援はSreakeにお任せください!
本記事では、CREとSREの違いについて「信頼性の対象の違い」「スキルの違い」「方法論の違い」をもとに解説してきました。
なお、「CREとSREのどちらが重要」といった比較は無意味です。方法論は違いますが、いずれも「お客様の利用環境の信頼性が高める」ことが最終的に実現することで、ビジネス的な価値を実現できるためです。
当社は、SREを顧客企業に提供する、いわば「SRE as a Service」を行う企業です。もし貴社で、自社サービスの運用においてSREを活用したい、SRE組織を立ち上げたい、ベストプラクティスから学びたいという要望がありましたら、SREのプロフェッショナルが集まる当社のSRE導入支援サービス「Sreake」をご活用ください。
SREの組織形成や教育は勿論のこと、貴社の業務内容を理解したうえ、サービスの戦略策定から設計・構築・運用、SaaS提供までSREに必要な要素を統合的に提供可能です。
少しでもSREに興味があるという企業様がいらっしゃいましたら、気軽にお問い合わせください。
東京在住のソフトウェア開発者、Motouchi Shuyaです。
システムの開発・運用・最適化が好きです。