DevOps企业落地，工具比脚本更重要
本帖最后由 monicazhang 于 2017-8-30 14:12 编辑初创企业的 IT 运维困局对于业务处在高速成长期的初创企业来说，IT 运维存在非常多的盲点和痛点。互联网架构 IT 系统的维护成本非常高，单纯靠人工借助开源工具维护 CMDB（配置管理数据库）困难且不现实。在未实现 DevOps 的 IT 环境中，研发人员无法了解到应用上线之后的运行效率、运行时间，以及带来的实际收益，后期能否对系统资源进行回收。对初创公司而言，业务上线后一旦无法产生效益，资源的回收是非常关键的。无论是从计算、存储还是网络层面，资源回收不及时会导致系统资源占用不断攀升。另一方面，IT 规模高速扩张后面临着越来越多的技术债务和遗留问题。作为运维团队来说，最重要的就是为结果负责。研发上线应用，需要运维团队马上就可以提供机器。而初创型企业不像 BAT 这样的大型互联网企业拥有大量的冗余资源，系统能够实现高强度的弹性伸缩。那么对于现有 IT 资源的精细化管理和高效率运维就显得愈加重要。总结而言，初创型企业的 IT 运维的难点包括以下四个方面：1. 系统架构IaaS 的云化和容器化，PaaS 的智能化，依赖库多样化，RUNTIME（运行时）复杂化，让运维人员无法应对新时代的运维要求。2. 技术债务由于资源成本压力，中小企业的 IT 运维及 IT 系统存在大量历史债务。大量的精力投向增量业务，对存量业务关注不够。业务部门要求开发部门尽快上线新业务，开发部门要求运维部门尽快把应用上线，而结果就是对产品和服务无法实现高效运维，形成恶性循环。3. 人员流动由于系统快速迭代，运维人员的工作强度大，流动率过高。对于基于开源工具的系统运维而言，人员的流动将直接影响系统运维的稳定性和可持续性。4. 战略规划大多数的中小企业没有 IT 战略规划，在 IT 资源投入上分配不合理，该花钱的没花，不该花的浪费严重，技术团队无法支撑企业 IT 的实际需求。从 DevOps 入手解决人的问题我们上面罗列的 DevOps 实现的难点非常常见，而最近几年日渐流行的 DevOps 理念和方法论似乎就是用来解决这些问题的。不过，在真实的企业环境中，DevOps 的落地又总是面临着这样或那样的问题和阻碍。在梳理了随行付现有 IT 系统的运维工作后，我们首先想到要解决的就是人的问题，也就是运维自动化入手。在引入 DevOps 工具之前，系统运维占据了整个团队 70% 的工作量。我们的运维团队周一到周四每天都在投产，运维人员每天都忙于各种应用发布，半夜处理问题是常态，而其中很多都是重复性的工作。
为了消除这些枯燥的重复性工作，我们最初想利用开源 CMDB 工具，或者自研的方式实现 DevOps。但是很快就发现在现实企业环境存在很多问题，限于人力、资源分配等因素，这些工具的成熟度很难在短期内达到 DevOps 的需求。在评估了多款商业化的 DevOps 工具后，我们最终选择了 FIT2CLOUD 的 DevOps 解决方案，通过成熟工具的引入把运维团队从繁琐的日常工作中解放出来。借助云化开发运维一体化的体系，我们实现了运维团队一部分系统权限向开发团队的开放。这样做的结果就是，研发团队的项目经理可以自己实现应用的上线和投产，投产操作与运维分离。运维团队在应用投产上不用投入过多的精力。从每周 4 天 24 小时的投产操作，到只安排一人值班处理相关故障，运维团队可以将更多的精力放在系统监控、资产管理、性能优化、日志分析等方面。引入 DevOps 工具的一个重要成果是降低了运维团队人员的流失率。在部署 DevOps 工具之前，我们的运维团队一年平均有三个人离职。而在 2016 年上线 DevOps 之后，我们的团队还没有人员离开。把运维人员从繁杂而重复的运维工作中解放出来，让他们有更多的时间来维护自己的技术能力，对于提升整个团队的稳定性是非常重要的。另外，借助 DevOps 工具，开发环境的运维也变得更加简单。以前，开发环境由运维团队运维的成本非常高，而在 DevOps 工具的帮助下，我们实现了内部资源的自动回收。这样一来，研发人员按照需求申请不同配置和使用时长的资源，在项目完成后自动回收。运维人员的精力进一步集中到 IT 基础设施的优化与规划方面。DevOps 落地如何不空谈？很多互联网企业的运维团队都面临着这样的困惑：DevOps 的方法论很先进，但是真正在自己的企业落地还面临着太多的阻碍和不确定性。比如，变更结果的可靠性和可预见性如何保证？不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的影响怎样才能被充分地评估？对分布式系统各部分的变更如何做到合理、有效地协调？怎样明确地界定开发与运维的组织边界？我们经常在说，运维的发展趋势是运维服务化、资源代码化、流程平台化、开发自助化。这其中就涉及到开发与运维的职能划分。运维部门把 API 提供给开发部门，在安全管控的前提上，实现开发服务的自助化。之前无论是开发环境、测试环境，还是生产环境，资源的开通配置过程都非常复杂。借助 DevOps 工具，开发、测试和预生产环境的资源均可由开发部门自助进行开通和维护。这样一来，开发部门和运维部门之前的沟通成本大大降低。DevOps 的价值显而易见，越来越多的企业在展开 DevOps 的实践，也在尝试着各种各样的落地路径。很多企业的 DevOps 团队通过编写 Chef、Puppet 或者 Ansible 脚本来实现 DevOps，但结果似乎都不是很成功。DevOps 提倡的是效率，这些团队的行为并没有真正体现出 DevOps 的理念。DevOps 无法实现企业落地的一个重要原因是工具的缺失。作为时下最流行的互联网架构运维理念，DevOps 应该是一系列工具加上如何使用这些工具的知识。鉴于任何工具都需要相应的使用知识，所以简单来说，DevOps 就是一系列的工具。Docker、Kubernetes、Istio、Namerd、Linkerd 这些开源项目都是 DevOps 工具链和产品的必备环节和组件。但对于企业、尤其是快速成长的互联网企业来说，单纯地通过开源工具实现 DevOps 是非常困难的，脚本的维护、多种工具地组合、针对企业现有流程的调试，以及由此带来的人力、物力投入，都为 DevOps 的落地增加了种种的不确定性。因此，在 DevOps 落地过程中引入商业软件是有其必要性的。很多人说，DevOps 是一种文化。但在实际的工作层面，DevOps 更像是运维部门和开发部门沟通的桥梁。通过 DevOps，运维部门和开发部门对接的标准化程度将会大大提升。最后我想说的是，DevOps 对于企业 IT（不仅仅是互联网企业 IT）而言有着非常重大的意义。这是历史上第一次有望将所有开发语言纳入到同一个全流程的管理框架之中，这一目标一旦达成，将是软件工业的一次重大转变。原创：孙志坤
页:
[1]