twg-operational-health

twg-operational-health

与根目录中的 twg 技能配合使用。准确的命令语法请以实时的 twg help 或 twg help describe <path> 为准。

CLI 启动器备用方案

运行 twg <command>。如果 Shell 提示 command not found，请使用 $HOME/.local/bin/twg （macOS/Linux）或 $env:LOCALAPPDATA\Programs\twg\bin\twg.exe（PowerShell），然后 告知用户将该目录添加到 PATH。不要将身份验证或命令错误视为 PATH 故障。

适用场景

• “我正在接手值班”
• “可靠性、事件、SEV 或事后复盘汇报”
• “调查正在发生的事件并寻找缓解措施”
• “分析根因或起草事后复盘/PIR 学习要点/行动项”
• “未解决的风险、阻碍、负荷过重的人员、运营健康状况”

首要步骤

确定范围、时间窗口、锚点、负责人/升级路径、状态、时效性和后续事项。 找到运营锚点后，再关联相关信息面。运行时不要使用 --site；TWG 会继承用户固定的 Jira/JSM 站点。只有用户明确要求使用其他租户时，才添加站点覆盖参数。绝不要假定事件发生在供应商内部站点。

证据策略

• 按影响、紧急程度、负责人明确性、复发风险和可执行性排序； 将当前风险与历史提及分开。
• 按服务、主题、负责人和时效性，对事件、PIR、后续事项、运行手册、负责人、资产或会议等证据进行紧凑归类。深入检查风险最高的类别；主题、负责人信号和置信度明确后即停止。
• 区分 working theory、confirmed problem、mitigation 和 root cause。确认根因时必须有因果机制；记录已关闭并不足以证明根因。将主张标记为 confirmed、supported、candidate 或 missing evidence；RCA 详情应使用引用资料。
• 后端、身份验证或架构错误反复出现时，修正一次后若错误再次发生，就报告这一缺口，并利用剩余证据，而不是尝试相近别名或查询宽泛清单。
• 通过 bitbucket pipeline query 查看构建健康状况，而不是逐个流水线调用 pipeline get；仅当失败日志或测试报告会改变模式、负责人或行动时，才使用 pipeline get。query 仅列出近期运行记录（--limit 默认值为 15），因此应调高该值并说明涵盖的时间范围。通过一次批量 get 深入检查排序后的集合。

操作指南

领导层可靠性评审 / 值班交接

加载 references/reliability-review.md。确定领导者、平台和时间窗口； 归类有证据支持的主题，区分原因与缓解措施，关联预防工作，并对领导层行动进行排序。交接时，添加首小时检查清单和升级路径图。

事件调查 / 缓解措施

适用于事件仍在进行、刚刚得到缓解或尚未进行 PIR 的情况。以事件记录为锚点，然后收集响应人员、症状、影响、近期部署/功能标志/配置、拓扑、告警/日志/指标线索、负责人、运行手册和类似事件。如果工单字段信息稀少，则通过有限的后续查询检查四类黄金信号。参见 references/incident-investigation.md。 输出四信号矩阵、假设、置信度、后续检查和缓解方案；没有因果机制时，绝不能将缓解措施称为根因。

事件后根因分析 / 经验总结

在缓解/恢复后起草或评估事后复盘/PIR 时使用。将事件与 PIR、关联文档、最终沟通记录、修复 PR 和行动项配对；涵盖已确认的缓解措施、因果机制、5 个为什么的推理链，以及检测/响应方面的缺口。参见 references/pir-root-cause.md。输出根因、促成因素、缓解措施与根因的区别，以及按优先级排序的行动项。

资产 / 资产刷新

根据项目/目标/Jira/PR/文档/活动证据整理贡献者。编写 AQL 前，先检查 Assets 架构/类型元数据；通过已发现的类似用户的属性（例如 Calculated user）关联人员。根据贡献中心性和资产风险进行排序，并报告置信度与缺口。参见 references/assets.md。

产能 / 人员配置 / 会议

进行人员配置时，先确定项目、主题或组织，并根据相关工作、所有权、评审影响力、文档以及项目或目标参与情况识别人员；提出建议前先检查工作负荷。对于会议，查询范围限定的录制内容，先预览文字记录，仅获取核心会议的完整文字记录，然后总结决策、行动项和信息缺口。

输出格式

• 开头先说明严重程度、紧迫性或建议，然后列出负责人、状态、时效性、影响、置信度和证据。
• 对于正在进行的调查，添加四信号证据矩阵和从事件到经验总结的时间线，其中包含已确认的问题、缓解措施、根因状态和预防措施。
• 汇总各项资料中的共性模式，按优先级列出后续行动并建议负责人，同时指出数据缺口（缺少文字记录、未匹配到资产、更新滞后、ACL/认证缺口、所有权不明确）。

反模式

• 不要获取所有文字记录或页面正文，也不要将每次事件提及都视为当前风险。
• 在初步事故后评审（pre-PIR）调查中，不要等聊天或评论给出 RCA 标签后才提出方向性假设。
• 没有确立机制时，不要把缓解措施称为根因。不要将工作流面板、机器人评论或不透明字段视为 RCA 叙述。
• 不要仅凭关键词匹配来判断组织归属——应交叉核对受指派人、服务负责人、PIR 参与者或组织树成员身份。
• 检查架构/类型字段前，不要根据显示名称猜测并关联 Assets；也不要仅根据活动次数提出人员配置建议。

参考资料

• references/assets.md - 以架构为先的 Assets 查询及人员/设备关联
• references/reliability-review.md - 范围受限的事件/PIR 领导层评审
• references/incident-investigation.md - 正在进行的调查与缓解措施
• references/pir-root-cause.md - 缓解后的根因分析与 PIR 工作流