作为互联网金融行业的新创企业，随行付支付有限公司（vbill.cn，以下简称为随行付）的IT系统建立在互联网业务架构之上，并且应用了大量的开源技术和工具。在公司成立后的六年时间里，随行付的IT系统规模持续扩张，同时也因技术和人员的快速迭代面临着IT运维的严峻挑战。

在8月9日举行的FIT2CLOUD东区（非金融）客户研讨会上，随行付运维总监孙志坤分享了随行付在DevOps领域遇到的现实挑战，以及通过工具实现DevOps企业落地的过程。

以下内容由孙志坤的演讲内容整理而成，经演讲者授权发布。

随行付是一家成立于2011年7月的第三方支付机构，目前拥有上千名员工，在全国设有28家分公司。秉承“普惠、科技、创新”的服务理念，随行付为商户提供个人支付、商户收单等小微企业移动金融服务，并且首创了行业支付模式，在银行卡收单服务的基础上推出移动支付、互联网支付、钱包支付、跨境支付、扫码支付等创新服务，针对快消连锁、餐饮连锁、超市连锁、电商物流等行业提供定制化的行业解决方案。目前随行付的收单业务已经覆盖了中国的200余个城市，日均覆盖2000多万持卡人。

在移动支付浪潮的带动下，随行付支撑海量、分布式金融业务的IT系统在初创时期全力向前奔跑，技术和人员的迭代都处在“小步快跑”的状态，同时业务的种类和规模也在飞速扩展。在“速度为先”的阶段，研发人员和运维人员之间的部门墙越来越厚，这种开发与运维之间的割裂为企业IT的运维带来一系列的挑战。

初创企业的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的落地又总是面临着这样或那样的问题和阻碍。

图1 随行付IT运维职能分布

在梳理了随行付现有IT系统的运维工作后，我们首先想到要解决的就是人的问题，也就是运维自动化入手。在引入DevOps工具之前，系统运维占据了整个团队70%的工作量。我们的运维团队周一到周四每天都在投产，运维人员每天都忙于各种应用发布，半夜处理问题是常态，而其中很多都是重复性的工作。

为了消除这些枯燥的重复性工作，我们最初想利用开源CMDB工具，或者自研的方式实现DevOps。但是很快就发现在现实企业环境存在很多问题，限于人力、资源分配等因素，这些工具的成熟度很难在短期内达到DevOps的需求。

在评估了多款商业化的DevOps工具后，我们最终选择了FIT2CLOUD的DevOps解决方案，通过成熟工具的引入把运维团队从繁琐的日常工作中解放出来。借助FIT2CLOUD云化开发运维一体化的体系，我们实现了运维团队一部分系统权限向开发团队的开放。这样做的结果就是，研发团队的项目经理可以自己实现应用的上线和投产，投产操作与运维分离。运维团队在应用投产上不用投入过多的精力。

从每周4天24小时的投产操作，到只安排一人值班处理相关故障，运维团队可以将更多的精力放在系统监控、资产管理、性能优化、日志分析等方面。

图2 FIT2CLOUD DevOps工具可将服务部署时间从小时级降至分钟级

引入DevOps工具的一个重要成果是降低了运维团队人员的流失率。在部署DevOps工具之前，我们的运维团队一年平均有三个人离职。而在2016年上线DevOps之后，我们的团队还没有人员离开。把运维人员从繁杂而重复的运维工作中解放出来，让他们有更多的时间来维护自己的技术能力，对于提升整个团队的稳定性是非常重要的。

图3 FIT2CLOUD DevOps工具统一管理开发、测试、准生产环境及生产环境

另外，借助DevOps工具，开发环境的运维也变得更加简单。以前，开发环境由运维团队运维的成本非常高，而在FIT2CLOUD的DevOps工具的帮助下，我们实现了内部资源的自动回收。这样一来，研发人员按照需求申请不同配置和使用时长的资源，在项目完成后自动回收。运维人员的精力进一步集中到IT基础设施的优化与规划方面。

DevOps落地如何不空谈？

很多互联网企业的运维团队都面临着这样的困惑：DevOps的方法论很先进，但是真正在自己的企业落地还面临着太多的阻碍和不确定性。

比如，变更结果的可靠性和可预见性如何保证？

不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的影响怎样才能被充分地评估？

对分布式系统各部分的变更如何做到合理、有效地协调？

怎样明确地界定开发与运维的组织边界？

我们经常在说，运维的发展趋势是运维服务化、资源代码化、流程平台化、开发自助化。这其中就涉及到开发与运维的职能划分。运维部门把API提供给开发部门，在安全管控的前提上，实现开发服务的自助化。之前无论是开发环境、测试环境，还是生产环境，资源的开通配置过程都非常复杂。借助DevOps工具，开发、测试和预生产环境的资源均可由开发部门自助进行开通和维护。这样一来，开发部门和运维部门之前的沟通成本大大降低。

DevOps的价值显而易见，越来越多的企业在展开DevOps的实践，也在尝试着各种各样的落地路径。很多企业的DevOps团队通过编写Chef、Puppet或者Ansible脚本来实现DevOps，但结果似乎都不是很成功。DevOps提倡的是效率，这些团队的行为并没有真正体现出DevOps的理念。

DevOps无法实现企业落地的一个重要原因是工具的缺失。作为时下最流行的互联网架构运维理念，DevOps应该是一系列工具加上如何使用这些工具的知识。鉴于任何工具都需要相应的使用知识，所以简单来说，DevOps就是一系列的工具。

图4 随行付运维自动化实践架构

Docker、Kubernetes、Istio、Namerd、Linkerd这些开源项目都是DevOps工具链和产品的必备环节和组件。但对于企业、尤其是快速成长的互联网企业来说，单纯地通过开源工具实现DevOps是非常困难的，脚本的维护、多种工具地组合、针对企业现有流程的调试，以及由此带来的人力、物力投入，都为DevOps的落地增加了种种的不确定性。因此，在DevOps落地过程中引入商业软件是有其必要性的。

很多人说，DevOps是一种文化。但在实际的工作层面，DevOps更像是运维部门和开发部门沟通的桥梁。通过DevOps，运维部门和开发部门对接的标准化程度将会大大提升。

最后我想说的是，DevOps对于企业IT（不仅仅是互联网企业IT）而言有着非常重大的意义。这是历史上第一次有望将所有开发语言纳入到同一个全流程的管理框架之中，这一目标一旦达成，将是软件工业的一次重大转变。

原创：孙志坤

作为互联网金融行业的新创企业，随行付支付有限公司（vbill.cn，以下简称为随行付）的IT系统建立在互联网业务架构之上，并且应用了大量的开源技术和工具。在公司成立后的六年时间里，随行付的IT系统规模持续扩张，同时也因技术和人员的快速迭代面临着IT运维的严峻挑战。

在8月9日举行的FIT2CLOUD东区（非金融）客户研讨会上，随行付运维总监孙志坤分享了随行付在DevOps领域遇到的现实挑战，以及通过工具实现DevOps企业落地的过程。

以下内容由孙志坤的演讲内容整理而成，经演讲者授权发布。

随行付是一家成立于2011年7月的第三方支付机构，目前拥有上千名员工，在全国设有28家分公司。秉承“普惠、科技、创新”的服务理念，随行付为商户提供个人支付、商户收单等小微企业移动金融服务，并且首创了行业支付模式，在银行卡收单服务的基础上推出移动支付、互联网支付、钱包支付、跨境支付、扫码支付等创新服务，针对快消连锁、餐饮连锁、超市连锁、电商物流等行业提供定制化的行业解决方案。目前随行付的收单业务已经覆盖了中国的200余个城市，日均覆盖2000多万持卡人。

在移动支付浪潮的带动下，随行付支撑海量、分布式金融业务的IT系统在初创时期全力向前奔跑，技术和人员的迭代都处在“小步快跑”的状态，同时业务的种类和规模也在飞速扩展。在“速度为先”的阶段，研发人员和运维人员之间的部门墙越来越厚，这种开发与运维之间的割裂为企业IT的运维带来一系列的挑战。

初创企业的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的落地又总是面临着这样或那样的问题和阻碍。

图1 随行付IT运维职能分布

在梳理了随行付现有IT系统的运维工作后，我们首先想到要解决的就是人的问题，也就是运维自动化入手。在引入DevOps工具之前，系统运维占据了整个团队70%的工作量。我们的运维团队周一到周四每天都在投产，运维人员每天都忙于各种应用发布，半夜处理问题是常态，而其中很多都是重复性的工作。

为了消除这些枯燥的重复性工作，我们最初想利用开源CMDB工具，或者自研的方式实现DevOps。但是很快就发现在现实企业环境存在很多问题，限于人力、资源分配等因素，这些工具的成熟度很难在短期内达到DevOps的需求。

在评估了多款商业化的DevOps工具后，我们最终选择了FIT2CLOUD的DevOps解决方案，通过成熟工具的引入把运维团队从繁琐的日常工作中解放出来。借助FIT2CLOUD云化开发运维一体化的体系，我们实现了运维团队一部分系统权限向开发团队的开放。这样做的结果就是，研发团队的项目经理可以自己实现应用的上线和投产，投产操作与运维分离。运维团队在应用投产上不用投入过多的精力。

从每周4天24小时的投产操作，到只安排一人值班处理相关故障，运维团队可以将更多的精力放在系统监控、资产管理、性能优化、日志分析等方面。

图2 FIT2CLOUD DevOps工具可将服务部署时间从小时级降至分钟级

引入DevOps工具的一个重要成果是降低了运维团队人员的流失率。在部署DevOps工具之前，我们的运维团队一年平均有三个人离职。而在2016年上线DevOps之后，我们的团队还没有人员离开。把运维人员从繁杂而重复的运维工作中解放出来，让他们有更多的时间来维护自己的技术能力，对于提升整个团队的稳定性是非常重要的。

图3 FIT2CLOUD DevOps工具统一管理开发、测试、准生产环境及生产环境

另外，借助DevOps工具，开发环境的运维也变得更加简单。以前，开发环境由运维团队运维的成本非常高，而在FIT2CLOUD的DevOps工具的帮助下，我们实现了内部资源的自动回收。这样一来，研发人员按照需求申请不同配置和使用时长的资源，在项目完成后自动回收。运维人员的精力进一步集中到IT基础设施的优化与规划方面。

DevOps落地如何不空谈？

很多互联网企业的运维团队都面临着这样的困惑：DevOps的方法论很先进，但是真正在自己的企业落地还面临着太多的阻碍和不确定性。

比如，变更结果的可靠性和可预见性如何保证？

不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的影响怎样才能被充分地评估？

对分布式系统各部分的变更如何做到合理、有效地协调？

怎样明确地界定开发与运维的组织边界？

我们经常在说，运维的发展趋势是运维服务化、资源代码化、流程平台化、开发自助化。这其中就涉及到开发与运维的职能划分。运维部门把API提供给开发部门，在安全管控的前提上，实现开发服务的自助化。之前无论是开发环境、测试环境，还是生产环境，资源的开通配置过程都非常复杂。借助DevOps工具，开发、测试和预生产环境的资源均可由开发部门自助进行开通和维护。这样一来，开发部门和运维部门之前的沟通成本大大降低。

DevOps的价值显而易见，越来越多的企业在展开DevOps的实践，也在尝试着各种各样的落地路径。很多企业的DevOps团队通过编写Chef、Puppet或者Ansible脚本来实现DevOps，但结果似乎都不是很成功。DevOps提倡的是效率，这些团队的行为并没有真正体现出DevOps的理念。

DevOps无法实现企业落地的一个重要原因是工具的缺失。作为时下最流行的互联网架构运维理念，DevOps应该是一系列工具加上如何使用这些工具的知识。鉴于任何工具都需要相应的使用知识，所以简单来说，DevOps就是一系列的工具。

图4 随行付运维自动化实践架构

Docker、Kubernetes、Istio、Namerd、Linkerd这些开源项目都是DevOps工具链和产品的必备环节和组件。但对于企业、尤其是快速成长的互联网企业来说，单纯地通过开源工具实现DevOps是非常困难的，脚本的维护、多种工具地组合、针对企业现有流程的调试，以及由此带来的人力、物力投入，都为DevOps的落地增加了种种的不确定性。因此，在DevOps落地过程中引入商业软件是有其必要性的。

很多人说，DevOps是一种文化。但在实际的工作层面，DevOps更像是运维部门和开发部门沟通的桥梁。通过DevOps，运维部门和开发部门对接的标准化程度将会大大提升。

最后我想说的是，DevOps对于企业IT（不仅仅是互联网企业IT）而言有着非常重大的意义。这是历史上第一次有望将所有开发语言纳入到同一个全流程的管理框架之中，这一目标一旦达成，将是软件工业的一次重大转变。

原创：孙志坤