“ 最近,一个资深的DevOps专家来和我们交流,听到他一些有启发性的观点,在此分享给大家。”
01
—
PO要关注系统稳定性吗?
交流从他的一个问题开始:“你们的PO会关注系统的稳定性吗?”
专家认为,真正的PO是要关注系统的稳定性的,包括时刻关注有关系统生产环境的各项监控指标以及软件交付过程中的各项DevOps指标,比如软件发布频率、软件变更引起的故障率、MTTR(故障平均修复时间)等。
PO要把提升系统稳定性的各种改进(比如监控、自动化运维)、故障修复与新功能开发放在同一个Backlog里,并把新功能开发的优先级放在系统稳定性、软件交付能力改进与故障修复之后。
因为如果系统不稳定,或者总是有各种故障,或者新功能的交付周期很长,业务都会受到严重影响,开发再多新功能也无济于事。
他曾经说服他负责的IT服务的业务大佬把新功能开发停下来两个月,让交付团队集中精力在提升系统的生产环境运维能力和DevOps能力的各种开发中。
经过这么一役,系统交付新功能的频率被大大提升,故障率则大幅下降。整个交付体验和运维能力都被大大提升了,业务也尝到了好处。
02
—
DevOps是关于每一个人的
专家分享了曾经有好几个月,他和对接的业务大佬每天早上坐在一起聊系统。
一开始,业务大佬认为IT系统都是垃圾,严重阻碍了业务的发展。专家给他演示了每一个功能开发,在系统上意味着什么,生产环境上每一个故障,是什么原因引起的。
他也在交流中深入理解了业务、市场的需要是什么。
经过几个月的深入交流,业务大佬对IT团队有了同理心,以专家为代表的IT团队,也对业务有了同理心。大家对彼此的需要有了更深入的理解。
业务需要IT更快的交付与故障修复能力,IT需要业务给予更多的时间与人力投入在软件架构、DevOps能力和自动化运维上。
结果是,双方都得到了自己想要的支持。DevOps的成功,是来自价值链上的每一个人的,包括业务团队与IT团队。
03
—
什么是好的工程平台
我们都说,DevOps的下一阶段是平台工程。
毕竟,每个交付团队重复造轮子般地搭建差不多的流水线工具栈,每个交付团队都要面对繁杂且冗长的监管、合规、安全等非功能性要求,从整个组织上来说,还是有巨大的时间和人力上的浪费。
最好的工程平台是,交付团队只需要关注业务功能开发,一旦他们的程序部署到平台上,CI/CD以及各种的非功能检查都会被启动,自动的检查、测试通过后就能直接运行到平台上,交付团队也不需要关心运行平台的底层设施和运维。
但专家也强调,工程平台给予交付团队便利的同时,平台对于交付团队来说也是一个受限的环境,交付团队必须遵守平台的各种具体要求,方能成为平台上的“公民”。
平台不可能做到面面俱到,必然有各种的局限,交付团队选择一个工程平台时,也必须要深入理解使用该平台的得与失。
甘蔗没有两头甜,其实这就像云上提供IaaS、PaaS和SaaS。你要自由,你就选择IaaS,但所有构建、运维等所有事务都要自己负责;你要省心,你就选择PaaS或SaaS,但适用性会受到限制。
所谓的自由,应该建基于团队的成熟性上。当一个团队的成熟度不够或者缺乏所需要的财力和人力时,通过放弃一些自由度和灵活性,选择适合自己的工程平台,是划算的选择。
04
—
数据应该关注做了什么
要实现真正的DevOps,数据和指标非常重要。而且,这些数据必须反映的是人们做了什么。比方说代码提交的行为、代码发布到生产环境的行为等。只有反映行为的数据是真实的,只有真实的数据和指标才值得被研究。
比方说,当一个组织声称自己是一家软件技术公司,但如果数据反映出来,只有30%不到的员工有代码提交的行为,那么剩下那70%的员工在做什么,就值得研究了。
再比方说,如果一个10个人的DevOps团队,数据反映只有1、2个人在发布代码到生产环境,这是否合理?
希望以上观点对你也有所启发。
觉得文章不错,顺手点个“点赞”、“在看”或转发给朋友们吧。
相关阅读:
关于作者
关注公众号看其他原创作品
敏于思 捷于行
坚持原创高质量软件交付相关文章
觉得好看,点个“点赞”、“在看”或转发给朋友们,欢迎你留言。