欢迎您的访问
专注于分享最有价值的互联网技术干货

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

几个T的资料等你来白嫖
双倍快乐
资源帮找!!!

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

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

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

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

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

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

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

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

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

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

(8)“ 内审合规”的KPI,真不是增加运维人手就能解决的,在资源允许的情况下,请 不要手动删除任何资源,数据是很重要的资源。 访问控制和 权限申请的流程,真的不是限制大家,相反,哪一次数据的误删除,不是我们加班来恢复的?宝宝心里苦呀

我们的KPI都掌握在大家的手里,技术一家人,希望研发测试的同学理解。

赞(2) 打赏
版权归原创作者所有,任何形式转载请联系我们:大白菜博客 » 运维说给研发测试的心底话

评论 抢沙发

2 + 4 =
  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏