数字时代Devops新运维研究

蔡建宇

（国防科技大学信息通信学院 湖北·武汉 430010）

1 Devops出现的背景

随着数字技术的不断成熟，它被广泛应用于各个领域，同样，这也为运维行业带来了巨大的发展机遇。如今，我们处于一个数字化的世界，每日所进行的数字信息交流难以计数。因此，据预测，到二零三零年时人们用来进行数字信息交流的全球联网设备可能会从八十亿增加到二千亿及以上。按照这种模式发展，全球范围内，人们的数字信息交流会更加密切，甚至将现实世界的“事实”以数字化的形态构建在互联网世界中。但构筑互联网世界的数字设备并不是完全没有漏洞，而一个小小的漏洞则可能引起巨大的蝴蝶效应。例如曾经出现的2000年问题：由于计算机系统的时钟设计出现 bug而导致各种各样的系统功能紊乱甚至崩溃。所以，在数字化时代中，能及时、精确地对数字设备进行运维就显得尤为重要。这不仅是为了维护计算机系统平稳高速地运转，更是在保障互联网世界中各企业的利益。

在当今的数字化时代中，运维对于计算机良好运行的重要性不可同日而语，整个运维行业登上了一个新的高峰。但同时，运维也面临着巨大的挑战：新时代的发展必然要求新技术的改进，而传统的运维技术则不能适应数字化时代的发展。

随着数字信息交流的日益密切和数字技术的成熟，全球数字化设备的数量更加庞大、类型更加多样。因此，运维所面对的问题也更加复杂多样。若不适时更新发展，仅凭传统运维就不能解决这些新时代中的新问题。

当今时代是一个快节奏的时代，企业的转型和发展速度不断加快。相应地，数字化设备更新换代的时间更短、速度更快。而传统运维往往是以数字化设备为导向的，这就使得运维与企业的数据信息脱节。所以在当今时代如果仍使用传统的运维技术，那么运维团队很容易会忽略数据信息本身的价值，并且其工作压力会更加沉重。

如何解决这类问题？相关技术人员理出了一条思路：开发出一套完全自动化运维体系，使得开发和运维能够紧密结合，实现“软件交付”“架构变更”等流程的自动化，甚至在某种条件下，能够达到无人干预的效果。而当前能够实现这一切的运维系统就是Devops。然而，Devops并不能帮所有的传统企业完成这类转型，它还需要向纵深发展。

2 Devops发展的必要性

在探究Devops是否是最好的模式时，我们需要明白一个道理：人是复杂的。所以我们不能单一片面地看待这个问题。一种模式的生成是应对人的需求后所形成的结果，例如，对于悲观者，我们可以通过程序手段约束人的主观意志，使他们能够客观地完成任务；对于乐观者，我们要充分发挥他们的主观能动性，使系统更好地为团体服务。因此并无最好的模式，只有合适自己的才是最好的。

就目前来看，能在流程约束这一方面做到最好的是ITIL，可以快速落地且清晰明确。因此，笔者推荐许多新成立的团队可以将ITIL作为开始。除此之外，ITIL还有其他几项优点：（1）成效快，通过建立一个变更流程，就可以快速且大幅度地提高生产质量，效果可谓是立竿见影。（2）程序少，在ITIL模式下，大部分的系统和流程都直接由运维部门主导实施就行。而其中最重要的CICD，ITIL体系只需要着重地关注最后一步。（3）管理落地，在整个流程落地的过程中，管理者能够完整保留自己的管理经验和工作方法，这样可以在最大程度上避免因执行者的不同而导致的差异与问题。

关于ITIL模式的说明中，它既强调要保证质量，又要求提高效率。就此，我们可以解读为，当发生质量与效率起冲突的情况时，ITIL会先选择质量。但当出现效率优先这种情况时，ITIL就无法先保障效率了。而Devops的出现就很好的解决了这种问题。当然，与ITIL相比，Devops还具有其他优势，例如不会出现流程反弹、边际效益等问题。不过这不是本文的重点，所以只略提一二。

从Devops的本质出发，我们可以看出该模式对开发、测试及运维这三类角色的合理分工提出了挑战。当我们侧重于快速为用户提供新服务时，就需要我们将上诉三类角色合为一体，而这一点恰恰是非常困难的。因为开发、测试和运维这三方的关键绩效指标、行事风格及语言体系各不一致。通俗来说，就是部门不同，各部门之间有门墙相阻隔。

3 传统Devops与互联网Devops的区别

在某种层面上而言，Devops的定义来源于IT行业，在IT行业里，研发工作和运行维护工作相融合的优势就在于能够把两个独立的部门整合，完成产品研发、内测、上线的迅速更新换代，从而从容面对瞬息万变的业界局势，持续及时地应对客户的需求变化。

尤其在产品给到运维部门的时候，因为在Devops期间该工作团队有切身工作体验，在对产品进行运营和维护时将有更大信心，能够在短时间内接管该产品的工作任务。

现行的IT单位与以往的单位在某些方面存在蛮大差异，例如APP的发布模式与单位的结构，即便现如今越来越多的互联网思维应用到了传统IT单位中，但这样的拿来主义并不是良好的可取行径。

诚然，以往各单位对于APP的发行方式将迎来的问题也与现有IT单位不尽相同，例如，传统单位为确保质量会进行烦琐的测试环节，这样的工作周期会与当下网络迅速更新换代的需求形成时间差，并且，传统单位对于Devops的最重要的需求也并不是研发和运行维护相结合：因其单位在各项工作职责上有明确的划分，区别于整合后的多职能团队，所以Devops能做到的整合并不是首要任务，他的重要关心问题是Devops能否推进已有流水线上的工作并呈现出全新的局面。

故此，在专业技能层面，传统单位只是想通过Devops达到结合已有工具的目的，打通业务交付的端到端流水线；在基础结构层面，利用Devops构建整合后效率提升和客户需求稳定的优良途径；在整个流水过程中，达到工作安排和事务分配常规环节能不断优化的目的。

4 Devops对运维人员的影响

大多企业会把研发和管理视作两个相对独立的部门。研发的主要动力大多是经常交付新特性，运行更偏重互联网服务的稳定性和互联网成本投放的效果。两个部门要达到的目的不甚相同，因此二者形成了明确边界，这样就使得互联网交付工作无法快速完成。

研发者并不在乎所打的代码对运行产生的效果。在提交代码以前也不会让运行者干扰他们的决定和审核。研发者在对其进行改动后，由于不尽快与运营者进行交流，从而使新代码无法迅速工作。研发者在自己的设备上修改配置，不会记下细微调整的环节。要寻找合适的配置参数，一般都要试验许多参数，在达到了一个能运行的情况时，通常无法确切知道究竟是哪个小的环节达到了这个情况。研发者更愿意借助能够迅速研发的工具，便于获取关于修改代码的反馈信息以及减少对于存储空间的占用等。

因为研发者大多用台式电脑工作，所以导致他们更愿意应用为PC端用户优化的操作系统。在研发期间，系统只在研发人员自己的一个服务器上运行，而在运维环节，系统大多分散在多个服务器上，比如网页、APP等。研发是通过功能需要推动的，而运维是通过非功能需要推动的，工作者想减少修改次数甚至不修改，以此来达到减小风险的目的。一旦放弃进行微修改，在固定期间要完成的修改任务不变，则每次需要修改的范围就会扩大。范围扩大了，所带来的风险也会变大。因为负责运行工作的人不想要进行修改，开发出来的新功能投放生产的速度也因此变慢，导致产品端把功能推给受众体验的速度减慢。运营人员如果不够掌握APP本身，那么也就无法准确调整运行环境和发布过程。开发人员如果不清楚运行环境，也就不能够对代码进行有利调整。

现在，企业在招聘的时候，会更加看重有过运营维护和编程工作经验的人才。简而言之，即Devops的好坏，会对程序的运营和维护工作有着非常重要的影响，这些人才更多是来做APP系统的运营工作，这样一来，就给程序研发者对工作按照需求进行安排提供了足够便捷的方式。

Devops逐渐发展成为可以把一切晦涩的运行和维护理论存储在开放标准里的一种办法，此标准允许及时进行记录和追踪。在掌握良多的运行和维护的理论内容和编程技能后，Developer和Administrator的工作职责也会随之融合。Devops能够不断进步，而且一定有一个新工具，一个崭新的结构和一个潮流的发展态势为其赋予全新且有力的能量。就像它给APP研发不断加之集成和交付那样，它同时也能给运维人才带来可编程的基础架构。