「DevOps」闲聊我心中的运维开发

时间 2019-11-16

标签 devops 闲聊心中开发繁體版

原文原文链接

前言

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

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

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

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

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

来自维基百科程序员

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

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

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

按照从前的工做方式，开发和部署，不须要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.总结

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

做者掘金文章总集

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