OPS Management
DoubleZero OPS Management 门户是贡献者记录和跟踪整个网络中的事件（计划外中断）和维护（计划工作）的地方。所有工单对所有贡献者可见。
门户： https://doublezero.xyz/ops-management
门户与 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。
- 创建一个或多个 API 密钥。
- 从此页面下载 API 文档。
事件
事件是计划外的影响服务的事件。
严重级别
根据对 DoubleZero 网络的影响分配严重级别。随着情况发展，您可以更新严重级别。
| 严重级别 | 影响 | 响应 |
|---|---|---|
sev1 |
完全中断或主要控制/数据平面故障且无回退方案 | 立即放下一切，即使在非工作时间。立即升级到 DoubleZero Foundation。 |
sev2 |
部分但严重的影响；服务降级，可能有回退方案 | 视为紧急。积极协调。持续降级需要隔夜响应。 |
sev3 |
有限或无用户可见影响；如不解决可能升级 | 工作时间内的最高优先级。密切监控。除非影响增大，否则不需要非工作时间升级。 |
严重级别示例
Sev1 示例
- 超过 10% 的用户流量在 DoubleZero 上被黑洞吞噬，无法回退到公共互联网
- 超过 80% 的用户入网、连接或断开尝试失败
- 超过 20% 的 DZD 报告接口错误
- Controller 向 DZD 代理返回有效但不正确的配置
Sev2 示例
- 超过 20% 的用户无法通过 DoubleZero 隧道发送/接收流量，但回退到公共互联网
- 0–10% 的用户流量在 DoubleZero 上被黑洞吞噬且无回退方案
- 20–80% 的新用户入网、连接或断开尝试失败
- 超过 20% 的配置代理无法应用 DZD 配置
- 0–20% 的 DZD 报告接口错误
- 上游问题导致可观测性丢失（监控/告警不可用）
- 链上数据管道不可用或产生不正确的数据
- 超过 20% 的互联网延迟收集或提交失败
- DZD 代理无法访问 Controller
- Controller 向 DZD 返回无效配置且不会被应用
Sev3 示例
- 0–20% 的用户无法通过 DoubleZero 隧道发送/接收流量，但有回退到公共互联网的方案
- 0–20% 的 DZD 报告接口错误
- 0–20% 的 DZD 遇到配置代理故障
- 0–20% 的用户入网、连接或断开尝试失败
- 单个数据提供商超过 20% 的互联网延迟收集或提交失败
- 所有数据提供商 0–20% 的互联网延迟收集或提交失败
- Bug 或技术债导致无法静音的告警噪音
- DIA 不可用或账本 RPC 网络问题影响 0–20% 的设备持续数小时
- 低影响问题，如小 Bug、外观错误或不影响客户流量的孤立事件
- 少量设备间歇性报告错误但无服务中断
打开事件
点击 Create New Record，在门户上选择 Type = Incident，或通过 API 提交。
必填：
| 字段 | 描述 |
|---|---|
title |
简短摘要（最多 100 个字符） |
description |
详细说明（最多 500 个字符） |
severity |
sev1、sev2 或 sev3 |
status |
创建时不能设置为终止状态（resolved、closed） |
| 设备和/或链路 | 至少需要一个。在 Web 表单上，从您的设备和链路代码下拉列表中选择。使用 API 时，传递对应的公钥作为 device_pubkey 和/或 affected_link_pubkey。 |
可选：
| 字段 | 描述 |
|---|---|
reporter_name / reporter_email |
您的联系方式 |
assignee |
负责解决问题的人 |
internal_reference |
您的内部工单 ID（例如 Jira、ServiceNow） |
start_at |
默认为创建时间；可编辑 |
创建后，将在贡献者事件 Slack 频道中发布通知，包含工单 ID、严重级别、受影响的设备/链路和贡献者名称。
更新事件
随着事件的进展，保持工单状态为最新。这是其他贡献者和 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 |
| 设备和/或链路 | 至少需要一个。在 Web 表单上，从您的设备和链路代码下拉列表中选择。使用 API 时，传递对应的公钥作为 device_pubkey 和/或 affected_link_pubkey。 |
严重级别对维护的适用方式与事件相同。将其设置为您预期在窗口期间对用户的影响，使用上述严重级别。
创建后，将在贡献者维护 Slack 频道中发布通知，包含工单 ID、受影响的设备/链路、计划窗口和贡献者名称。
管理维护状态
随着窗口的推进，保持状态为最新。
| 状态 | 何时设置 |
|---|---|
planned |
已安排，尚未开始 |
in-progress |
工作已开始 |
completed |
工作已成功完成 |
closed |
在 end_at 后 24 小时自动设置 |
cancelled |
在执行前或执行期间取消 |
planned → in-progress → completed → closed (auto 24h after end_at)
↓ ↓
└──────────┴──→ cancelled
升级联系人
升级联系人告诉 DoubleZero 和其他贡献者，当您负责的网络部分出现问题时应联系谁。您为自己的组织设置联系人。联系人可以是个人或团队，例如您的 NOC。每个联系人有一种或多种联系方式以及值班时间表。
打开 Settings 菜单（齿轮图标）并选择 Escalation Contacts。只有 ops manager 可以添加或编辑联系人。
添加联系人
为每个联系人设置：
| 字段 | 描述 |
|---|---|
| 名称 | 联系人的名称，无论是个人还是团队（如您的 NOC） |
| 时区 | 本地时区，用于读取时间表 |
| 可用性 | 24/7，或一个或多个每周值班时间段 |
| 联系方式 | 一种或多种联系方式，按优先级排序 |
支持的联系方式包括电子邮件、电话、Slack、Telegram 和 WhatsApp。顺序很重要：第一种方式是首先尝试的方式。
可用性和覆盖缺口
联系人要么全天候（24/7）可用，要么在您定义的每周时间段内可用，例如周一至周五，09:00 至 17:00。时间段以联系人的本地时区输入并以 UTC 显示，因此夏令时会自动为您处理。
覆盖缺口视图显示每周您的组织中无人值班的时段。使用它来发现并填补缺口。
轮值窗口
一周被分为半小时的窗口。对于每个窗口，您可以设置联系人被联系的顺序。这使您可以在不编辑每个联系人的情况下运行值班轮值。
可见性
您可以控制谁能看到您的联系人。DoubleZero 始终可以看到。您可以选择其他人是否可以：
| 设置 | 其他谁可以看到您的联系人 |
|---|---|
| 仅 DoubleZero（默认） | 没有其他贡献者 |
| 所有人 | 所有贡献者 |
| 部分贡献者 | 仅您选择的贡献者 |
您自己的团队始终可以看到您的联系人。可见性为整个组织设置一次，适用于您的所有联系人。
用户管理
默认情况下，您的 Ops Manager 密钥是唯一可以代表您的组织操作的账户。您可以添加团队成员，以便更多人可以管理您的工单。
打开 Settings 菜单（齿轮图标）并选择 User Management。只有 ops manager 可以添加或移除团队成员。
为每个团队成员设置：
| 字段 | 描述 |
|---|---|
| 名称 | 此人的姓名 |
| 钱包公钥 | 他们用于登录的 Solana 钱包 |
| 访问级别 | Read 或 Read-write |
访问级别：
- Read：可以查看工单和升级联系人，并创建只读 API 密钥。不能创建、更新或关闭工单。
- Read-write：拥有创建、更新和关闭工单的完整权限，并可以创建任何级别的 API 密钥。
每个团队成员使用自己的钱包登录，方式与您连接 Ops Manager 密钥相同。
权限和升级
贡献者可以做什么
- 仅为自己的设备和链路创建和管理工单。
- 将工单分配给自己或升级到 DZ/Malbeclabs。
- 查看所有贡献者的所有工单。
- 添加团队成员并设置其访问级别（仅限 ops manager）。
- 管理其组织的升级联系人（仅限 ops manager）。
DZ/Malbeclabs 管理员可以做什么
- 为任何贡献者的设备和链路创建工单。
- 在贡献者之间分配或重新分配工单。
- 处理升级和支持请求。
DZX 链路所有权
DZX 链路连接来自两个不同贡献者的设备。A 侧贡献者（链路名称中的第一个设备）拥有该链路，并且是唯一可以为其创建工单的人。
示例： 对于链路 deviceA:deviceB，拥有 deviceA 的贡献者拥有该链路。
如果问题在 Z 侧：
- A 侧贡献者为 DZX 链路创建工单。
- 将工单分配给 DZ/Malbeclabs。
- DZ/Malbeclabs 进行调查，如有需要将重新分配给 Z 侧贡献者。
我们认识到此工作流程存在局限性。Z 侧贡献者目前无法为不属于自己的 DZX 链路创建工单，这意味着协调必须通过 DZ/Malbeclabs 进行。我们正在改进此功能，以便 DZX 链路的双方都可以独立声明事件和维护。