Google の新しい専門職 : CRE が必要な理由
2016年10月19日水曜日
私がテクノロジーにかかわるようになってから 25 年が経過しましたが、その間にほぼすべてのことが変化しました。研究室にあったコンピュータは今や私たちのポケットの中にあり、四六時中つながっている状態です。そして、こうしたコンピュータを使えば、最も楽観的なサイエンス フィクションに匹敵するようなことまで可能になりつつあります。
25 年前と同じようなものはほとんど存在しません。ただ、カスタマー サポートだけは別です。サポートは（基本的に）今でもコール センターでヘッドセットを付けた人たちが担当しています。
新しい世界では、そのような古いモデルは不十分です。私たち Google はそんな状況を変えたいと考えています。
Google は先ごろ、Customer Reliability Engineering（CRE : 顧客信頼性エンジニアリング）という新しい専門職を発表しました。この新たな役職に就く人のミッションは、Google と Google Cloud Platform のお客様とが運用に関して運命共同体となり、お客様が Google に委ねている重要なアプリケーションに対するお客様側の管理権限を高め、金銭的なものよりも意義のある運命を共有することにあります。
その妥当な理由を把握するまで少し時間がかかりましたが、最終的に次のような考えに落ち着きました。
人は、自分の環境を管理したいと進化的に思ってしまうのです。これは、生き抜くための特性として本当に価値のあることです。そのため管理できないと感じると、あまりいい反応を示さなくなります。危険度が高ければ高いほど、管理できないことに対して、より大きく反応してしまいます。
さて、大いに価値があるこのサービスに対し、なぜ Google は課金しないのでしょうか。
Google の SRE において最も重要な方策は、呼び出しの際に使われるページャを手放すことができるという点なのです。CRE にしても同じことが言えます。お客様の側において適切にバグが修正されなかったり、共同での検視作業や衛生的な運用が行われなかったりしたときは、Google はページャをお客様にお返しすることになります。
ここで気をつけていただきたいのは、0 ドルというのは無料と同じではないということです。Google レベルの厳しい運用基準を達成するには、お客様の側でも継続的に責任を持っていただかなくてはなりません。
これには時間も努力も必要です。達成に向けては Google もお客様を支援しますが、それでもお客様が自ら取り組む必要があります。この契約がどういったものかについては、上で紹介した書籍『Site Reliability Engineering』をご覧いただき、そこに書かれた概要に取り組む意思があるかどうか自ら問いかけてみてください。
企業がお客様に対して「一緒にやっていきましょう」と言うことが流行していますが、企業側がその役割をきちんと果たしているケースは多くない、というのが実情です。
真に「一緒にやる」人たちは、双方に対する義務感があり、お互いの責任を背負っています。共通のゴールに向けて共同で作業し、相互にやり取りする金銭よりも重要な運命を共にするのです。
このプログラムはすべてのお客様に適しているわけではありません。実際、努力が必要なので、お客様の大半は申し込まないのではないかと私たちは見ています。
25 年前と同じようなものはほとんど存在しません。ただ、カスタマー サポートだけは別です。サポートは（基本的に）今でもコール センターでヘッドセットを付けた人たちが担当しています。
新しい世界では、そのような古いモデルは不十分です。私たち Google はそんな状況を変えたいと考えています。
Google は先ごろ、Customer Reliability Engineering（CRE : 顧客信頼性エンジニアリング）という新しい専門職を発表しました。この新たな役職に就く人のミッションは、Google と Google Cloud Platform のお客様とが運用に関して運命共同体となり、お客様が Google に委ねている重要なアプリケーションに対するお客様側の管理権限を高め、金銭的なものよりも意義のある運命を共有することにあります。
お客様が感じる不安
クラウドを導入している組織を外から見ていると、非常に不安を感じているのがよくわかります。その妥当な理由を把握するまで少し時間がかかりましたが、最終的に次のような考えに落ち着きました。
人は、自分の環境を管理したいと進化的に思ってしまうのです。これは、生き抜くための特性として本当に価値のあることです。そのため管理できないと感じると、あまりいい反応を示さなくなります。危険度が高ければ高いほど、管理できないことに対して、より大きく反応してしまいます。
ここで、基本的なパブリック クラウドのビジネス モデルを考えてみましょう。これを要約すると、次のようになります。
「物理的なインフラと（ある程度の）データを管理することは断念しましょう。不安が生じますが、その代わりクラウドによってさらに大きなイノベーションを得ることができ、コストが低減し、セキュリティは高まり、安定性も増します」
完全に合理的な取引ですが、私たちの中にある最も進化的な衝動の 1 つに逆らうことになります。お客様がこのビジネス モデルに不安を感じるのも当然です。
私は過去 5 ～ 6 年の間に、安価な料金と引き換えに不安を飲み込むことをよしとしないお客様がたくさんいることを学びました。特にクラウドに関しては、ほとんどの企業で危険が伴うため、なおさらです。ところが、クラウド業界はこうした現状を理解するための取り組みを十分に進めているとはいえず、すでに一部の著名な企業はオンプレミスに戻ってしまっています。
クラウド プロバイダーは、この危機的状況を自らの意思で無視しています。クラウドを導入していない圧倒的多数の企業にアプローチするには、こうした不安に対応することが必須条件の中心となるにもかかわらず、そのことから目を背けているのです。
クラウド テクノロジーの時代において、これは完全に間違っています。
「物理的なインフラと（ある程度の）データを管理することは断念しましょう。不安が生じますが、その代わりクラウドによってさらに大きなイノベーションを得ることができ、コストが低減し、セキュリティは高まり、安定性も増します」
完全に合理的な取引ですが、私たちの中にある最も進化的な衝動の 1 つに逆らうことになります。お客様がこのビジネス モデルに不安を感じるのも当然です。
私は過去 5 ～ 6 年の間に、安価な料金と引き換えに不安を飲み込むことをよしとしないお客様がたくさんいることを学びました。特にクラウドに関しては、ほとんどの企業で危険が伴うため、なおさらです。ところが、クラウド業界はこうした現状を理解するための取り組みを十分に進めているとはいえず、すでに一部の著名な企業はオンプレミスに戻ってしまっています。
クラウド プロバイダーは、この危機的状況を自らの意思で無視しています。クラウドを導入していない圧倒的多数の企業にアプローチするには、こうした不安に対応することが必須条件の中心となるにもかかわらず、そのことから目を背けているのです。
サポート チームのミッションとは
組織内におけるサポート チームの役割は、以前は非常にわかりやすいものでした。質問に答え、問題を素早く効率的に解決することです。しかし今では、すべての IT サポート チームの役割は、結局のところほぼ FAQ やヘルプ センター、確認リスト、手続きといったものになっています。クラウド テクノロジーの時代において、これは完全に間違っています。
不安を抱えるお客様は、その気持ちを理解してもらいたいと考え、思いやりや人間性を求めているのです。「そう感じているのは自分たちだけではなく、プロバイダーも自分たちのことを真剣に考えている」といったことを感じ取りたいのです。何と言っても、お客様は私たちのプラットフォームやツールにビジネスを委ねているのですから。
今、この時代において、真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。
人は不安がなければ、うまく動いているプラットフォームから真剣に移行するために時間を費やし努力しようなどとは考えません。移行の決断に至るのは、払拭できない不安から始まるのです。
クラウドを利用しているお客様は、実際あまりクラウド プロバイダーの信頼性を気にしてはいません。それよりも、製品化されているアプリケーションの信頼性を気にしているのです。稼働しているクラウドの信頼性については、間接的に気にしているに過ぎません。
アプリケーションの信頼性は、次の 2 つによって成り立ちます。
今、この時代において、真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。
人は不安がなければ、うまく動いているプラットフォームから真剣に移行するために時間を費やし努力しようなどとは考えません。移行の決断に至るのは、払拭できない不安から始まるのです。
不安は 1 を信頼性で割った数値に等しい
お客様が不安を感じる最も大きな原因が信頼性であることは間違いありません。ただし、目に見えにくい原因も存在します。クラウドを利用しているお客様は、実際あまりクラウド プロバイダーの信頼性を気にしてはいません。それよりも、製品化されているアプリケーションの信頼性を気にしているのです。稼働しているクラウドの信頼性については、間接的に気にしているに過ぎません。
アプリケーションの信頼性は、次の 2 つによって成り立ちます。
- クラウド プロバイダーの信頼性
- アプリケーションのデザインやコード、運用などに内在する信頼性
1. については、すでに業界内でも課題として認識されています。大手クラウド プロバイダーでは、この課題のみに対応するエンジニアを何千人も雇っているほどです。
Google はこの分野の専門職を作り上げた草分け的存在で、Site Reliability Engineering（SRE : サイト信頼性エンジニアリング）という専門職を設けています。
ちなみに、この SRE については書籍も出版されています。
では、2. についてはどうでしょうか。製品化されたアプリケーションのデザインや実装、運用に内在する信頼性に関して、誰か気にかけている人はいるのでしょうか。
今のところ、気にかけているのはお客様だけです。
ところが、これに対する業界内での標準的な回答は次のとおりです。
「ここにホワイト ペーパーや成功事例があり、コンサルタントもいます。あまり変なことをしなければ、アプリケーションもまあ大丈夫ですよ」
クラウド業界ではお客様に対し、私たちのプラットフォームに生計を預けてくださいと提案します。ビジネス パートナーになりましょう、そして管理することは断念してくださいとお願いします。その代わり私たちは、…… ホワイト ペーパーを提供しますから、と言うのです。
お客様が不安に思うのも、ごもっともです。というか、不安に感じるべきですよ！
クラウド プロバイダーがどれだけ革新的だとしても、スピードや規模を提供したとしても、この取引ではお客様は常に不公平さを感じることでしょう。特に、夜中の 3 時に何かおかしなことが起こった場合はそうですよね。
もしかして、私の言うことは大げさすぎると思っていませんか？
数か月前、Dropbox はパブリック クラウド プロバイダーの利用を止め、オンプレミスに戻ると発表しました。この選択に関し、同社は決断に至るまでのプロセスを時間をかけて説明し、「自社の運命は自社で管理したい」という強い思いを示しました。管理できないことの不安が積み重なって限界に達し、同社はクラウド プロバイダーのもとを去ることにしたのです。
…… むかしむかし、2 つの王国が戦争していました。開発者王国と運用者王国です。
開発者王国は、ユーザーにとって面白く便利な機能を開発し、提供することに専念していました。同王国では、イノベーションが早ければ早いほど良いとされていたのです。開発者民族の理想の世界では、開発が中断されることは決してなく、新しくて魅力的な製品が展開されていました。
一方、運用者王国では、出荷されたシステムの信頼性を気にかけていました。というのも、夜中の 3 時に何かが起こったら、呼び出されるのは運用者民族だからです。いったんシステムが安定すると、運用者民族はもう何も新しいものは提供したくないと考えていました。新しいバグは 100 % 新しいコードから発生するためです。
この 2 つの王国は何十年にもわたって戦い続け、多くの血が流されました（まぁ本当の血ではありませんが、メールって結構炎上しますよね ……）。
そんなある日、Benjamin Treynor-Sloss という人がいい考えを思いつきました。
彼は長年にわたる争いの根底にある思い込みが間違っていることに気づき、この問題を全く新しい方向に持っていったのです。それは、エラー予算という考え方でした。
開発するシステムは（おそらくペースメーカー以外は）どれも 100 % ずっと稼働し続ける必要はない、というのがその考えです。システムが中断されることはありますが、ユーザーは自分のことに精一杯なので気づくことはないというのです。
つまり、ほぼすべてのシステムに、利用できないことに対する許容範囲をほんの少し（ゼロではなく）設けるということです。そのダウンタイムは予算とみなします。システムのダウンタイムが予算内に収まれば、そのシステムは健全というわけです。
たとえば、可用性 99.9 % のシステムが必要だとしましょう。これは、このシステムを利用できない時間が 0.1 % あっても大丈夫だということです（1 か月を 30 日だとすると、43 分に相当します）。
システムが 43 分以上ダウンするようなことをしない限り、何でも思う存分開発し展開できます。ただし、予算をオーバーした場合は、開発時間のすべてを問題解決とシステムのさらなる安定化に向けたコードを書くことに費やさなくてはなりません。より安定したシステムを開発すれば、翌月にエラー予算をオーバーする可能性が低くなり、より多くの新しい機能を開発したり展開したりできるのです。
要するに、エラー予算によって開発者民族と運用者民族のお互いの思惑を一致させることができ、好循環が生まれるのです。
こうした考えから、SRE という専門職が誕生しました。
Google では、SRE と開発者の間に基本的な合意事項があります。システムが一定の条件を満たしている場合、SRE はシステムの稼働時間と健全な運用に責任を持つこととする、というものです。その条件は次のとおりです。
Google はこの分野の専門職を作り上げた草分け的存在で、Site Reliability Engineering（SRE : サイト信頼性エンジニアリング）という専門職を設けています。
ちなみに、この SRE については書籍も出版されています。
では、2. についてはどうでしょうか。製品化されたアプリケーションのデザインや実装、運用に内在する信頼性に関して、誰か気にかけている人はいるのでしょうか。
今のところ、気にかけているのはお客様だけです。
ところが、これに対する業界内での標準的な回答は次のとおりです。
「ここにホワイト ペーパーや成功事例があり、コンサルタントもいます。あまり変なことをしなければ、アプリケーションもまあ大丈夫ですよ」
クラウド業界ではお客様に対し、私たちのプラットフォームに生計を預けてくださいと提案します。ビジネス パートナーになりましょう、そして管理することは断念してくださいとお願いします。その代わり私たちは、…… ホワイト ペーパーを提供しますから、と言うのです。
お客様が不安に思うのも、ごもっともです。というか、不安に感じるべきですよ！
クラウド プロバイダーがどれだけ革新的だとしても、スピードや規模を提供したとしても、この取引ではお客様は常に不公平さを感じることでしょう。特に、夜中の 3 時に何かおかしなことが起こった場合はそうですよね。
もしかして、私の言うことは大げさすぎると思っていませんか？
数か月前、Dropbox はパブリック クラウド プロバイダーの利用を止め、オンプレミスに戻ると発表しました。この選択に関し、同社は決断に至るまでのプロセスを時間をかけて説明し、「自社の運命は自社で管理したい」という強い思いを示しました。管理できないことの不安が積み重なって限界に達し、同社はクラウド プロバイダーのもとを去ることにしたのです。
初めての SRE
Google が CRE という専門職を作った背景には、これまでの 10 年にわたる SRE という専門職の道のりがあります。SRE の歴史について詳しくない人のために、ここで少し説明しておきます。…… むかしむかし、2 つの王国が戦争していました。開発者王国と運用者王国です。
開発者王国は、ユーザーにとって面白く便利な機能を開発し、提供することに専念していました。同王国では、イノベーションが早ければ早いほど良いとされていたのです。開発者民族の理想の世界では、開発が中断されることは決してなく、新しくて魅力的な製品が展開されていました。
一方、運用者王国では、出荷されたシステムの信頼性を気にかけていました。というのも、夜中の 3 時に何かが起こったら、呼び出されるのは運用者民族だからです。いったんシステムが安定すると、運用者民族はもう何も新しいものは提供したくないと考えていました。新しいバグは 100 % 新しいコードから発生するためです。
この 2 つの王国は何十年にもわたって戦い続け、多くの血が流されました（まぁ本当の血ではありませんが、メールって結構炎上しますよね ……）。
そんなある日、Benjamin Treynor-Sloss という人がいい考えを思いつきました。
 |
| Google の Vice President である Benjamin Treynor-Sloss。SRE の父と呼ばれている |
彼は長年にわたる争いの根底にある思い込みが間違っていることに気づき、この問題を全く新しい方向に持っていったのです。それは、エラー予算という考え方でした。
開発するシステムは（おそらくペースメーカー以外は）どれも 100 % ずっと稼働し続ける必要はない、というのがその考えです。システムが中断されることはありますが、ユーザーは自分のことに精一杯なので気づくことはないというのです。
つまり、ほぼすべてのシステムに、利用できないことに対する許容範囲をほんの少し（ゼロではなく）設けるということです。そのダウンタイムは予算とみなします。システムのダウンタイムが予算内に収まれば、そのシステムは健全というわけです。
たとえば、可用性 99.9 % のシステムが必要だとしましょう。これは、このシステムを利用できない時間が 0.1 % あっても大丈夫だということです（1 か月を 30 日だとすると、43 分に相当します）。
システムが 43 分以上ダウンするようなことをしない限り、何でも思う存分開発し展開できます。ただし、予算をオーバーした場合は、開発時間のすべてを問題解決とシステムのさらなる安定化に向けたコードを書くことに費やさなくてはなりません。より安定したシステムを開発すれば、翌月にエラー予算をオーバーする可能性が低くなり、より多くの新しい機能を開発したり展開したりできるのです。
要するに、エラー予算によって開発者民族と運用者民族のお互いの思惑を一致させることができ、好循環が生まれるのです。
こうした考えから、SRE という専門職が誕生しました。
Google では、SRE と開発者の間に基本的な合意事項があります。システムが一定の条件を満たしている場合、SRE はシステムの稼働時間と健全な運用に責任を持つこととする、というものです。その条件は次のとおりです。
- システムが（開発中に）Production Readiness Review（PRR : 製品化準備調査）という厳しい検査プロセスに合格すること
- システムを開発した開発チームが、（モニタリングなど）重要なサポート体制を保ち、定期検査や検視などの重要なイベントに積極的に関与すること
- システムが定期的にエラー予算をオーバーしないこと
開発者が SRE との関係でこうした責任を果たさない場合、SRE はシステムから離れることになります（もちろん呼び出しにも応じません！）。
このような基本的な関係を構築することで、Google には協力し合うという企業カルチャーが生まれ、高い信頼性と驚異的スピードのイノベーションにつながったのです。
CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施します。
このプロセスの最終段階で、Google はお客様に対し「ここに御社システムの信頼性に関するギャップがあります。これが御社のエラー予算です。信頼性を向上したい場合は、こういった変更が必要です」とお伝えします。
また、呼び出しをする場合やチケット発行に関する基準にお互いが合意できるよう、共通のシステム モニタリング体制を構築します。
Google の PRR に合格するには、お客様の側で多くの作業が必要となります。しかし、その努力の結果、次のような成果に結びつくのです。
このような基本的な関係を構築することで、Google には協力し合うという企業カルチャーが生まれ、高い信頼性と驚異的スピードのイノベーションにつながったのです。
CRE のミッションは何か
Google では、お客様に対しても同じようなアプローチが必要だという結論に達しました。SRE の原理や教訓をお客様に適用すると、CRE にたどり着くのです。CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施します。
このプロセスの最終段階で、Google はお客様に対し「ここに御社システムの信頼性に関するギャップがあります。これが御社のエラー予算です。信頼性を向上したい場合は、こういった変更が必要です」とお伝えします。
また、呼び出しをする場合やチケット発行に関する基準にお互いが合意できるよう、共通のシステム モニタリング体制を構築します。
Google の PRR に合格するには、お客様の側で多くの作業が必要となります。しかし、その努力の結果、次のような成果に結びつくのです。
- 呼び出しに関する共通認識が生まれる。お客様がユーザーに呼び出されないようになれば、Google も呼び出されることはない。
- 最重要事項に関するチケットが自動で生成され、エスカレーションされることになる。
- CRE チームがお客様の悲惨な現場の対処に参戦する（お客様が必死でがんばったとしても、悲惨な出来事は避けられないため）。
- Google のデザイン調査や製品調査を経たシステムが手に入る。
追加料金は 0 ドル
さて、大いに価値があるこのサービスに対し、なぜ Google は課金しないのでしょうか。Google の SRE において最も重要な方策は、呼び出しの際に使われるページャを手放すことができるという点なのです。CRE にしても同じことが言えます。お客様の側において適切にバグが修正されなかったり、共同での検視作業や衛生的な運用が行われなかったりしたときは、Google はページャをお客様にお返しすることになります。
ここで気をつけていただきたいのは、0 ドルというのは無料と同じではないということです。Google レベルの厳しい運用基準を達成するには、お客様の側でも継続的に責任を持っていただかなくてはなりません。
これには時間も努力も必要です。達成に向けては Google もお客様を支援しますが、それでもお客様が自ら取り組む必要があります。この契約がどういったものかについては、上で紹介した書籍『Site Reliability Engineering』をご覧いただき、そこに書かれた概要に取り組む意思があるかどうか自ら問いかけてみてください。
企業がお客様に対して「一緒にやっていきましょう」と言うことが流行していますが、企業側がその役割をきちんと果たしているケースは多くない、というのが実情です。
真に「一緒にやる」人たちは、双方に対する義務感があり、お互いの責任を背負っています。共通のゴールに向けて共同で作業し、相互にやり取りする金銭よりも重要な運命を共にするのです。
このプログラムはすべてのお客様に適しているわけではありません。実際、努力が必要なので、お客様の大半は申し込まないのではないかと私たちは見ています。
ただ、数十億ドルものビジネスをクラウド上で行っている大企業が、このような機会を見逃すのは愚かな行為だとも思います。この機会をリスクから逃れる練習だと考えてみてください。しかも、どんな CEO でも飛びつくような価格で入手できるものなのです。
Google がこのような投資を行っているというだけで、お客様の不安が軽減されているのです。
新たなソーシャル契約で不安を軽減
過去数週間、Google は CRE という専門職とその計画についてお客様にひっそりとお伝えし、その関心度を探ってきました。多くのお客様は最初に大きなため息をつき、肩の力が抜け、そして安心した表情になっていきます。Google がこのような投資を行っているというだけで、お客様の不安が軽減されているのです。
もちろん、これは奉仕活動ではありません。単にビジネスとして理にかなっているだけです。こうした原理や実践が、お客様が Google を使い続ける大きな動機となります。技術的にロックインするのではなく、人間関係を通じて構築される一体感につながるのです。
お客様の重要なアプリケーションに特有の信頼性が備わることにより、Google のプラットフォームの実質的な信頼性も向上します。その結果、Google のイノベーションの速度も高まります（これこそ Google が本当にやりたいことなのです）。
クラウドのお客様へ。これはお客様にふさわしい新たなソーシャル契約です。
クラウド事業を拡大し、イノベーションを進めたいとお考えのサービス プロバイダーの方へ。私たち Google と一緒に取り組み、事業を拡大させましょう。
Google と同じクラウド プロバイダーの方にも、こうした新しい専門職を広めるようご協力いただきたいと思います。これこそが、すべてのお客様が本当に必要としていることなのですから。
* この投稿は米国時間 10 月 10 日、Director of Google Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿はこちら）の抄訳です。
- Posted by Dave Rensin, Director of Google Customer Reliability Engineering (CRE)
お客様の重要なアプリケーションに特有の信頼性が備わることにより、Google のプラットフォームの実質的な信頼性も向上します。その結果、Google のイノベーションの速度も高まります（これこそ Google が本当にやりたいことなのです）。
クラウドのお客様へ。これはお客様にふさわしい新たなソーシャル契約です。
クラウド事業を拡大し、イノベーションを進めたいとお考えのサービス プロバイダーの方へ。私たち Google と一緒に取り組み、事業を拡大させましょう。
Google と同じクラウド プロバイダーの方にも、こうした新しい専門職を広めるようご協力いただきたいと思います。これこそが、すべてのお客様が本当に必要としていることなのですから。
* この投稿は米国時間 10 月 10 日、Director of Google Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿はこちら）の抄訳です。
- Posted by Dave Rensin, Director of Google Customer Reliability Engineering (CRE)
0 件のコメント :
コメントを投稿