コンテンツにスキップ

OPS Management

DoubleZero OPS Management ポータルは、コントリビューターがネットワーク全体のインシデント(計画外の障害)とメンテナンス(計画作業)を記録・追跡する場所です。すべてのチケットはすべてのコントリビューターに公開されます。

ポータル: https://doublezero.xyz/ops-management

ポータル vs Slack

OPS Management ポータルと Slack は連携して機能します。すべてのインシデントとメンテナンスはチケットとして追跡され、ポータルまたは API からアクセスできます。各チケットは適切な Slack チャンネルに自動的に通知し、すべてのコントリビューターにネットワーク上で何が起きているかの共有ビューを提供します。Slack は会話の場です:ログの共有、他のコントリビューターとの調整、アクティブな問題への協力が行われます。

チケットは、ポータルまたは API のどちらで作成されたかに関わらず、正式な記録です。Slack スレッドはそうではありません:チケットのステータスは更新されず、永久に保存されることもありません。会話が Slack で行われていても、チケットのステータスは常に最新の状態に保ってください。

ポータルと Slack はそれぞれ異なる目的を持っています。両方を使いますが、適切な用途に使ってください。

ポータル(または API)の用途 Slack の用途
チケットのオープン、更新、クローズ アクティブな問題に関する会話とコラボレーション
ステータス遷移の記録 ログやスクリーンショットの共有、通話の開始
チケットの割り当てまたはエスカレーション 問題にすばやく注目を集める
クローズ時の根本原因の設定 他のコントリビューターとの調整

オンボーディング

ポータルを使用する前に、以下の手順を一度完了してください。

1. Ops Manager キーの設定

Solana ウォレットの公開鍵を Ops Manager キーとして登録します。対応ウォレット:Phantom、Solflare、Coinbase Wallet。

doublezero contributor update \
  --ops-manager <OPS_MANAGER_PUBKEY> \
  --pubkey <CONTRIBUTOR_PUBKEY>

2. ポータルでウォレットを接続

  1. https://doublezero.xyz/ops-management にアクセスします。
  2. Connect Your Wallet をクリックし、ウォレットを選択します。
  3. メッセージに署名して、Ops Manager キーの所有権を証明します。

認証が完了すると、Incident Tracking Table が表示されます。

アカウント設定は Settings メニュー(右上の歯車アイコン)内にあります:API Key Management、User Management、Escalation Contacts。表示されるオプションはロールによって異なります。

3. API キーの作成(オプション)

Web フォームの代わりにプログラムからアクセスする場合:

  1. Settings メニュー(歯車アイコン)を開き、API Key Management を選択します。
  2. 1 つ以上の API キーを作成します。
  3. このページから API ドキュメントをダウンロードします。

インシデント

インシデントとは、計画外のサービスに影響を与えるイベントです。

重大度レベル

DoubleZero ネットワークへの影響に基づいて重大度を割り当てます。状況の変化に応じて重大度を更新できます。

重大度 影響 対応
sev1 完全な障害、またはフォールバックなしの重大なコントロール/データプレーンの破損 勤務時間外であっても、すべてを中断して直ちに対応。DoubleZero Foundation に即座にエスカレーション。
sev2 部分的だが大きな影響;フォールバックの可能性があるサービスの劣化 緊急として扱う。積極的に調整。持続的な劣化の場合は夜間対応が必要。
sev3 ユーザーへの影響が限定的またはなし;未解決の場合にエスカレーションの可能性 勤務時間中の最優先事項。注意深く監視。影響が増大しない限り、時間外のエスカレーションは不要。
重大度の例

Sev1 の例

  • DoubleZero 上のユーザートラフィックの 10% 以上がブラックホール化し、パブリックインターネットへのフォールバックなし
  • ユーザーのオンボーディング、接続、または切断の試行の 80% 以上が失敗
  • DZD の 20% 以上がインターフェースエラーを報告
  • コントローラーが DZD エージェントに有効だが不正確な設定を返している

Sev2 の例

  • ユーザーの 20% 以上が DoubleZero トンネル経由でトラフィックを送受信できないが、パブリックインターネットにフォールバック可能
  • DoubleZero 上のユーザートラフィックの 0〜10% がフォールバックなしでブラックホール化
  • 新規ユーザーのオンボーディング、接続、または切断の試行の 20〜80% が失敗
  • 設定エージェントの 20% 以上が DZD 設定の適用に失敗
  • DZD の 0〜20% がインターフェースエラーを報告
  • 上流の問題によるオブザーバビリティの喪失(監視/アラートのダウン)
  • オンチェーンデータパイプラインのダウンまたは不正確なデータの生成
  • インターネットレイテンシの収集または送信の 20% 以上が失敗
  • DZD エージェントからコントローラーにアクセス不能
  • コントローラーが DZD に適用されない無効な設定を返している

Sev3 の例

  • ユーザーの 0〜20% が DoubleZero トンネル経由でトラフィックを送受信できないが、パブリックインターネットにフォールバック可能
  • DZD の 0〜20% がインターフェースエラーを報告
  • DZD の 0〜20% が設定エージェントの障害を経験
  • ユーザーのオンボーディング、接続、または切断の試行の 0〜20% が失敗
  • 単一のデータプロバイダーのインターネットレイテンシ収集または送信の 20% 以上が失敗
  • すべてのデータプロバイダーのインターネットレイテンシ収集または送信の 0〜20% が失敗
  • サイレンスにできないアラートノイズを引き起こすバグまたは技術的負債
  • DIA のダウンまたはデバイスの 0〜20% で数時間にわたる台帳 RPC ネットワーキングの問題
  • マイナーバグ、表示上のエラー、顧客トラフィックに影響しない孤立したインシデントなどの低影響の問題
  • サービス中断なしにデバイスのごく一部が断続的にエラーを報告

インシデントのオープン

ポータルで Create New Record をクリックし、Type = Incident を選択するか、API 経由で送信します。

必須:

フィールド 説明
title 短い概要(最大 100 文字)
description 詳細な説明(最大 500 文字)
severity sev1、sev2、または sev3
status 作成時に終了状態(resolved、closed)には設定不可
Device and/or Link 少なくとも 1 つ必須。Web フォームではデバイスおよびリンクコードのドロップダウンから選択します。API を使用する場合は、対応する公開鍵を device_pubkey および/または affected_link_pubkey として渡します。

オプション:

フィールド 説明
reporter_name / reporter_email 連絡先情報
assignee 解決の責任者
internal_reference 内部チケット ID(例:Jira、ServiceNow)
start_at デフォルトは作成時刻;編集可能

作成されると、チケット ID、重大度、影響を受けるデバイス/リンク、コントリビューター名を含む通知がコントリビューターインシデント Slack チャンネルに投稿されます。

インシデントの更新

インシデントが進行するにつれて、チケットのステータスを最新の状態に保ってください。これは、他のコントリビューターや DZ が何が作業中であるかを理解するためのシグナルです。

ステータス 設定するタイミング
open 初期状態:問題が報告され、まだ作業されていない
acknowledged 確認し、オーナーシップを取った
investigating 積極的に診断中:ログの収集、メトリクスの確認
mitigating 根本原因が判明または推定;修正またはワークアラウンドを適用中
monitoring 修正を適用;保持されるか確認中
resolved 問題の修正を確認;根本原因が必須
closed 完全に完了;追加のアクション不要;根本原因が必須
open → acknowledged → investigating → mitigating → monitoring → resolved → closed

適切な場合はステータスをスキップできます。例えば、すぐに作業を開始した場合は open から investigating に直接ジャンプできます。現在の状態に最も正確なステータスを常に使用してください。

各ステータス更新は、元の Slack 通知スレッドに返信として投稿されます。

インシデントのクローズ

インシデントを resolved または closed に移行するには、根本原因 を設定する必要があります。すでに判明している場合は、それ以前のステージで根本原因を設定できます;クローズ時には必須となります。

コード 説明
hardware ハードウェアの修理、交換、またはアップグレード(SFP、NIC、ケーブル、デバイス)
software ソフトウェアまたはファームウェアの修正、更新、または再起動
configuration 設定の変更、修正、またはロールバック
capacity 輻輳、容量制限、またはトラフィック管理
carrier 回線、波長、またはクロスコネクトプロバイダーの問題
network_external コントリビューターの制御外の外部ネットワークの問題
facility データセンターインフラの問題(電力、冷却)
fiber_cut 修復された物理的なファイバー損傷
security 緩和されたセキュリティインシデント
human_error 修正された運用ミス
false_positive 調査後に実際の問題は見つからなかった
duplicate 別のチケットで既に追跡済み
self_resolved 介入なしに問題が解決された
dz_managed DoubleZero が管理するソフトウェアコンポーネント(activator、controller など)の問題

メンテナンス

メンテナンスレコードは、可用性に影響する可能性のある計画的で時間が限定された活動です。他のコントリビューターが確認し、ウィンドウの競合を回避できるように、事前に作成してください。

メンテナンスのスケジューリング

ポータルで Create New Record > Maintenance をクリックするか、API 経由で送信します。

必須:

フィールド 説明
title 短い概要(最大 100 文字)
description 詳細な説明(最大 500 文字)
severity sev1、sev2、または sev3。予想されるユーザーへの影響に設定します(以下の注記を参照)。
start_at 計画開始時刻(UTC)
end_at 計画終了時刻(UTC);start_at より後である必要があります
Device and/or Link 少なくとも 1 つ必須。Web フォームではデバイスおよびリンクコードのドロップダウンから選択します。API を使用する場合は、対応する公開鍵を device_pubkey および/または affected_link_pubkey として渡します。

重大度はインシデントと同様にメンテナンスにも適用されます。ウィンドウ中に予想されるユーザーへの影響に設定し、上記の重大度レベルを使用してください。

作成されると、チケット ID、影響を受けるデバイス/リンク、計画ウィンドウ、コントリビューター名を含む通知がコントリビューターメンテナンス Slack チャンネルに投稿されます。

メンテナンスステータスの管理

ウィンドウの進行に応じてステータスを最新の状態に保ってください。

ステータス 設定するタイミング
planned スケジュール済み、まだ開始されていない
in-progress 作業が開始された
completed 作業が正常に完了した
closed end_at の 24 時間後に自動設定
cancelled 実行前または実行中にキャンセル
planned → in-progress → completed → closed (auto 24h after end_at)
    ↓          ↓
    └──────────┴──→ cancelled

エスカレーション連絡先

エスカレーション連絡先は、ネットワークの担当部分に問題が発生した際に、DoubleZero や他のコントリビューターが誰に連絡すべきかを伝えます。自組織の連絡先は自分で設定します。連絡先は個人またはチーム(NOC など)にできます。各連絡先には、1 つ以上の連絡方法と、オンコールのスケジュールがあります。

Settings メニュー(歯車アイコン)を開き、Escalation Contacts を選択します。連絡先の追加や編集ができるのは ops manager のみです。

連絡先の追加

各連絡先に以下を設定します:

フィールド 説明
Name 連絡先の名前。個人または NOC などのチーム
Timezone ローカルタイムゾーン。スケジュールの読み取りに使用
Availability 24/7、または連絡先がオンコールである 1 つ以上の週次タイムスロット
Contact methods 連絡先への 1 つ以上の連絡方法(優先順位順)

対応する連絡方法は、メール、電話、Slack、Telegram、WhatsApp です。順序が重要です:最初の方法が最初に試すべき方法です。

アベイラビリティとカバレッジギャップ

連絡先は、24 時間 365 日(24/7)利用可能か、定義した週次タイムスロット中に利用可能です。例えば、月曜日から金曜日の 09:00 から 17:00 です。スロットは連絡先のローカルタイムゾーンで入力され、UTC で表示されるため、夏時間は自動的に処理されます。

coverage gaps ビューは、組織の誰もオンコールでない週の時間帯を表示します。ギャップを見つけて解消するために使用してください。

ローテーションウィンドウ

週は 30 分のウィンドウに分割されます。各ウィンドウで連絡先に連絡する順序を設定できます。これにより、各連絡先を編集することなくオンコールローテーションを実行できます。

公開範囲

連絡先を閲覧できる人を制御します。DoubleZero は常に閲覧できます。他に誰が閲覧できるかを選択します:

設定 連絡先を閲覧できる他の人
DoubleZero only(デフォルト) 他のコントリビューターはなし
Everybody すべてのコントリビューター
Some contributors 選択したコントリビューターのみ

自チームは常に連絡先を閲覧できます。公開範囲は組織全体で一度設定され、すべての連絡先に適用されます。


ユーザー管理

デフォルトでは、Ops Manager キーが組織のために行動できる唯一のアカウントです。複数の人がチケットを管理できるように、チームメンバーを追加できます。

Settings メニュー(歯車アイコン)を開き、User Management を選択します。チームメンバーの追加や削除ができるのは ops manager のみです。

各チームメンバーに以下を設定します:

フィールド 説明
Name 個人の名前
Wallet pubkey サインインに使用する Solana ウォレット
Access level Read または Read-write

アクセスレベル:

  • Read:チケットとエスカレーション連絡先の閲覧、および読み取り専用 API キーの作成が可能。チケットの作成、更新、クローズはできません。
  • Read-write:チケットの作成、更新、クローズへの完全なアクセス、および任意のレベルの API キーの作成が可能。

各チームメンバーは、Ops Manager キーを接続したときと同じ方法で、自分のウォレットでサインインします。


権限とエスカレーション

コントリビューターができること

  • 自分のデバイスとリンクのチケットのみ作成・管理。
  • チケットを自分に割り当て、または DZ/Malbeclabs にエスカレーション。
  • すべてのコントリビューターのすべてのチケットを閲覧。
  • チームメンバーの追加とアクセスレベルの設定(ops manager のみ)。
  • 組織のエスカレーション連絡先の管理(ops manager のみ)。

DZ/Malbeclabs 管理者ができること

  • 任意のコントリビューターのデバイスとリンクのチケットを作成。
  • コントリビューター間でチケットを割り当てまたは再割り当て。
  • エスカレーションとサポートリクエストの処理。

DZX リンクの所有権

DZX リンクは 2 つの異なるコントリビューターのデバイスを接続します。A サイド コントリビューター(リンク名の最初のデバイス)がリンクを所有し、そのリンクのチケットを作成できる唯一の存在です。

例: リンク deviceA:deviceB の場合、deviceA を所有するコントリビューターがリンクを所有します。

問題が Z サイドにある場合:

  1. A サイドのコントリビューターが DZX リンクのチケットを作成します。
  2. チケットを DZ/Malbeclabs に割り当てます。
  3. DZ/Malbeclabs が調査し、必要に応じて Z サイドのコントリビューターに再割り当てします。

このワークフローには制限があることを認識しています。現在、Z サイドのコントリビューターは自分が所有していない DZX リンクのチケットを作成できないため、調整は DZ/Malbeclabs を通じて行う必要があります。DZX リンクの両側がインシデントとメンテナンスを独立して報告できるよう、改善に取り組んでいます。