我认识的运维工作

运维这个工作对于非运维岗位的人来讲，一直都是神秘的，大家对于运维的工作内容其实并不了解，或者了解的比较片面。其实算是一种工作类别了，除去互联网软件行业的运维人员不说，一般的机关事业单位也有相应的岗位配置，即信息处，科技处之类维护单位IT系统的团队，他们与互联网公司的运维人员工作有类似之处。这里我主要介绍下国内互联网公司的运维。

国内互联网公司的运维工作大致有以下几个内容：1）资源管理，2）变更部署，3）监控告警，4）故障响应；除去这4个必备的内容外，很多公司的运维还需要参与系统的架构设计，推动系统性能，成本等优化以及系统安全等工作。

1.资源管理

资源管理其实最简单的理解就是机器的管理，包括采购，规划，调度等。对于开发团队来说，他们不需要关心机器从哪里来，只需要找运维要机器就好，运维会根据开发的需求给出相应的服务器资源。当然提到资源当然就涉及到成本，运维人员需要根据开发的业务重要程度合理的分配资源，保证采购回来的机器足够使用。

2.变更部署

这个部分其实包含的内容非常多而且也非常复杂，包括业务的部署，变更，发布，回退等等。先说部署工作，部署工作不仅仅是将开发生产出来的软件直接丢到机器上跑起来就完事的，这里需要运维解决环境问题，比如系统，依赖（包括库以及组件），网络等等，否则服务无法正常运行。变更其实是制定规则的一个过程，对于互联网公司来说，大多数故障都来源于变更，开发上线程序，运维迁移数据等等。为了降低变更的影响面，提高成功率，运维需要制定一系列的变更规则出来，比方灰度时间间隔不能太短，一次不能灰度太多机器等。

3.监控告警

除了基础监控（cpu,内存，磁盘等）以及开发自己上报的监控外，运维人员还需要对系统的关键部位安插告警点，对于敏感业务可能需要运维自己写脚本进行更加细致，及时以及定制化的监控以便及时发现和定位系统的异常

4.故障响应

这部分是运维最常见的工作，当系统发生故障时，运维需要进行定位和修复，运维一般是进行系统级别的操作，比方切换网络，切换机房等。代码层面的问题需要配合开发一起解决。

以上工作属于大多数运维人员的基本工作内容了，运维即运营维护，运营层面需要做到以最低的成本做到高可用和高性能，维护层面需要最及时的发现系统问题以及推动解决问题。这个岗位需要的不仅是技术，还需要一些管理能力，工作日常非常琐碎，单个运维一般会对接多个开发。

这个团队离老大比较远，一般是部门老大不怎么关注的团队，如果老大哪天找你了，相信我一般不会是好事

=============================更新======================

对于互联网公司来说，最初不存在所谓的运维工程师，相关工作由后台开发工程师承担。公司规模小的时候，这种模式运行的很好。开发自己购买资源，上架机器，部署，发布，监控等等。

公司规模大了以后，问题就出现了，人多手杂，发布流程没有人去推进和落实，系统经常莫名其妙的因上线出现各种问题，排查和修复工作异常艰难；资源利用率低下，忙的机器负载高到死机，闲的机器常年吃灰；现网环境管理混乱，开发在生产环境调试软件，任意修改系统参数；数据，网络，系统没有安全可言，漏洞日益增多；容灾高可用得不到保障，死一台服务器，整个业务受到影响；研发流程低级问题频发，代码相互覆盖，回退，联调环境相互干扰，效率很低。为了彻底治理这种乱象，DO分离，出现了运维工程师这个职业，本质上是后台工作的劳动分工。

研发和运维工作的界限比较模糊，以前的运维工作比较简单，部署服务，管理资源，7*24监控等等，对于研发侧的工作基本不会涉及，研发部门与运维部门通过交付文档来接口，当然很多情况是没有文档的，只是开发的口头交付而已，这种做法的痛点比较多，最明显的，开发更关注业务的快速实现，很多时候会忽视安全，容灾，性能，可维护性这些方面，当一个有上述缺陷的模块发布到线上后，系统稳定性就会面临很大威胁，但是在业务时间压力面前，又不得不放行，最终的结果要么是运维苦逼的人肉支撑，要么是系统出现故障，研发运维一起背锅。运维的话语权较弱，存在感非常低。

近年来DevOps概念盛行，希望运维可以将工作多向研发侧延伸一截，谷歌提出了SRE，本质上也是DevOps的具体实践，和传统的运维不同的是，SRE除了传统运维的工作内容之外，会参与到研发工作当中，相关ITIL流程系统化落地，研发管理，持续交付体系建设，架构评审，混沌工程，容量管理等等。本质上是扩大运维的影响力，更大范围更深层次的推进标准化和稳定性建设。与传统的运维工作相比，与业务融合度更高，从过去的被动响应式变成主动干预，相当于在之前的try catch之前加入了大量的if else防御性拦截。

不过DevOps在国内的实践有点尴尬，符合要求的人确实很少。传统运维价值有限，入行门槛低，很多人把运维工作干了一个又穷又苦又LOW的民工职业。导致现在有实力的人大多不愿意去做运维，而事实上，一个合格的运维首先应该是一个合格的开发工程师（很多同行不赞同，欢迎来探讨：）），除专业相关技能之外，还需要兼备管理，沟通，协调，方法论等多个方面的能力。

小公司重敏捷，大公司重稳定。在实践中，敏捷和稳定是一对相互冲突的范畴，只能是折中的艺术。运维工程师的核心职责是稳定，风控，成本。所有工作内容都是围绕这个核心展开的，根据公司对于这个职业的定位不同，能力范围不同，工作内容也有所不同。

最后推荐1本适合运维新人看的书籍：《凤凰项目，一个IT运维的传奇故事》， 书本身非常轻松，但是涵盖了很多运维的工作日常，以及运维工作的一些思考，值得一看