ウェルナー・フォーゲルスのリーダーシップスタイル：内部からAWSを構築したCTO

主要事実： ウェルナー・フォーゲルス（b。1958）は2005年からアマゾンの最高技術責任者（CTO）を務めています（2004年にシステムズ研究の取締役として参加）。彼はVrije Universiteit Amsterdamからの博士号を保有しており、アマゾンが彼を採用する前にスケーラブルなエンタープライズ・コンピューティングを研究しました。彼はAWSの分散システムの基礎のアーキテクトであり、最終的に一貫性のあるデータシステムの主要な理論家です — 彼が共著したDynamopeaper（2007）で形式化されたアイデア。DynamoDBを支える。彼の「すべてが常に失敗する」原則と「構築すればあなたはそれを実行する」DevOpsのエトスは、業界標準の教義になりました。彼はAll Things Distributedで20年以上継続的に彼のブログに書いてきました。これは、テックで最も長く走っているCTOの中の1つです。

フォーゲルス・ユー・ビルド・イット・ユー・ラン・イット・モデル

フォーゲルス・ユー・ビルド・イット・ユー・ラン・イット・モデルは、ソフトウェアサービスを設計して出荷するチームも、その本番運用 — 監視、インシデントへの対応、直接修正 — を所有するエンジニアリング・リーダーシップ・フレームワークです。「すべてが常に失敗する」という付随する格言とペアリングされると、モデルは例外ではなく、予想されるオペレーティング条件として失敗を扱い、最初のコード行からのグレースフル・デグラデーション設計を強制します。結果は、設計決定とオペレーショナルの結果の間の緊密なフィードバック・ループです。フォーゲルスは、それはスケールで実際のソフトウェア信頼性への最速ルートであると主張しています。

ウェルナー・フォーゲルスは、2004年にアマゾンが彼を採用したときに、Vrije Universiteit Amsterdamの分散システムの教授でした。2005年以来、彼のブログAll Things Distributedでこれらのアイデアについて継続的に書きました。彼はスタートアップの創設者やプロダクト・ビジョナリーではありませんでした。彼は、個々のコンポーネントが失敗するときに落ちないという信頼できるソフトウェアを構築する方法を研究するのに何年も費やした学者でした。

アマゾンはその特定の専門知識が必要でした。なぜなら、アマゾンは落ちていたからです。企業は依存関係の複雑な絡み合いに成長していました — チームが他のチームのコードを直接呼び出し、明確なサービス境界がなく、関連のないシステムを破壊する展開。フォーゲルスは2004年にシステムズ研究の取締役として参加し、2005年にCTOになりました。その後、彼は次の2年間、大規模テクノロジー組織が自分たちをどのように構成するかについてのブループリントになったエンジニアリング命令の共著に費やしました。

「構築すればあなたはそれを実行します」は、彼が決してそのために働いた企業の基準教義です。APIマンデート、マイクロサービス・アーキテクチャ、および開発チームが本番システムを所有すべきであるという考え — これらはフォーゲルス隣接のアイデアです。彼の名前が付けられていない場合でも。

彼を研究するのに役立つのは、単なる技術的出力ではありません。それはアカデミックな心がオペレーター問題に適用される方法であり、100億ドルのビジネスにスケールした原則を生み出しました。

リーダーシップスタイルの分解

60/40の分割は、フォーゲルスがテクニカル・アーキテクトとしてもカルチャー・ビルダーとしても研究されている理由を説明しています。APIファースト・アーキテクチャは構造的貢献です。オペレーター謙虚さのポーズは、それが難しく遅い場所を含む、その建築を正直に実装するために、数千人のエンジニアが可能にしたものです。

リーダーシップの主要特性

ウェルナー・フォーゲルスを定義した3つの決定

1. APIマンデート

Bezos API Mandate — Amazon Web Servicesの成長に直接結びついている — ジェフ・ベゾスの考えとしてしばしば説明されます。これは部分的には正確です。ベゾスはマンデートを書きました。しかしフォーゲルスはそれを運用化し、強制し、その周りに建築原則を構築しました。

マンデートはおおよそ：すべてのチームは、データと機能をサービス・インターフェースを通じて露出する必要があります。裏口統合なし、他のチームのシステムからの直接データベース読み取りなし、共有内部コードなし。すべての通信はインターフェースを通じて発生します。そしてインターフェースは、外部の開発者に露出できるように設計されなければなりません — アマゾンが彼らを露出させることを計画していたからではなく、その制約があなたに利便性のショートカットではなく、実際にクリーンなインターフェースを設計することを強制するからです。

そのマンデートのビジネス結果はAWSです。アマゾンは、外部の顧客に奉仕するのに十分な信頼性とクリーンさの内部サービス・インフラストラクチャを構築する必要がありました。彼らが内部で実行していたサービス — 計算、ストレージ、データベース、メッセージング — 他の企業も必要とするサービスであることが判明しました。AWSは、最初から製品として計画されませんでした。それはフォーゲルスが支持し、強制した内部建築規律から出現しました。

今日のオペレーターのために、APIマンデート原則は以下に翻訳されます：あなたの組織の何が、明示的で所有されたインターフェースを通じてではなく、非公式な関係、直接データアクセス、または文書化されていない依存関係を通じて統合されていますか。これらの非公式な統合は、あなたのオペレーション的な負債です。任意のコンポーネントが変更される場合、文書化されていない方法でそれに依存するすべてのものは、予期しない方法で壊れます。APIマンデートは、内部チーム通信のためにREST APIを構築することは必要ありません — それは各システムを所有している人が何であるか、システム間の契約が何であるか、コンポーネントが失敗または変更されるときに何が起こるかを尋ねることが必要です。

2. 「構築すればあなたはそれを実行します」

フォーゲルスはこの原則を2006年のインタビューで明確に表現しましたが、彼はアマゾンでそれを2年前に実装していました。概念はDevOps運動に先立つ数年です。DevOpsが最終的に法制化した大部分を予期しています。

議論は単純です：ソフトウェア・エンジニアは、システムが失敗すると2amで起きたら設計決定が異なります。オペレーション・エンパシー — あなたのコードが本番動作を理解する — は、あなたの決定の結果を所有することを通じて構築されます。Dev とOpsが別々のチームである場合、インセンティブグラデイントが調整されていません：devは機能を出荷したい、オプスは安定性を望みます。彼らの間のハンドオフは、共有責任ではなく交渉になります。

「構築すればあなたはそれを実行します」がそのハンドオフを削除します。機能を出荷するチームは、それを監視し、インシデントに対応し、本番に表示される問題を修正します。これは、設計決定と運用結果の間の直接的なフィードバック・ループを作成します — ソフトウェア信頼性を改善するための最速の方法。

このモデルは投資を必要とします。開発エンジニアにとって本番の所有権を管理可能にする監視、アラート、オンコール・ツール構築する必要があります。本番インシデントを学習の機会として扱う文化を作成する必要があります。そうしないと、オンコール説明責任は、フィードバック・ループを低下させる恐怖の種類を作成します。そして、その説明責任を取ることを喜んでいるエンジニアを採用する必要があります。これはすべてのエンジニアではありません。

アマゾンはその投資を行い、AWSの信頼性記録はそれを反映しています。Andy Jassyは、AWSを構築してリードしてからアマゾンCEOになる前に、この所有権文化を数千人のエンジニアにスケール化しました — モデルが、フォーゲルスが最初にそれを明確に表現したときにほとんどの観察者が可能だと思った以上のサイズで機能することを実証します。AWSが成功したことを見た後、「構築すればあなたはそれを実行する」を採用した企業は、しばしば、根本的なインフラストラクチャ投資なしに句を採用しました。これは、モデルのいくつかの実装がエンジニアリング・チームを燃え尽くした理由です。

3. 年次CTO文字

AWS re:Inventで毎年、フォーゲルスは、前年からアマゾンの約束をレビューし、アマゾンが短い場所を認め、来年の優先事項を設定する公開文を出版しています。彼はAWSの初期の年からこれを行っています。

そのフォーマット — 明示的な説明責任レビューを持つ年次公開約束 — は企業CTOにとって異常です。ほとんどの年次レターは前方向です：ここは来年の興奮したプランです。フォーゲルスの手紙は最初に逆向きです：ここは、我々が行うと述べたものです。ここは我々がしたものです。ここは我々がしなかったことと理由です。

その効果は2倍です。外部的には、アマゾンの約束が善意で行われる開発者およびエンタープライズ顧客コミュニティとの信頼を作成します。なぜなら、過去の約束が尊ばれたかどうかについての公開記録があるからです。内部的には、それは組織を通じてカスケードされる説明責任の基準を作成します：CTOがアマゾンが配信する予定であるかについて公開説明責任がある場合、それらの約束に貢献するすべてのチームは、配信の失敗が実際の結果を持つことを理解しています。

モデルは移譲可能です。ほとんどの組織は四半期ごとの計画サイクルで約束を作成し、決してパブリックに表面化しないレトロスペクティブで評価します。フォーゲルスの貢献は、公開説明責任が、特定的に十分であることについて、これらの約束がどれだけ真摯に行われるかを変えることを実証します。

ウェルナー・フォーゲルスがあなたの職務ですること

CEOであれば、APIマンデート原則はあなたのソフトウェアだけではなく、あなたの組織インターフェースに適用されます。1つのチームが、文書化されたプロセスではなく、非公式な関係を通じて別のものからの情報を取得するたびに、文書化されていない依存関係を作成しました。それは、その関係の中心にいる人が去った、病気になった、または役割を変更するまで、うまく機能します。あなたのCOOに、あなたの組織の重要な情報フローをマップしてもらい、特定の人々が彼らを維持するためだけに存在するものを識別してください。これらはあなたのオペレーション的な単一故障点です。フォーゲルスは非公式で人物に依存するのではなく、インターフェースを明示的に所有してください。

COOであれば、「構築すればあなたはそれを実行する」はオペレーション経営的な同等を持っています：プロセスを設計する人々は、それが機能する方法の結果を経験する必要があります。あなたのオペレーション・チームが顧客成功の担当者が嫌うオンボーディング・ワークフローを設計し、オペレーション・チームが顧客に直接またはrepと話さない場合、フィードバック・ループが壊れています。プロセス設計に本番所有権の同等の構築：誰もがプロセスを指定するかどうかを指定するかどうかは、定期的に指定されたシステムで時間を過ごす必要があります。彼らが作成した摩擦を感じるために十分な通常。

プロダクトリーダーであれば、フォーゲルスの「すべてが常に失敗する」原則はあなたのプロダクト要件に適用する価値があります。ほとんどのプロダクト要件はハッピー・パス仕様として書かれています。すべてが機能するときに何が起こるか。興味深い要件 — あなたのプロダクトの信頼性を決定するもの — は失敗モードです。APIコールが失敗するときに何が起こるか、ユーザーがフロー中盤でコネクティビティを失うとき、サードパーティの統合が予期しないデータを返すとき。あなたのチームに、要件ドキュメントの何パーセントが故障パスをカバーしているかを尋ねてください。20%未満の場合、本番内で予測しなかった予期しない動作をするプロダクトを設計しています。

営業またはマーケティングにいるなら、フォーゲルスの長形の公開通信モデルには、アカウント管理と顧客成功における直接的なアプリケーションがあります。ほとんどのベンダー通信は前方向です：ここは構築していることです。ここはあなたのロードマップです。ここに来ています。フォーゲルスのアプローチは最初に逆向きです：ここは約束しました。ここは配信しました。ここはそこに短い場所です。あなたの最も重要なエンタープライズ顧客は別の四半期ロードマップデックよりもそのフォーマットに反応するでしょう。彼らはあなたのプロダクトが規格があることを知っています。彼らが実際に尋ねている質問は、あなたが正直であるかどうかについてです。

Reworkはフォーゲルスのエンジニアリング教義を小さなチーム所有権にどのように翻訳するか

フォーゲルスはあなたが本番システムで独立したチームを仕事で所有する十分な人員を持つという仮定でモデルを構築しました。Reworkで実行されているほとんどの企業はしません。Reworkがすることは、「誰がワークフローを設計するのか」と「誰がそれを毎日実行するか」の間のギャップを、単一のオペレーション表面の内部に折りたたむことです — CRMパイプライン、自動化ルール、およびエスカレーション・ロジックを設定する人は、取引が失敗するか、SLAが壊れるときにページングされる同じ人です。これは「構築すればあなたはそれを実行する」の小さなチーム版であり、失敗シグナルと修正は同じツールに住んでいるため機能します。Reworkはまた、「すべてが常に失敗する」姿勢をそのデフォルトにエンコードしています。すべての自動化は目に見える故障状態を持っており、すべてのオーナーフィールドが必須であり、すべてのハンドオフはSlack DMではなくログイベントです。10人のオペレーション・チームのために、それはフォーゲルスの信頼性基準への現実的なパスです — プラットフォーム・チームを採用することはできませんが、構築で所有権と故障を可視化できます。

注目すべき引用と教室の外の教訓

彼のAll Things Distributedブログから：「すべてが常に失敗する。」その声明は、20年以上のライティングのさまざまな形で返した彼は、核分散システム原則をキャプチャします：信頼性は失敗を防止することについてではありません。それは、コンポーネントが失敗するときに機能し続けるシステム設計についてです。ソフトウェアでは、グレースフル・デグラデーション、サーキット・ブレーカー、再試行ロジックを意味します。組織では、主要な人物が利用できない、ベンダーが配信に失敗するか、システムが故障するときに機能し続けるプロセスを設計することを意味します。

2022年のre:Inventで、フォーゲルスはクラウドの約束をこのように説明しました。「低いコストで実験する能力は、テクノロジーが私たちに与えた最も強力な贈り物の1つです。」それはマーケティング声明ではありません — それは建築的なものです。分単位でインフラストラクチャをスピンアップでき、使用したものだけを支払うことができるときは、失敗した実験のコストはほぼゼロに低下します。それは、何が価値があるかを試す価値があるかを変えます。レガシー・インフラストラクチャを持つほとんどの組織は四半期の賭け決定を支援します。なぜなら、間違っているコストが高いからです。フォーゲルスの議論は、不確実性に対する正しい応答は、あなたの予測を改善することではなく、実験のコストを低いにすることです。

彼はまた、彼の失敗についてめったに話しません。これは、彼がする場合、注目に値します。2022年のインタビューで、彼はアマゾンの初期のデータベース選択が、年をかけて解決するために数年をかけて必要な重要な移行負債を作成したことを認めました。Jeff Dean Googleでは同様の建築的なーニング・モーメント — システムが1つのスケール用に構築された場所の種類 — に直面しました。次のスケールで機能するのをやめ、これらを公開で名前を付ける意欲は、エンジニアを制度的知識から分離し、エンジニアが制度的神話になるのに分離します。具体的な技術決定が間違っていることが判明した場所を言及する意欲 — 漠然と誤りが行われたことを認識するのではなく — 彼が公開して設定し、おそらく内部で保持する知的基準です。

このスタイルが壊れるところ

「構築すればあなたはそれを実行する」は、本番を所有する上級エンジニアを必要とします。経験の少ないジュニアチームの費用制限されたスタートアップで、小さなチームでのオンコール負担が急速に持続不可能になる可能性があるため、うまく動作しません。アマゾンは、本番所有権を管理可能にする監視、ツール、インシデント対応インフラストラクチャに投資できました。15人のスタートアップは投資できません。

APIファースト・マンデートは、移動を高速化する必要があるジュニア段階の企業も遅くします。あなたがあなたのプロダクトが何であるかを知る前にクリーン・サービス境界を強制することは、不必要なオーバーヘッドを作成します。フォーゲルスの原則は、既に製品マーケット・フィットを持ち、複雑さをスケーリングしている組織に最適化されています。最初の場所で製品マーケット・フィットを発見するための間違ったツールです。

そしてプラットフォーム・ロックインはAWSアーキテクチャーアプローチについて正当な批判です。DynamoDB、SQS、Lambdaなどの深くAWSプリミティブで構築する場合、別のクラウドまたは前提への移動は高くなります。フォーゲルスの反論は、今のオペレーション効率が後の移植性コストの価値があるということです。その取引はリアルであり、すべてのエンジニアリング・リーダーはデフォルトに実際にすべきかではなく、明示的に作成する必要があります。

---

エンジニアリング・アーキテクチャーおよびスケーリングに関連する読書については、Linus Torvaldのリーダーシップスタイル、Andy Groveのリーダーシップスタイル、およびMartin Fowlerのリーダーシップスタイルを参照してください。