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. 私たちのオペレーションチームの仕事はビジネスロジックとリソースロジックの間を翻訳することで、私たちのアラートの半分は基本的に人間にコストやスケーリングの分析やトレードオフを手動で行わせることを求めてる。なぜなら自動化できないから、根本的なリソースモデルやプラットフォームがそれを不可能にしてる。これを修正するには、内部を見なきゃいけない。

でも、複雑さのコストは下がらない でも、現在のソフトウェアの複雑さのどれくらいが問題空間に内在するもので、どれくらいが単なる悪いデザインや人間のシェフが多すぎるせいなのか？おそらくほとんどが後者のカテゴリーだと思う。もっとソフトウェアが増えるかもしれないけど、全体的には複雑さが減るかもしれない。LLMが十分に良くなればね。

うーん、実際にはSREやDevOpsは、昔呼ばれていたシステム管理者とはあまり変わらないと思う（私も元システム管理者だし）。中途半端な企業の未来は、SREがLLMの火事を追いかけることになると思うけど、競争力のあるビジネスはシステムを構築するためのはるかに良い戦略を持っているはず。人間は依然として最も効率的で一般的な推論者だから、エネルギーを大量に消費する脆弱なAIモデルに実装の大部分を任せるのは、失敗する道を選んでいるようなものだと思う。

ごめん、個人的なことじゃないんだけど…8年の経験が必要なのに「ジュニア」って肩書きだけって、かなり劣悪な環境に近いと思う。別の話だけど、あなたが言ってるオペレーションの優れたスキル（プロジェクト管理や要件収集など）が、私の$dayjobでも問題になってるのはわかる。でも、そういうスキルはどの時代でも価値があると思ってたし、AIの時代だけに必要なわけじゃないんだよね。ただ、みんなの経験や環境によって期待値は変わるよね。それに、私の$dayjobでは、ソフトウェアベンダーに適正に支払うための資金が全然足りなくて、結局は払った分の品質しか得られないから、しょっちゅう質が低いアウトプットになっちゃう。低コードってわけじゃなくて、ちゃんとしたフルコードの開発者を雇ってるし契約もしてるんだけど、質が悪いことが多いんだよね。低コードの提供や機会が増えて、よりしっかりしたAI開発支援が進む中で、SREの役割がますます重要になるんじゃないかな。低コードや低コストの分野で働いてるかどうかに関わらず。

ブートキャンプの開発者は、職場で常に厳しい状況に置かれる運命だったと思う。彼らは、真のコンピュータサイエンスの学位を持つエンジニアが不足していることの症状で、コードがそこそこできる人を探して妥協した結果だよね。でも、この問題は最終的には解決する。今は、コードが簡単で安価な時代に、コンピュータサイエンスの卒業生が多すぎる。ブートキャンプの開発者を雇うメリットはあまりないと思う。でも、もし本当にコーディングが好きで、大学でCSを学べなかったなら、ブートキャンプは楽しむための良い経験になるかもしれない。仕事探しの目的ではなく、自分の楽しみのためにね。ただ、あまりお金をかけないように。