在回答这个问题之前,我们先了解一下什么是运维模式。所有模式是对待人和事物的态度后得到的方法论,比如我对人性是持悲观的态度,那么我就需要建立流程制度对人加以约束,使他们在做事时尽量减少自己的主观意志,客观去完成所分配的任务。反之,如果我对人性持有乐观态度,那么我可能更多地去激励,让人员发挥主观能动性,形成共同的价值观、行为准则,通过系统方式给予落地。这里需要注意的是:人是很复杂的动物,往往不能单一而论,大多时需要两者结合,合适自己的才是***的。如果你想和更多DevOps技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的***实践以及行业***动态。
在流程约束上,目前做得***的运维模式是ITIL理论,它通过流程驱动运维落地,同时有很好的落地实践,包括要建设哪些系统都有清晰的注明。我记得我***次接触ITIL理论时,惊为天人,因为在复杂运维场景下能够抽象出一套完善理论是一件很不容易的事。对于很多初成立的团队,我建议选择这种模式作为伊始。ITIL的优点除了上面易落地外还有以下原因,值得尝试:
见效快,比如只需要建立一个变更流程,就能立即大幅度提升生产质量。
运维部门主导,在ITIL模式下的绝大多数系统和流程只需要运维部门实施即可,甚至最关键的CICD,ITIL体系也只关注于***发布到生产那一块。
管理落地,流程落地的过程就是管理落地的过程,在这个过程中,管理者可以把自己的经验和方法完整地实践下来,可以***屏蔽执行者的差异。
ITIL主要关注质量和效率之间的质量,兼顾效率。这句话的理解是,当质量和效率发生冲突时,ITIL会优先保障质量。所以当要求效率优先时,ITIL会比较困难,这也就为DevOps发展提供了空间。当然ITIL本身也有其他问题,比如流程反弹、边际效益等,但由于不是本文重点因此不展开讲。
而DevOps模式的本质是对开发、测试及运维角色的分工挑战。如果我们把重心放到最终产出物,即如何快速提供新服务给用户时,就会遇到一个非常大的挑战–开发、测试、运维需要融为一体。让以上三种角色协同其实不是一件容易的事情,因为三方的KPI、行事风格及语言体系并不相同,这就是我们常说的那堵部门墙。