OPS 管理
DoubleZero OPS 管理门户是贡献者记录和跟踪事故（计划外中断）及维护（计划内工作）的地方。所有工单对所有贡献者可见。
门户： https://doublezero.xyz/ops-management
门户与 Slack
OPS 管理门户和 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 密钥。
认证完成后，将显示 事故跟踪表。
帐户设置位于 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% 的互联网延迟数据采集或提交失败
- 缺陷或技术债务导致无法消除的告警噪音
- DIA 中断或账本 RPC 网络问题影响 0–20% 的设备持续数小时
- 低影响问题，如小型缺陷、外观错误或不影响客户流量的孤立事件
- 少量设备间歇性报告错误但未造成服务中断
开启事故
点击 Create New Record，在门户上选择 Type = Incident，或通过 API 提交。
必填：
| 字段 | 描述 |
|---|---|
title |
简短摘要（最多 100 个字符） |
description |
详细说明（最多 500 个字符） |
severity |
sev1、sev2 或 sev3 |
status |
创建时不能设置为终态（resolved、closed） |
| Device 和/或 Link | 至少需要一个。在 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 |
| Device 和/或 Link | 至少需要一个。在 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 可以添加或编辑联系人。
添加联系人
为每个联系人设置：
| 字段 | 描述 |
|---|---|
| Name | 联系人名称，可以是个人或团队（如您的 NOC） |
| Timezone | 本地时区，用于解读时间表 |
| Availability | 24/7，或联系人值班的一个或多个每周时间段 |
| Contact methods | 一种或多种联系方式，按优先级排列 |
支持的联系方式包括电子邮件、电话、Slack、Telegram 和 WhatsApp。顺序很重要：第一种方式是首先尝试的。
可用性和覆盖缺口
联系人可以全天候（24/7）可用，也可以在您定义的每周时间段内可用，例如周一至周五 09:00 至 17:00。时间段以联系人的本地时区输入并以 UTC 显示，因此夏令时会自动处理。
覆盖缺口 视图显示每周您的组织中无人值班的时间段。使用它来发现并填补缺口。
轮值窗口
一周被分成半小时的窗口。对于每个窗口，您可以设置联系人被联系的顺序。这让您无需编辑每个联系人即可运行值班轮换。
可见性
您可以控制谁能看到您的联系人。DoubleZero 始终可以看到。您可以选择其他人是否可以看到：
| 设置 | 还有谁可以看到您的联系人 |
|---|---|
| 仅 DoubleZero（默认） | 其他贡献者不可见 |
| 所有人 | 所有贡献者 |
| 部分贡献者 | 仅您选择的贡献者 |
您自己的团队始终可以看到您的联系人。可见性为整个组织设置一次，适用于您的所有联系人。
用户管理
默认情况下，您的 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 链路连接来自两个不同贡献者的设备。A 侧 贡献者（链路名称中的第一个设备）拥有该链路，是唯一可以为其创建工单的人。
示例： 对于链路 deviceA:deviceB，拥有 deviceA 的贡献者拥有该链路。
如果问题出在 Z 侧：
- A 侧贡献者为 DZX 链路创建工单。
- 将工单分配给 DZ/Malbeclabs。
- DZ/Malbeclabs 进行调查，如有需要则重新分配给 Z 侧贡献者。
我们认识到此工作流程存在局限性。Z 侧贡献者目前无法为其不拥有的 DZX 链路创建工单，这意味着协调必须通过 DZ/Malbeclabs 进行。我们正在努力改进此功能，使 DZX 链路的双方都能独立声明事故和维护。