本稿は以下で公開されている Ben Treynor 氏と Niall Murphy 氏のインタビュー記事の翻訳です。
免責事項/Disclaimer
本稿は 非公式 の翻訳記事です。インタビュアーの Niall Murphy 氏 (@niallm) に翻訳を公開することの許可は取っています。本稿の内容に関して Niall Murphy 氏と Google 社は一切の責任を負いません。
Japanese version of the Ben Treynor Sloss interview; thanks @t2y_en
4:33 PM - 27 Jan 2017
誤訳などありましたら私宛に編集リクエストを送って頂けると助かります。
補足事項
- 本文中に英文で引用しているところは、原文の中でその段落の対談の中から抜き出されている文章です。おそらくその文脈における要旨として強調されているのだと思います。翻訳するにあたり、その部分だけ翻訳しても意図が伝わりにくいと思ったため、やり取り全体の段落を読んだ上で見返すと良いのでは？と考えて原文の英文をそのまま掲載しています
- SRE は「サイト信頼性エンジニアリング」と「サイト信頼性エンジニア」の両方を指す略語でもあります。訳文中で SRE という略語を使うときは前者の「サイト信頼性エンジニアリング」を指す意図か、もしくは総称として使っています
サイト信頼性エンジニアリングとは何か？
このインタビューでは、Ben Treynor が Niall Murphy とともにサイト信頼性エンジニアリング (SRE) とは何か、どのように、そしてなぜうまく機能するのか、業界における運用チームと SRE の差別化となる要因について、彼の考えを共有します。
インタビューをする人
Niall Murphy, サイト信頼性エンジニア
インタビューされる人
Ben Treynor, エンジニアリング VP
Fundamentally, it’s what happens when you ask a software engineer to design an operations function.
Q. ところで SRE とは何ですか？
A. 基本的には、運用機能を設計するためにソフトウェアエンジニアにお願いするときに発生するものがそうです。私が Google にやって来たとき、ソフトウェアエンジニアと歴史的に手作業で解決してきた問題をソフトウェアを使って解決する傾向のある人たちの両者が混在したチームの一員になれたことは幸運でした。つまり、それはこの運用作業を行う公式チームが作られたときでした。このチームでは自然と「すべてのことはソフトウェアの問題として扱える」という考え方で取り組み、実践してきました。
そのため、基本的に SRE は歴史的に運用チームが行なってきた作業をします。しかし、その作業をソフトウェアの専門知識をもつエンジニアを使って行います。こういったエンジニアは本質的に人間の労働を自動化しようとする傾向とそのためのスキルの両方をもっているという事実を当てにしています。
Google にあるたくさんの行動条件の上で SRE チームが自分たちの環境とどのように関係をもつかの原則があります。本番環境だけでなく、開発チーム、テストチーム、ユーザーなどもそうです。これらの規則や作業のプラクティスは、運用作業ではなく主にエンジニアリング作業をうまくやることに役立ちます。
Q. このことは日々の作業や SRE チームの責任にどう反映されていますか？
A. 一般的には、SRE チームは、可用性、遅延、パフォーマンス、効率性、変更管理、監視、緊急対応、およびキャパシティプランニング (容量計画) の責任を負います。
今日の、多くの運用チームは同様の役割を担います。チームによっては私が認識している内容の一部がない場合もあるでしょう。しかし、SRE が行う手法はそういった運用チームとは大きく違っています。複数の理由からそう言えます。
最も重要なことは採用です。私たちはソフトウェア開発能力と開発志向をもつエンジニアを採用します。
SRE 向きのソフトウェアエンジニアとは、プログラミング言語、データ構造とアルゴリズム、そして効率的なソフトウェアを書くことを熟知している人たちです。重要なことは、あるサービスの提供開始時にそのソフトウェアのタスクを処理しているとして、そのタスクの規模が拡大したとしても そのタスクを効率良く処理しなければなりません。
Typically we hire about a 50-50 mix of people who have more of a software background and people who have more of a systems background. It seems to be a really good mix.
私たちの採用プロセスでは、Google SWE の基準をほぼ満たしていて、私たちにとって役立つ補完的なスキルセットがある人かどうかを試験します。ネットワークエンジニアリングと Unix システム管理は、私たちが確認する2つの共通内容です。他にもあります。優れたソフトウェアスキルをもっていても実務での開発経験が少なく、その上でネットワークエンジニアリングかシステム管理の専門家でもあるという人がいるとします。私たちはそういった人を SRE チームに採用します。通常、採用においては (前述の) ソフトウェアエンジニアリングの資質に優れた人とシステムエンジニアリングの資質に優れた人を 50:50 の割合で採用するようにしています。ソフトウェアとシステム両方の割合が同じになるようなこの割合がチームを機能させるのにとても良いです。この混ぜることが本当に優れているようにみえます。
私たちは年間を通して不変の採用基準があります。どんなに応募者を探すことが難しい時期でもあります。そして、採用数を増やすためにその基準を緩和するという圧力もかなりありました。私たちはこの点において自分たちの基準を決して変更しませんでした。私の考えでは、これは SRE にとって極めて重要な意味をもっています。その理由は最終的に求めているチームが、基本的に手動で何度も繰り返すようなことを 受け入れない 人たちのチームでありながら、開発組織の他方ではたくさんの同じ学術・知的背景をもつチームでもあるからです。これは SRE と SWE の間で相互尊重と相互語彙が関係するということを促しています。
エンジニアリングの役割とは対照的に通常の運用の役割の中でみることの1つは、義務に関することだけでなく、背景や語彙そして結局のところは敬意の隔たりがあります。私にとってこのことが病理です。
Q. Google 以外の組織でソフトウェアエンジニア (SWE) と運用チームとの間で評価基準が同じではないというのをよく見かけました。その評価基準の違いにより、双方で異なるインセンティブをもつという要因からうまく連携がとれません。つまり、このことが今日この業界に存在するあるモデルに行き着く理由です。そのモデルとは、SWE チームがなにかを書き上げて、運用チームに対する壁の上にそれを放り投げます。運用チームはなんとかそれを動かそうと試みるものの、できなかったらそれを投げ返す、などいったやり方です。
A. この文脈において、SRE とは何かという組織的な違いからみえることがあるのも興味深いです。それは単に個人の働き方の習慣だけではありません。
SRE がもっている重要な特徴の1つは、SRE チーム間で移動するのが自由であり、そのグループが流動性をもつために十分な規模があることです。さらにサイト信頼性エンジニアからソフトウェアエンジニアへ転向することも自由です。しかし、一般的にサイト信頼性エンジニアはソフトウェアエンジニアへ転向しません。
この移動の自由さの必要条件は、一般的なソフトウェアエンジニアとソフトウェアエンジニアに転向したサイト信頼性エンジニアが等価であり、そういった人たちと SRE にいるシステムエンジニア間での補償が等価であることです。こういった人たちは全員がパフォーマンス、生産性、専門性においてすべて同じ基準をもちます。そしてソフトウェアエンジニアと SRE にいるソフトウェアエンジニアチームの間では自由に移動します。SRE チームに所属していて自分が携わっているプロジェクトまたはシステムが「ひどい」ものだと気付いた誰もが気軽に移動できることの重要な点は、そのことが優れた脅しとなります。この脅しは開発チームにとって運用するのが恐ろしいシステムを構築しないインセンティブとなります。
私がすべての時間を使う脅しはこうです。「基本的に私たちは SRE チームのエンジニアのみを採用しています。もしあなたが運用上の大きな課題があるシステムを構築しているなら、そのサイト信頼性エンジニアは去ってしまい、私はそれを許可するでしょう。」それから、サイト信頼性エンジニアが去ってそのグループが最小必要人数を下回るときに私たちは運用責任を開発チームへ戻します。
Google ではこの反応を制度化しています。それは 生産準備レビュー (PRR) のようなものです。PRR は、引き継ぐ前にそのシステムとその特性の両方を調べることと、さらに責任を共有することにより、こういった状況に陥ってしまうことを避けるのに役立っています。これが現実の世界でシステムがどういうものであるかについて幻想をもたずに私が知っている最もシンプルで最も効率的な方法です。さらにこの方法はシステムを低負荷で運用するという巨大なインセンティブを開発チームにもたらします。
Q. 適切なインセンティブを獲得することは重要です。そういった目的のためにサイト信頼性エンジニアが少ないということがなぜ重要なのでしょうか？
We will assign SRE’s where they’re going to do the most good.
A. 初期の段階で私たちは選択肢をあまりもっていませんでした。私たちは SRE の需要と同じぐらいの速度でサイト信頼性エンジニアを採用できなかったため、サイト信頼性エンジニアは常に希少な存在でした。「サイト信頼性エンジニアが最良のことをやろうとしているところに割り当てるつもりだ。」と単純に言うことにより、その希少性を私たちの優位性に使いました。運用のみのプロジェクトは比較的低い投資収益率 (ROI) になります。私はサイト信頼性エンジニアをそういったプロジェクトへは投入しません。はるかに成熟して確立されたプロジェクトが他にあり、そういったプロジェクトに配属されたサイト信頼性エンジニアはかなり高い限界利益を得られるでしょう。歴史的に、私たちは1人のサイト信頼性エンジニアが同じ業務を行う2人のソフトウェアエンジニアに置き換えられることをみてきました。その理由の1つとしてサイト信頼性エンジニアは生産関連技術やそのサポートモデルの専門家になる傾向があるからです。ざっくり言うと、それが SRE の需要を高く維持していることに役立っている方程式です。供給よりも高い需要は、その業務そのものが曖昧なところに引き込まれないようにすることに役立っています。
Q. SRE は業務が始まった後で正しく保守されることをどのように保証しますか？
We care deeply about keeping SRE an engineering function, so our rule of thumb is that an SRE team must spend at least 50% of its time doing development.
A. SRE は四半期ごとにサービスレビューがあります。それは意図的にあるチームが担っている ops の作業量を測定するために設計されています。この作業量に慣れてしまうと、自分の時間のほとんどを ops のみの作業に使ってしまいます。このレビューは、そういった状態にあなたが陥っている場合に私たちが気付いて適切な措置をとるということを確認する外部チェックです。ときにはそのチームを解体することもあります。
私たちは、SRE がエンジニアリング機能を有することについて非常に関心をもつため、大まかなやり方として SRE チームが実際に開発を行うために少なくとも50%の時間を使っている必要があります。それでは、どうやってその時間を強制しているのでしょうか？まず第一にその時間を測定する必要があります。測定後、開発作業に費やす時間が50%未満になっているチームはかたくなに方向性を変えたり、チームを解体することを請け負います。
Q. この業界の仕事を50%といったように比較できるのかが私は分かりません
A. 全くその通りです。Google における SRE とその他の、名目上は「SRE」という仕事を区別するという観点から、1つの簡単な方法を用いてあなたが身につけている習慣を理解してみましょう。それでは、他のグループとインタビューしたり、将来的に参加する可能性のあるチームのメンバーと話したりするとき、つい最近何行ぐらいのコードを書いたか、そして労働時間のどのぐらいの割合がコードを書くことに費やされたかを調べてみてください。もし彼らの回答が「私は先月3つの機能を書いた」であるなら、まぁもう答えは出ていますよね。
In Google SRE, we pay close attention to the promotion rates by level for everybody irrespective of systems or software background, and compare that to the overall Eng vs Eng SWE promotion rates to make sure that they are statistically identical. And they are.
あなたが尋ねたいと思う別の質問は、SRE 内部または外部で働いている誰が上位の開発者かということです。どのくらいの頻度でサイト信頼性エンジニアは昇進するのでしょうか？サイト信頼性エンジニアの昇進率は SWE チームと同じでしょうか？
Google の SRE では、私たちは Eng 全体と Eng ソフトウェアエンジニアリングの昇進率が統計的に同じであることを確認するために、システムまたはソフトウェアの背景に関係なく、全社員向けにレベルごとの昇進率に細心の注意を払います。 And they are.
Q. 昔からある運用と開発グループとの競合についてもう少し話して頂けますか？
The incentive of the development team is to get features launched and to get users to adopt the product.That’s it!… the incentives of a team with operational duties is to ensure that the thing doesn’t blow up on their watch.So these two would certainly seem to be the tension.
A. 業界における昔からの競合の1つは、開発チームが何かを言う前にその開発チームが検討しなければならない長いチェックリストをサポートするように ops チームが考え出すことです。これは重大な競合です。その理由は2つのグループのインセンティブが実際に異なっているということが明確にみえるところの1つです。他のすべてのことを剥ぎ取って、開発チームのインセンティブはいくつもの機能を提供して、そのプロダクトを採用するユーザーを増やすことです。それだけです！そして、同様に他のすべてのことを剥ぎ取って、運用の職務を担うチームのインセンティブは自分たちの管轄で障害が起きないことを保証することです。そのため、この2つは確かに葛藤した状態にあるようにみえます。この状態をどのように解決しますか？
The business or the product must establish what the availability target is for the system. Once you’ve done that, one minus the availability target is what we call the error budget… So Ideally, we would spend all of our unavailability budget taking risks with things we launch in order to get them launched quickly.
SRE が行なっている解決方法が エラー予算 です。そして、それはとてもうまく機能しています。エラー予算はこの基本的な観察から生じます。基本的にすべてのことを100%にしようとするのは誤った可用性の設定です。おそらくペースメーカーは適切な例外です！とはいえ、一般論として、あなたが想像できるどんなソフトウェアサービスまたはシステムにとって100%は適切な可用性の目標ではありません。それは100%利用できるシステムと99.999%利用できるシステムとの違いが分かるユーザーはいないからです。その理由はユーザーとソフトウェアサービスとの間には他の要素がたくさんあります。そこで運用しているソフトウェアサービスのわずかな差というのは、失敗する可能性があるその他すべてのノイズの中に紛れてなくなってしまうからです。
100%がシステムの可用性の目標として誤っているとするなら、それではシステムにとって適切な可用性の目標とはどのぐらいでしょうか？私はそれがプロダクトの質問であると提案します。これは全く技術的な質問ではありません。それは、ユーザーはどんなことに満足するのか、ユーザーがどのぐらいの料金を支払ってくれると仮定するのか、直接的なのか間接的なのか、そしてユーザーの代替手段は何なのかといった質問です。
ビジネスまたはプロダクトは、そのシステム向けに可用性の目標が何かを確立しなければなりません。その目標設定を行った後、その可用性の目標から1を引いた値を私たちはエラー予算と呼んでいます。つまり99.99%利用できるなら0.01%は利用できないという意味です。ここで私たちは0.01%の非可用性を許容しました。**これが予算です。**私たちはこの予算を超えて使わない限り、やりたいことのうち何に予算を費やしても構いません。
それでは、私たちはエラー予算を何のために使いたいと考えるでしょうか？開発チームはいくつもの機能を提供して新たにユーザーを獲得したいと考えます。そのため理想的には、素早く機能を提供してユーザーを獲得するためにリスクを取りながら非可用性の全予算を費やすでしょう。この基本的な前提がモデル全体を説明しています。このようにして SRE 業務を概念化するとすぐに次のようなことを言い出すでしょう。よく分かった。段階的な発表を行うか、1%の実験段階をもつようにしよう。素早く機能の提供ができるように、機能の提供に関して多くの機会がもてるように、リスクをとる非可用性の予算を少なくする方法は明らかだ。良さそうですね。
さらにこのアプローチは他に良い帰結を迎えます。もしそのサービスがネイティブにそこにあってエラーを投げたら、その0.01%の時間は何も得られないものに非可用性の予算を浪費しているということが分かります。そのため、サービスのネイティブな安定性を改善するために SRE チームと開発の世界の両方にインセンティブがあります。そして、例えば機能を提供することのように、自分たちのやりたいことに使うために予算を残しておくようにするでしょう。
これに関する他の重要な利点は、開発チームがやろうとしていることについて SRE がどんな判断も下す必要がないということです。SRE は測定したり強制したりはしますが、私たちが評価したり判断したりはしません。私たちの見解は次の通りです。「測定した可用性がサービスレベル目標 (SLO) を上回っている限り、それは明らかに良い仕事をしているということです。取り組んでいるものがどのぐらいのリスクがあるのか、実行するのにどのぐらいの実験をすべきなのか、といったことについて正確な判断をしています。そのため、全力でやりいことを始めましょう。私たちが干渉するつもりはありません。」そしてこれは予算を使い切る まで 継続します。
予算を使い切ってしまったとしたら、私たちにはテストが適切に行われているのかどうか分かりません。それは機能について開発チームと SRE チーム間にある非対称性の大きな情報となります。その機能がどのぐらいのリスクがあるのか、どのぐらいのテストを行ったのか、そこのエンジニアたちは誰なのか、などです。通常、私たちはそういったことを知りませんし、推測して想像を膨らませるようなこともしません。本当に私たちはそんなことをやろうとすらしないのです。私たちが可用性のレベルを元に戻せる唯一 確実 な方法は、あなたが非可用性の予算を獲得するまで新たに行うすべてのサービスや機能の提供を止めることです。つまり私たちが行うことはそれです。もちろん、このような出来事はめったに起こりませんが、起きることはあります。私たちは P0 バグの修正以外の新たなサービスや機能の提供を凍結します。P0 バグの修正とは、それ自体が可用性の向上を表します。
これは2つの素晴らしい効果があります。1つは、開発チームがやろうとしていることを後から批判するといったこのゲームの中に SRE がいないということです。そのため、敵対関係や情報隠蔽またはその他のことをする必要がありません。それが正に望んだものです。
もう1つは、私が予想していなかったことの1つではありますが、本当に重要なことだと分かったことがあります。開発チームはそのゲームがどう機能するかを解明した時点から自分たちで基準を設けてそれを満たすように自警するということです。多くの場合、Google で稼働しているシステムは1つの開発チームで開発されているものではありません。異なる機能に携わっているたくさんの小さな開発チームがあります。もし個々の開発者の視点からそのことについて考えるなら、そういった開発者はエラー予算を浪費して1週間後にリリースを控えたクールな新サービス提供を妨害してしまうような、ちゃんとテストされていない機能を望まないかもしれません。新サービス提供の前に多くのテストが行われたことを確認するために複数チームの統括マネージャーを開発者が探すように動機付けます。一般的に、開発チームと SRE チーム間の情報の非対称性よりも開発チーム内部での情報の非対称性はずっと低いです。そのため、開発者がそういった会話をするための最高の設備が整っているのです。
Q. ノーと言うために SRE にとっての道徳的権限は、現在も Google で確立されています。
A. そして、それは極めて重要なことです。
Q. 外部の組織が SRE 機能をまわしていくにあたり、この権限を必要とすることがどのような役に立つのでしょうか？
A. 道徳的権限は物理の質問です。それは事前に目標となる SLO が定まっていることを確立することが極めて重要です。その理由はそのことがサービスを測定するという合意に対する標準であるからです。SRE はお互いが前もって望んで合意したものを強制したり単純に測定したりする場所になります。非常に恵まれたポジションとなります。
実際に道徳的権限をどのように生成するかという観点では簡単です。あなたが所属している開発チームはこのサービスの SLO がどういった基準値を満たすかについて前もって私たちと話しています。そして、現在その基準値を下回っているとします。私たちができることは他に何もありません。これは物理の問題です。ここであなたの心を変えることはできません。私たちはこの図がユーザーにとっての最善の利益であることを前もって話しあいました。いまそのデータが明らかに基準値を下回っていることを示しています。そのため、私たちはその可用性のレベルが回復するまでただ待たなければなりません。この待ち時間の一部を次のリリースが再び基準値を下回らないことを保証するために使えます。
Q. SRE チームのライフサイクルについてお話しましょう。ライフサイクルを通してどのように業務は変わるのでしょうか？
A. 今日この方法は 能力成熟度 モデルを通して一般的に行われています。多くのモデルがあり、そのほとんどすべてが同じことを言っています。それらのモデルはすべて基本的な質問から始まります。あなたがチームとして行なっていることを自分で把握していますか？という質問です。それとも、問題空間の一部をそれぞれのメンバーが把握していて、単にそういったメンバーの集まりに過ぎないのですか？ほとんどのチームはその論点から始めます。あなたは多くのメンバーを抱えていて、それぞれのメンバーが部分的に仕事内容を把握しています。そして、あなたが何かを行う必要があるとき、やりたいことを達成できる専門知識をもつ人たちを組み合わせてメンバーを獲得できます。
このような方法では、そのサービスがうまくいかないとき、その成果はメンバーが誰だったかに依存しています。これは私たちが混乱した状況と呼んでいるものと言えます。チームが成熟するにつれて、混乱した状況から定義された状況へと移っていきます。例えば「ここに私たちが行なっている標準的な方法があり、その内容は文書化されているため、チームの誰でも同じことができます。」と言うことから始めます。そこに居合わせたメンバー個々人の組み合わせには全く依存しません。そこから実際にそのサービスを測定しているところで最適化に関することに移ります。ここであなたは「これは何が起きるべきだろうか」と言いました。実際に起こったことをみて、その内容と起きるべきだと期待していることを比較します。それから、あなたは指事する内容を変えたり、メンバーの行動を変えたり、もしくはその両方を変えたりして、期待したことが起こるまでずっと繰り返します。
So anything that scales headcount linearly with the size of the service will fail.
私たちが測定するものに四半期ごとにサービスレビュー (前段で説明しました) があります。このサービスレビューは SRE の環境がどのようなものかを表します。彼らが話す内容、彼らがどのぐらい幸せか、彼らが一緒に働いている開発チームを好んでいるかどうかなどに関わらず、重要なことは彼らが時間を使っているところを測定することです。これは2つの理由により重要です。1つ目の理由は、彼らが運用作業で時間の大半を使っている場所をできるだけ早く気付きたいからです。あなたはその時点で時間を使っていることを止めて是正しなければなりません。その理由はすべての Google サービスは成長します。そして、一般的にそういったサービスはサービスに携わるメンバーの人員が増えるよりも速く成長します。**そのため、サービスの規模とともに線形的に人員が増えるものは失敗します。**もし運用に大半の時間を使っているなら、その状況は自己修正するものではありません。最終的にいま運用で自分のすべての時間を使っているところで危機に陥ります。そして、危機に陥るだけでは終わらず、その後そのサービスが停止するか他の重大な問題をもつかのどちらかになります。
2つ目の理由は、繰り返しになりますが、エンジニアリングチームです。チームのメンバーをみたら、チケットを閉じたりリソースを設定したりすることを行なっていて、メンバーのキャリアや目標は前に進んでいません。メンバーはエンジニアリングスキルと、メンバーやそのマネージャーが開発したいものの専門知識をもっています。そして、それが開発されました。その理由はメンバーはソフトウェアエンジニアであり、ソフトウェアを書いて、自分たちより上位の経験と能力があるエンジニアと一緒に働くことで学ぶからです。そのため、メンバーがそういった行動をとっていることを確認する必要があります。
Q. 監視や最も重要な SRE の責任について議論しましょう。SRE と監視の背景にある哲学について話して頂けますか？
A. 監視を行う古典的な方法は、何らかの値または条件、その他どんなものでも構いませんが、ずっと見張っていて、関心をもつ状態になったときにメールを送ります。私が知っているものではこれが最も一般的な監視方法です。しかし、メールは監視にとって適切な手法ではありません。もしメールを読んで何か作業を行う必要があるかどうか決めることを人間に求めているとしたら、それは間違っています。この答えはアラートが発生しているところで人間はいかなる場合も決して解釈しないようにすべきです。私たちが書いたソフトウェアが解釈するようにします。私たちは行動を取る必要があるときに単に通知を受け取るだけです。
そのため、私の見解では、有効な監視出力は3種類 しかありません。人間が今すぐ行動を取らなければならないと言う アラート があります。そこで起きていること、または起きようとしていることに対して人間がその状況を改善するために直ちに行動を取らなければなりません。
2番目の分類は チケット です。人間が行動を取る必要はありますが、直ちに行う必要はありません。もしかしたら数時間、通常は数日の猶予をとりますが、何らかの人間の行動を必要とします。
3番目の分類は ログ です。誰もこの情報をみている必要はありませんが、有事の際の調査目的に利用できます。ただ期待していることは誰もそれを読まないことです。
私はこの3つの分類の中に当てはまらない監視出力をみたことがありません。監視を実装しようとする人がログを生成するものの、それをチケットとして扱わないという間違いをするところを私は何度も繰り返しみてきました。それは大きな間違いです。普通にみていて気づくことの1つに次のようなことがあります。「ああ、そう、すべての監視システムの出力機能に多くのレビュー時間を費やさなければなりませんでした。」うーん、そんなことはしません。それは多くのユーザーまたは多くのインスタンスを抱えていくにつれて規模が拡大していきません。その機能の量が増えていくと品質が低下します。監視設定または監視パーサー、もしくはその他の監視に関するものを扱うシステムを開発する必要があります。監視出力を3分類のうちの1つに変えるシステムを書く必要があります。
Q. それでは、監視とは何かが失敗したときに通知を伴って支援するものですか？さらにそれを素早く修正することを支援しますか？
A. そうです。もっと一般的に言うと、私たちがシステム全体の可用性について話すときに2つの基本的なコンポーネントがあります。どのぐらいの頻度でシステムが停止するかを表す平均故障間隔時間 (MTBF) があります。そして、故障したときに復旧するまでの時間を表す平均修復時間 (MTTR) があります。
MTBF と MTTR の2つを扱う何らかの機能が可用性です。これらの時間の範囲を超えてしまいながら、可用性の高いシステムを作るための方法が2つあります。(もちろん範囲の両極端の間でも大丈夫です。もしその数字を積み重ねるならばですが)障害の発生が本当に稀となる、または障害が発生したときに本当に素早く復旧できるでしょう。Google は極端に高い可用性に関して当然のごとく評価を得ています。そして SRE が両方を行うことでその評価を獲得しています。
最初のレベルでは、私たちのほとんどの時間を使う場所です。私たちは障害を許容するシステムを構築します。多層防御 と同様、グレイスフル・デグラデーション の視点について話します。この2つは同じものから変異したそれぞれ異なるものです。障害は発生します。重要なことは障害が発生したときにユーザー体験が価値のあるところで劣化しないことです。そうすれば、ユーザーは目にみえる問題を実感することなくその問題を復旧する十分な時間がとれます。自動化されているのでほとんどの障害に関して MTTR は数ミリ秒ですみます。一般的にうまくいかないものに対して2分以内に対応できる人間はいません。もしユーザーへの影響なく障害が発生するようなものを望んでいるとしたら、最良の方法は自動的に修復することです。私たちは多層防御によって自動修復を行います。
システムの異なるすべてのレイヤーにおいて、ユーザー体験が影響を受けることなく単一障害点を許容するように設計されています。それはデータセンターレベルの単一障害点であってもです。すべてのことが自動的に行われます。人間は指一本すら上げません、そして人間がそれについて知っておく必要も多くの場合はありません。ただ障害が発生するだけです。それが多層防御です。
グレイスフル・デグラデーションは完全に崩壊することなく障害を許容する能力です。例えば、ユーザのネットワークが遅くなっているとき、ハングアウトのビデオシステムはビデオの解像度を低下させて音声品質を維持します。Gmail では、遅いネットワークだと大きな添付ファイルを読み込まないようになるときがあります。ですが、ユーザーはメールを読み続けられます。これらはすべて自動化された対応であり、人間が何もすることなく高可用性をもたらします。
Q. 人間が何かしなければならないときのケースはどうですか？
A. 人間が実際に何かをする必要があるとしたら MTTR がとても重要になります。具体的に MTTR の「R」の部分は、人間がそのページを取得した、または人間がそのページをトリアージした、それとも人間が何かをするためにキーボードをもっているとしても、そういった内容ではないことを意味します。人間が行うことは、誤った判断をしたり効果のない措置をとってしまうことに対して、正しくその状況を評価して適切な是正措置をとることです。
他の業界では運用マニュアルがありますが、私たちは運用の事前訓練を行います。その訓練とはオペレーターが様々な緊急状態に対して適切に対応する方法を知っていることを私たちが確認する手段です。しかし、あなたがソフトウェアエンジニアのグループに入って「運用の事前訓練を行います」と言ってみたら、気付くかどうかはともかく、メンバーの瞬膜が目を覆い、すぐに会話を終えることになるでしょう。このことに対応できる方法の1つはロールプレイングゲームから発想を得ることです。ソフトウェアの界隈にいる多くのエンジニアはどこかでロールプレイングゲームをしたことがあります。その経験がない人たちでも少なくとも聞いたことぐらいはあるでしょう。
そのため、運用の事前訓練をしたい人はいないですが、Wheel of Misfortune のゲームには誰もが乗り気になります。このコンテキストでは、Wheel of Misfortune はロールプレイングゲームを進める中で障害を選択するために統計的に調整された仕組みにすぎません。そのロールプレイングゲームとは、1人の人間がダンジョンマスター (この場合は「システム」) の役割を果たし、そして別の人はオンコールエンジニアの役割を果たします。ドキュメントが好きな人たちは聞いてください。私たちはこのシナリオで何が起きるのか、オンコールエンジニアはどう言うかを記録しました。そして、オペレーターが実際に行うべきだったことと比較しました。その後、私たちは追加の情報もしくは理想的な対応が行われたことに関するコンテキストを提供するために「運用マニュアルのためのチーム」という脚本を調整しました。
運用の世界で何が SRE を機能させるかの一環は、考える必要がなくなるまで適切な対応を行うようにメンバーを訓練することです。そして、私たちは文化的に相性の良い方法でその訓練を行いました。もしあなたがこの訓練をしている SRE グループをみたら、実際にそのグループメンバーはそういった演習を楽しみにしているでしょう。その理由は知っていることを誇示する絶好の機会であり、そのことが楽しいからです。
Q. 私たちはすべてではないですが、SRE の責任の一部について話しました。キャパシティプランニング (容量計画) についてはどうでしょうか？
A. 需要予測やキャパシティプランニングでは、予測された将来の需要のために十分な多層防御があることを確認しているかをみることができます。ほとんどの企業がそういった計画を行なっているようにはみえないということを除いて特別なことは特にありません。
Google SRE と他企業で働く人との別の差別化要因となる質問です。そのため、あなたのサービスでどのような N+M の冗長構成をとりますか？よくある回答はこういったものです。「分かりません。サービスがどのぐらいのキャパシティになるのかを評価したことががないからです。」
彼らは正確にそういったことを言わない場合もあるかもしれません。しかし、もし彼らが自分たちのサービスのベンチマークをどのように行っているか、負荷の100%または130%に対するサービスの応答をどう測定しているか、需要の頂点に達したときにどのぐらいの予備のキャパシティがあるのかについて話すことができないのだとしたら、彼らは知らないのです。需要予測やキャパシティプランニングが存在しない場合、頻繁に停電や多くの緊急事態になると予想できます。
Q. 従来のモデルでは IT はコストセンターです。それは基本的に損失を防ぐことについてであり、コストセンターとして認識されているために大きく変化をする特別なインセンティブがありません。SRE モデルでは効率を改善し、キャパシティを拡張し、プロダクトのより効率的な運用に貢献するよう私たちに権限が与えられています。このモデルにおける上位の意思決定者のインセンティブは何でしょうか？
A. 確かに効率化のためのインセンティブは2つのレイヤーがあります。1つ目は、SRE の人員は無償ではないということです。製品分野は一定数の人員を確保します。その分野では開発者にお金を使う、または SRE にお金を使います。理論的には、そのサービスが SLO を満たしている期間のみ、その最適化のための機能を得るために SRE へ対価を支払う必要があります。そのため、SRE の費用を節約するインセンティブがあります。さらに SRE チームが対処する必要がある作業が発生しないようにチームが書くコードにも注意を払います。その上、ひどいコードを構築している場合、優れたサイト信頼性エンジニアはみんな去ってしまい、自分でそのサービスを運用するか、よくてもいちかばちかの選択に前向きな若手チームをとるかのどちらかです。
2つ目は、もし可用性に対してキャパシティが重要であると認識したら、SRE チームがキャパシティプランニングを担当しなければならないということを認識しています。そして SRE チームがプロビジョニングや変更管理を担当する必要があることも意味しています。それゆえにサービスがどう動作するかとそのプロビジョニングがどう完了するかの機能としての効率的な運用プロセスを獲得します。そのため、その名前が示す通り SRE (サイト信頼性エンジニアリング) は効率的な運用プロセスを改善することに関与しなければなりません。その理由は SRE が最終的にプロビジョニングを制御するからです。そのため、プロビジョニング戦略に最新の注意を払うことにより、総コストに関わるとてもとても大きなレバーを得ます。
Q. Google の SRE は競合環境が増えたことにより苦労していますか？他の組織で「SRE」という用語を使うことについてどう思いますか？
A. 一般的に、人が他の組織へ旅立つとき、そういった人たちは多くの場合戻ってくることが分かりました。他の企業が今日行なっていることと現時点で Google SRE を区別していることは、他の企業にも時間をかけて取り入れられると私は予想しています。単にそれが優れた方法だからです。
もちろん、それは多くの経営支援と意思決定を行うためのデータに依存します。ある問題が上位の管理職の責任となるときが数回発生しています。この場合は技術インフラストラクチャー VP と最終的には CEO です。そういった人たちは常に SRE チームを支援します。そのため、何もやる必要はありません。しかし、すべての企業でそういった経営支援を受けられないかもしれません。
Q. 用語を区別するという点であなたは「DevOps」という用語を知っていますか？
A. 私はその用語をよく知っています。私は数年前に DevOps を思い浮かべて始めました。DevOps は SRE がやることとよく似たことを行なっている人たちを表現しているようにみえます。開発者と運用チームが一緒になってやろうという考えに行き着いていて、私は素晴らしいと考えています。
Q. この用語は定義の見ためが楽しくありません。開発者が運用担当者と密接に連携して働くのは良い考えです。その問題は運用を改善するという点です。もし SRE が行なっている手法を丸ごと受け入れるとしたら、運用を改善するというのは誤ったビジョンです。
A. はい。「DevOps」が実際に意味することは多岐にわたるようにみえます。私たちは過去15年間にわたり現在の SRE の定義を繰り返し行なってきました。重要なコツは、社内の立場を等価にすること、自由な移動、希少性、運用負荷のキャパシティ、エラー予算などがあります。私はこの定義が Google では実際にとてもうまく機能しているとみています。私たちは開発者にとってさらに魅力的な役割となるようにこの定義を進化させていくと同時に、効率的で高可用性をもつ大規模システムの運用をさらに効果的なものになるようにしていくと、私は予想しています。
We’ve iterated to the current SRE definition over the last 15 years… I expect we’ll continue to evolve it to make the role even more attractive to developers while at the same time making it more effective at running efficient, high availability, large scale systems.