Google記事の要約

25年の間に、コンピュータやそれを取り巻くテクノロジーは大きく変化した。一方、カスタマーサポートだけは、依然としてコールセンターでヘッドセットをつけた人たちが担当しており、変化していない。それでは不十分なので、Customer Reliability Engineering（CRE : 顧客信頼性エンジニアリング）という新しい専門職を発表した。

パブリッククラウドを利用する組織は、自分の環境を自分たちで管理できないことに対して不安を覚えている。これは、進化の中では当然で価値のある感情である。しかし、クラウドベンダーは、この不安を無視して導入を推し進めている。

以前のサポートチームの役割は分かりやすく、問題を解決するということだった。しかし、今では結局のところFAQやヘルプセンターにといったものになっている。現代において、このサポート体勢は完全に間違っている。今、この時代において、真に適切なサポートチームのミッションはたった 1 つ。それは、お客様の不安をゼロにすること。

お客様は、実際あまりクラウドプロバイダーの信頼性を気にしてはいない。それよりも、製品化されているアプリケーションの信頼性を気にしている。アプリケーションの信頼性は、次の 2 つによって成り立っている。

クラウドプロバイダーの信頼性
アプリケーションのデザインやコード、運用などに内在する信頼性

1はすでに業界内で認識されており、クラウドベンダーはSite Reliability Engineering（SRE : サイト信頼性エンジニアリング）という専門職を設けている。一方、2は、気にかけているのはお客様だけで、これに対する業界内での標準的な回答は次のとおり。

「ここにホワイトペーパーや成功事例があり、コンサルタントもいます。あまり変なことをしなければ、アプリケーションもまあ大丈夫ですよ」

お客様が不安に思うのも、ごもっともです。というか、不安に感じるべきですよ！

そういうわけで、Dropboxはオンプレに戻りましたとさ。

CREのミッションは、これらの不安をなくすこと。

CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査する。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施する。

このプロセスの最終段階で、Google はお客様に対し「ここに御社システムの信頼性に関するギャップがあります。これが御社のエラー予算です。信頼性を向上したい場合は、こういった変更が必要です」と伝える。

また、呼び出しをする場合やチケット発行に関する基準にお互いが合意できるよう、共通のシステムモニタリング体制を構築する。Google の PRR に合格するには、お客様の側で多くの作業が必要となるが、その努力の結果、次のような成果に結びつく。

呼び出しに関する共通認識が生まれる。お客様がユーザーに呼び出されないようになれば、Google も呼び出されることはない。
最重要事項に関するチケットが自動で生成され、エスカレーションされることになる。
CRE チームがお客様の悲惨な現場の対処に参戦する（お客様が必死でがんばったとしても、悲惨な出来事は避けられないため）。
Google のデザイン調査や製品調査を経たシステムが手に入る。

企業がお客様に対して「一緒にやっていきましょう」と言うことが流行していますが、企業側がその役割をきちんと果たしているケースは多くない、というのが実情。
真に「一緒にやる」人たちは、双方に対する義務感があり、お互いの責任を背負っている。共通のゴールに向けて共同で作業し、相互にやり取りする金銭よりも重要な運命を共にする。