このページは機械翻訳されています。英語の原文が正式版です。 英語で読む →
メインコンテンツにスキップ

インシデント対応プレイブック

よくある問題への対応手順です。

接続の問題​

WebSocket の切断​

症状: WebSocket 接続が失われ、メッセージを受信できない

対応:

  1. 指数バックオフによる自動再接続を実装します
  2. REST エンドポイントをポーリングし、取りこぼした更新を取得します
  3. 再接続後、すべてのチャネルに再購読します

予防策: 接続状態を監視し、堅牢な再接続ロジックを実装します

API タイムアウト​

症状: REST リクエストがタイムアウトする、または 5xx エラーが返される

対応:

  1. 指数バックオフでリトライします
  2. ヘルスエンドポイントを確認します: GET /health
  3. システムが過負荷の場合はリクエストレートを下げます

予防策: リクエストのスロットリングとサーキットブレーカーを実装します

注文の問題​

高いリジェクト率​

症状: 多くの注文がリジェクトされる

調査:

  1. すべての注文レスポンスと WebSocket の order_updates メッセージから status と reason をログに記録します。GET /orders?wallet=... はデフォルトでオープン注文を返し、リジェクト理由は含みません
  2. 証拠金を確認します: GET /portfolio?wallet=...
  3. アカウントの上限を確認します: GET /risk/limits?wallet=...
  4. 銘柄が満期を迎えていないことを確認します: GET /instruments?currency=...

対応:

  • 証拠金の問題の場合: ポジションサイズを縮小するか、担保を追加します
  • ティアの問題の場合: 売り注文をロングの在庫でカバーするか、ティア変更について Hypercall にお問い合わせください
  • 満期を迎えている場合: 別の銘柄を使用します

約定の欠落​

症状: 注文は約定しているが、約定通知が届かない

調査:

  1. GET /fills?wallet=... で約定を確認します
  2. WebSocket の fills チャネルの購読を確認します
  3. WebSocket の接続状態を確認します

対応:

  • fills チャネルに再購読します
  • REST エンドポイントをポーリングして取りこぼした約定を取得します
  • 約定と注文ステータスを照合します

古い注文ステータス​

症状: REST の注文ステータスが WS と一致しない

調査:

  1. WebSocket の接続状態を確認します
  2. 注文キャッシュが最新であることを確認します
  3. REST と WS の注文ステータスを比較します

対応:

  • WS 再接続後に REST をポーリングして差分を取得します
  • 照合には REST を信頼できる情報源として使用します

MMP の問題​

MMP が頻繁に発動しすぎる​

症状: 多くの注文が MMP によってキャンセルされる

調査:

  1. 署名付きの GET /mmp-config?wallet=...&currency=... で MMP 設定を確認します
  2. 約定パターンと累積メトリクスを確認します
  3. 上限が低すぎないか確認します

対応:

  • MMP の上限 (数量、デルタ、ベガ) を引き上げます
  • interval_ms を増やし、ウィンドウ内でより多くの約定を許容します
  • クォートの頻度を下げます

MMP が発動しない​

症状: 約定が上限を超えているのに MMP が発動しない

調査:

  1. 署名付きの GET /mmp-config?wallet=...&currency=... で MMP が有効になっていることを確認します
  2. 注文に mmp_enabled=true が設定されていることを確認します
  3. 通貨が注文の原資産と一致していることを確認します

対応:

  • 注文で MMP を有効にします: mmp_enabled=true
  • 正しい通貨に対して MMP を設定します
  • 必要に応じて上限を調整します

署名付きの MMP 読み取りでは、GetMmpConfig の有効期限と署名を X-Hypercall-Expires-At-Ms ヘッダーと X-Hypercall-Signature ヘッダーで送信します。

証拠金の問題​

証拠金不足​

症状: 注文が "Insufficient margin" でリジェクトされる

調査:

  1. ポートフォリオを確認します: GET /portfolio?wallet=...
  2. 証拠金の計算を確認します
  3. どのシナリオで失敗しているかを確認します

対応:

  • ポジションサイズを縮小します
  • 担保を追加します
  • ポジションをクローズして証拠金を解放します
  • エクスポージャーをヘッジして最悪ケースの損失を抑えます

スポット価格の欠落​

症状: 注文が "Missing spot price for underlying" で始まる理由でリジェクトされる

調査:

  1. GET /markets で原資産の index_price を確認します
  2. 原資産のシンボルが正しいことを確認します
  3. ステータスページでオラクルのインシデントが発生していないか確認します

対応:

  • スポット価格フィードの復旧を待ちます
  • 可能であれば別の原資産を使用します
  • 問題が解決しない場合はサポートにお問い合わせください

システムの問題​

高レイテンシ​

症状: API レスポンスが遅い、または WebSocket メッセージが遅延する

調査:

  1. システム負荷を確認します
  2. レスポンスタイムを監視します
  3. ネットワーク接続を確認します

対応:

  • リクエストレートを下げます
  • リクエストのスロットリングを実装します
  • 問題が解決しない場合はサポートにお問い合わせください

レート制限​

症状: リクエストがリジェクトまたはスロットリングされる

現状: レート制限はウォレット単位で適用され、キャンセル、エージェント認可、MMP 書き込み、リスクシミュレーションにはそれぞれ送信元単位の個別の上限があります。詳細はレート制限をご覧ください。

対応:

  • Retry-After ヘッダーを確認し、待機してからリトライします
  • X-RateLimit-Remaining を監視して上限到達を回避します
  • 可能な場合はバルクエンドポイントを使用します

緊急時の手順​

キルスイッチ​

即時対応:

  1. すべての注文をキャンセルします: DELETE /bulk_order または DELETE /bulk_order_cloid、1 リクエストあたり最大 50 注文
  2. WebSocket を切断します
  3. クォートシステムを停止します

復旧:

  1. すべての注文がキャンセルされたことを確認します: GET /orders?wallet=...
  2. ポートフォリオを確認します: GET /portfolio?wallet=...
  3. 根本原因を調査します
  4. 問題の解決後にクォートを再開します

データの照合​

インシデント後:

  1. REST エンドポイントをポーリングして現在の状態を取得します
  2. 注文を照合します: GET /orders?wallet=...
  3. 約定を照合します: GET /fills?wallet=...
  4. ポートフォリオを照合します: GET /portfolio?wallet=...
  5. WebSocket の購読を再開します

エスカレーション​

問題が解決しない場合:

  1. アクセス時に提供された既知の問題とステージングのお知らせを確認します
  2. 詳細な手順についてはランブックを確認します
  3. 以下の情報を添えてサポートにお問い合わせください:
    • ウォレットアドレス
    • エラーメッセージ
    • タイムスタンプ
    • 再現手順