当我决定在团队里面开展DevOps实践的时候，我觉得最难的不是技术或者工具，而是对团队的改造。在技术领域，相信无论是公司或者业界都有很多比较成熟的技术，要满足目前业务的发展，找到适合团队的技术选型应该难度不大。在工具的选择上，更是已经形成了很多事实上的标准，可以参考的案例也很多。
在DevOps的实践前期，我们需要在项目微服务化改造，环境搭建，CI建设等方面投入很多人力。在交付压力没有降低的情况下，需要团队额外做上面这些事情，有些小伙伴可能就不能理解，觉得这是瞎折腾。所以在DevOps实践之前一定要跟团队充分沟通，让小伙伴们都理解DevOps实践最终能给团队带来哪些收益。但这个收益真的很难说清楚。因为DevOps实践带来的收益往往是比较虚的，起码这个收益是间接或者长期的，并不是所有人都看得到。比如有位小伙伴问我，进行DevOps实践以后，我们能少加点班吗？在这个行业待了一段时间的人都很清楚的知道，任何一种先进的技术，架构，开发模式的出现，都不是为了解决加班多这个问题的.....它们解决的问题是要从原来每个星期迭代一个版本提升到迭代两个版本，但加班时间是不能减少的。当然，我不能这样回答那位小伙伴的问题，毕竟这样的事实对一位小萌新来说是有点残酷的。我只能反复强调会给个人成长带来的收益敷衍他的这个问题......
软件转型的过程中，一般认为需要打赢三场战争才能成功。第一是技术战争，第二是商业模式战争，第三是意识战争。意识战争往往是最难的。要让团队的所有的小伙伴都认同了DevOps实践能给我们带来收益这个观点似乎是不可能的，所以实际操作的过程中，只要有大部分小伙伴愿意尝试，我们就可以开始了。只要我们在实践的过程中，能不断的给其他小伙伴一些正面的反馈，他们也会在将信将疑的实践中慢慢转变意识。
团队改造的目标是打造全功能团队，我们要打破原来产品，开发，测试，运维，运营之间的边界，把大家融合成一个目标一致的团队。比如原来开发和测试之间的目标就是不一致的。开发完成功能开发后肯定想着快速上线，功能交付就是开发的目标。但测试肯定要让开发把所有bug都解决了才允许上线，因为测试的目标是保证版本的质量。当我们打破开发和测试的边界以后，团队的目标都定为快速迭代，快速纠错。这时候可能版本还有一些优先级比较低的bug，但测试也允许上线了，因为大家的目标都是快速迭代。
因为我们打破了原来产品，开发，测试，运维，运营之间的边界，所以团队成员的分工职责可能就没有原来那么明显了，这就要求团队的小伙伴要互相学习。除了原来自己擅长的领域要继续保持先进以外，还需要学习其他领域的知识，比如开发要懂一些测试，测试要懂一些运维等等。
最后，我们还需要发现团队的短板，只有迅速把短板补齐了，团队才能高效运转。
网友评论