Google はなぜダウンしないのでしょうか?

Google の公式データによると、2015 年に同社の Google アプリ スイートは 99.97% の時間利用可能でした。

おそらく私たちはこれを当然のことと思っているかもしれませんが、これは注目すべき事実であり、世界中の何十億もの Google ユーザーは、Google がこれほどエキサイティングなことをこれほど簡単に処理できる理由について考えたことがないようです。

人間の労働をソフトウェアに置き換える

Google はこの問題を説明するために、「Site Reliability Engineering」（中国語では「Website Reliability Engineering」と翻訳され、以下 SRE と表記）という 3 つの単語を使用しました。これら 3 つの単語は特に魅力的に聞こえないかもしれませんが、実際、Google が 10 年間にわたって堅持してきた中核となる哲学です (名前はさらに魅力的ではありません)。

この概念を 1 つか 2 つの文で説明するのは難しいですが、1 つの中心的なアイデアにまとめることができます。つまり、ネットワーク サービスを専門とする IT プロフェッショナルではなく、コーダーがネットワーク サービスを運用できるようにするということです。このアイデアが実装されれば、プログラマーは、運用作業（ここでの運用とは、主にサービスの安定性とパフォーマンスの維持を指します）を完了するために人間の介入を必要としないツールを開発することになります。

「こうして、自分たちで物事をやることに疲れた人々が、これまで手作業で行っていたことをソフトウェアでやるチームを作り上げている」と、ベン・トレイナー・スロスという名のグーグル社員が投稿した。

シリコンバレーの多くの人々にとって、これは常識のように思えます。 Amazon から Box.com まで、このアプローチはテクノロジー業界全体で採用されています。これは DevOps (Development plus Operations) モデルと呼ばれ、ソフトウェア開発者とシステム管理者が何らかの取り組みを通じて結びつくことを意味します。しかし、Chef や Puppet に代表されるように、DevOps モデルは Google の SRE から徐々に進化して以来、大きく変化してきました。 Google は過去 10 年間 SRE については沈黙してきましたが、大規模で効率的なネットワーク運用に関しては過去に沈黙していました。

しかし、Google は現在、SRE 関連の問題についてより積極的に議論する新しい段階に入っています。これは主に、Google が自社のクラウド サービスを促進し、外部の企業が自社のソフトウェア サービスを利用できるようにしたいと考えているためです。それだけでなく、Google は SRE に関連する問題を具体的に調査するための本も執筆しました。

さて、この本のタイトルは『Site Reliability Engineering』です。この本は、O'Reilly（技術書を専門に扱う出版社）から最近出版されたもので、Sloss の論文がこの本の第 1 章として使用されています。

DevOps に興味があるなら、この本は必読です。たとえ興味がなくても、本の冒頭、つまり序文、紹介、第 1 章を読めば、世界最大のネットワーク帝国である Google の原動力を理解するのに十分です。

多くのテクノロジー企業にとって、そして実際、テクノロジー業界以外の多くの人々にとって、システム管理（または運用、何と呼んでも構いません）は最後の仕上げであり、コンピューター サイエンスの最も厄介な側面の 1 つです。

しかし、グーグル社内で「常時稼働」担当副社長として知られるスロス氏は、サイトの信頼性は「あらゆる製品にとって最も基本的な機能」であると主張し、問題を一転させた。結局のところ、「システムが機能しなければ、あまり役に立ちません。」

ヘーゲルの対立物の統一理論

Sloss は SRE の起源です。彼はこのプロジェクトを立ち上げたのは、Google が創業当初に同社の運営プロジェクトの責任者として彼を採用した時でした。 「SRE は、ソフトウェア エンジニアに運用チームの設計を依頼したときに実現するものです」と彼は言います。 「私はチームを設計し、管理しました。まるで私自身が SRE であるかのようにチームが運営されました。」

Todd Underwood は現在、Google の SRE ディレクターを務めています。彼は、Google が Sloss のようなプログラマーを雇うのは当然だと考えている。 「Googleがまだ初期段階にあったころ、何が問題になるのか、どうすれば修正できるのかを明確に理解しているソフトウェアエンジニアはいたが、誰もそれを自分でやりたいとは思わなかった。」

これは実に面倒なことだ。しかし、Chef の CTO (最高技術責任者) である Adam Jacob 氏も、大規模な企業に成長したいのであれば、このような変革は必要だと考えています。 「ソフトウェア開発と実際の運用を結びつけるのは、ごく自然なことです。この 2 つを自然に切り離すことはできません。特に、この問題を歴史的に見ると、このことがよりよくわかるかもしれません。」

開発と運用は従来、まったく無関係な 2 つのレベルであったことを考慮すると、この変革は非常に興味深いものとなるでしょう。開発者は、新しいソフトウェアを作成し、それを修正し、最終的にそのソフトウェアをできるだけ早く一般に公開することに尽力します。一方、運用スタッフは問題が起こらないように全力を尽くしており、最善の方法は変更を最小限に抑えることです。 「これらは無関係な目標だ」とアンダーウッド氏は言う。「しかし、開発と運用を結び付けると、それらの競合する目標が排除され始めるというのがジョークだ」

アンダーウッドはそれを「ヘーゲルの対立物の統一理論」と呼んだ。しかし、彼がそう言ったとき、誰もそれを信じませんでした。 「もうヘーゲルを読まない人がいる」と彼は自嘲的に言った。しかし、この説明は要点を突いています。それが整うと、Google は優れたアイデアをすべてこのモデルに移行するプロセスを加速しました。

開発と運用のバランス

重要な考え方があります。開発と運用の間の衝突を減らすために、Google は 100% の稼働率を要求しません。 Sloss 氏が本の中で述べているように、ネットワーク サービスが常に 100% 利用可能であることを保証することは実際には必要ではありません。ユーザーは 100% と 99.999% の違いを実際に区別することはできません (実際、ラップトップ、WiFi、バッテリーがオフラインになっている時間は 0.001% をはるかに超えています)。稼働時間の妥当な割合（エラー バジェット）を 100% 未満に設定すれば、変更を加えてデバッグするのに十分な時間を確保できます。

「エラー バジェットは開発と SRE 間の摩擦を取り除きます」と Sloss 氏は言います。 「停止はもはや悪いことではありません。これは予想されるイノベーション プロセスの一部であり、開発と SRE の両方が恐れることなく対処できます。」

同時に、Google は SRE が旧式のシステム管理に進化しないようにするためのいくつかの対応する規制も導入しました。原則として、SRE は従来の運用作業 (プログラミングと競合する) に 50% を超える時間を費やすことは許可されていません。 SRE チームで運用が開発よりも優先される場合、Google は運用スタッフの一部を一般的なソフトウェア開発作業に移動します。

「開発と運用の間の意識的なバランスにより、SRE は創造的で自動化されたエンジニアリングに投資する十分な余地を確保できます」と Sloss 氏は述べています。 「もちろん、彼らは作戦にも耳を傾けなければなりません。」

Chef の Jacob 氏は、ここで言及されている 50% の比率はそれほど重要ではないと考えていますが、その姿勢は気に入っています。同氏は「それがビジネスだ。誰かが業務をこなさなければならない。業務はほぼ無限にあるので、それを管理したくなるのも無理はない」と語った。

Google では、SRE を採用する際にも厳格なガイドラインを設けています。採用者のうち 50% ～ 60% は他のすべての Google エンジニアと同じ厳格な評価に合格し、残りのエンジニアは Google エンジニアの 85% ～ 99% のスキルに加えて、UNIX オペレーティング システムやハードウェア ネットワーク プロトコルの徹底的な理解など、SRE に特有のスキルでありながらほとんどのソフトウェア エンジニアが備えていないスキルを備えている必要があります。

これらはすべて、開発と運用の適切なバランスを確保するためのものです。

SREの野望

これは多くのレベルで新しい概念です。しかし、Google チームは、本の中でこのアイデアを説明しようとしたときに、より古い例を選択しました。 Google SRE の精神的な先駆者は、1960 年代にアポロ宇宙船の月面着陸プログラムを作成した MIT 出身のプログラマー、マーガレット ハミルトンでした。ハミルトン自身が言ったように、アポロ計画から生まれた文化の一部は、学ぶべきことが何もないように思える人々も含め、すべての人や物事から学ぶことだった。

ハミルトンさんはプログラマーですが、業務においても重要な役割を果たしています。この点を説明するために、この本では、彼女が娘のローレンをコンピューターラボによく連れて行ったときの話が紹介されています。ある日、ローレンはたまたまボタンを押し、「打ち上げ後シナリオ」プログラムを実行していたコンピューターにアポロ打ち上げ前プログラムを埋め込みました。

これによりシステム全体がフリーズしました。ハミルトンは、実際の飛行中にこのエラーが発生するのを防ぐために、システムにエラー検出コードを追加しようとしました。彼女の上司は、宇宙飛行士がそのような間違いを犯すはずがないと主張して、その考え全体を却下した。しかし、アポロ8号では、宇宙飛行士たちはまさにそのような間違いを犯しました。幸いなことに、ハミルトンはシステムドキュメントに回避策を記載していました。その後の作品でも、彼女はこのエラー監視コードを追加しました。

もしあなたが私のところに来て「寒いよ」と言ったとしても、それは無駄です。しかし、「寒いですね。どうすれば直せるかお教えしましょう」と言えば、あなたは素晴らしいのです、とアンダーウッド氏は言う。 「当社には、何かがうまくいかないことを知っている人、どこでうまくいかないかを知っている人、そして、どうすればそれが起こらないように防ぐことができるかを考え出せる人がいます。」

これは DevOps、Google の用語では SRE です。これら 3 つの単語は大したことではないように聞こえるかもしれませんが、非常に強力なアイデアです。それによって Google が誕生しましたが、アンダーウッドのように哲学的な SRE の中には、さらに大きな野望を持つ人もいます。彼らのビジョンでは、運用自体は開発よりも速く進みます。

「長期的には、誰もこの施設を運営しなくなることを期待している」とアンダーウッド氏は語った。

今日頭条の青雲計画と百家曼の百+計画の受賞者、2019年百度デジタル著者オブザイヤー、百家曼テクノロジー分野最人気著者、2019年捜狗テクノロジー文化著者、2021年百家曼季刊影響力のあるクリエイターとして、2013年捜狐最優秀業界メディア人、2015年中国ニューメディア起業家コンテスト北京3位、2015年光芒体験賞、2015年中国ニューメディア起業家コンテスト決勝3位、2018年百度ダイナミック年間有力セレブなど、多数の賞を受賞しています。