要約

  • GitHub は03:53:19 UTC に API 要求の性能低下を掲載した。
  • 題名は GraphQL API Requests とし、更新本文はより広い API Requests という表現を使った。
  • 04:09:01 UTC に緩和、04:09:10に解決を掲載し、最初の通知から約16分だった。
  • 失敗要求数、影響顧客、地域は定量化されていない。
  • 詳細な根本原因分析を後日示すとしたが、確認した事故記録にはまだなかった。

GraphQL という題名と API Requests という更新文をどう読むか。前者は具体的なサービス面を示し、後者はより広く見える。記録が説明しない差を、報道側が勝手に同一化してはならない。

GitHub の時系列は明確である。03:53:19 UTC に性能低下、04:09:01に緩和、九秒後の04:09:10に解決となった。事業者が示した時間は約16分である。

しかし時間が短いことは、失敗した要求や顧客側の回復作業が少ないことを自動的に意味しない。

GraphQL は中心だが境界は未確定である

GraphQL は構造化データを要求する具体的な API 面であり、画面、連携、リポジトリ道具、社内自動化の下に置かれ得る。

GraphQL だけが低下したなら、REST などは別の状態だった可能性がある。本文の広い表現が実際の広範囲を示すなら、題名は最初の部品だけを表した可能性もある。記録はどちらかを確定しない。

安全な説明は、名付けられた GraphQL 事故を中心にし、本文の表現差を併記することである。全 GitHub API が停止したとは言えない。

要求失敗率、顧客数、地域、遅延分布もない。約16分に低いエラー率が続いたのか、鋭い急増があったのかは分からない。

再試行の費用は分数ではなく作業で測る

対話利用者は更新して続けられる。自動処理は作業を失敗状態にし、待機し、過剰に再試行し、後段を止めることがある。

事業者の解決は顧客の作業を自動再生しない。方針で再試行するもの、失敗したままのもの、人が開始するものに分かれる。

変更操作では、拒否されたか、応答前に完了したか、後処理へ受け付けられたかを確認する必要がある。無条件の再実行は重複を生む。

そのため顧客側の回復は16分を超え得る。信頼できる最終状態がない要求と作業の数が残存費用である。

解決は原因説明を完了しない

緩和と解決は GitHub が回復を観測して活動中の事故を閉じたことを示す。発端は示さない。

詳細な原因分析は予告されたが、事故ページにはまだなかった。基盤、配備、容量、依存サービスのいずれかを推測すべきではない。

次の有用な説明は、部品、発端、検出、緩和、再発防止、影響指標を示し、広い API Requests が GraphQL の略記だったかも明らかにする。

顧客は03:53:19から04:09:10 UTC までと、その後の再試行を調べられる。失敗、遅延、重複、滞留が各社の実影響である。

GitHub が可用性を短時間で戻した事実と、未解明部分は両立する。事故は約16分で解決したが、作業費用、技術原因、正確な API 境界は状態文だけでは解決していない。

情報源