事後分析: 26分間のログイン失敗(2026年1月19日)

要約

2026年1月19日、14:02から14:28 UTCの間に、パネルへのログインまたはAPIに対する認証試行の約3分の2が失敗しました。既存のセッションもランダムに無効化されました。実行中のインスタンス、そのネットワーキング、トラフィックは、その間ずっと影響を受けませんでした。プロビジョニングは26分間一時停止し、その後ドレインされました。注文が失われることはありませんでした。

タイムライン

すべての時刻はUTC、2026年1月19日です。

根本原因

セッショントークンにフィールドが追加されました。ライターはすぐに新しい形式を出力しましたが、6つのパネルノードのうち2つのリーダーが再起動されておらず、新しいフィールドを含むものを拒否しました。リクエストは6つのノードすべてに分散されるため、新しいノードで発行されたセッションは、任意のリクエストで古いノードによって検証される確率が約3分の1でした。結果は断続的に見えたため、最初の6分間の診断はデプロイログではなくデータベースに向けられました。

より深い原因は、2023年に私たちが書いたルールです。アプリケーションコードではなくスキーマファイルに触れる変更は設定として分類され、設定は「単なる値」であるという理由でカナリア段階をスキップしました。そのルールは、スキーマファイルがフィーチャーフラグだけだったときは妥当でした。スキーマファイルの定義が拡大するにつれて誰もそれを再検討せず、この変更は静かに間違ったものになっていたルールに従って正しく分類されました。

これは、それを適用したエンジニアのミスではありません。分類は書かれたとおりに正確に実行されました。

影響範囲

• パネルログイン: 26分間、61%の失敗率。
• APIトークン: 同じ失敗率、同じ時間帯。冪等性キーにより、再試行された作成は重複しませんでした。
• 実行中のインスタンス: 影響なし。パケット損失、再起動、ストレージへの影響はありません。
• プロビジョニング: 一時停止（失敗ではない）。ウィンドウ中に4件の注文が確定し、4件すべてが14:28までに完了しました。

変更したこと

1. カナリア段階は現在無条件です。 どの分類であっても、デプロイするものはすべて、他の場所に送信される前に、合成トラフィックを使用して1つのノードに5分間送信されます。1月21日に完了。
2. リーダーは30日間、以前の形式を受け入れます。 トークン検証は明示的にバージョン管理され、オーバーラップウィンドウがあるため、部分的にロールアウトされた変更はまったく劣化しません。1月23日に完了。
3. 合成ログインが15秒ごとに実行されます。 ネットワーク外部から、3つのリージョンで、2分間の平均化ウィンドウではなく、2回連続で失敗したときにページングされます。1月22日に完了。
4. ステータスページは自動的に公開されます。 合成ログインが2回失敗したとき、人間が文を書くのを待たずに自動公開されます。人間の文がそれに続きます。1月26日に完了。

変更しなかったこととその理由

パネルトラフィックのクライアントIPやリクエストボディは依然としてログに記録しません。 それらがあれば、ノード間の3分の1の分布がすぐに明らかになり、おそらく9分節約できたでしょう。9分は、すべての顧客がどこからログインするかを恒久的に記録する価値はありません。ロギングページの保持テーブルは変更されません。

セッションを共有のクロスサイトストアに移動しませんでした。 すべてのサイトにまたがる単一のセッションストアは、リーダーが1つになるため、混合リーダーの問題を完全に回避できたでしょう。また、私たちが6年間構築していない、誰が何に接続しているかの集中化された常時ホットな記録を正確に作成することになります。

ステータスページの外部に障害発表チャネルを追加しませんでした。 ソーシャルメディアを提案する人もいました。ステータスページは、私たちが正確に保つことを約束できる唯一のものであり、2番目のサーフェスを追加することは、2番目のサーフェスが古くなることを意味します。

クレジット

SLAはインスタンスの可用性をカバーしています。インスタンスは26分間ずっと利用可能だったため、契約上、誰にも返金義務はありませんでした。ウィンドウ内で認証に失敗したすべてのアカウントに1日分のクレジットを適用しました。これは約3,100ユーロに相当します。サーバーに到達できなかった人々とその区別について議論することは、全員の午後を無駄にするからです。