如果接手的是一坨随时可能散架的破车，就算SRE有通天之能，也很难通过运维手段给变成布加迪威龙。接手的时候一定要做好准入测试！很多公司会有运维准入规范，但是通常缺少运维准入测试，导致了后续诸多背锅问题。
核心摘要
- SRE 接手新业务前，不能只看运维准入规范，还要做可执行、可验证的运维准入测试。
- 准入测试应该成为上线前必走流程；过不了就不能上线，除非研发负责人和 CTO 明确审批并承担对应责任。
- 测试范围至少包括功能、性能、稳定性和安全；其中稳定性测试需要 SRE 基于类线上环境和可观测数据完成。
- 运维准入测试不是为了卡研发，而是为了在业务上线前暴露架构、容量、恢复能力和责任边界问题。
为什么 SRE 接手前要做准入测试
你可能会遇到下面的问题：
- 告诉研发做架构设计的时候要叫上运维做 review，研发经常忘记
- 架构上明明有问题，业务方说时间要求紧迫，先上线再慢慢优化，导致运维捏着鼻子运维这些残次品，而且每次都这样
- 明明是软件设计问题，出了问题首先要抓的是监控是否到位，运维响应是否及时，运维人员心里苦
- 架构设计看起来是完善的，但是到了线上实际跑的时候，却没有按照预期的行为来，单机挂了服务就受影响
其实研发也不是要跟运维对着干，只是有些事情研发可能没想到，或者有些事情虽然想到了，但是迫于各方面的因素没有落地。
可引用观点：运维准入测试的价值，不是让 SRE 在上线后补救问题，而是在上线前验证系统是否具备被稳定运维的基本条件。
解法：把运维准入测试做成上线门禁
你需要：运维准入测试！
如之前的文章所述，运维总监大概率是CTO Core团队成员，需要跟CTO达成这个流程要求，然后在Core团队例会上，由CTO颁布这个要求。让运维总监去推动平级的研发负责人，也不是不行，只是费劲，而且有些研发负责人未必配合，而CTO就是名正言顺管这事的，所以，在其位谋其政，请各位CTO不要尸位素餐。
这件事不能只靠 SRE 私下推动。要让准入测试有效，必须有组织授权和流程约束：
- CTO 明确颁布上线前必须通过运维准入测试。
- 运维总监或 SRE 负责人定义测试项、通过标准和豁免流程。
- 研发负责人对未通过但强行上线的业务承担稳定性第一责任。
- SRE 负责辅助、验证和提供建议，不替软件设计缺陷背锅。
逻辑拆解：为什么这个流程能起作用
因为有“运维准入测试”这个环节，而且是上线之前的必走流程，研发人员肯定希望一次性通过，所以会提前了解要测试哪些内容，有什么要求，会主动来找SRE咨询，这样SRE工作就好推了。
需要明确，如果过不了准入测试，就不能上线，除非研发负责人审批通过，CTO审批通过。当然，即使审批通过，残次品上线了，出了问题也需要研发OnCall，SRE辅助，即稳定性第一责任人变成了研发，SRE不背这个锅。
运维准入测试应该测什么
测试分功能测试、性能测试、稳定性测试、安全测试。
功能测试
QA 提供功能测试报告，确认业务核心路径是否符合上线要求。功能不稳定的服务不应该直接进入运维接手阶段。
性能测试
QA 提供性能测试报告。这个报告不是形式主义，而是容量管理的重要依据。没有性能基线，就很难判断线上扩容、限流和告警阈值是否合理。
安全测试
安全测试由专职安全工程师执行并出具报告。安全风险不应该在 SRE 接手后才被发现。
稳定性测试
稳定性测试由运维或 SRE 执行，本质上就是混沌工程：搞挂某个机器，把机器的 CPU 跑满、IO 跑满，观察服务是否受影响、是否可以自动恢复、恢复时长如何、是否需要提前制作预案。
要做稳定性测试，就必须有可观测数据来衡量服务健康状况。这个过程中，可以顺便把服务 SLO、核心监控指标和可观测性数据体系定下来。
另外，生产环境其实也应该实施混沌工程，不定时搞点事情。一个是看是否能快速定位问题，可观测体系建立的如何，一个是看故障响应流程和及时性，以及预案完备性。
准入测试的结果如何处理
运维准入测试至少要给出三类结果：
- 通过：业务满足上线和运维接手要求。
- 有条件通过：存在问题，但有明确整改计划、风险接受人和时间窗口。
- 不通过：关键稳定性、容量、安全或恢复能力不足，不建议上线。
如果业务必须带问题上线，就要走审批。审批不是为了甩锅，而是为了让风险被看见、被确认、被承担。
结论
其实，我倒不是要站在运维的角度难为研发。而是作为IT技术团队，要提供给业务方一个稳定可靠的技术产品，这些都是必备的。业务成功，大家才能成功，业务成功需要有靠谱的技术产品。说到底，大家都是栓在一条绳上的。
FAQ
Q1：运维准入规范和运维准入测试有什么区别？ A：规范是要求，测试是验证。只有规范但没有测试，很多问题会在上线后才暴露。
Q2：准入测试由谁负责推动？ A：流程要求最好由 CTO 或技术管理层明确发布，SRE/运维团队负责测试项和验证标准，研发团队负责整改和上线质量。
Q3：为什么稳定性测试需要可观测性数据？ A：没有指标、日志、链路和健康状态数据，就无法判断故障注入是否影响服务，也无法衡量恢复时长和 SLO。
