DevOps—-2014年度最火热的IT术语,人们谈论它远比实际用到它还要多,也许有时候我们可以怀疑一下他们是否真的知道那是什么。

DevOps究竟是什么?它几乎是任何你想要的,供应商们要确保它包含他们所卖的任何东西。下面我就来谈谈我所理解的DevOps是什么,又或者不是什么。

简单地说,DevOps就是两个半互相联系的东西。首先,DevOps在开发过程中就深入考虑了运维方面的问题。第二,它确保开发团队和运维团队之间能至始至终通力合作;最后那个半部分就是DevOps中包含有Clouds, Docker 和APIs这样的新技术使开发人员能通过使用应用过程界面、云服务和其他新架构来控制更多软件部署和运维过程。

第一方面—-深度运维的考虑能促使开发团队适度区别他们的代码和凭证,能让测试变得简单,同时还可以登记OS-side配置,提供运行时日志、仪器仪表数据、遥测技术等等。尤其是当系统在实际使用过程中变得混乱的时候,运用DevOps能使一切变得简单。运用DevOps在眼下看来很有必要,但这样做起来并不容易,尤其是对现有的这样一个代码库,因为可能会阻止新功能的开发。

关于团队间紧密合作这一点,DevOps在这方面才刚起步,尤其是当你既要鼓励合作以达到持续进步,同时也要避免相互间的指责时,就常常面临挑战。正确地优先考虑non-feature问题,这是相当重要的,因为这些问题对运维团队至关重要。从中可以看出,这样的合作关系在起着作用。

将运维团队尽早地加入到设计过程中来也是重要的,要让运维团队的特征尽早并且时常显现出来,而不只是让他们充当临时的角色。运维团队还需要推进和维护well-sync dev /测试环境和跟进反馈情况,同时还要对核心业务以及他们的截止日期有所掌握。这些看起来都不简单,但对于DevOps的长期成功却是十分有必要的。

说到最后那一半,那是十分有趣的,因为开发团队想要更多的部署权、管理器使用权、运行时微功能、云服务,甚至像数据库一样的东西。眼前的挑战是,其中许多事出现了运维上的问题,这些问题是意料之外的,或者说对于一个新开发团队,这样的问题是无趣的,因为这个时候,他们往往觉得他们的供应商大肆宣传云服务。有时候这就像一把双刃剑,帮助解决问题的同时也会制造问题。因此,我们在找一个平衡点,就是通过上述提到的深入的运维思考与合作。

什么不是DevOps?有些人认为开发运维一出,单纯的运维可能就要销声匿迹了,而开发者就被不断地通过全自动化条件或让超级开发人员来完成全部的运维工作来提高技能。这种说法是很荒谬的,至少对于那些真实的大型系统,因为它们不仅仅是中规模集成度。

首先,我们都对全自动化表示看好,但这并不意味着运维就要被取代,因为如果我们没有运维团队,没有这样一群有经验的人员,我们就无法知道什么是自动化,也不知道如何实现自动化。确实,云服务让自动化变得简单,像亚马逊服务平台和阿里云的关系型数据库服务能减少一些服务任务。当系统变得复杂,问题出现得更多,变化更频繁的时候,自动化更是能发挥它的作用。自动化在一点点变好,它帮助解决一些低级任务,但它绝对不会取代经验丰富的运维团队的。

其次,我们可能常听到说,开发者往往通过代码和自动化来提高他们处理运维问题的技能和知识,并“完成”运维方面的工作。其中,DevOps使得开发和运维合二为一,也出现了UberDev工程师。当然,让运维工程师来做他们自己的工作有时候都显得困难,更不用说训练开发工程师来做运维方面的工作,尤其是在考虑到安全、性能、协调和可靠性、备份以及其他一些问题的时候。至少在我看来这样是不切实际的。

同时,还有人认为DevOps是一场革命性的创新,有了它,人们可以继续将相关技术进行融合,加快日常代码编制等。虽然这些常常包含在新的DevOps过程中,但其实它早就已经不是什么新鲜的词了。所以,这个过程背后的思考远比这个过程本身来得重要。

Docker和VMs 这些新工具让事情变得更为有趣,也让开发团队和运维团队的合作在某种程度上变得更紧密。但换个角度看,这些新工具的发现和使用也促使你拥有良好的实践能力,尤其是在保持一致性的开发测试、生产环境以及配置分离、凭证和其他一切关键要素的时候。这些技术都很棒,但这些不能算是DevOps。

最后,DevOps是一个新的焦点,开发团队和运维团队需要通过紧密合作和融合,但在运作管理水平上,DevOps更多的是用在开发团队中。不过现在知道什么是DevOps了吧,那赶快加入到这样的团队中去吧。