前言

在我入职上家公司的运维部之前，我所以为的运维工程师只是修修电脑，拉拉网线，布布机器。

诸不知，运维所涉及的知识面、专业点非常广，对从业人员素质也要求非常高，运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多：

桌面运维工程师
业务运维工程师
DBA工程师
配置工程师
运维开发工程师
以及其它....

原本准备写篇前端眼中的运维开发，恰巧前组长写了两篇结合自身六七年开发经验写的体会。用他的文章来阐述再合适不过了。以下来自其投稿以及穿插一些知识普及。

1. `DevOps`：打破协作壁垒

来自维基百科

DevOps（Development和Operations的组合詞）是一种重视「软件开发人员（Dev）」和「IT运维技术人员（Ops）」之间沟通合作的文化、运动或慣例。

透过自动化「软件交付」和「架构变更」的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。

按照从前的工作方式，开发和部署，不需要IT支持或者QA深入的跨部门的支持；

而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。

具体来说，就是在 软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。

2. 运维开发的价值

从岗位职责来看：运维开发要做的工作是：

通过开发技能帮助运维实现运维工作的自动化。说白了就是“辅助”，或者说是运维的臂膀，需要把运维中遇到的问题提供平台查询，或者把一些常见的重复操作给抽象出来做成工具，减少运维的人工介入。

运维服务伴随并支撑着业务发展的整个生命周期。

而DevOps将运维服务的执行方式升级为更加软件工程化的手段，减少人肉操作，DevOps 强调自动化、拉动式来提高团队交付效率与质量。

而传统的运维需要谋求技术转型，从原来只关注操作系统层面的技术已经不够了，还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升，也需要持续关注整个业务、应用、服务的生命周期管理。

简单来说，就是把过去传统的黑盒运维的思维方式抛弃，进入白盒运维的时代，我们必须更加深入代码、深入业务运营，让整个线上服务运行于更优质高效的状态。

3. 运维开发是什么？

要建设运维自动化或者实践 DevOps 离不开运维开发工程师的参与，但要怎样才能更好地发挥运维开发的作用呢？

我曾作为运维开发经理的角色和各种类型的运维开发一起协作过，团队中有本来就做运维开发的，也有本来做其他业务（电商、平台）的开发转来协助运维团队的，还有原本是做业务运维后来转型做运维开发的。

和他们协作一段日子后，总体感觉如下：

运维开发首先是一个程序员，不是运维工程师。

一个好的运维开发需要具备「运维理解」+「开发能力」：

对「开发能力」的技术要求低于其他业务形态（如游戏、电商、搜索等）。
对运维业务的理解难度会低于电商、游戏等业务形态，即对「运维理解」的要求不高。
对运维相关技术栈的掌握程度要求高，如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、K8S等。

综上所述，运维开发是一个深度不算太深的职业分支，而现在之所以对运维开发需求量热起来了，主要由于老一辈的资深运维普遍研发能力有限，而这是有历史原因的。等到业界提出 DevOps的时候，他们往往已经专注于团队管理、容量规划、架构调优、运维服务质量等高级范畴，所以基本不太可能抽出大块的时间来重新学习编码并开发自动化系统。

所以，当我们有自动化系统的建设需求时，需要更专业的程序员来协助。但一般的非专职运维开发的程序员做出来的系统对于运维来说往往不太好使，这时候有部分年轻的运维工程师升级了研发技能，转型运维开发，把好使的运维系统做出来了，赢得了运维团队的好评，大家都为「运维开发」点赞。

所以，大家将「好使的运维系统」和「运维开发」等价起来，以为我们只要招来一个运维开发，那么一套完美的运维平台就能自动诞生出来，这是个很大的误区。

4. 打造「好使的`DevOps`系统」

其实「好使的DevOps系统」真正等价于「运维理解」+「开发能力」，这两种能力也是可以分离的，不一定要强加在运维开发工程师一个人的身上。

类似其他业务形态的开发过程，需要产品经理和程序员两种角色分离，企业也不会说要招聘既会写代码、又会出需求的程序员。

所以，当运维能把运维自动化的需求细致地文档化下来，把自动化系统的设计、架构等关键环节确立下来，这就是最好的「运维理解」。这时把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员，最终就可以得到「好使的运维系统」。

当然，一般企业不会专门为运维开发配备「产品经理」，所以运维开发想要再往高级发展的话，也可以替代运维出需求，升级为运维产品经理，以程序员的思维角度来解决运维服务的工程效率和质量问题，我认为这也是类似 Google 所提倡的 SRE 文化。

4.1 `DevOps`平台

编者补充描述

光说不练假把戏，编者在上家公司的主职就是将DevOps操作界面化。其中的核心模块：应用部署发布监控

图为DevOps应用部署发布监控界面图

我们组在做上图的DevOps系统时，面临的情况是：

无产品、无设计、需求也是靠业务运维和开发们的口头描述。

其中的核心功能：应用部署界面，在参考其它同类产品后，发现都不适合业务场景，要么功能太分散，要么就仅是流程控制。于是前端功能里，我们做了这些：

区分不同环境下的包，实现有序管理。
应用的状态可以通过界面做启停、查看配置等任务。
Jenkins服务操作可通过界面完成，简化配置工程师的工作。
业务运维与开发团队的日常发包工作界面化

此时一个优秀的运维开发需具备以下技能：产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等。

所以，当运维需求被理解、分析得足够透彻，以及运维开发获得了「产品经理」能力后，运维开发就是一种普通的开发分支，按需求文档编码即可。

5. 优秀的运维开发

从事DevOps平台开发相关工作已有六七年了，自身经历总结，觉得一个优秀的运维开发工程师应当具备以下能力和素质。

1. 提高运维意识。

从下到上，从上到下的工作都要做好，对上运维工作的价值和含金量可以得到认可，对下我们的工作能够提高效率解放运维。

运维意识是很重要，并不是你技术很牛，学的技术很多很熟，就不代表你不需要运维意识。

其实领导很看重运维意识的，例如有没有做好备份，权限分配问题，平台测试情况，故障响应时间等，这些都是意识，而不是你学了很多技术自认大牛了，平台发现故障你又没什么大不子，以为很简单的问题喜欢处理就处理，不需要向其它部门反馈等，领导不是看你的技术如何，而是看你的运维意识如何，你没运维意识，技术再牛也没用，只会让其它部门的人跟你不协调。

2. 了解业务场景

DevOps平台最终服务于运维部和开发测试部同事，因此只有熟悉了解了每一项业务的运维场景，才能更好去设计功能与代码开发，熟悉业务场景才能方方面面考虑周全，开发出来的代码才能满足各类场景应用。

3. 拒绝重复犯错

人难免会犯错，这是无法避免的，我们应当根据已有的犯错经验，总结犯错的原因，以及如何避免同类情况再次发生，甚至可以把一些典型的错误在团队中分享，把一个人的错误得到的经验传播于整个团队。

4. 凡事有备份，可回退

运维工作中经常有一些发布，迁移，备份等复杂操作，因此，在研发DevOPs平台的时候，要做好全面的操作计划，思考每一步可能的回退与备份。

5. 平台操作尽量简化

DevOps平台目的就是为了能够提高运维的工作效率，解放运维，因此在设计与开发的时候，应当保持操作简单，不要让事情变得太复杂，能点一下到位的，尽量不要让人点五六下才能完成操作。

6. 注重优化用户体验

DevOps开发是一个迭代的过程，虽然我们常说以功能开发为主，但是用户体验也同等重要，试想一下，纵使你开发的功能众多，如果体验不友好，用户便失去了再次使用的欲望，如果用户拒绝，抵触使用平台，做再多功能也是失败，最终平台推广失败。因此，在研发的过程中，我们应当深入体验自己开发的产品，把自己当成用户去体验平台操作。尽可能的去优化用户体验。这是一个优秀的运维开发工程师必需要懂的。

在设计与开发的过程中经常会碰到复杂，繁琐的场景，这个时候我们很容易失去耐心，我们要时刻提醒自己，必须严格履行自己的工作职责，端正自己的工作态度，做一件事，要么不做，既然做了就要做好：当你想要放弃的时候,想想当初为什么要开始。

6.总结

本文是我个人对运维开发以及其职业发展的一些浅薄理解，总的来说，运维开发还是一个比较有意思且有良好发展的职业分支，虽然偶尔也要背黑锅，但也欢迎更多努力、聪明、有才华的同学加入运维开发行业。

作者掘金文章总集

需要转载到公众号的喊我加下白名单就行了。

公众号