什么样的项目，可由运维负责稳定性？
情景再现
业务 leader 跟运维 leader 说：“我们最近计划上线一个新项目，麻烦找个运维兄弟对接一下，上线之后的稳定性工作就靠这个兄弟了哈。”
这样一个简单的对话交接，这个项目的稳定性负责人就变成了某个还被蒙在鼓里的“运维兄弟”。
这有问题
这个项目刚刚上线，大概率还在快速迭代阶段，未必达到运维准入标准。这样的项目由“运维兄弟”来负责稳定性，能否做好很大程度是靠天意。而且项目的稳定性完全由运维人员来负责也是不对的，即便这个项目各方面都做的挺好了，也应该是研发、运维共担稳定性，除非，这个项目已经不迭代了，没有研发人员了。
那什么样的项目可由运维人员来共担稳定性？即运维准入标准是什么？
运维准入标准
我建议每个运维团队都要建立自己的准入标准，没有达到标准的项目，运维人员也可以介入，但不负责稳定性，只有达到准入标准的项目，运维人员才共担稳定性。
如果你所在的运维团队没有这个标准，建议尽快制定一下。
对于不同的公司，这个标准会有一些差异，但是一些关键点应该是共通的，比如：
- 可用性准入
- 性能准入
- 可观测性准入
- SOP准入
可用性准入
可以模仿生产环境来准备一套测试环境，把项目部署上去，然后做可用性准入测试。比如随机搞挂一台机器，把机器的资源利用率压高等。
如果条件允许，可以引入一整套的混沌测试体系，如果条件不允许，至少要把常见的手工可以模拟的故障都模拟一下。
性能准入
性能准入测试有几个好处：
- 发现明显的性能缺陷。比如项目无法达到一个常规的性能水准，要么是项目特殊（需说明），要么是架构代码设计问题
- 了解系统容量上限。未来正式上线之后方便做容量水位管理，知道何时应该扩容
可观测性准入
待上线的项目要接入指标、日志、链路追踪等常规的可观测性能力，要把 SLI 指标梳理好，日志格式要符合公司统一规范，链路追踪也必须要接入。
可观测性能力是故障发现、定位的基础，要足够重视，对这个方面不重视的研发团队，通常也是对系统稳定性不重视，或者说，就是认知低，只会写 CRUD。
SOP 准入
这是梳理常规故障应该如何应对。在做这个准入沟通时要注意，有些问题应该是系统架构自身解决的，采用外挂的方式是下策。最牛逼的系统是不太需要运维的。
结语
本文只是提纲挈领从大面上思考应该在哪些方面做准入控制，希望对你有所启发。本文没有考虑周全的也欢迎留言一起交流哈。
