美文网首页
DevOps,数字化企业必须接受的工作方式和企业文化的革命!附干

DevOps,数字化企业必须接受的工作方式和企业文化的革命!附干

作者: 科技无忧 | 来源:发表于2020-03-27 21:03 被阅读0次

互联网科技已成为一种全行业通用的核心生产力,可以说,每个有竞争力的公司,无论它们处在哪个行业,都应该是一家优秀的科技公司。银行是拥有金融执照的IT 公司;运营商是拥有网络牌照的IT公司;各类商品生产或销售企业的核心竞争力也将越来越依赖于它们的生产、物流、供应链、营销与客户服务等方面的IT系统的能力与效率;包括各地政府所倡导的智慧城市,也必须构建在包含各类互联网科技的IT系统所组成的“新基建”之上。

IT系统在各行业大中型企业中的重要性越来越高的同时,伴随而来的是针对IT系统的新需求越来越多,且越来越需要更加及时的响应。能够快速和持续地创新、快速实现并切入市场、提供优质可靠的服务,已成为未来企业获得成功的关键所在。功能迭代、局部升级、A/B Test甚至版本回滚成为常态,这都对传统的开发、运维模式提出了新挑战。

但大多数传统企业都不能在几分钟或几小时内针对IT系统完成变更所需要的所有部署,往往需要几周甚至几个月的准备时间。他们更不可能每天在生产环境中进行成百上千次的部署,而是在以月甚至季度为单位,来计划IT系统的整体升级和部署。对他们而言,生产环境的升级和部署并不是日常工作,而每次进行生产环境的升级和部署时,常常都需要运维人员通宵达旦,如临大敌,因为会造成服务中断,同时很可能会有各种意想不到的事故如影随形。

长久以来,对于非互联网公司,开发部门和运维部门之间都存在着一堵高墙,本来关系密切的工作被两个部门踢来踢去。在这种以职能为导向的集中式开发与集中式运维相互独立的组织架构中,实现“以市场为导向,让小团队快速、独立地创造价值”这一目标,几乎是不可能的。因为运维团队不得不满足许多开发团队的各种迥然不同的需求,结果导致运维工作需要较长的交付周期,并且需要反复地调整任务的优先级,而且部署结果还常常不尽如人意。

在这方面,我们很有必要了解一下互联网公司是如何做的。对于互联网公司来说,他们的IT系统几乎都必须提供24小时不间断的服务,却能够始终保持着高频率的创新与升级。以Facebook为例,其采取的最有效的一个措施就是让所有工程师、工程经理和架构师轮流值班,负责他们自己构建的服务的运维工作。通过这样做,所有构建服务的人都对自己在上游所负责设计的架构和代码有了亲身的感受,这对下游的运维部署工作产生了巨大的积极影响。显然,通过使开发团队拥有更强的运维能力,或者让运维工程师融入开发团队,可以以市场为导向创造出更多的业务成果,并能最终提高效率和生产力。

为了解决上面内容所提及的各种问题,DevOps(开发运维)应运而生,其提出将开发和运维团队的工作紧密结合起来,建立持续交付和持续反馈的工作闭环。但需要强调的是,DevOps并不是一种技术,而是为了促进开发运维一体化而施行的一系列技术工具、组织架构及企业文化层面的思想与实践。不同的企业对DevOps的具体实现方式并不完全相同,但总的来说,应该包括如下一些方面的内容:

第一:将运维融入日常的开发工作:

包括创建一套集中式的类生产环境平台和工具集服务,让开发团队都能够通过使用这套平台和服务来提高生产力,例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台等。这样,开发团队就能够把更多的精力和时间用在功能构建上,而不是消耗在获取交付和支持生产环境特性所必需的基础设施上。此外,还要使运维工程师融入开发团队或为每个开发团队分配能够切实承担职责的运维联络人,邀请他们参加开发团队的会议。这样,他们的工作优先级几乎完全受所在产品团队的目标驱动,而不再专注于解决自己的问题,运维工程师与其内部和外部客户的联系也就更加紧密了。

第二:建立出从产品计划直至功能上线的端到端的快速交付流水线

很多时候,只有在将应用部署到生产环境时,才能看到应用的实际表现。如果发现问题,通常为时已晚。所以,为了使工作快速可靠地从开发流向运维,应当保证价值流的每个阶段都使用类生产环境。此外,这些环境必须能用自动化的方式进行搭建,在理想情况下,应该使用脚本和存储在版本控制系统中的配置信息按需搭建,而不需要依赖运维团队进行手动操作。部署流水线的目标就是能够基于版本控制系统中的信息重复搭建整套生产环境。

第三:实现快速可靠的自动化测试

其目标是让开发人员在日常工作中创建自动化测试套件,并在开发早期就保证产品质量。这样做有利于建立快速的反馈回路,帮助开发人员尽早发现和解决问题,从而提高集成频率,使测试从阶段性活动演变成持续性活动,并支持企业的持续创新。通过执行自动化测试,所有测试人员(当然包括开发人员)得以去做那些不能被自动化的高价值活动,如探索性测试或设计和优化测试流程本身。

第四:采用松耦合架构降低发布风险

紧耦合的架构可能带来这样的后果:每当试图提交代码到主干,或将代码发布到生产环境中时,都有可能因为错误而导致整个系统出现故障。接口定义清晰的松耦合架构则与之相反,它优化了模块间的依赖关系,提高了生产力和安全性,让小型且高产的开发团队可以灵活地执行小的变更,并能够安全和独立地进行部署。这里有必要提一下微服务,微服务就是一种松耦合的架构,而DevOps和微服务的很多技术理念都是重合的,但两者的关注点并不同,微服务帮助我们以一种松耦合和细颗粒度的方式开发、测试和发布服务,而DevOps提倡小规模和小批量的持续集成和持续部署,两者相辅相成的,共同解决问题。

关于DevOps的更多干货,这里还有本[DevOps实践指南]电子书,系统地介绍了DevOps的相关知识,有兴趣的朋友可以获取。

总之,以平台化、生态化、智能化和敏捷化为主要特征的全行业的数字化企业时代已经到来,传统企业在建设和重构自己的IT系统时,除了引入先进的设计思想和技术元素外,更要采用与之匹配的工作理念与实施方法,否则将无法发挥其价值,从这个角度来说,DevOps的作用是不可或缺的,也是所有开发和运维人员以及企业技术管理人员都需要意识到的。

创作不易,欢迎朋友们关注、评论、转发。

相关文章

网友评论

      本文标题:DevOps,数字化企业必须接受的工作方式和企业文化的革命!附干

      本文链接:https://www.haomeiwen.com/subject/tlgruhtx.html