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. ポータルでウォレットを接続
- https://doublezero.xyz/ops-management にアクセスします。
- Connect Your Wallet をクリックし、ウォレットを選択します。
- メッセージに署名して、Ops Manager キーの所有権を証明します。
認証が完了すると、Incident Tracking Table が表示されます。
アカウント設定は Settings メニュー(右上の歯車アイコン)内にあります:API Key Management、User Management、Escalation Contacts。表示されるオプションはロールによって異なります。
3. API キーの作成(オプション)
Web フォームの代わりにプログラムからアクセスする場合:
- Settings メニュー(歯車アイコン)を開き、API Key Management を選択します。
- 1 つ以上の API キーを作成します。
- このページから 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 サイドにある場合:
- A サイドのコントリビューターが DZX リンクのチケットを作成します。
- チケットを DZ/Malbeclabs に割り当てます。
- DZ/Malbeclabs が調査し、必要に応じて Z サイドのコントリビューターに再割り当てします。
このワークフローには制限があることを認識しています。現在、Z サイドのコントリビューターは自分が所有していない DZX リンクのチケットを作成できないため、調整は DZ/Malbeclabs を通じて行う必要があります。DZX リンクの両側がインシデントとメンテナンスを独立して報告できるよう、改善に取り組んでいます。