程序员和运维哪个转架构容易（如何解决开发和运维之间的固有隔阂）

程序员和运维哪个转架构容易（如何解决开发和运维之间的固有隔阂）1994年，我开始从事专业的编程工作，当时的技术领域与今时今日有着天壤之别。大多数公司的处境都很尴尬，他们看到了科技的价值，但往往在投资或采用科技的时候犹豫不决。那时的CPU、内存和存储都非常昂贵。带宽非常稀少，很有限，而且也非常珍贵。大多数软件开发和运维（SRE或系统管理）团队都需要手动开发、测试和发布应用程序以及托管的基础架构，更重要的是，这些工作都是单独完成的。数据中心必须设计、构建和配备适当的电源、气候控制以及布线，然后由有能力的技术人员控制和管理昂贵的基础设施硬件。从斗志昂扬的创业公司到大型企业，他们都有某种形式的“数据中心”。90年代中期，互联网尚处于起步阶段，不像现在这样普及。人们带着黑色的通讯录小本本，里面记载了所有联系人的信息。当时我们还在使用寻呼机，呼叫后等待对方回电话。信息的传播仅限于纸质媒介，比如期刊和书籍等。人们会去图书馆看书，通过纸质的索引卡查找资料，并通过杂志

“我刚开始做开发的时候还没有开发运维，这一原则改变了我的职业生涯！”

作者 | Angel Rivera

译者 | 弯月，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下为译文：

有人让我写一篇“什么是开发运维”的文章，我决定采用一种与众不同的方式来写这个主题。在本文中，我将根据我在科技行业几十年的工作经验来定义开发运维。我将带你横穿我的专业时间线，并讨论开发运维走进我的生活的整个过程，以及对我的职业生涯带来的影响。

90年代

90年代中期，互联网尚处于起步阶段，不像现在这样普及。人们带着黑色的通讯录小本本，里面记载了所有联系人的信息。当时我们还在使用寻呼机，呼叫后等待对方回电话。信息的传播仅限于纸质媒介，比如期刊和书籍等。人们会去图书馆看书，通过纸质的索引卡查找资料，并通过杂志、报纸或书籍获取所需的信息。这是一个手动获取信息的时代。

1994年，我开始从事专业的编程工作，当时的技术领域与今时今日有着天壤之别。大多数公司的处境都很尴尬，他们看到了科技的价值，但往往在投资或采用科技的时候犹豫不决。那时的CPU、内存和存储都非常昂贵。带宽非常稀少，很有限，而且也非常珍贵。大多数软件开发和运维（SRE或系统管理）团队都需要手动开发、测试和发布应用程序以及托管的基础架构，更重要的是，这些工作都是单独完成的。数据中心必须设计、构建和配备适当的电源、气候控制以及布线，然后由有能力的技术人员控制和管理昂贵的基础设施硬件。从斗志昂扬的创业公司到大型企业，他们都有某种形式的“数据中心”。

当时我的软件开发工作主要包括：

• 单独编写代码

• 通过“另存为……”的方法建立新版本的代码

• 手动编译

• 手动测试应用程序（通常需要点击、提交以及验证结果是否正确）

• 几乎没有代码审核

• 手动创建部署的发行包

• 编写包的发布/安装说明

• 通过软盘、CD或网络文件共享上的共享目录将发布包发给运维团队

• 等待…

每次等待新版本都需要4小时-10天的时间，这个时间的长短取决于运维团队的忙碌程度以及运维人员部署新版本的水平，开发人员和运维团队之间几乎没有沟通。事实上，大多数开发团队和运维团队之间都存在意见上的分歧。两个团队之间常常会彼此产生敌意，运维团队认为开发团队的软件质量不过关（未经测试或测试覆盖太低），而开发团队则抱怨运维团队未能尽快将软件部署到生产环境。

随着我的职业生涯发展，我花了很多时间思考引发开发和运维团队之间不必要的敌意的因素。我无法理解为什么这群技术娴熟的高素质团队不能凝聚在一起，高效地实现我们的共同目标和使命。很显然，开发和运维团队根本不在同一个世界里。二者只有一个共同的目标，那就是将软件发布到生产中。除了这个目标之外，他们之间没有兴趣共同努力解决问题。在科技发展的这个时期内，开发和运维团队由于彼此脱节而产生了负面影响，甚至危害到了公司的文化。当然，也并非每个团队和组织皆是如此，但我敢说，大多数团队/组织中都或多或少地存在这种现象。

敏捷开发

以上我简单地描述了我作为软件开发人员早期的一些职业发展经历，让你对我的工作态度、心态和文化有一个大致的了解。我发现我描绘出的情况似乎不是特别美好。其他人可能有完全不同的经历，但我相信大多数团队都经历过类似的职能不健全。

随着时间的推移和技术的发展，硬件和宽带越来越便宜，越来越快，而且还提供了更强大的动力。在这个时期，开发团队对软件的开发方式有了更进一步的了解。各个团队开始从上到下分析他们的流程，并了解到软件开发生命周期中已知的瓶颈。许多团队意识到，如果改变软件开发流程并改善沟通，则可以更快地交付高质量的软件。于是，许多团队和组织开始采用和实施敏捷软件开发概念，这些概念帮助各个团队了解自己开发团队中的不足，他们开始尝试融合新的概念和想法，并总结出新的方法论和策略。这些敏捷方法论包含了一种侧重于协作、客户反馈和小型快速发布的迭代方法。

各个开发团队和组织在敏捷原则的帮助下，成功地改善了组织运营，多年后，我注意到团队生产代码的速度得到了大幅提高。开发人员在开放式代码中进行协作，而对于团队来说，版本控制系统是创建、修改和共享代码的关键因素。随着时间的推移，开发团队能够以更聪明的方式开展工作，而且制作高质量代码的时间也大大缩短了。编写、测试和打包代码的速度也更快了。尽管开发团队火力全开急速地编写代码，但我们遇到了一个意想不到的问题：代码的发布速度赶不上开发的速度。我们很快意识到，我们专注于改进我们的软件开发流程，却忽略了发布或部署的流程。因此，我们有很多积压的新代码，这些代码没有发布给我们的客户，对开发人员来说，这是一个巨大的问题。

我接触开发运维的过程

一直以来，我都在从事编写代码的工作，而且我对代码的各个方面都非常感兴趣。为了满足我的好奇心，我知道我必须与运维团队建立真诚健康的关系。在职业发展生涯的早期，我意识到开发人员和运维团队之间存在共生的关系，而且我天真地以为其他开发人员和运维人员也这么想。

不可否认，当现实赤裸裸地摆在眼前时，我感到非常沮丧。我无法理解为什么这些团队之间会存在“隔阂”。我觉得这些“隔阂”是开发和运维团队为了维护自己的“地盘”而制造的借口。我认为两个阵营之间的“隔阂”是巨大的创新阻力。自从意识到这一点后，我开始称自己为“站在运维一方的开发人员”，而且我认为自己实至名归。

后来，我们意识到，虽然我们在敏捷方面做出了很多努力，但由于缺乏与运维的互动而完全发挥最大优势，于是我们联合起来制定了新战略，将软件开发生命周期中的运维也考虑在内。当时，还没有开发运维这个词，但这个词的精神已经开始活跃，而且在许多采用和实施敏捷的开发团队都采纳了这个思想。许多“敏捷”团队都面临相同的困境——开发团队非常关注快速开发软件，而且在实际将代码发布到生产环境时遇到了巨大阻碍。

开发团队的同事意识到我与运维团队的关系良好，所以他们建议我利用这种关系在两个团队之间架起一座桥梁。我有点担心搞不好有可能会破坏与运维团队的良好关系。我不想让别人误以为开发团队想侵犯别人的领地。我思虑良久，究竟该如何让运维团队接纳这个激进的想法。我在脑海中一遍又一遍地练习我与他们之间的谈话，等到有十足的把握后，我安排了与运维团队的会面。但随着会议的临近，我的担心也日益加剧。

这一天终于来了，我把脑海中排练了无数遍的台词说了出来。令我惊讶的是，运维团队的经理打断了我的话，然后突然问道他的团队如何才能像开发团队一样快速运作。他解释说，他们一直在偷偷观察我们在协调、质量、速度和成功等方面的改善。他坦诚地说，运维团队意识到他们当前的流程是阻碍软件快速发布的最大阻力。听完运维的立场，我心里非常高兴，他们愿意与我们一起改进开发和操作流程。

于是，我们开启了“打破障碍”之旅，虽然整个过程一点都不简单，也不容易。在我的记忆中，设计一个方便两个团队理解和接受的精益敏捷战略是我们必须克服的最大障碍。由于开发团队已经实施了敏捷，而且经历了敏捷文化的转变，所以在向运维团队提出建议时，他们觉得我们有点居高临下的态度，而且我们有点过于自负。考虑到当时的情况及敏感度，我们迅速制定了沟通策略，尽量避免我们在相互的对话中由于一本正经的口气而导致某些人产生抵触情绪。提高团队之间的沟通水平是最难克服的障碍。在注意到这点之后，我们同时从个人和集体的角度出发推进团队协作，共同交付软件。

随着时间的推移，开发和运维团队的互动得到了改善，最终我们成功地战胜了之前的职能障碍。团队之间建立了真正的信任，这是见证奇迹的时刻。开发人员向运维人员讲解了开发过程，以及与技术栈范例相关的细节。与此同时，运维人员向开发人员讲解了他们的发布流程，以及他们在维护基础设施方面的详细工作。团队之间的这些变化并非一蹴而就。这些变化随着时间的推移一点点发生，我认为这种成功的文化转变应该归因于集体的努力，以及从迭代试验和错误中吸取经验教训。两个团队感受到了沟通和透明度的好处。他们可以更好地定义和理解每个岗位，以及各个岗位对集体产生的影响。

什么是开发运维？

在“开发运维”这个词出现之前，我们的团队就建立了开发运维的文化。多年以后，当我听到开发运维这个词的时候，感觉眼前一亮，我当即明白了其中的含义。通过这个词来描述我们团队的工作方式再合适不过了。

下面，让我来分享一下我对开发运维的定义：

开发运维是......

●一个概念

●一种心态

●每个人都能够理解并接受的一种共同的态度

●必须培养并反复改进的文化

●分享

●指导

●学习

●包容并对所有想法持开放态度

●迭代

●连续

●协作

●一种优秀的开发和交付软件的方式

开发运维不是......

●易于实现或实施

●产品或工具链

●头衔或职位

●云基础架构提供商

●一本书

●一项技术

●编程语言

●营销活动

●CI / CD

●Kubernetes

●容器

●开源软件

●基础设施代码

●自动化

●不是开玩笑!!!

总结

在本文中，我根据自己长达几十年的工作经历，描述了我对开发运维的个人看法。我希望我的描述能够对你有所启发，也希望大家能够了解开发运维的需求及其为组织带来的价值。我很高兴能够回忆我的个人经历并与你分享。

感谢您阅读本文！

原文：https://circleci.com/blog/devops-did-not-exist/

本文为 CSDN 翻译，转载请注明来源出处。

【END】

CSDN 博客诚邀入驻啦！

本着共享、协作、开源、技术之路我们共同进步的准则，

只要你技术够干货，内容够扎实，分享够积极，

欢迎加入 CSDN 大家庭！

扫描下方二维码，即刻加入吧！