8月17日に発生した大規模障害と、今後の対策について
The August 17 outage, and the work ahead
The August 17 outage, and the work ahead
8月17日に発生したサービス停止の件についてご報告します。現在、再発防止に向けた取り組みを鋭意進めております。今後の改善計画や詳細な進捗については、追って改めて共有いたします。
"4月以降、月間のコミット数が14億から29億に増加した"。うわ、短期間ですごい伸び方だな。
これらのサービスにおけるエラーがクライアントサイドでのリトライループを誘発し、復旧中のトラフィックを増大させた。
これまで経験した中で最悪の障害って、大抵こういうパターンが含まれてるんだよね……。
AIを多用するユーザーを追い出すために、単純にコミット数で課金すればいいと言ってる人がいるけど、GitHubはMicrosoft傘下だっていうことを忘れてない?Microsoftにとって、開発者にAIを使い続けてもらうことには大きなインセンティブがあるんだよ。
むしろMicrosoftは、その損失が「ユーザー全員がモデルを使ってコード生成のためにOpenAIのサブスクにお金を払っていること」に起因するものなら、赤字を出してでもGitHubを運営したいんじゃないかと思う。
これらのサービスにおけるエラーがクライアントサイドでのリトライループを誘発し、復旧中のトラフィックを増大させた
エラーを何がなんでもユーザーに見せないようにするという、昨今の広範なトレンドの弊害だな。たとえユーザーが7時間スピナー(読み込み中)を眺める羽目になろうともさ。
内部エンドポイントへの返答遅延がVS Codeの潜在的なリトライバグを誘発し、トラフィックを約10倍に増幅させ、Copilotトークンサービスの復旧を遅らせた。
詳細な根本原因分析はこれをただの「バグ」として済ませようとしているけど、クライアントのリトライ処理に、リトライのバックオフ動作が設計通りに機能しているか確認するユニットテストがないなんて、本気で言ってるのか?今回の場合、トークンサービスのレスポンスが不安定になったときに、問題を隠蔽しようとして過剰に動作してしまったんだろう。
"...これらのインシデントは、私たちがこの取り組みを加速させなければならないことを明確にしている"
GitHubは逆に少しペースを落とすべきじゃないのか?「もっと速く変更しなければならない」なんて、8時間も続く大規模なダウンタイムの報告書の書き出しとしてはかなりヤバいよ。
リトライって悪なのかな?
こういう理由で、個人的にはどうも納得がいかないんだよね。モバイル通信みたいに接続が本質的に不安定な環境なら役立つのはわかる。でも、これだけ常時接続が前提のデスクトップ向けサービスなら、リトライなんて極力したくない。何かが本当に壊れているときに隠蔽されてしまうし、今回のような最悪のシナリオは悲惨だよ。
「リトライは邪道だ」なんて言ってると少し頭が固いと思われるかもしれないけど、自分の中ではどうもモヤモヤする。
4月以降、月間のコミット数が14億から29億に増加した
正気の沙汰じゃない。
業界全体が「生産性パニック」に陥っている証拠だね。どこかで生産性信者が歓喜の涙を流してそうだ。
GitHubのCTO自身が自分のプロダクトを使っていないというのは指摘されるべきだと思う。2024年1月以降、コミットがゼロだ:https://github.com/v-fedorov-gh
サイドプロジェクトもないの?何もない?ちょっと奇妙だよね。
異なるサービスに分散させるのは悪くないアイデアだと思う……。
それでも、無料枠で彼らが提供していることには少し感謝の気持ちが湧いてしまう。これが利他的な動機じゃないのはわかっているし、十億ドル企業の肩を持つ必要がないのも承知だけど……。
彼らと同じ規模で、これほどの内容を「無料(しかも広告なし)」で提供しているサービスが他にどこにある?簡単なことじゃないよ。Wikipediaの方が利用者は多いかもしれないけど、あれはもっとシンプルな仕組みだしね(モデレーション部分は凄まじいけど)。OpenStreetMap?もっと小さくてシンプル。Internet Archive?それも小さくてシンプル。Linuxディストリビューションのミラー?それもGitHubが無料でやってることと比べればシンプルだよ。
もう何年もAzureへの移行を進めてるんじゃなかったっけ?なんでまだ58%しか終わってないんだ……。MicrosoftはAI機能への注力は一旦置いておいて、これを終わらせるべきだよ。