17,821 文字
先週、私たちはDevonにバナーコンポーネントのマウント時にイベントを追加するよう変更を依頼しました。その結果、1週間で660万件のpost hogイベントが発生し、733ドルのコストがかかりました。Devonの費用は500ドルで、これにイベント費用733ドルが加わり、合計1,200ドル以上になりました。教訓：AIが生成したコードは必ず複数回レビューしましょう。
おや、これは面白い話題になりそうですね。コードレビューのプロセスから安全対策、私の好きな分析プロバイダーであるPost Hogまで、さまざまなことに触れています。深く掘り下げてみましょう。楽しみです。
ここから学べることは多くあります。将来的に私たちは自分でコードを書く機会が減っていくでしょうから、今回のような間違いをみんなで理解して、今後防いでいくことが大切です。
先に進む前に、Post Hogがこの件に反応し、セールスに連絡するよう勧めて返金対応をしていることに触れておきたいと思います。彼らは「誤りが請求額に反映されるべきではない」と述べています。このような正直なミスをした場合、彼らは助けてくれるでしょう。Post Hogは素晴らしいサービスで、私も同様のサポートを受けた経験があります。彼らのサービスは全体的に素晴らしいです。
では、今日のスポンサーからの短いメッセージをお聞きしましょう。
Work OSは企業向け認証設定を驚くほど簡単にしてくれます。もし別の会社のITチームの管理者からSAMLやOctaの設定確認を依頼されたことがあるなら、その難しさを知っているでしょう。そのため、今日のスポンサーであるWork OSに非常に興奮しています。
最近このような問題に直面した経験から、私も近いうちにWork OSに移行する予定です。彼らは私にこれを言うためにお金を払っているわけではありません。広告のために支払っているだけです。しかし、広告のためにリサーチすればするほど、私たちが行っていることに適した解決策だと実感しています。
将来的に企業がライセンスを購入して、エンタープライズ認証で設定・プロビジョニングできるT3チャットのエンタープライズサポートを提供する予定です。Work OSが登場する前は、これには何週間もの労力が必要でした。今では、ITアドミンパネルを設定して連携先の会社に送るだけです。
自分側で「アプリにアドミンポータルを追加」ボタンをクリックして設定し、リンクを製品を販売しようとしている相手に送るだけです。そうすれば、会社側はあなたに連絡することなく、アイデンティティのプロビジョニング層全体を設定できます。
過去にこれが必要だった人なら、その有用性を理解できるでしょう。まだ必要になったことがない人は羨ましいですが、必要になったときはWork OSを思い出してください。彼らはあなたの生活を格段に楽にしてくれるでしょう。
私の言葉を信じる必要はありません。OpenAI、Cursor、Vercel、Carta、FA、Plexity、Plaid、Socket、Webflow、Loom、Jasperなど、彼らと協業している有名ブランドのリストを見てください。彼らは、エンタープライズ企業やエンタープライズに販売しようとする企業向けの認証ソリューションなのです。ちなみに、最初の100万ユーザーは無料です。
Work OSのスポンサーシップに感謝します。今すぐsoyv.link/workosでチェックしてください。
まず最初に、Devonが提出したPRをレビューしたのか、それともDevonがメインブランチに直接コミットしたのかは明確にされていませんが、このスクリーンショットではミスを修正するためにメインブランチに直接コミットしています。また、彼らはPost Hogで「すべてのイベント」インサイトを作成して、イベントタイプがスパイクした時に検知できると指摘しています。これはどんな分析プロバイダーでも持つべき重要なチャートです。ほとんどのプロバイダーはイベント単位で請求するので、突然大量のイベントが発生した場合、何か大きな問題が起きている兆候であり、すぐに修正する必要があります。
彼らの無料枠（月100万イベント）を超えるほどの本格的な会社でも、それは素晴らしいことです。多くのトラフィックを受けているということです。また、このような無料枠があることで、今回のようなミスを検知する大きなバッファにもなります。
Devonはマスターへの直接プッシュをしないよう努力しているようです。Primeがそうさせようとしても、PRを使うほうを好むようです。これは良いことです。メインブランチにコミットするのではなく、PRだけを作成します。ここまで良いところを見つけましたが、まだまだ学ぶべきことはあります。
AIがコードベースに関わるようになる現実を受け止める必要があります。このような災害をどのように軽減するか考えなければなりません。重要なのは、より安価なAIプロバイダーを使う方法ではなく、AIが生成したコードがあなたを台無しにしないようにする方法です。
ここでは3つの重要なことについて話す必要があります：
コードレビュー文化（私の好きなトピックですが、通常は誰も気にしません）
ユーザーベースの価格設定
安全ネットとアラート
まず退屈な話から始めましょう。コードレビュー文化です。
現実を見つめましょう。誰もコードレビューを好んでいません。ここに大きな問題があります。AIはたくさんのコードを生成します。AIはコードを書くことをはるかに簡単にしますが、レビューの部分ではほとんど役に立ちません。これは最悪です。
ツールや技術が向上するにつれて、面倒に感じることへの許容度は下がります。グラフを描くとすれば、使用しているツールの品質が上がるにつれて、本質的に面倒なことへの許容度は下がっていきます。これは人間がどのように調整するかという性質です。
ほとんどの人にとって、痛みは相対的なものであることを理解することが重要です。比較的幸せな生活を送ってきて、家を買おうとしているときに、誰かがあなたの前にその家を購入し、夢の家を逃してしまったとします。それはひどく感じるかもしれません。しかし、その日を生き延びるための食料を見つけるのに苦労している人にとっては、あなたが世界で最も身勝手に見えるでしょう。痛みは相対的であり、何かがあなたを傷つける程度は、その事象の悪さだけでなく、その周りの状況がどれだけ良いかにも依存します。
AIによって、多くの退屈なこと、苦痛なことが減ってきました。AIが私たちの仕事を奪うことに同意するかどうかにかかわらず、AIは確実に仕事の内容を変えています。Cloudflareのドキュメントが大部分あいまいでも、Claudeと会話したり、Cursorでバグを修正したりするだけで、デプロイできるようになりました。これは奇跡です。新しいことを学ぶプロセスをはるかに退屈でなくしました。
しかし、同時にコードを書く行為自体も退屈でなくなりました。コードの各行を書く行為も痛みが少なくなりました。ジェネレーターに大きく依存するコードベースでは、人々が各行のコードに注意を払わなくなったのと同じように、AIがこれをさらに悪化させていると思います。
T3チャットのような素晴らしいツールを使って何でも質問でき、他のどのツールよりも比較的速くコードを吐き出してくれるのは素晴らしいことですが、それは一種の問題でもあります。LlamaにNext.jsのフルスタックStripe課金システムを実装するよう依頼すると、そのすべてのコードを素早く吐き出すことは驚異的です。しかし、そのコードを盲目的にコピーしてコードベースに投げ込むことになります。
このコードを書く行為は、それを実際にレビューして正しいことを確認するよりもはるかに簡単です。すでにここでミスを見つけています。Stripe/StripeJSは何かかもしれませんが、Stripe公開キーを使用することはおそらくそれほど悪くないでしょう。しかし、このような重要なものについては、個人的には自分で書くか、私のStripe推奨ドキュメントのようなものに従うほうがいいでしょう。Stripeを正気を保ちながら実装するのは難しいので、多くの時間をかけました。AIにこれをやらせることは、どんな理由であれ絶対に信頼しません。
しかし、もし私のチームの誰かがそうして、ClaudeとCursorに大量のコードを生成させてPRを上げたとしたら、彼らはそのコードを実際に読んでレビューするのに私が費やさなければならない労力よりも少ない労力で済むでしょう。
コードレビューは、コードを書くよりも常に少し退屈です。そのコードを何回書き直したかによって異なります。同じ50行を5回書き直した場合はより多くの作業になりますが、一度書いた場合は、それをレビューして正しいことを確認する作業は、最初に書くプロセスよりも多くの労力が必要です。
AIは大量のコードを生成することをはるかに簡単にしましたが、その代わりに仕事中の退屈なことへの許容度をはるかに低くしました。より多くのコードとより少ない労力でPRが増えていますが、それをすべてレビューする労力は減っていません。むしろ、レビューするコード量が増えているので、労力は増加しています。
私はこれらのツールのおかげで、費やした時間あたりのコミット量が増えていることを知っています。これは事実です。毎日これらのツールを使って実際のコードを書いていないと、この事実が見えないかもしれません。効率が上がりますが、その効率は本質的に他のことへの許容度を下げます。
そして現実は、誰もコードレビューを好まなかったということです。だから、それに対する許容度は下がっています。人々はコードレビュー中に注意を払わなくなっています。徹底的にレビューしなくなり、ここやそこに質問をするだけで、「ああ、知らない、Claudeが生成したものだから」という返答になります。
これは私自身にも数回起きました。ウェブサイトに奇妙なコピーがあり、Markが「なぜこれがあるの？」と尋ねると、「ああ、Claudeが生成したもので、生成されたときに読んでいなかった」と答えました。それは良くありません。
私たちはこの事実を受け入れる必要があります。また、コードレビューをより楽しめるように、より多くのことをするよう最善を尽くす必要があります。私はかつて、チームに毎日コードレビューから始まり、コードレビューで終わるという厳格なルールを持っていました。GitHub上で担当しているすべてのPRをクリアするまで、エディタを開くことは許されません。
まだコメントしていない割り当てられたすべてのPRにコメントするか承認すると、コーディングに進めます。一日の終わりには、一日の始まりからのレビューや変更点を確認するために、少なくとも1時間を確保する必要があります。
これは重要です。もっと多くの人がこの文化を持ち、慣れることが必要だと思います。コードレビューが日常の一部になると、それほど悪く感じなくなります。歯を磨くことを毎回決断するように考えると、朝起きたらすぐに行うよりもはるかに面倒に感じるのと同じです。それはあなたの日課の一部でなければなりません。
コードレビューが要求されるものであることは最大の失敗です。コードを作成して出荷したいとき、人々にピンを打たなければならないという事実は、面倒なことを頼むようで気分が悪くなります。「歯を磨いてくれない？」と「私のコードをレビューしてくれない？」と言うのは、本質的に同じような感じがします。これらは私たちの欠陥のある人間の脳で同じように処理されています。
しかし、それが日課の一部であれば、PRを提出すると比較的早くレビューされると信頼できるなら、PRを提出することについてもっと気分が良くなるでしょう。そして、それらのレビューを行うことについても気分が良くなるかもしれません。しかし、それがあなたの文化や日課の一部でなければ、それは常に面倒で悪いと感じるでしょう。
嫌いな指摘をしますが、何度も見ているので言わざるを得ません。コードレビューはオンコール担当者の責任ではありません。あまりにも多くのチームが「ああ、コードレビューね、それはオンコールの一部だよ」と言っているのを見てきました。オンコール当番の週は、一週間中コードレビューをし、インシデントがあればそれに対処し、その結果コードレビューが一切進まなくなります。
私自身、このようなチームにいたことがあります。ひどいものでした。コードレビューはオンコール担当者の責任ではありません。コードレビューは全員の責任です。オンコールも全員の責任だと言っておきますが、それはまた別の議論になるでしょう。
今のところ、コードレビューは私たち全員の問題です。そして、勤勉なコードレビュー文化がなければ、あなたは台無しになるでしょう。
1週間ほど前、GitHubに新しいブランチをプッシュすると自動的にPRを開き、名前と説明を生成するAIボットがあれば便利だとツイートしました。何かをプッシュしたときに、ひどいCLIを使ってPRを提出する代わりに、開始点があれば良いなと思ったのです。ドラフト状態であっても良いのですが、現在のGitHubでは4回のボタンクリックと遅いビューが必要です。
誰かが私を批判し始めました。PRとコードレビューが重要だと考えるのは、私が酷い開発者か、周りの人が酷い開発者だからに違いないと。なぜかPRについての悪い議論を偶然始めてしまったのが不思議です。Primeは合理的に、ドライブバイPR（大きなオープンソースプロジェクトで、誰かがランダムにPRを提出して「これは悪いから自分のやり方で修正する」というもの）が話題になっていると考えました。それは確かにひどいことですが、それは人々がここで話していることではありません。
「存在すべきでないプロセスを最適化しないでください。単にそれを排除してください。PRは、あなたがまだ完全に信頼していない人々のために予約されるべきです。学習中のジュニアプログラマー、システムに十分慣れていない新しいチームメンバー、外部の貢献者たち。中級および上級プログラマーは単にマスターにコミットしてプッシュするべきです」
Twitterではいくつかのバカげた意見を見てきましたが、Hassenにはある程度の敬意を払わなければなりません。これはケーキを持っていきます。これは実際に、このアプリで最も愚かな開発者の意見かもしれません。私はこれを取り上げることさえしません。単に先に進むだけです。
チャットが私の気分を良くしてくれてありがとう。彼らはトロールしていません。彼らの返信を十分読みました。彼らはトロールではありません。それは悲惨なことですが、それはその個人が持つ本当のスタンスです。そして、私は死にそうな気がします。
しかし、私たちがここにいる理由は、狂気に陥ることなく物事を実際にどう行うかを伝えることです。誰もコードレビューを好まないことを受け入れる必要があります。しかし、より多くのコードがコミットされるにつれて、現実的には、コードを書く時間とレビューする時間の比率はシフトするでしょう。
AI以前は、これはおそらくレビューコードに有利に寛大だったと思います。開発の仕事をしている多くの人の時間は、実際にレビューにあまり費やされていません。彼らはそうすべきです。そして、あるべき姿は1/3対2/3くらいだったと思います。AIの前は、時間の1/3をコードレビューに、2/3を実際にコードを書くことに費やすのが正しい分割のように感じました。
これは、書いているコードの複雑さ、作業しているものをどれだけ頻繁に削除するか、コードの行ごとにどれだけの研究が必要かなど、多くの要素に大きく依存します。
核心は、私たちはAI以前にコードを十分にレビューしていなかったと思います。AIを使うと、実際にコードを書くことは少なくなります。プロンプトでコードを生成しています。これは順番に、レビューの量を増やす必要があることを意味します。
実際のコードの記述プロセスは、単に「git add .」することではなく、よりレビュー重視である必要があります。私のお気に入りの方法は「git add -p」です。これにより、システム上で変更した各行と各チャンクについて、ミニコードレビューができます。
これにより、自分のシステム内でミニコードレビューができます。他にもこれを行う方法はあります。VS Codeプラグインなどです。GitHub Desktopアプリはひどいですが、他人に提出する前に、作業しているコードをレビューするべきです。
自分自身が十分に見ていないコードをプッシュする考えは、私を少し気分悪くさせます。なぜなら、自分が個人的にやる気がなかったことを自分のチームに負担させることは良くないからです。
コードをコミットする際、ClaudeやCursorですべて生成したとしても、部分ごとにステージングして、各部分をチェックする習慣をつけるよう最善を尽くしてください。他の人の問題にする前に確認するのです。面倒に思えるかもしれませんが、すぐに第二の天性になることを約束します。
そして、コードレビュー中に愚かな質問をするのは素晴らしいことだと認識する必要があります。なぜか、多くの人々がコードレビューは排他的にコードへのフィードバックを行う場所だと感じています。「これはもっと良くなるべき」「これは壊れるかもしれない」というだけでなく、質問をしてください。
確信が持てない場合は、質問してください。なぜなら、あなたが確信を持てないなら、他の人も同様である可能性が高いからです。そして、質問が単に「これはどこからインポートされているの？」や「これはどのように機能するの？混乱しています」のようなものであっても、その質問が多くの他の人が聞くことを恐れていたものであるか、開発者によって行われた基本的なミスや誤った仮定である可能性に驚くでしょう。
私のチームが愚かな質問をして、それが実際には私がしたミスや間違いだったケースがどれだけあるか言い尽くせません。質問を常にする文化を持つことが重要です。そうでなければ、人々は愚かに見えることを恐れて質問することを恐れるでしょう。
どんなチームやコードベースにとっても最悪のことは、誰かが愚かに見えるのを恐れて質問することを恐れていることです。愚かな障害を防ぐ最も速い道は、愚かな質問をすることを恐れるエンジニアを持つことです。なぜなら、愚かな障害を防ぐ唯一の方法は愚かな質問をすることだからです。
文化の核心的な部分として、誰もが常に定期的に愚かな質問をするべきだということを確立しようとしてください。これは非常に重要であり、PRは質問をするのに最適な場所です。そして、もしあなたのシニア開発者が質問しすぎることで怒っているなら、すべての愚かな障害のリストを保管し始めてください。
そして、次回あなたがそれで問題に遭遇したとき、そのリストをあなたの上司に見せてください。なぜなら、これはエンジニアリング文化の基本的な失敗であり、あるべき以上に一般的だからです。
また、PRで良い質問があれば、それをコメントとしてコミットしてください。これはコードベースにコメントを残す最良の場所です。実際に質問があったときです。コメントで質問を予測しようとしないでください。コードを書くときに質問に答えるためにコメントを使用し、他の人が質問を持っている場合は、それも含めてください。誰もがこのコンテキストを持ちやすくしましょう。
PRや課題で質問をし、プライベートメッセージや個人的なチャットでは決して質問しないでください。または少なくともチーム用のSlackグループチャットで質問してください。DMで質問することは、誰かを快適にさせる良い方法です。
新しい人を雇うとき、私は彼らに愚かな質問をDMで送ることを許可します。実際、それをルールにしています。新入社員は、私またはチームに対して、毎日少なくとも1つの愚かな質問をする必要があります。ほとんどの人は恐れているため、単に私にDMすることを好みます。しかし、これをルールにし、愚かな質問をするまで一日を終えることを許可しないと、それが非常に根付き、彼らは二度と考えなくなります。
かつて、コードレビューにコメントをすることがその人の知性への侮辱とみなされるチームで働いていました。即座に承認でなければ、彼らを侮辱していることになりました。これは恐ろしいことです。本当に恐怖を感じます。コメントを残せない文化があることは本当に悪いことです。
そして、そのコードベースでの障害やバグの発生率は、コードレビュー中に質問をしやすい競合する会社や製品よりも大幅に高いと私は推測します。これは会社を失敗に導く大きな要因です。
正直に言って、このようなビデオを作成することで失敗しているような気もします。なぜなら、会社がこのような恐ろしい文化を持っていることは、私が運営したり投資したりしているスタートアップや初期段階のビジネスが他の会社よりも優れている大きな理由だからです。
Amazonがこのような奇妙で少し有毒な文化を持っていて、誰もがPRにコメントすることを恐れているなら、彼らがS3で行っているアップロード操作に追いつく可能性は低くなります。しかし、彼らがこれらのビデオを見始め、自分たちの文化がいかに悪いかを認識して修正すれば、私が彼らと競争するのはより難しくなります。つまり、このアドバイスを与えることで、ある意味自分の利益に反する行動をしていることになります。しかし、これらのことを理解し、それらに関する良い文化を構築することは重要です。
「愚かな質問ルール」をより多くの人が採用していることを知って嬉しいです。これは私のお気に入りのことの一つです。愚かな質問ルールは非常に重要です。
この部分を十分に強調できたことを願います。コードレビュー文化についてこれまで以上に積極的になる必要があります。なぜなら、コード量は増加し、それをレビューする時間は現在減少しており、それは本当に恐ろしいことだからです。
この特定のDevonの失敗には他の側面もあります。使用量ベースの価格設定も重要な部分であり、安全ネットとアラートも同様です。ありがたいことに、これらの部分はもう少し速く進めます。
まず使用量ベースの価格設定から始めましょう。使用量ベースの価格設定は本当に良いことです。サービスが心配せずに拡大縮小できることを意味します。しかし、突然もっと心配しなければならない閾値があります。
現実的に言えば、NetlifyやVercelのようなプラットフォームは、多くのことで多くの時間とお金を節約します。PRを作成するたびに、プレビュービルドが自動的に作成され、GitHubにリンクされ、クリックしたときだけライブになり、サーバーレスを通じて運用され、請求はそのコンピュートの実行時間に基づくという事実は、以前にはできなかった多くのクレイジーなことができるようになります。
サーバーレスに関する私の解説ビデオを見てください。新しい開発環境を立ち上げるたびに固定費を食べる必要がなく、使用量に基づいて課金されれば、実際の作業に応じた数字にすることができるのは本当に素晴らしいことです。
問題は、固定費よりも数字が大幅に高くなる可能性があることです。例えば、月額50ドルのサーバーがあり、このサーバーで私たちのアプリを実行し、10万ユーザーまでスケールできるとします。しかし、開発中にプレビューを立ち上げたいデベロッパーがいるとします。それらのプレビューを、月額5ドルの安価なインスタンスに置き、これらは400ユーザーしか処理できないとします。
今や、誰かがPRを提出するたびに、それがクローズされるまで毎月5ドルが費やされることになります。それは最悪ですが、使用量ベースの価格設定はそれを防ぐのに本当に良いです。また、Post Hogと競合する他の企業のように、手動でティアを変更する必要がないことも意味します。
例えば、以前私たちが解決策として使用していたMix Panelについて例を挙げましょう。Mix Panelは良さそうなプラットフォームです。問題は、ユーザーがどれだけのイベントを行うか推測しなければならず、それに対して本当に恐ろしい金額を請求されることです。予想よりも少ないイベント数だった場合でも、同じ金額が請求されます。そして、より多くのイベント数になった場合は、追加のイベントを失うだけです。
これは、最悪の敵にも望まない恐ろしい推測ゲームです。Post Hogが良い理由は、この部分をあなたの代わりにやってくれることです。100万以下で無料枠以下であれば、請求されません。しかし、超えると使用量に基づいて請求されます。
問題は、一方では、500万のイベントがあれば600ドル請求され、50万のイベントであれば何も請求されないということです。しかし、突然2000万に上がると、営業部門に連絡する必要があり、$2,300になります。
Mix Panelが使用量ベースの価格設定を提供できない唯一の理由は、その価格設定があまりにも極端であり、もしそうすれば、すべての訴訟から迅速にビジネスが破綻するからです。それは狂気です。
私たちはまだMix Panelのために、実際の使用量よりもはるかに高いティアを支払っていると思います。なぜなら、支払いを伴う大きな取引があり、多くの人が来た月があり、イベントを失うことを恐れてアップグレードし、今はダウングレードするのが怖いからです。恐ろしいことです。
これらの問題は使用量ベースの価格設定では存在しませんが、予想よりもはるかに高額な請求書が来るという新しい問題があります。しかし、ここにはいくつかの解決策があります。
支出制限：これらのサービスのほとんどは、現在何らかの形で支出制限を持っています。すべてがそうだったわけではありません。支出制限には注意点があり、支出制限は、サービスがダウンする可能性があることを意味します。
ここに、Netlifiyの素晴らしいツイートがあります。これを見たとき、Netlifyともっと仕事をしたいと思いました。このポストには驚きました。
これは、Netlifyで巨大なウイルス性の請求書があったために起こりました。誰かが突然1,000ドルの請求書を受け取り、返金されましたが、それでもウイルス性になりました。サーバーレスの恐怖にも掲載されていると思います。誰かが静的サイトに対してNetlifyから104,000ドルの請求書を送られました。
理由は、サイトに大きなファイルがあり、そのファイルが他の人のウイルス性のコンテンツに埋め込まれ、人々が3.5メガバイトのMP3をロードしてスパムし、狂気の量の帯域幅を使用していたからです。
ちなみに、これには簡単な修正方法があります。高帯域幅のアセットをUploadThingに置くことです。それは私たちが行っている最良のことの一つです。出口トラフィックに対して課金しないことで、あなたがその費用を負担しなくてもいいようにしています。VercelやNetlifyなどのプラットフォームでこれらの暴走する請求書の最大の原因の一つです。エッジでの190テラバイトのトラフィックは高価で、理由があって多くのお金がかかります。しかし、あなた自身をそのような立場に置くべきではありません。
ここでの最大の問題は、私の意見では、請求書やミスだけでなく、サポートに連絡したときの対応でした。サポートは50%オフを提供しました。いや、80%オフを提供したので、20%だけ支払えばよかったのですが、5%まで下げることを提案しました。つまり、5,000ドルしか支払わなくていいのです。
ひどいです。受け入れられません。これは請求書の規模のために非常に高いレベルまでエスカレーションされるべきケースであり、迅速に無効にされるべきでした。最終的には、幸いにも、Netlifyは請求書を完全に返金し、責任を取りました。
しかし、MattのCEOからのこの投稿は、私の考えを変え、これらすべてについて再考させました：「トラフィックのスパイクが自動的に、そして絶対的に悪意があると分類できる場合、私たちのプラットフォームはそれをブロックするように設定されています。新しいパターンであれば、自動ルールに追加し、料金を免除します」
これは重要な部分です。誰かがDDoS攻撃を行い、サービスがそれをブロックできなかった場合、彼らはブロックしなかったミスの予想コストとして払い戻すことができ、そのミスから学んだことを使って将来的にブロックします。
問題のトラフィックが明らかに悪意があるわけではなく、顧客が成功している兆候である可能性がある場合は難しいです。これは本当に重要な詳細です。
「この場合、自動ブロックは、立ち上げを台無しにしたり、ウイルス性のキャンペーンを台無しにしたり、新興アーティストのファンを失望させたりする可能性があります。無料ユーザーにとって、私の哲学は常に、栄光の瞬間を台無しにした場合、それを修正するために戻ることができないということでした。請求書をキャンセルしたり、料金を返金したりすることは常に可能です」
山の頂から叫びたいです。これは、私たちが多く見逃している非常に重要なポイントだと感じます。これらのプラットフォーム、Post Hogのようなもの、Planet Scaleのようなもの、VercelやNetlifyのようなプラットフォームのスケーリング特性を持つこれらのプラットフォームの魔法は、ウイルス性になり、大きな瞬間があったため、突然100万人のユーザーを獲得した場合、ダウンしないことが以前よりもはるかに簡単だということです。
「抱擁の死」がミームになったのには理由があります。これらの種類の問題は非常に一般的でした。そして、これらのサービスがあれば、それは起こりません。あなたのサービスは稼働し続けることができます。結果は高額な請求書かもしれませんが、あなたのサービスがはるかに成功する可能性があるなら、コンサートのチケットの発売が数百万人にアクセスされる可能性があるなら、あなたの新しいSaaSがProduct Huntでウイルス性になり、突然たくさんの新しいユーザーを獲得した場合、請求書はそれほど重要ではありません。
問題は、これが誤って起こる場合です。請求書がウイルス性の瞬間からではなく、エラー、DDoS攻撃、構成ミス、ユーザーの失敗、これらの他のことから来る場合、またはDevonが悪いプルリクエストを作成した場合です。
面白いことに、これらは検出が難しいミスです。そして、Mattが言うように、「私たちは戻ることができません。もし私たちが自動的に、この無料ティアのユーザーが突然100万人がサイトにアクセスしているのを見て、念のためにシャットダウンしたら、あなたはそのウイルス性の瞬間を奪ってしまいます。そのウイルス性の瞬間は返金できません。それを返すことはできません。しかし、もし悪い請求書だったら、単に返金してください」
そして、これらのケースのほとんどすべてで、サーバーレスの恐怖を通過すると、最近確認していないので2024年1月のケースに詳しくありませんが、2024年6月までとそれ以前は、これらすべてを確認しました。これらはすべて返金されました。これらの恐怖物語のすべては、最終的に大きな請求書の被害者となった人とチームに返金されました。
そして、それはこのウェブサイトの奇妙な意図しない効果です。私はAndressが大好きで、Coolifyでの彼の仕事を愛していますが、彼は意図せずに私のポイントを証明しています。これらのサービスは多くの問題を防止します。彼らはあなたが無限にスケールすることを可能にします。そして、これらのクレイジーで誤った請求書の一つを持っている場合、それが単に返金される可能性が非常に高いです。
ここでMattからのもう一つの良い指摘があります：「このような大きな請求書は、自動的に私たちのシステムから出るべきではなく、サポートチームはこれをビジネスユーザーとして扱うべきではありませんでした。また、この場合、トラフィックは古いデバイスが多い地域からの有機的なトラフィックと一致するため、これがDDoS攻撃だと推測すべきではありませんでした。上記すべてに同意します」
一つ言いたいのは、NetlifyやVercelのようなものにアセットをアップロードする場合、それが半メガバイト以上ある場合、「私は何をしているか知っている。これが愚かだと知っている」というボタンを押さなければならないべきです。大きなファイルを、帯域幅に多くのお金を請求するこれらのCDNの一つにアップロードする場合、その瞬間に何をしているか知るべきです。なぜなら、これらの請求書の90％はそれが原因だからです。
そして、これはこれらのプラットフォームから見たい最大のことです。最初に言おうとしていたことは、アラートです。これらはある程度あなたの問題です。パターンの大きなスパイクや変化が実際に確認する方法であなたに送信されるように、アラートを設定する必要があります。1日に15のアラートを受け取ってすべて無視するようなものではなく、コストに関連する使用量ベースのものが急増した場合に、エンジニアに警告する方法が必要です。それは不可欠です。
ここに2.5を追加します。これはプラットフォームの問題でもあります。VercelやNetlify、Post Hogのようなプラットフォームは、これらのスパイクの一つが発生したときに認識し、発生したときにユーザーに通知するためにもっと努力する必要があります。
ユーザーが月に500または5,000イベントから500万に行くとき、突然閾値を超えてより多くのお金を使わなければならないとき、それらのいずれかが発生したとき、プラットフォーム上のユーザーは積極的に警告され、一定の時間内に「はい、この請求書に問題ない」ボタンを押すよう強制されるべきです。
プラットフォームはそれを持っていません。それはあなたの問題です。より多くのこれらのプラットフォームがこれを導入する未来に期待しています。残念ながら、ほとんどがこれを導入していますが、私はより多くの知識と閾値を超えたときのアラートがほしいです。
Vercelは実際、今これについて比較的良いですが、それは本当に100％マークでのみあなたに警告しています。無料使用量の50％に達すると通知され、75％に達すると通知され、そして90％と100％になります。しかし、すでに超えることを期待している場合は注意を払わないでしょう。そして、突然400％の使用量に達し、請求書が月額10ドルから70ドルに変わっても、その時点ではアラートさえも受け取らないかもしれないので、気づかないかもしれません。
それはバランスです。そして、使用量ベースのプラットフォームがこれらのユーザージャーニーとストーリーを本当に考え抜き、これらのものが引き起こす問題に遭遇する可能性を低くすることが重要だと思います。
そして、あなたはそれを行うビジネス上のインセンティブを持っています。ここに2.6を追加します。これはあなたのブランドが不必要なブランドヒットを少なくすることを可能にします。
Vercelとの会話の中で、「メール問題を修正しなければ、ブランド間の関係を終了するかもしれない」と率直に伝えた時点がありました。なぜなら、請求変更などが発生したときにユーザーに送信されるメールが十分に徹底的にレビューされておらず、Vercelに大きなブランドダメージをもたらしたからです。
「請求の仕組みを変更しています。あなたの請求書は月額50ドルから700ドルになります」と書かれたメールのスクリーンショットを撮ることができれば、それはあなたの会社の助けにならないウイルス性の瞬間です。
これらのアラートやこれらの方法論、これらの価格がどのように伝えられるかについて、多くの考えを入れる必要があります。そして、それはPRの問題ではなく、PRの問題です。これは公の表現の問題です。それはマーケティングとブランドの問題です。
あなたの会社から出るコミュニケーションのすべての部分は、特にアラートに関しては、徹底的に考慮される必要があります。
使用量ベースの2つの大きなことは、支出制限とアラートです。残念ながら、会社はアラート側で十分な仕事をしていません。だから、これらのことが起こったときにそれらをキャッチするために細心の注意を払う必要があります。
そして、これらのプラットフォームとこれらのプラットフォームでのエンジニアたちに見ています：アラートを修正してください。簡単ではないと言っているわけではありません。「より良いアラートスイッチを押すだけ」ではありません。これに複数の人がフルタイムで取り組む必要があります。これはマーケティングの仕事の一部です。
議論すると、それはプラットフォームがどのように理解され、受け取られ、好まれるか嫌われるかについての本当に重要な問題です。そして、これをもっと上手く行えば、サーバーレスの恐怖に表示される頻度が減るでしょう。Twitterで悪い理由でウイルス性になる頻度も減るでしょう。そして、誰もが良くなります。
私は本当に、もし彼らが早い段階でアラートとメールにより多くの思考と時間を費やしていたら、Vercelに関する騒ぎははるかに少なかっただろうと考えています。彼らは改善していて、それについて嬉しく思います。しかし、これは単に彼らと関係があるという理由だけで、人々が私をどのように認識するかに直接影響しています。だから、私はそれを本当に真剣に受け止め、多く考えています。
同様の方法で、ここでパート3、安全ネットとアラートです。アラートについては既にカバーしましたが、安全ネットの側面はここで本当に重要です。
安全ネットはガードレールとは異なります。ガードレールは、ユニットテストのようなもので、「それをするべきではない」と教えてくれます。しかし、それらは障害を防止しません。それらは、私たちが失敗かもしれないと思っているものを通知します。
安全ネットは、新しいバージョンが問題を引き起こしているときに古いバージョンに一クリックでロールバックするボタンのようなものです。特にAIコードをコミットしている場合、使用量ベースのものでは不可欠です。
一クリックロールバックオプションなしで使用量ベースのプラットフォームに配信しないでください。これを非常に大きな決定的な声明にします。ミスを一クリックで即座にロールバックする方法がなければ、使用量ベースのものに配信しないでください。なぜなら、自分自身を台無しにするからです。それは多分そうなるかどうかの問題ではなく、どれだけの時間でそうなるかの問題です。
悪い変更を元に戻す方法を持つことは、悪い変更があなたの会社の終わりになる可能性がある世界では非常に重要です。悪い変更が解決するのに何時間もかかる可能性があります。悪い変更が顧客を失う可能性があります。悪い変更が誰かを解雇させる可能性があります。一部のサービスでは、悪い変更が文字通り誰かを殺す可能性があります。それが病院のようなものであれば。
悪いことだと分かった瞬間に、悪いことを即座に元に戻す方法が必要です。展開よりも積極的にロールバックするべきです。
これは奇妙なことで、どうしてこうなったのか分かりません。人々はロールバックするよりも配信することに躊躇しません。どうしてこうなったのか本当に理解できません。私がよく考えることの一つです。
なぜ人々はマージと配信ボタンを押すことに、ロールバックボタンを押すよりも積極的なのでしょうか？ロールバックボタンは配信ボタンよりもはるかにリスクが低いのに、人々はそれをクリックするのをより恐れています。私には全く意味がありません。そして、それは私たちが変える必要がある文化的なことの一つです。
人々はロールバックについて恐れや恥を感じることが少なくなる必要があります。ロールバックはあなたが仕事で悪いことを意味しません。ロールバックはあなたがエンジニアとして失敗であることを意味しません。ロールバックは、予期しないことが起こったことを意味します。
何が起こったのかまだ分からないかもしれません。しかし、少なくとも、それを理解するにつれて、ロールバックする必要があります。ロールバックしているものが原因ではないことが判明しても、それを行う意思のある文化を持つ必要があります。
これはグーグルと私が同意するまれな時の一つです。希望は戦略ではありません。グーグルによれば、少なくとも、グーグルでの障害の70％は既存のライブシステムの変更によるものです。ここでの障害を防止する最良の方法は、進行中のロールアウトを実装し、問題を迅速かつ正確に検出し、問題が発生したときに変更を安全にロールバックすることです。はい、同意します。
進行中のロールアウトは、特にインフラストラクチャでは実装するのが最も簡単なことではないので、なぜほとんどの人、特に初期から中期段階の人々がそれをできないのか理解できますが、彼らはロールバックにもっと積極的であるべきです。前進と後退の方法を持ち、失敗を迅速に元に戻し、何か問題が発生した場合に迅速に元に戻すことができる方法で構築することは非常に重要です。
ここで私が文句を言っているすべてのことをまとめると、まず、コードレビューは重要です。それをあなたの文化の一部にしてください。第二に、アラート、アラート、アラート、アラート。そして、ポイント3、安全ネット。ロールバックするか死ぬかです。
AIが私たちのコーディングをますます行うようになり、障害がますます一般的になる世界では、ロールバックする意思がなく、それらが間違ったときに間違う可能性のあるものに対して良いアラートを持っておらず、これらのことを前もって捉え、ミスが生きる前にそれらに慣れるための強力なコードレビュー文化を持っていない場合、あなたは成功しません。
業界が変化し続け、より多くのこれらのウイルス性のツイート、これらのクレイジーなビルド、これらの基本的な失敗が発生するにつれて、これを修正するためにDevonをより良くすることはできません。これを防止する方法でAIを改善することはできません。これらのことが起こる可能性を低くするために文化を変える必要があります。
そして、その文化を変えなければ、変える人に負けるでしょう。だから、あなたの会社が倒産したくないなら、まだ実装していない場合は、これらのことのいくつかを実装し始めることを強くお勧めします。面白いことに、大企業は実際にこのほとんどをすでに理解しています。
だから、勝ちたいなら、そしてこのように考えているチームがない場合は、その変更を行う必要があります。他にはあまりありません。この長談義を楽しんでいただければと思います。あなたたちの考えを聞かせてください。次回まで、平和を、ナード達よ。
コメント