运维是干什么的
「运维」二字可能有几层意思，分别能够指代运维工程师、运维团队或许是整个运维效劳体系。
咱们能够看出，这三层是从狭义到广义的递进。相信绝大部分人问的都是运维工程师，只有极少数人能意识到还有运维效劳体系这一层意义。
咱们常常会听到一些言辞，比方：
云效劳遍及了，
运维工程师就要赋闲了。
等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的时分，他们往往现已专心于团队办理、容量规划、架构调优、运维效劳质量等高档范畴，所以根本不太可能抽出大块的时刻来重新学习编码并开发主动化体系。
所以，当咱们有主动化体系的建造需求时，需求更专业的程序员来协助。
但一般的非专职运维开发的程序员做出来的体系关于运维来说往往不太好使，这时分有部分年轻的运维工程师晋级了研制技术，转型运维开发，把好使的运维体系做出来了，赢得了运维团队的好评，咱们都为「运维开发」点赞。
所以，咱们将「好使的运维体系」和「运维开发」等价起来，以为咱们只需招来一个运维开发，那么一套完美的运维渠道就能主动诞生出来，这是个很大的误区。
其实「好使的运维体系」真实等价于「运维了解」+「开发才能」，这两种才能也是能够别离的，不必定要强加在运维开发工程师一个人的身上。
相似其他事务形状的开发进程，需求产品司理和程序员两种人物别离，企业也不会说要招聘既会写代码、又会出需求的程序员。
所以，当资深运维能把运维主动化的需求详尽地文档化下来，把主动化体系的规划、架构等关键环节建立下来，这就是最好的「运维了解」。
这时把这份靠谱、好使、详尽的需求文档交给具有强「开发才能」的程序员，终究就能够得到「好使的运维体系」。
当然，资深运维要获取产品司理才能也不是那么简略，并且也需求和运维开发无障碍地讨论技术，个人觉得有必要具有且不限于以下技术包：
产品规划、产品规划、面向对象、需求模型、范畴模型、规划模型、规划准则、规划方式、产品东西和文档才能等。
所以，当运维需求被了解、剖析得满意透彻，以及资深运维获得了「产品司理」才能后，运维开发就是一种一般的开发分支，按需求文档编码即可。
再往高档开展的话，运维开发也能够代替资深运维出需求，晋级为运维产品司理，以程序员的思想视点来处理运维效劳的工程功率和质量问题，我以为这也是相似Google所发起的SRE文明。
终究，许多运维可能考虑要不要转运维开发，当你觉得编码的趣味远远大于其他运维技术的时分，虽然争夺尽力去转！
把自己当成一个真实的程序员，以程序员的点评标准来要求自己，不要觉得运维才能和编码才能各自半桶水是功德，正如我前面的那句话：“运维开发首先是一个程序员，不是运维工程师。”
运维效劳体系与技术水平量化
每个
运维工程师心中其实都有自己的主意，无妨用思想导图的方式将其列出来，找出自己感兴趣的点，持续深化，打造自己的中心竞争力。
而思想导图也能够持续往横向纵向扩展，构成自己心中完好的一套运维概念。
下面跟咱们共享一张思想导图，展现我个人心中的运维效劳体系。当然，这儿边还有许多能够打开，但细节就不便利透露了，这归于个人经历未必能适用其他运维团队。
因为运维一般讲究广度而疏忽了深度，所以简单导致自身的技术栈广而不精的情况，那怎样量化自己的技术水平满意深化呢？
举一个咱们都了解的MySQL技术作为比如，如果把MySQL水平界说成1~10级，下面是我对各种等级水平的了解。
为何要量化技术呢？因为人的时刻、专心力究竟有限，如何把精力分配到不同的技术上，需求必定的战略。
正常情况下，咱们把精力平均分配到各种详细技术，期望能够做到八面玲珑，但不会太深化某项技术，所以技术水平到达的等级落在1~3之间。
如路人A的技术水平表是这样的：（当然还有其他技术项，如网络、安全等等，这儿仅仅简化了便利讨论）。
最低要求
运维是一种需求技术面比较广的工种，咱们遍及都是处于技术面广但不深的状况，我把2级界说为科普级，意思是到达该级就能够满意各种日常作业要求。
所以说上面的路人A，最好尽快争夺把还在1级水平的Shell和MySQL都提升到2级，就能够满意日常作业要求，这也是咱们对
运维工程师的最低要求。
进阶要求
除了满意最低要求之外，培育自己的中心竞争力，为日后的开展打下根底，引荐咱们对1~2项深化学习，到达4、5级甚至更高的水平。
跟着互联网运维工作的各种PaaS、IaaS遍及后，主动化程度越来越高，现在现已不像以前那样需求那么多「操作员」。
也就是说，技术水平偏低的运维急需技术晋级或许技术转型，能支撑你走多远的不是那些1、2级的技术，而是4、5级以上的技术。
写在终究
本文是笔者个人对运维以及其作业开展的一些浅陋了解，总的来说，运维仍是一个比较有意思且有良好开展的作业分支，虽然偶然也要背黑锅，但也欢迎更多尽力、聪明、有才调的同学加入运维工作。
阅读推荐:运维工程师的一天，你真的了解吗？
