DevOps发展趋势解读.docx

《DevOps发展趋势解读.docx》由会员分享，可在线阅读，更多相关《DevOps发展趋势解读.docx（6页珍藏版）》请在第一文库网上搜索。

1、DevOps发展趋势解读【导读】实施DeVoPS的初衷是想通过开发与运维的高度融合解决敏捷交付的问题，同时将DEV/0PS两支以前相对割裂的队伍更好的整合起来，实现1+12的目标。不过现实却是：DEV队伍更为膨胀，而OPS队伍则认为现在的应用是一个更黑的黑匣子2016年我参加一个系统集成公司的年会的时候，大家让我讲点什么，因为临时叫到我，于是我没加思考就讲了一个盛世危言。我说虽然今年大家取得了十分丰硕的成果，只不过我们需要居安思危，随着云计算、软件定义数据中心，特别是DeVOPS的快速发展，系统集成的门槛会越来越低，与应用开发离得比较远的系统集成企业日子会越来越难过，因此希望企业能够加速业务的

2、转型升级。在DEV和OPS两个领域都干过超过十年，这让我对DevOps有着不同寻常的期许。随着企业IT上云的加速，甚至很多DBA都已经在为自己的前途感到十分悲观了。通过自动化工具、管道化的流程工具，开发者就能够敏捷交付应用系统，并且这些系统的运维成本是极低的，一旦系统存在问题，开发者也可以快速参与，对于企业来说是诱惑力十足的愿景。在2017年，我的一个客户也和我谈了他们对未来IT的规划，他们希望通过微服务架构的应用改造，让每个独立的应用都变得足够简单，每个数据库也足够的小，同时通过在云平台上自研工具链实现DeVOPS。为此我还帮他们联系了一个做云工具链的团队，帮他们实现他们的目标。数年过去了，

3、这个客户在一些小型系统上确实尝到了DeVOPS的甜头，认为DeVoPS是万能的千金良方。直到最近的一件事，把他们搞得焦头烂额。在一些小系统上获得成功后，客户把DeVOPS的实践推广到了大型的核心系统。不过前阵子一套新上线不久大型的系统出现了一些问题，业务高峰期系统无比卡顿，大量数据积压。在多方专家分析无果后，客户找到了我们。我们发现分析这个问题与以前我们分析系统故障时完全不同了，IT基础组件和应用都部署在一个K8S的容器云环境中。出问题的数据库和Kafka都是容器化部署的，而在容器镜像打包的时候，镜像中并没有包含任何可用于监控分析的工具。因此我们只能通过有限的日志去寻找问题的蛛丝马迹。后来经过

4、几轮折腾，开始把日志中看到的堆空间不足的问题做了调整后虽然有些效果，但是还不足以解决所有的问题。最后没办法，只能要求开发人员重新打了容器镜像，又监控了一段时间，终于把系统中的问题都找出来了。最关键的问题是因为业务高峰期的并发消息数量过大，Kafka是采用JBOD三副本方式配置的，而底层的CePh存储也是三副本的。如此高的IO负载下，IO延时过大，导致系统全面出现问题。当我们把分析结果交给开发人员时，他们根本就无法理解为啥这种架构就会出问题，确实也是，开发人员并不是全栈专家。事后我也在考虑，从这个用户这些年的DeVOPS实践来看，总体还是成功的，利用工具链，开发单位实现了敏捷交付。不过也暴露了一

5、些问题，那就是当系统出问题的时候，解决起来比以前更为复杂了。而且从这个案例中，也发现了开发团队发布应用时的一些不专业的技能，给后续运行带来了极大的问题。在我们与运维团队的交流中，他们觉得研发部门发布的东西对他们来说都是一些黑匣子，他们基本上没有能力去帮助研发团队解决问题。我想这个案例暴露出来的问题还是有一定的代表性的，可能很多在实施DeVOPS的团队都会面临这个问题。无独有偶，这个案例发生后不久，8月22日，INFOWOR1D上发布了一篇ConIPUteWorId的自身业务分析师ScottCarey的文章。翻译成中文就是开发者根本不想做运维。这篇文章引用了亚马逊的EiniIyFreeman博客

6、里的一段话作为开场白，描述了DeVOPS中的一些不尽如人意的问从文字中可以看出她对于这个问题的一些无奈。当初实施DeVOPS是想通过开发与运维的高度融合解决敏捷交付的问题，同时将DEV/0PS两支以前相对割裂的队伍更好的整合起来，实现1+12的目标。不过现实往往比较骨感，这个目标的实现并不容易。最主要的问题是DEV/0PS是两支拥有完全不同技术背景与技术能力的队伍，甚至很多企业里这两支队伍的上级管理部门还不同，甚至两个部门之间存在较大的对立与争议。DevOps的理念并没有真正弥合这两个队伍之间的鸿沟，反而让DEV队伍更为膨胀，认为自己无所不能，运维部门仅仅是其从属；而OPS队伍则认为现在的应用

7、是一个更黑的黑匣子，他们对此无能为力，因此他们只要把IT基础设施，也就是服务器、云平台管管好就可以了。数据库、中间件之类的反正都和应用一起打包到容器里了，干脆就让研发队伍去管吧。这种DeVOPS实践中让开发人员承担大量运维人员的工作，开发人员可以肆无忌惮的写代码和发布系统，从表面上看，少了运维部门得干预，反而提高了系统交付的速度，也节约了成本。不过这种模式存在两个问题，一个是研发人员不仅仅成为开发领域的全栈工程师，而且依然要成为运维领域的全栈工程师，才能把这件事干好。这种期望往往是虚妄的，也是导致研发人员发出“我不想做运维”的呐喊的主因。也有一些研发人员十分愿意接受这样的挑战，不过他们很快会发

8、现拉网线和装水管需要的是两种完全不同的技能的时候，也会放弃这种追求了。这就引发了第二个问题，那就是当DEV在某个与运维相关的领域知识与能力不足的时候，发布的产品里可能会包含很多低级错误，一旦系统出问题，运维部门又缺乏技术手段去定位与分析，那么就只能请出十分高水平的专家。出现这些问题实际上并不是DeVOPS的理念出现了问题，而是我们在实现DeVOPS的路上走了弯路，让我们陷入了一些乌托邦似的陷阱。事实可能与某些IT部门的领导的愿景完全不同，那就是无论如何通过DEV来简化OPS,我们都无法完全避开运维的问题，在目前的技术条件下，可以完全自动驾驶的IT系统是不存在的。我们的工具链开发过程中缺乏运维专

9、家的参与，只注重功能的实现而缺乏运维知识，这导致了我们的DeVOPS流程走的很顺利，但是一旦出现问题，DEV人员不明白系统，因此无从下手。OPS人员面对应用系统的黑匣子，空有一身本领也无从下手。而当每次系统出问题，运维团队都无法解决问题，必须请来十分强大的专家，用上内核跟踪，火焰图这样的终极武器来定位问题的时候，我们的DeVOPS可能已经走向邪路了。更有甚者，还有一些组织的领导和某些研发团队的负责人认为DevOps可以最终演进为更高的目标-NOoPs,从而可以大大节约运维的成本，并把运维的费用全部或者大部分转移到研发一端。最近在我与一些企业IT负责人交流的时候，有不少都流露出了这种愿望。这些研

10、发出身的IT主管都认为，只要研发时设计到位，NOOPS是能够实现的。以我目前的认知能力来看，这是一种十分可怕的观点。实际上，DeVOPS不是要培养更为全栈的工程师而是要让DEV/0PS两个工作结合的更为紧密，从而变得更高效。目前DevOps存在的问题从最根本上还是组织对于DevOps的认知错误导致的。为了节约成本而把运维责任推给了开发人员并不是解决DevOps问题的良药。通过应用架构的改造，以及系统上云，确实可以大大节约企业的IT运营成本，只不过开发与运维这两个体系的建设并不能够去做简化或者弱化运维。让运维人员必须深入了解开发与让开发人员成为运维专家都不是DeVoPS中正确的手段。通过研发与运

11、维的专家共同构建标准化的规范体系，工具链，智能化运维工具，通过不断提升的底层平台的能力来支撑DeVOPs,才能让这个工作做的更好。如果说DeVoPS并不是为了让DeV都成为OPS专家，OPS都成DeV专家，那么这部分互相跨越边界的工作就必然需要一种自动化的手段来实现。因此和作者SCott的观点类似的是，我也认为平台工程可能是可以解决DeVOPS目前存在的问题的一种方法，只不过平台工程本身就是个大工程。需要更高水平的研发与运维专家参与，并且投入足够的资金才能够做好。不过目前我们的大部分组织都只希望从DeVOPS中获得实惠，而并不想为DeVOPS投入平台工程的成本。如果真的这样，这个问题就很难解决了。平台工程里的一个十分关键的问题就是运维专家的经验如何成为工具链的一部分，这里就涉及到了专家知识自动化的问题，如果不解决这个基础问题，那么运维专家就要全程参与DevOPS的每个活动，这也是极为高成本的，因此工具链中的运维知识生态化也是十分关键的，也值得认真探讨，只是今天的篇幅有限，我们就不展开讨论了。最后要说的是，今天我的观点仅仅是认知与解决DeVOPS问题的一个方法，并不是放之四海皆准的原则，不同的企业，不同的IT发展阶段，不同的技术团队，在DeVOPS的实践中会有不同的选择。不管如何，组织的IT主管真正看明白DevOps才是这个组织的DevOps走上康庄大道的第一步。-全文完-