ごく普通のエンジニアリング運用チームを強力な SRE チームに変える
Google Cloud Japan Team
※この投稿は米国時間 2019 年 10 月 4 日に Google Cloud blog に投稿されたものの抄訳です。
運用チームにエンジニアを絶えず増員しても、お客様の拡大には対処しきれません。Google のサイト信頼性エンジニアリング（SRE）の原則を適用すれば、運用上の問題にソフトウェア エンジニアリングによる解決手法を取り入れることで、うまく対処できます。本稿では、従来のネットワーク エンジニアリングの通例にとらわれず、SRE に転換することで、Google がグローバル ネットワーク運用チームを変革した方法をご紹介します。Google の本番環境ネットワーキング チームがこの問題にどのように取り組んだのかをお読みいただき、ご自分の組織に SRE の原則をどのように取り入れることができるのかを検討してみてください。
スケーリングの限界
2011 年、Google の本番環境ネットワークは、大幅な増員を続ける優秀なエンジニア チームによってサポートされていました。本番環境には多種多様なテクノロジーが導入され、絶えず成長を続けており、常に注意が必要でした。デバッグ、アップグレード、アップサイジング、修復、モニタリング、インストールといった作業は、24 時間年中無休で行われていました。チームは時間帯の異なる 3 つ地域に分散し、フォローザサン モデルを採用していました。
100 名規模のチームでのコミュニケーションは容易でなく、意思決定はさらに困難でした。その結果、チームは変更に対して否定的な傾向に陥っていきました。変更に対して否定的な姿勢でいることで、Google のアジャイル開発チームをサポートすることが困難になりました。そうした状況に対する当然の措置として、この大人数のグループは、役割をより明確にした少人数のチームに分割されることになりました。テクノロジーをより深く追求できるようになり、効果的な意思決定ができるようになったという点で、この措置は確かに不可欠でした。しかし、それにも限界があったのです。テクノロジーは週 1 回の頻度で更新されていましたが、しばらくすると、作業量に対して利用可能なエンジニアリング リソースが不足し始めました。専門の知識や技術を持つスペシャリストは絶えず必要とされていたので、問題に対して単に人員を投入するということはできませんでした。
たとえば、Google のネットワークには本番環境のトラフィックを転送するルーターが 100 台あり、各ルーターは四半期ごとにアップグレードする必要があるとします。大まかに言えば、各エンジニアリング拠点で 33 台のルーターを 33 名で担当する、つまり 1 人 1 台担当する計算になります。これぐらいなら、四半期ごとに 1 人 1 台ルーターをアップグレードするだけですから、簡単でしょう。
この程度なら大した負担はなさそうですが、たとえば、最新のリリースにバグが見つかり、ロールバックが必要になった場合はどうでしょうか。さらには、ルーターが 1,000 台になった場合はどうなるでしょうか。この場合、1 人のエンジニアが毎月アップグレードしなければならないルーターは 10 台です。それでは 10,000 台の場合はどうでしょう。冗談ではないですよね。一年間毎日、ルーターのソフトウェア アップグレード作業をすることになってしまいます。最終的に、この作業に追われて他の重要な仕事ができなくなることや、この作業に対応するのに十分な人員を確保（トレーニングも必要）するのに苦労することは明らかです。
新たな希望の発見
実際のところ、ルーター ソフトウェアのアップグレードを来る日も来る日も遅れなく行うという作業は、長期的に採用できる仕事とは思えません。私たちはこの作業に以下の特徴があることに気付きました。
●繰り返し
●日常的
おそらくあなたは、ルーターのアップグレードがチームの転換にどう関係するのか、不思議に思われていることでしょう。Google のネットワークの運用についての専門知識は、苦労なしに得られるものではありません。そのため、私たちはネットワーク エンジニアを SRE に転換することを望んでいました（単にエンジニアと SRE を入れ替えるのではなく）。そうすれば、彼らをつなぎとめて、ソフトウェアとシステムに関する彼らの専門知識も維持できるからです。私たちはこれに慎重に取り組み、このルーターのアップグレードという課題を手始めとして、エンジニアリングの成功を重ねることで自信をつけました。
ルーターのアップグレード作業は、ソフトウェア エンジニアリングを必要とするプロジェクトの良い例でした。それは、Google のエンジニアリング担当バイス プレジデント Ben Treynor による SRE の説明にぴったり合致しています。「ソフトウェア エンジニアに運用上のファンクションの設計を依頼したときに生まれるものが SRE の本質である。」
しかし、私たちは Cisco や Juniper などのルーターを熟知したネットワーク エンジニアのチームでした。その時点では、ソフトウェア開発についてあまり知りませんでした。ネットワーク運用の経験があるために、自分たちの問題に対して、ソフトウェア システムを開発するだけで解決できるとは考えませんでした。
私たちは思い切って挑戦しました。問題を解決するためにソフトウェアを開発することにしたのです。ネットワークをサポートするエンジニアとして、ルーターをアップグレードする人員が不足する可能性を真剣に心配していました。その方がビジネスにとってはるかに大きなリスクだったのです。数か月後にはプロトタイプを動かすことができ、周囲の SRE チームや開発チームのパートナーにフィードバックを求めました。
運用グループのシニアリーダーはプロジェクトを先に進めることを許可してくれましたが、それに伴うリスクを慎重に検討する必要がありました。自動化することで、人間にとって面倒な作業が記録的な速さで実行されますが、それが失敗した場合、記録的な損害が生じるためです。Google 社内で SRE アプローチに取り組む最後の領域の一つとして、マシンの世界でのこれまでの経験を生かすことができました。
当初は、ネットワーク デバイスの接続といった直接的な作業がなくなって、ソフトウェアに処理を行わせることに違和感がありました。ソフトウェア プロジェクトへの参加経験がなかったネットワーク エンジニアにとっては、なおさらそうでした。これは、人間が行う仕事をソフトウェアに置き換えるときに誰もが持つ感覚です。やがて、私たちの粘り強さは報われました。設計を公開し、システムの安全機能を具体的に説明したことによって、他のネットワーク運用グループの信頼を得ることができました。
1 年後には、ネットワーク エンジニアがルーターを手動でアップグレードするのは、ルールではなく例外となりました。実際、システムの信頼性ははるかに向上したので、手動でアップグレードを行うためには論理的根拠が要求されるようになりました。短期間のうちに、このアップグレード システムを開発した私たち小さなチームは、自分たちが先頭に立って、非常に新しく、今までにない問題を解決していることに気付きました。すなわち、システムのスケールアップと、信頼性を高めるためのエンジニアリングです。
この段階に達したとき、私たちは SRE の原則を自分たちの領域に適用できることを証明していました。ネットワークには、SRE に本質的に適さない特殊な部分はなかったのです。
その後まもなく、さらに多くのエンジニアが加わって、チームの約 10% が手動作業を自動化するシステムの開発をやりとげるまでになりました。私たちはその効果を測定する指標を作りましたが、それでもなお、Google の成長によって増え続ける作業に遅れずに対応できていないことは明らかでした。
大規模な転換に乗り出す
SRE の実施により、求められる業務に対応する能力が高まったため、私たちは SRE をさらに実施する必要があると判断しました。次の段階は、Google での運用チームから SRE への大規模な転換を全面的に実施することでした。私たちは、ネットワーク エンジニアという職務が、チームまたはビジネスニーズにとってもうふさわしくないことに気付きました。そのため、チームのスタッフ全員をより適切な職務である SRE へと転換する期限を設けました。このことはおそらく、業務に本当の改革が起こっているという非常に強いメッセージになりました。
チームリーダーたちは 1 年半をかけて、4 つの SRE チームを編成する計画を立てました。各チームは、それぞれ Google のネットワーク インフラストラクチャの異なる部分を担当します。3 拠点のうちの 1 つが業務終了時に次の拠点に問題を引き継ぐという、フォローザサンの運用モデルではなく、それぞれの SRE チームを 2 つの拠点に分散し、12 時間ずつオンコールで対応するというものです。
このモデルへの切り替えにはトレードオフを伴い、チームが適応するまでに時間がかかりました。チームのエンジニアは勤務時間外にポケベルを持ち歩くことになり、通常業務のグループは縮小されました。一方で、作業グループの規模が小さくなったため、コラボレーションが増え、意志決定がはるかに楽になりました。今までは毎日違うメンバーに運用上の問題を引き継いでいましたが、より少人数のオンコール サポートの担当者同士でやりとりするようになりました。その結果、責任感が向上し、問題解決への積極性が高まりました。メンバーの通常勤務時間が重なる時間帯に、拠点間での会議を開催することが多くなりました。これによって、2 つの時間帯に分散していても 1 つのチームとしての一体感を築くことができました。
私たちはチーム内での実際のスキルに格差があることに気付きました。まず、スタッフのほとんどはソフトウェア エンジニアリングの経験がありません（ネットワークについては確かな経験があります）。そこで、すべてのスタッフを対象とした社内教育プログラムを作成して自習時間を取れるようにし、能力の向上、実習、質問のための機会を設けました。これは決して自分たちだけで行ったわけではなく、ソフトウェア開発チームと SRE チームの同僚に大いに助けられました。彼らは、私たちが適切な人材を必要最低限の人数だけ確保し、社内でトレーニングできるようになるまで、授業を行い、課題を出し、丁寧に指導してくれたのです。また、SRE への変換を導く能力のある意欲的な講師を数名採用しました。彼らは、エンジニア経験のある人材から選ばれた経験豊富な SRE と SWE でした。
サイト信頼性エンジニアリングに役割を変更するために、既存のネットワーク エンジニアに対して採用面接を行うのは効率が悪く、業務を停滞させることがわかりました。既存のスタッフは残したかったため、面接を社外の人材のみに絞りました。既存のメンバーに求めていたことは面接の準備ではなく、システムを構築して運用上のファンクションを置き換えてくれることでした。そうは言っても、引き続き日常業務をこなす必要があります。この状況に対応するため、新しいプロセスを作成しました。作業実績を提出して Google の SRE にとって重要な能力があることを証明できるようにしたのです。十分な実績が集まったエンジニアは、SRE に転換されるようにしました。
ルーターのアップグレードをはじめ、転換への過程で数多くの新しいシステムが生まれ、成功しました。それらのエンジニア プロジェクトは、私たちの成功への原動力となりました。そして、システムの構築、手動作業の削減、SRE への転換、さらなるシステム構築、システムの信頼性の向上などの過程から成る、永続性のあるカルチャー サイクルとなったのです。
SRE チームの構築に向けて
このページを読んでいらっしゃる方は、Google のネットワークがパケットを転送し続けていることにお気付きになるでしょう。実際のところ、パケットの転送量は 1 桁増加しています。この変革は決して簡単ではありませんでした。組織の管理運営上の問題が山積みで、その他にも作業量の慎重な分析、新しいシステムの計画、スタッフのトレーニング、不安感や不明確で不確かなことへの対処が必要でした。また、もともとのキャリアとはかけ離れたやり方で能力を伸ばすことを学ぶ機会となりました。しかし、最後には達成することができました。
ここに至るまで、多くの人に助けられました。SRE 部門を 1 から立ち上げる場合、だれもがこのような助けをすぐに得られるとはかぎりません。トレーニングおよびカルチャーの引き継ぎができる SRE と SWE がすでにいたことが、大きな成功につながりました。役職はともかく、チームに優秀なエンジニアがいたことが本当に重要でした。彼らは意欲的に SRE の原則とプラクティスを理解して取り入れただけでなく、何よりもコーディングができました。
私たちの理論は正しかったのです。従来のネットワーク エンジニアリング運用チームを、成功した、さらに言えば素晴らしい、SRE チームに変えることができました。
皆さんの組織でこのような変革を検討されているなら、最後にお尋ねします。皆さんの運用チームには、ソフトウェアを開発して問題を解決できるメンバーがいますか。「はい」であるなら、そのメンバーが挑戦できるよう支援してみてください。
本稿の執筆にあたり、見識を共有し、力を貸してくれた多くの人々、特に Steve Carstensen、Adrian Hilton、Dave Rensin、John Truscott Reese、Jamie Wilkinson、David Parrish、Matt Brown、Gustavo Franco、David Ferguson、JB Feldman、Anton Tolchanov、Alec Warner、Jennifer Petoff、Shylaja Nukala、Christine Cignoli の各氏に感謝いたします。
-By Tom Wright, SRE
