適切なエラーハンドリングがなかったせいで、ヌルポインタが原因でバイナリがクラッシュしたんだ。今頃はもう兆ドルのミスになってるよね？

グーグルのポストモーテムは本当に驚かされる。社内から外部まで見てきたけど、詳細さがすごいんだよね。問題は、彼らは絶対に同じミスを繰り返さないってこと。学んで、正しいプロトコルやエラーハンドリングを導入して、さらに堅牢なシステムを作るんだ。でも、グーグルの規模だと、常に何かがうまくいかないことがある。大事なのは、それが顧客やユーザー、他のシステムに影響を与えないようにどう対処するかってこと。正直、これは内部にいないと見えないし、チームごとに見るものが全然違うこともある。宇宙の中で最も複雑なシステムに近づいているかもしれない。人間としてはこれ以上のものは作れないから。もしかしたらAGIはできるかもしれないけど、私たちには無理だね。

これは本当にアマチュアレベルの話だね。NPE、エラーハンドリングなし、指数バックオフなし、テストカバレッジなし、ステージングでのテストなし、段階的なロールアウトなし、致命的な失敗。彼らのSRE本を読んだけど、こういうことは全部書いてあるよね。https://sre.google/sre-book/table-of-contents/ https://google.github.io/building-secure-and-reliable-system... 基準が緩んだのか、それとも本はただのマーケティングだったのか。

このポリシーデータには意図しない空白フィールドが含まれていた。サービスコントロールは、各地域のデータストアでポリシーに対して地域ごとにクォーターチェックを行った。これがそれぞれのポリシー変更に対して空白フィールドを引き込み、nullポインタに当たってバイナリがクラッシュループに入るコードパスを実行した。これはホアの「10億ドルのミス」の別の例だね。

• なぜ意図しない「空白フィールド」（null）が挿入可能なのか？設定には意図しないnullを許さないスキーマタイプが必要だよ。残念ながら、Spanner自体はSQLライクで、フィールドは明示的にNOT NULLと宣言しなければならない。デフォルトはnullableフィールドだ。
• それでも、これらのポリシーを管理するプログラムには独自の型システムがあり、設定用のアプリケーションレベルのスキーマ言語がある可能性がある。これも無効な状態を表現できないようにするチャンスだね。
• それからサービスコントロールでは、データストアからアプリケーションオブジェクトにポリシーをデシリアライズする際に「スキーマオンリード」を証明する機会がある。プログラミング言語の型やアプリケーションレベルのスキーマを使って、データレイヤーを出る前にポリシー行が期待される形を持っているか検証できる。もしかしたらnullポインタエラーはこのレイヤーで発生したかもしれないけど、新しいコードパスで問題が起きたから、無効なデータがデータレイヤーを抜けてアプリケーションコードに入った可能性が高いね。
• 最後に、サービスコントロールアプリケーションはnullポインタ参照を許す言語で書かれている。もし私がこのシステムのメンテナンスをしていたら、最小限の侵襲で考えるのは、ポリシーライターとポリシーリーダーに「タグ付き列挙型」や「ユニオン型」、「和型」を使ってnullを表現できないポリシーを表すアプリケーションレベルのスキーマを導入することだね。理想的には、新しい種類のポリシーはユニオン型に追加される新しいバリアントとして表現できる。これをアプリコードに追加することはできるけど、プログラム全体を安全な言語に書き直す必要はない。残念ながら、プロト3、Googleの通常のスキーマ言語にはこの制約がないみたい。これがあるものの例：https://github.com/stepchowfun/typical

私はクラウドの仕事をしてるけど、このサービスではないんだ。一般的に言うと： - すべてのコードにはユニットテストと統合テストがある - バイナリや設定ファイルの変更は、通常数日かけて、仕事ごと、地域ごとに徐々に展開される。カナリア分析でこのスローな展開を確認する。 - パニックロールバックも、状況を悪化させないように比較的ゆっくり行われる。例えば、ジョブの再起動でデータベースが過負荷になるのを避けるためにね。40分のダウンタイムは4時間のダウンタイムよりマシだ。今回の件についての内部情報はないけど、PMの見解としては、コードはテストされたけど、このエッジケースはテストされてなかったって感じ。クォータポリシーの設定は設定ファイルとして展開されるんじゃなくて、データベースを更新することで行われる。データベースはレプリケーション用に設定されていて、そのため変更が数秒で全データベースに反映されたんだ。バイナリや設定ファイルの変更のように、仕事ごと、地域ごとに適用されるわけじゃなかった。ヌルポインタに対するフラストレーションには同意するけど、もしエンジニアたちがこれを不可能だと思っていたなら、他の言語でのassert()が原因でリクエストがポリシーチェックに失敗する可能性もあっただろうね。この重要なサービスを別の言語で書き直すのは、すべてのポリシーチェックがフラグでガードされていること、すべてのクォータポリシーチェックがオープンに失敗すること、データベースの変更が地域ごとにゆっくり展開されることを確認するよりも、リスクが高いと思う。免責事項：これはすべて非公式で、私の個人的な意見です。

（関連チームにいたことがあるから捨てアカ）サービスコントロール（Chemist）は、ちょっと古いサービスで、約10年前からあって、GCPの多くのAPIにとって認証、認可、監査、クォータなどで重要なんだ。Cloudではほぼ必須。ほとんどのGCP APIの経路にプロキシがあって、バックエンドにリクエストを転送する前にChemistを呼び出すんだ。（だから、ポストモーテムで言われてるfail openの緩和策は機能しないと思う）ChemistとプロキシはどちらもC++で書かれていて、長年にわたってたくさんのレガシーなゴミが蓄積されてきた。チームは広範な静的分析やテスト、段階的な展開、フィーチャーフラグ、赤ボタン、強力な監視/アラートシステムを整えている。特にSREたちはすごいよ。ChemistはIAMやクォータなどのポリシーチェックをたくさん扱っているから、その分野に関わる他のチームもコードベースに貢献してきた。時間が経つにつれて、ショートカットが取られて、そういうチームはすべての変更に対してChemistの承認を得る必要がなくなった。しかし、ここ数年で、組織は多くの変動やオフショアリングを経験してきた。これが、L8/L9が主導する派手で新しいプロジェクトに焦点を当てることに繋がり、品質やメンテナンス、信頼性を優先する代わりに人員を正当化する方向に進んでしまった。このシフトが品質基準の低下や、より早く物を出すプレッシャーの増加に寄与していて（私がCloudを辞めた理由の一つでもある）、Googleで一般的なサーバー/サービスのベストプラクティスがここではあまり一般的ではないんだ。それでも、この特定のケースでは、問題は冴えないコードやコードレビューにあるように思える。（確か、いくつかの失敗があったのにコードがマージされたはず）。Spannerを通じて設定変更を即座に行うのは、さらに悪化させたね。

私は内部の人間だから、捨てアカウントを使ってる。今回のインシデントの根本原因は、リーダーシップが手を抜いてスピードを求めたことだよ。これが何年も続いて、最終的には崖から落ちた。具体的な失敗モードは「死のクエリ」として知られている。クエリが既存のバグを引き起こしてサーバーがクラッシュするんだ。C++サーバーでは避けられない。サービスコントロールはC++で動いていて、死のクエリや他の失敗モードを最小限に抑えるための包括的なエンジニアリングガイドラインを使ってる。今回のインシデントの前には、過去10年間で大きなインシデントはなかった。このインシデントは新しいグローバルクオータポリシーに関連していて、リーダーシップの圧力のもとで急いで作られた。こういう機能は、別のサービスで作るべきだし、少なくとも確立されたエンジニアリングガイドラインに従うべきだよ。報告書に書かれているアクションアイテムについては、確立されたエンジニアリングガイドラインの方がはるかに優れている。チームはできる限りその基準を守ってきた。

インシデントレポートは興味深いね。SREチームの反応が早かった（2分）、その後「赤いボタン」の展開。でも「私たちの大きな地域のいくつか、例えばus-central-1では、サービスコントロールのタスクが再起動する際に、依存している基盤インフラに群れ効果を生み出し（つまり、そのSpannerテーブル）、インフラを過負荷にした。」っていうのがあった。サービスコントロールはこれを避けるための適切なランダム化指数バックオフを実装していなかった。us-central-1では、影響を最小限に抑えるためにタスク作成を制限し、負荷を減らすためにマルチリージョンデータベースにトラフィックをルーティングした結果、完全に解決するのに最大で約2時間40分かかった。私の経験では、こういうことはよくある。特に多くのノードのクオータを回復するような特異な状況では、通常の運用では意味のあるクオータがすぐに超えてしまって、別の失敗シナリオに突入することになる。基盤インフラが耐えられる限り、クオータを一時的に無効にできるのは良いことだし、自然に時間がかかる回復操作を制限するのもいい。

他人にダウンタイムが起こると、みんな「これはジュニアレベルのミスだ」とか批判するのに、自分に降りかかると、避けられなかったとか予測できなかった理由をつけるのが便利だよね。実際、人間はミスをするし、期待が高すぎる。実店舗のビジネスが予期せず閉店しなければならないとき、ドアにサインを貼って謝罪するだけで済む。でもテクノロジーの世界では、年間数時間のダウンタイムにこんなにストレスを感じるのはおかしいと思う。みんなもう少しリラックスしてほしいな。

マルチリージョンがレジリエンスや可用性のメカニズムとしてよく語られるのは面白いけど、実際には大手クラウドプロバイダーはこういう障害時に地域を超えて絶望的に絡み合っているように見える。