SREはリリースを止めたり、修正を要求したりできるから、私の在職中はあまりそうは感じなかったけど、Googleは大きいから、実際にそういう風に振る舞えるチームもあるんだろうね。

同意するよ。多くの場合、開発者がプロダクトの人になる方が、プロダクトの人が開発者になるよりも簡単だと思う。LLMがあっても、技術的なタスクを効果的にこなすには、ある程度の技術スキルとコードを読む能力が必要だからね。もちろん、プロダクトが本当に深いドメイン知識を必要とするものであれば、状況は違ってくるかもしれないけど。

それに、アーキテクトも必要だよね。誰かがロボットのためにきれいな図や仕様書を描かなきゃいけない。ただ、自動化された工場みたいに、必要なのはほんの一部だけなんだ。

C-suiteの役員や株主はどうなるの？自動化から安全なの？

まさにその通り。これはただの人が、俺たちの新しい支配者にいつか頭を下げなきゃいけないってことを理解する前に、藁をつかんでるだけだよ。追記：もしかしたら、彼は完全に気づいていて、遅くなる前に本を売りたいだけかもしれないね。

SREが本番環境の障害をデバッグして「根本的な」技術的原因を探るのは、SREの機能のほんの一部に過ぎない。SREの目標に従えば、これは実際にはほんの一部ではなく、そもそも起こるべきではないことなんだ。はっきり言うと、これは常に必要だってことは分かってるけど、そうなった時は、サイト信頼性エンジニア（SRE）が何かを見落としたからだよね。だから、もしそれが仕事の大部分と見なされるなら…それはGoogleが定義したSREじゃないってことになる。私たちがコメントしているブログ記事とはほとんど関係ないけど、少なくとも私にはデバッグに焦点を当てた部分は見当たらなかった。将来的に信頼性のあるソフトウェアを生み出す能力が重要になるって言ってて、これは正しいと思うし、SREの公式な定義とも合ってる。

Cloud RunやCloud Functionsに関わった経験から言うと、クラウドプロバイダーでないほとんどの会社は、K8sと実際に競争できる中程度の機能を持った実装で、カテゴリー1に入ると思う。Kubernetesは大きな問題で、個人的にはクソみたいなプロトタイプだと思う。業界はそれに飛びついた（GoogleがDockerやAWSに対抗しようとして、コンテナやクラウドがホットな新しいものだった時に、KubernetesはBorgとほぼ同じだと見せかけたから）。それからコミュニティはプロトタイプの状態に固執して、すべてのSAASを買って、プロダクション環境をそれに基づいて構築した。今では、Kubernetesユーザーからお金を搾り取ることで生計を立てているSAASプロバイダーやプラットフォームエンジニア、DevOpsの人たちが自分たちの金のなる木を守ってる。K8sのマーケティングの一環として、インフラストラクチャエンジニアリングをKubernetesの上に構築することとして再ブランド化したけど、K8sは抽象化が漏れたり、膨大な設定面積を露出させたりするから、結局は「K8sだけどもっと設定が必要」って感じになる。あと、「プラットフォームが必要」ってことで、プラットフォームエンジニアリングもやらなきゃいけないし、gitをCIやslackbot/email/2FA、リリーススクリプトに接続するための全くユニークなユースケースのために。私の新しい会社ではこれを修正するために取り組んでるけど、オープンソース化できるのは多分1〜2年後になると思う（まだ一般化されてないし、Kubernetesと同じ過ちを犯したくないから。でも、オープンソースにはするつもり）。問題は主にマルチテナンシー、より良いプリミティブ、プラットフォーム自体でのユーザーストーリー全体のモデリング、スケーリングと状態に関する誤った二項対立や悪い抽象化を取り除くこと。あと、公式のツールがもっと必要で、YAMLがどのゾーンのネットワークホップの2以内に入ったら、バカ帽子をかぶらなきゃいけない。あなたの例では、1. このレベルの粒度でスケーリングやプロビジョニングを考える必要はないはずで、常にマルチテナントのゾーンレベルで行うべき。これはKubernetesが犯した大きな過ちの一つで、Borgはそれをずっと上手く処理してた。2. YAMLは確かにクソだけど、可用性の報告やアラートにはもっと公式なサポートが必要。すべてのeコマースショップや銀行がこれを構築するのは意味がない。3. 大量のアラートや設定は、クラウドプラットフォームがCloud Runのスケーリング速度で同期的/リアルタイムの請求を公開すれば、実際にはビジネスロジックで表現できる。考えてみれば、DevOpsチームが扱う問題の多くは、実際には1. スケーリングイベントを処理できる必要がある。2. コストをコントロールする必要がある。3. 時々これらが対立して、両者の間を翻訳するのに苦労する。4. 誰もプラットフォームレベルでハードな請求制限/強制を設定させてくれない。（私はRun/Appengine/Functionsのためにこれに近いものを実装したけど、本当に難しい問題だと思う。でも、可能だと思う。リアルタイムの使用量→請求→残高のデビットは、私たちのプラットフォームで最初に実装したことの一つだった）。5. なぜかスケーリングとプロビジョニングは別物（部分的にはクラウドプロバイダーが遅いから、部分的にはKubernetesがシングルテナントだから）。6. 私たちのオペレーションチームの仕事はビジネスロジックとリソースロジックの間を翻訳することで、私たちのアラートの半分は基本的に人間にコストやスケーリングの分析やトレードオフを手動で行わせることを求めてる。なぜなら自動化できないから、根本的なリソースモデルやプラットフォームがそれを不可能にしてる。これを修正するには、内部を見なきゃいけない。