DevOps实践的思考

互联网的迅速发展，各种新的开放方法，devops就是最近很火的一种工程方法。

    DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

    DevOps从思想理念：“小步快跑”，“快速迭代”，就是非常适合互联网的这个快速发展的行业。从行业来说，互联网是典型的ToC业务，面向海量的用户，没有既定的规则，一切从“试错”开始，敏捷快速响应，就是应对之道。

   从过程改进的理论（行动---反馈--改进---再反馈）来说，ToC业务有非常快速的反馈，主要体现为下面几大指标。

参考：https://www.cnblogs.com/zkio/p/7239071.html

一.流量数量指标

1.浏览量（PV）2.访问次数  3. 访客数（UV）4. 新访客数  5. 新访客比率 6. IP数

二.流量质量指标

    1. 跳出率  2. 平均访问时长  3. 平均访问页数

三.流量转化指标

    1. 转化次数  2. 转化率

以上指标，恰恰是运营者要关注的目标，把这些指标反馈的开发者，就能更好的指导开发，做出更好的产品。因此DevOps所倡导的敏捷、开发运行一体化等理念是有较好的落地基础的。

然而在企业信息化的业务ToB，DevOps的实践环境就得讨论一番，有其特殊性。

    1.ToB业务一般面对的是企业内的员工，或是企业的需求。目标客户有限，且无可替代性。典型的政务型网站，你办事就得用，不存在需要吸引客户的情况。就算难用，忍忍就过去了，提意见还容易得罪的，大家是来办事了，不是找碴的，把事办了就行。所以没有及时且真实的反馈信息指导开发。

    2.ToB业务的信息化，一般是为了提高效率，需要组织再造，优化人员结构。推广信息化就会打破既得者的利益，因此实施过程中，组织中各类人员会有意无意的排斥--增加工作量，没有好处，还能会被“优化”。

    3.根据“康威定理”-设计系统的组织其产生的设计等价于组织间的沟通结构。一个企业的组织结构的现状，是由于外部内部环境各种因素长期复杂博奕出来的，企业软件的研发必定会反映这种博奕，而作为技术实践者是不可能理清期的关系，最多只能部分反映，因此企业软件总是做不好，总是被人骂。如果技术实施者对自个定位不清楚，陷入组织博弈中，那就更做不好企业应用。

    4.ToB业务的提出者，往往是管理层。他们往往想通过企业软件的开发来提高组织效率，达到某种企业的战略目标。但是企业业务错综复杂，梳理清楚就会很费时间，同时环境变化很快。就单单管理层来说，人员变动就可能很大。企业软件的实施目标就会随着时间，业务的变化，组织内的博弈，而发生变化，甚至会烂尾。除非有很强大的外部压力，如互联网的发展，使银行“脱媒”，想通过企业软件再改造组织结构是难以完成的。

    因此对于ToB业务，DevOps没有及时的反馈，就不如ToC业务产生的效果大。最多只是在软件开发的形式上加速，如编译，布署 加快，最重要提提高组织效率，达成组织目标方面，却很难实现。

  如何解决了？ 第一种层次就是“软件是企业的”反映，先进行组织结构的变化，从根本上解决利益的问题，再完成支撑软件的开发。把软件的研发与组织再造结合起来。第二种层次就是“迫于外部竞争压力的变革”以大工程的形式进行信息化。最高一层就是管理层有一个信息化的架构办公室，对企业信息化进行自顶而上的设计，同时对一线给予及时的反馈指导，处理各种复杂的矛盾。此办公室的决议不会因为管理层人员的变动而变化，从企业最根本的战略目标出发，进行企业信息化，不断的优化，不断的改进，从而适应社会发展的需求。