运维说给研发测试的心底话

互联网，讲究快速迭代，快速上线，敏捷开发。

有些 固定上线时间 的项目，可能因为技术方案变化，导致测试时间压缩，最终导致上线出问题，而由运维来背锅。

为保住KPI，运维有很多心里话想和研发测试说一说：

（1）“ 敏捷开发，频繁交付 ”的KPI，真不是增加运维人手就能解决的，需要 自动化回归 的支持，需要 自动化上线 的支持

（2）“ 上线失败，快速回滚 ”的KPI，真不是增加运维人手就能解决的，需要 回滚方案 的支持，而 回滚方案真的测试 过么

（3）“ 快速扩容，快速响应 ”的KPI，真不是增加运维人手就能解决的，需要架构设计的支持（很多系统无法 水平扩展 ，来了机器，无法扩容），需要 快速部署 的支持，需要 服务发现 的支持（所有上游修改配置重启肯定是不行的），需要 压力测试和容量评估 的支持

（4）“ 系统高可用 ”的KPI，真不是增加运维人手就能解决的，需要 优雅降级 的支持，需要架构设计的支持，如何评判系统是否 高可用 ？这个简单，关掉线上任何一台机器试试，看用户服务是否受影响，如果受影响，研发哥哥们拜托了

（5）“ 快速故障报警 ”的KPI，真不是增加运维人手就能解决的，需要 监控系统 的支持（操作系统和运维层面的监控，我们可以实施，但错误日志、接口、业务的监控呢？），另外报警短信能少一点么，过度报警会让人变得“麻木不仁”的

（6）“ 快速故障定位 ”的KPI，真不是增加运维人手就能解决的，需要数据 量化健康信息 的支持（58到家的守望者平台做的还是不错的），需要 快速诊断 的支持（58到家的调用链跟踪系统做的还是不错的）

（7）“ 快速故障恢复 ”的KPI，真不是增加运维人手就能解决的，需要 故障转移 的支持，相信我们，故障发生时，如果运维人员不知道怎么抉择，且又必须做出抉择，这时的抉择往往是错的（我们能做的，是重启），我们也不想凌晨打给你们，但希望你们能实现 自动化