“我刚开始做开发的时候还没有开发运维，这一原则改变了我的职业生涯！”
作者
AngelRivera
译者
弯月，责编
郭芮
以下为译文：
有人让我写一篇“什么是开发运维”的文章，我决定采用一种与众不同的方式来写这个主题。在本文中，我将根据我在科技行业几十年的工作经验来定义开发运维。我将带你横穿我的专业时间线，并讨论开发运维走进我的生活的整个过程，以及对我的职业生涯带来的影响。
90年代
90年代中期，互联网尚处于起步阶段，不像现在这样普及。人们带着黑色的通讯录小本本，里面记载了所有联系人的信息。当时我们还在使用寻呼机，呼叫后等待对方回电话。信息的传播仅限于纸质媒介，比如期刊和书籍等。人们会去图书馆看书，通过纸质的索引卡查找资料，并通过杂志、报纸或书籍获取所需的信息。这是一个手动获取信息的时代。
年，我开始从事专业的编程工作，当时的技术领域与今时今日有着天壤之别。大多数公司的处境都很尴尬，他们看到了科技的价值，但往往在投资或采用科技的时候犹豫不决。那时的CPU、内存和存储都非常昂贵。带宽非常稀少，很有限，而且也非常珍贵。大多数软件开发和运维（SRE或系统管理）团队都需要手动开发、测试和发布应用程序以及托管的基础架构，更重要的是，这些工作都是单独完成的。数据中心必须设计、构建和配备适当的电源、气候控制以及布线，然后由有能力的技术人员控制和管理昂贵的基础设施硬件。从斗志昂扬的创业公司到大型企业，他们都有某种形式的“数据中心”。
当时我的软件开发工作主要包括：
单独编写代码通过“另存为……”的方法建立新版本的代码手动编译手动测试应用程序（通常需要点击、提交以及验证结果是否正确）几乎没有代码审核手动创建部署的发行包编写包的发布/安装说明通过软盘、CD或网络文件共享上的共享目录将发布包发给运维团队等待…每次等待新版本都需要4小时-10天的时间，这个时间的长短取决于运维团队的忙碌程度以及运维人员部署新版本的水平，开发人员和运维团队之间几乎没有沟通。事实上，大多数开发团队和运维团队之间都存在意见上的分歧。两个团队之间常常会彼此产生敌意，运维团队认为开发团队的软件质量不过关（未经测试或测试覆盖太低），而开发团队则抱怨运维团队未能尽快将软件部署到生产环境。
随着我的职业生涯发展，我花了很多时间思考引发开发和运维团队之间不必要的敌意的因素。我无法理解为什么这群技术娴熟的高素质团队不能凝聚在一起，高效地实现我们的共同目标和使命。很显然，开发和运维团队根本不在同一个世界里。二者只有一个共同的目标，那就是将软件发布到生产中。除了这个目标之外，他们之间没有兴趣共同努力解决问题。在科技发展的这个时期内，开发和运维团队由于彼此脱节而产生了负面影响，甚至危害到了公司的文化。当然，也并非每个团队和组织皆是如此，但我敢说，大多数团队/组织中都或多或少地存在这种现象。
敏捷开发
以上我简单地描述了我作为软件开发人员早期的一些职业发展经历，让你对我的工作态度、心态和文化有一个大致的了解。我发现我描绘出的情况似乎不是特别美好。其他人可能有完全不同的经历，但我相信大多数团队都经历过类似的职能不健全。
随着时间的推移和技术的发展，硬件和宽带越来越便宜，越来越快，而且还提供了更强大的动力。在这个时期，开发团队对软件的开发方式有了更进一步的了解。各个团队开始从上到下分析他们的流程，并了解到软件开发生命周期中已知的瓶颈。许多团队意识到，如果改变软件开发流程并改善沟通，则可以更快地交付高质量的软件。于是，许多团队和组织开始采用和实施敏捷软件开发概念，这些概念帮助各个团队了解自己开发团队中的不足，他们开始尝试融合新的概念和想法，并总结出新的方法论和策略。这些敏捷方法论包含了一种侧重于协作、客户反馈和小型快速发布的迭代方法。
各个开发团队和组织在敏捷原则的帮助下，成功地改善了组织运营，多年后，我注意到团队生产代码的速度得到了大幅提高。开发人员在开放式代码中进行协作，而对于团队来说，版本控制系统是创建、修改和共享代码的关键因素。随着时间的推移，开发团队能够以更聪明的方式开展工作，而且制作高质量代码的时间也大大缩短了。编写、测试和打包代码的速度也更快了。尽管开发团队火力全开急速地编写代码，但我们遇到了一个意想不到的问题：代码的发布速度赶不上开发的速度。我们很快意识到，我们专注于改进我们的软件开发流程，却忽略了发布或部署的流程。因此，我们有很多积压的新代码，这些代码没有发布给我们的客户，对开发人员来说，这是一个巨大的问题。
我接触开发运维的过程
一直以来，我都在从事编写代码的工作，而且我对代码的各个方面都非常感兴趣。为了满足我的好奇心，我知道我必须与运维团队建立真诚健康的关系。在职业发展生涯的早期，我意识到开发人员和运维团队之间存在共生的关系，而且我天真地以为其他开发人员和运维人员也这么想。
不可否认，当现实赤裸裸地摆在眼前时，我感到非常沮丧。我无法理解为什么这些团队之间会存在“隔阂”。我觉得这些“隔阂”是开发和运维团队为了维护自己的“地盘”而制造的借口。我认为两个阵营之间的“隔阂”是巨大的创新阻力。自从意识到这一点后，我开始称自己为“站在运维一方的开发人员”，而且我认为自己实至名归。
后来，我们意识到，虽然我们在敏捷方面做出了很多努力，但由于缺乏与运维的互动而完全发挥最大优势，于是我们联合起来制定了新战略，将软件开发生命周期中的运维也考虑在内。当时，还没有开发运维这个词，但这个词的精神已经开始活跃，而且在许多采用和实施敏捷的开发团队都采纳了这个思想。许多“敏捷”团队都面临相同的困境——开发团队非常