audit-performance

审计性能

找出增长没有有效上限或重复执行却没有进展的工作。生成有证据支撑的台账或报告，然后优先选择能保留恢复能力的最小修复方案。

工作流

1. 追踪热点路径。 找出重复执行的同步、轮询、流处理、重试、队列、定时任务、文件系统遍历和请求时读取。沿生产调用方追踪每一项；忽略仅用于测试的路径。
2. 计算放大效应。 用具体单位说明触发条件和最坏情况下的工作量：行数、查询数、页面数、条目数、字节数、任务数、重试次数或完整文件重写次数。区分有界的大常数与随历史记录、租户、路径或故障持续时间增长的工作量。
3. 检查是否持续推进。 对每项重试、固定前缀批处理、截止点或过渡期轮询，确定下一次尝试前会发生什么变化。如果没有任何内容必须改变，它就可能无限循环或永久饥饿。检查部分修复是否只是延后了相同的工作。
4. 证伪严重性。 检查现有上限、索引、退避、截止时间、修复负责人和调用方频率。排除那些已被低成本充分限制或持续自动修复的问题。
5. 先记录，再修复。 如果项目维护性能台账，按照现有惯例追加每项有依据的问题及重要的排除项。否则，返回简洁的报告。包含优先级、触发条件、影响、当前负责人、验收切入点和证据。
6. 按照下方策略确定优先级。 如果获准实施，则调用项目的测试编写工作流，并在最外层可行的切入点证明旧行为会导致测试失败。完成修复和审查，并更新台账或报告，附上验证证据。

优先级策略

当问题可能导致用户可见的卡顿或错误、内存／磁盘增长、请求处理受阻、数据丢失、整个服务群集范围的放大效应，或阻止后续工作的毒性条目时，应给予最高优先级。

优先选择能限制现有工作量且风险较低的修复方案：逐页流式处理、遵循背压、合并定时任务、将毒性行移出、跳过已证实的空操作，或确保一次穷尽式搜索最终会得到终止结论。安全上限是用于防止异常情况的保护措施，不是常规产品限制：将上限设在合法的大型工作负载之上；达到上限时发出可采取行动的遥测信息，并明确接下来会发生什么。

不要仅凭看起来吓人的数字确定优先级：

• 只要被轮询的状态有实际的恢复负责人，且最终可能发生变化，轮询就可以持续进行。应修复永远无法恢复的状态，而不是仅仅持续时间较长的定时器。
• 如果没有生产证据，低成本且有界的数据库工作可以接受。不要仅仅为了减少适度的固定查询数量，就构建投影、缓存、游标状态机或备用读取模型。
• 不要优化掉近期可能用于产品界面或行为的信息。

防护原则

• 保留修复能力。缓存或空操作快捷路径必须保留低成本的恢复信号，并在出现偏移、不确定、重启或先前失败时回退到常规协调。
• 恢复扫描必须完成，或持久化记录进度以便继续。对于本地且可清理的命名空间，优先进行一次完整扫描，并将上限设得足够高，以便识别异常情况，而不是普通的大型项目。对于确实很大的命名空间，持久化游标并从游标处继续。找到目标时更新身份；穷尽扫描仍未找到，或达到异常上限时，给出该领域的终止判定。切勿永远重复扫描同一个未完成的前缀。
• 区分可重试故障与终止故障。永久性拒绝不得永远卡在队列头部或固定前缀处。
• 限制传输两端及所有持久化和内存队列的容量。明确说明溢出时的行为；绝不静默丢弃已接受的持久化数据。
• 评估缓存、索引或增量协议时，应看最糟糕的编辑操作，而不是平静时的平均表现：向保留的长集合中插入、修改远离活动视图的数据、移动、删除。断言工作量有界，同时验证结果完全准确。
• 在信任测量结果之前，确认被测工作负载确实完成了预期操作：各项力量相遇、路线确实走完、故障分支确实执行。也要测量故障分支。
• 将成本测量与进程中运行的其他所有内容隔离开。
• 让兼容性工作与产品生命周期相匹配。对于发布前的代码，优先直接修改；除非真实的持久化数据确有需要，否则不要添加旧版分支或迁移。
• 每个新增或变更的限制都必须有可观察的日志或指标，说明限制类型、配置上限、受影响的所有者和过载时的结果。

完成标准

只有当每项审计发现都有生产环境触发条件、量化的放大效应、优先级依据、验收切入点和记录在案的处置结果，且每项被排除的候选项都说明了使其可接受的上限或修复机制时，审计才算完成。只有当实现的红绿验证证明工作量有界且能够持续恢复时，实现才算完成。