先日、Twitterを眺めていたら、たまたま以下のような記事を見つけ、お恥ずかしながらそこで初めてCREについて知りました。
やはりCREもGoogleが提唱した役割のようで、以下の記事に詳細があります。せっかくなので要約してみました。
# Google記事の意訳
25年の間に、コンピュータやそれを取り巻くテクノロジーは大きく変化した。一方、カスタマーサポートだけは、依然としてコールセンターでヘッドセットをつけた人たちが担当しており、変化していない。それでは不十分なので、Customer Reliability Engineering（CRE : 顧客信頼性エンジニアリング）という新しい専門職を発表した。
パブリッククラウドを利用する組織は、自分の環境を自分たちで管理できないことに対して不安を覚えている。これは、進化の中では当然で価値のある感情である。しかし、クラウドベンダーは、この不安を無視して導入を推し進めている。
以前のサポートチームの役割は分かりやすく、問題を解決するということだった。しかし、今では結局のところFAQやヘルプセンターにといったものになっている。現代において、このサポート体勢は完全に間違っている。今、この時代において、真に適切なサポート チームのミッションはたった 1 つ。それは、お客様の不安をゼロにすること。
お客様は、実際あまりクラウド プロバイダーの信頼性を気にしてはいない。それよりも、製品化されているアプリケーションの信頼性を気にしている。アプリケーションの信頼性は、次の 2 つによって成り立っている。
- クラウド プロバイダーの信頼性
- アプリケーションのデザインやコード、運用などに内在する信頼性
一つ目はすでに業界内で認識されており、クラウドベンダーはSite Reliability Engineering（SRE : サイト信頼性エンジニアリング）という専門職を設けている。一方、2は、気にかけているのはお客様だけで、これに対する業界内での標準的な回答は次のとおりです。
「ここにホワイト ペーパーや成功事例があり、コンサルタントもいます。あまり変なことをしなければ、アプリケーションもまあ大丈夫ですよ」
お客様が不安に思うのも、ごもっともです。というか、不安に感じるべきですよ！
そういうわけで、Dropboxはオンプレに戻りましたとさ。
CREのミッションは、これらの不安をなくすこと。
CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査する。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施する。
このプロセスの最終段階で、Google はお客様に対し「ここに御社システムの信頼性に関するギャップがあります。これが御社のエラー予算です。信頼性を向上したい場合は、こういった変更が必要です」と伝える。
また、呼び出しをする場合やチケット発行に関する基準にお互いが合意できるよう、共通のシステム モニタリング体制を構築する。Google の PRR に合格するには、お客様の側で多くの作業が必要となるが、その努力の結果、次のような成果に結びつくのです。
- 呼び出しに関する共通認識が生まれる。お客様がユーザーに呼び出されないようになれば、Google も呼び出されることはない。
- 最重要事項に関するチケットが自動で生成され、エスカレーションされることになる。
- CRE チームがお客様の悲惨な現場の対処に参戦する（お客様が必死でがんばったとしても、悲惨な出来事は避けられないため）。
- Google のデザイン調査や製品調査を経たシステムが手に入る。
ANDPADさんのCRE
ANDPADさんの場合、カスタマーサポートからの問い合わせを一手にうけ調査、必要であれば開発部隊に詳細調査や修正依頼をする、といった役割のようです。
また、問い合わせを一次受けとして捌いており、お客様の困りごとなどがよく見えることから、こういった困りごとがないような製品開発（品質の高い製品開発）にも取り組んでいくそうです。
コメント