看到51CTO的公众号文章中推荐的一本书《凤凰项目》，内容涉及到持续集成、持续交付以及devops的工作方式方法，对一直以来笃信的项目管理模式进行了更深层次的反思与审视，带来的冲击是空前的。
需求、设计、开发、测试、运维这些角色的划分是基于追责机制的，而这恰恰也阻碍了各环节的协作，我们经常会听到运维嫌系统问题多，测试嫌开发bug多，开发嫌设计不全面，设计嫌需求不明确，为了为自己的不佳表现找借口，抱怨就变得司空见惯，各团队之间的协作变得越来越困难，越来越依赖于项目主管的协调与斡旋，效率低下不说，团队之间相互的信任若游丝一般随时都可能消失，这就是我们平时常说的——内耗。
在另一篇文章之中有详细介绍，在程序猿的形成和进化过程中，总有那么一两个分支向往更遥远的星空，脱离原来的族群走向更高级的形式，从瀑布到精益，从敏捷到DevOps就这么不断的产生了，这首先是一种思维方式和思维习惯的转变，更是一种自我管理和角色的转变，推动这些事情的转型到底应该是运维、测试抑或开发自己？正如我在团队的自我管理转型过程中宣导的那样，实现组织的自我管理并不代表没有了主管，没有了经理，而是主管和经理的角色发生了转变，是同进步的关系而不是被替代，是把自己变成教师，教练、协调者与促成者的角色，这个时期最核心的目标是抵挡住一种诱惑——那就是忍不住为下属解决问题的诱惑。
同样，如果把DevOps的实践等同于消灭测试和运维，那么运维和测试会舍我其谁的推进此事么？这本身就是一种革命，谁会去主动革自己的命呢！？所以，做这件事情之前首先要做的是重新摆正开发、测试、运维的位置，是价值的提升还是逐渐被取代，对自我的要求有何变化？原来赖以谋生的技能是否能够继续满足转型后的更高要求？需要在哪些方面弥补之前并未意识到的短板和不足？总之，如果不想自我革命也不想被革命，那就看清形势、找准位置，并为之改变自己。
当然这是从角色自己的角度来主动谋求改变，从组织的角度，角色的尽早重新定位是devops实践的落地和顺利推进的思想保证，到底该如何定位开发、测试运维的转变呢，其实devops的最佳实践的核心是开发+开发的自测试+开发的自运维，开发者的本职工作是开发，这是一直以来的共识，但开发的自测试和开发的自运维是大部分开发者抵触的，而如果想要实现流水线的作业，自测试和自运维是绕不过去的一面墙，而这是开发人员所不擅长的，这个时候测试的职责应该转变为赋能开发自测试，运维的职责转变为赋能开发自运维。
由于职责的转变，那么相应的考核标准也应改变，通过上面的转变看似所有的压力和责任都归集到了开发者身上，测试和运维成了旁观者，其实不然，如果开发的开发效率没有提高、质量没有提升，系统的稳定性没有增强，应该问责的是测试和运维，这是考核二者的根本指标，即是否有效赋能开发。而能否有效赋能开发，对测试团队来说取决于能否找到合适的工具，恰当的方法论和测试“术”层面的技巧，并进行适当的改进和实践最终集成到持续集成和持续交付的流水线中以提升开发人员的自测试水平和效率；对运维团队来说取决于能否提供合适的工具和流程、机制进行持续的反馈并将其可视化，集成到流水线中提升开发者对系统问题的响应效率，并及时处理掉，提升系统的稳定性体验，正如《凤凰项目》一书中所说：更强的产品可靠性取决于更高频率的产品变更。如果没有上述保证，这是不可想象的。
小说的结局一般都是美好的，《凤凰项目》也不例外，究竟是运维推动devops这一最佳实践还是测试推动，抑或开发推动，应该以不同公司的不同环境而定，自上而下的发起与自下而上的推动同样重要，安全、监管与产品的理解与支持也是能否有效落地的重要推手，更别说公司高层勇于试错，鼓励创新的魄力与胸怀了……
评论