如果接手的是一坨随时可能散架的破车，就算SRE有通天之能，也很难通过运维手段给变成布加迪威龙。接手的时候一定要做好准入测试！很多公司会有运维准入规范，但是通常缺少运维准入测试，导致了后续诸多背锅问题。

前言

你可能会遇到下面的问题：

• 告诉研发做架构设计的时候要叫上运维做 review，研发经常忘记
• 架构上明明有问题，业务方说时间要求紧迫，先上线再慢慢优化，导致运维捏着鼻子运维这些残次品，而且每次都这样
• 明明是软件设计问题，出了问题首先要抓的是监控是否到位，运维响应是否及时，运维人员心里苦
• 架构设计看起来是完善的，但是到了线上实际跑的时候，却没有按照预期的行为来，单机挂了服务就受影响

其实研发也不是要跟运维对着干，只是有些事情研发可能没想到，或者有些事情虽然想到了，但是迫于各方面的因素没有落地。

解法

你需要：运维准入测试！

如之前的文章所述，运维总监大概率是CTO Core团队成员，需要跟CTO达成这个流程要求，然后在Core团队例会上，由CTO颁布这个要求。让运维总监去推动平级的研发负责人，也不是不行，只是费劲，而且有些研发负责人未必配合，而CTO就是名正言顺管这事的，所以，在其位谋其政，请各位CTO不要尸位素餐。

逻辑拆解

因为有“运维准入测试”这个环节，而且是上线之前的必走流程，研发人员肯定希望一次性通过，所以会提前了解要测试哪些内容，有什么要求，会主动来找SRE咨询，这样SRE工作就好推了。

需要明确，如果过不了准入测试，就不能上线，除非研发负责人审批通过，CTO审批通过。当然，即使审批通过，残次品上线了，出了问题也需要研发OnCall，SRE辅助，即稳定性第一责任人变成了研发，SRE不背这个锅。

测试分功能测试、性能测试、稳定性测试、安全测试。SRE需要提供一个类线上环境，让研发把服务部署上去，QA提供功能测试报告、性能测试报告，这个性能测试报告是容量管理的重要依据。安全测试由专职的安全工程师来做，出具安全测试报告。稳定性测试则由运维人员来做，就是混沌工程，搞挂某个机器，把机器的CPU跑满、IO跑满之类的，看看服务是否受影响，是否可以自动恢复，恢复时长如何，是否需要提前制作预案。要做稳定性测试得有可观测数据，衡量服务的健康状况，这个过程中，顺便也就把服务的SLO定出来，相关的核心监控指标定出来，可观测性数据体系建立起来。

另外，生产环境其实也应该实施混沌工程，不定时搞点事情。一个是看是否能快速定位问题，可观测体系建立的如何，一个是看故障响应流程和及时性，以及预案完备性。

小结

其实，我倒不是要站在运维的角度难为研发。而是作为IT技术团队，要提供给业务方一个稳定可靠的技术产品，这些都是必备的。业务成功，大家才能成功，业务成功需要有靠谱的技术产品。说到底，大家都是栓在一条绳上的。