在知乎上，我经常被邀请回答很多类似的问题：运维到底是做什么的？运维工作有趣吗？运维有前途吗？运维会被各种技术取代吗？但是，我知道我主要以休闲娱乐为主，一般不回答严肃的技术或专业相关的问题。这一次，我希望通过这篇文章向大家描述清楚运维到底是干什么的。至于是否有前途、发展以及是否会失业等，还请读者自行判断。什么是运维？“运维”一词可能有多种含义，可以指代运维工程师、运维团队，也可以指代整个运维服务体系。可以看出，这三个层次是从狭义向广义递进的。相信大多数人问的都是运维工程师，只有少数人能体会到运维服务体系的意义。我们经常会听到一些言论，比如：随着云服务的普及，运维工程师会失业。当DevOps或者SRE落地的时候，运维工程师也会失业。随着容器技术的普及，运维工程师也应该失业了。。。记不清有多少次运维工程师失业了，但是我想就算换了运维工程师，运维服务不会消亡，它会伴随和支持业务发展的整个生命周期。你为什么这么说？我们还是用业务的诞生过程来分析。一个站点或APP大致经历了以下诞生过程：PM设计产品原型，交付给Dev进行开发实施，QA测试，再交付给Ops进行部署上线，最终提供给用户使用。这些简单的步骤涉及许多人、角色和交付流程。这是一个完整而复杂的系统工程，任何一个环节出现失误都可能影响最终呈现给用户的体验和效果。我们关注从Dev将完成的业务产品交付给Ops到线上运营的阶段。Dev同事主要负责业务产品的功能完备、逻辑正确性等业务指标，而Ops同事主要负责业务产品的运行质量和稳定性。、可用性等系统指标。不管后续的交付步骤是使用DevOps还是SRE来实现，都离不开一个通用运维服务的执行。所以，Dev还是Dev，Ops还是Ops。没有人被取代，只是运维服务的执行方式升级为更加软件化的方式，减少人为操作。DevOps强调自动化和拉动，以提高团队交付效率和质量。但传统运维需要寻求技术改造。仅仅关注操作系统层面的技术已经不够了。还需要提高程序代码性能调优、持续交付和容器化等软件基础设施方面的技能。持续关注整个业务、应用和服务的生命周期管理。简单来说，就是摒弃过去传统的黑盒运维思维模式，进入白盒运维时代。我们必须深入代码和业务运营，让整个在线服务运行在更加优质高效的状态。至于会不会更换运维，就看你属于什么运维了。没有运维开发工程师的参与，运维工程师和运维开发工程师就无法构建运维自动化，也无法实践DevOps，但如何才能更好地发挥运维开发的作用呢？作为运维产品经理，接触过各类运维开发。团队有的原本从事运维开发，有的原本从事其他业务（电商、平台）的开发，协助运维。团队。和他们一起工作了一段时间，总体感觉是这样的：运维开发首先是程序员，而不是运维工程师。一个好的运维开发需要具备“运维理解”+“开发能力”。对“开发能力”的技术要求低于其他业态（如游戏、电商、搜索等）。运维业务的理解难度会低于电商、游戏等业务形态，即对“运维理解”的要求不高。需要高度掌握运维相关的技术栈，比如Linux、Git、Nginx、Zabbix、Docker、K8S等。综上所述，运维开发是一个不太深的职业分支，并且之所以现在运维开发的需求越来越火热，主要是因为老一辈的资深运维一般研发能力有限，这是有历史原因的。对于入行8年以上的资深运维人员来说，刚开始做运维的时候，更多接触的是机房、机架、主机、交换机、防火墙等硬件设备。然后在与业务运维对接后，一般会借助Shell、Python等脚本来辅助工作。到业界提出DevOps时，往往已经聚焦于团队管理、容量规划、架构调优、运维服务质量等高级领域，因此基本不可能抽出大量时间重新学习编码并开发自动化系统。因此，当我们需要搭建自动化系统时，就需要更多专业的程序员来协助。但是，普通的非专业运维程序员做出来的系统，往往不太好运维。此时，一些年轻的运维工程师升级了研发技能，转型为运维维护体系，已经完成，赢得了运维团队的好评。人人称赞“运维开发”。所以大家把“一个好用的运维系统”等同于“运维开发”，认为只要招到一个运维开发人员，一个完美的运维平台就会自动诞生，这就是一个很大的挑战。误解。事实上，“一个好用的运维系统”真的等同于“运维理解”+“开发能力”。和其他业态的发展过程类似，产品经理和程序员的角色需要分开，企业不会说要招会写代码、能满足要求的程序员。因此，当高级运维人员能够将运维自动化的需求详细记录下来，并建立起自动化系统的设计、架构等关键环节，这就是最好的“运维理解”。这时候，把这份可靠、易用、详细的需求文档交给“开发能力”强的程序员，最终就能得到一个“好用的运维系统”。当然，高级运维想要获得产品经理能力并不是那么简单，还需要与运维开发无障碍地讨论技术。个人认为需要具备但不限于以下技能包：产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等因此，当运维需求理解和分析得足够透彻，并且高级运维已经具备了“产品经理”的能力时，运维开发是一个通用的开发分支，可以按照需求文档。对于高级开发，运维开发也可以替代高级运维需求，升级为运维产品经理，从程序员的角度解决运维服务的工程效率和质量问题。我认为这与谷歌所做的类似。推广SRE文化。最后很多运维可能会考虑要不要转运维开发。当你觉得编码的乐趣远大于其他运维技能时，努力转行吧！把自己想象成一个真正的程序员，按照程序员的评价标准来问问自己。不要认为运维能力和编码能力是半桶水是好事，就像我前面那句话：“运维开发首先是程序，他们是工作人员，不是运维工程师。”运维服务体系与技能等级量化每个运维工程师其实心里都有自己的想法，不妨以思维导图的形式列出来，找出自己感兴趣的点，继续In-深度，打造自己的核心竞争力。思维导图还可以继续横向和纵向扩展，在你的脑海中形成一套完整的运维概念。给大家分享一张思维导图，展示一下我心目中的运维服务体系。当然，还有很多东西可以开发，只是不方便透露细节。这是个人经验，不一定适用于其他运维团队。由于运维普遍注重广度而忽视深度，很容易导致自己的技术栈广而不精，那么如何量化自己的技术水平够深呢？下面以一个大家比较熟悉的MySQL技能为例。如果MySQL级别定义为1~10级，下面是我对各个级别的理解。为什么要量化技能？因为人的时间和注意力毕竟是有限的，如何将精力分配到不同的技能上，需要一定的策略。一般情况下，每个人都会把精力平均分配到各种具体的技能上，希望做到面面俱到，但又不会太深入某个技能，所以技能等级的等级就落在1到3之间。比如路人A的技能等级表是如下：（当然还有其他的技能项，比如网络，安全等，这里只做简化讨论）。运维的最低要求是一类需要广泛技能的工作。大家一般都处于技艺广而不深的状态。我把Level2定义为科普级别，也就是说达到这个级别就可以满足各种日常任务的需求。所以上面的路人A要争取尽快把还处于1级的Shell和MySQL都升级到2级，以满足日常的工作需求，这也是我们对运维的最低要求工程师。进阶要求除了满足最低要求外，培养自己的核心竞争力，为以后的发展打下基础。建议深入学习1~2项，达到4级、5级甚至更高的水平。随着互联网运维行业各种PaaS、IaaS的普及，自动化程度越来越高，现在“运营商”也没有以前那么多了。也就是说，技能水平较低的运维急需技能升级或技能改造。能支撑你走远的，不是1、2级的技能，而是4级以上的技能。写在本文最后的是作者个人对运维及其职业发展的理解。总的来说，运维还是一个比较有趣，发展比较好的职业分支。虽然偶尔会背黑锅，但欢迎更多努力、聪明、有才华的同学加入运维行业。
