工作内容
SRE工程师，其实就是运维工程师，一般包括日常运维工作和工具开发两类工作。
日常运维工作根据方向不同，内容可能不尽相同，值班期间主要是处理日常服务报警、不值班期间可能就是做一些跟运维方向相关的工作。
值班期间的工作，也就是24小时oncall，处理报警，还有处理业务的需求。
报警处理根据不同业务的情况各有不同，有的业务报警比较多，有的业务报警比较少，另外根据报警的严重程度不同，处理难度也可能略有不同；其中最难处理的是无法止损的报警，无法止损的报警最为费心，需要想办法降低损失，需要通过一些可以操作的手段做出一些动作，但是在故障期间，对于问题准确评估比较困难，而且存在报警风暴，压力会比较大。
其次比较麻烦的是，不太容易找出根因的报警，虽然可以止损，但是根因追溯可能由于层次较深，而且没有工具辅助，往往需要手动一层一层的进行分析，耗时较长。
除了这两类报警，比较容易发现根因的报警处理起来是比较方便的，但是比较方便处理的报警可能由于值班人所处场景的限制，也会出现比较麻烦的情况，比如在地铁上、信号不好的区域、上厕所了等等，处理速度会比较慢。
最后一类最容易处理的报警就是可以被自动处置的报警，一看问题自动处置了，就等着报警恢复就完事了。
这是报警处理，除了报警处理，值班期间还需要对业务的需求进行处理，业务的需求包括业务权限不在的各方各面，包括app创建、监控修改、流量接入干预、上线卡单处理、容量变更，每一块可能还会细分，比如流量接入方面，包括内网流量干预、外网流量干预等等，不过这类工作基本上就是熟能生巧，一般业务不需要什么计算机知识，或者不需要很深入的计算机知识，在数月之内可以掌握。
还有一类工作就是在值班期间要对业务的疑难杂症进行处理，这类问题往往是运维工程师工作内容中比较有含金量的工作之一，因为这类工作往往并不是简单的处理就可以解决问题，有些问题可能已经是陈谷子烂芝麻，有些可能需要对服务进行细致分析，往往才能找到问题所在，但是问题的解决之道大多都在别处，运维的工作就是找到确凿的根因；不过这类工作有个问题是比较消耗时间，而且产出不会在okr中，所以完全根据时间是否富裕决定。
除了，值班期间的三类工作，不值班期间工作内容一般就包括两个方面，跟业务有关的稳定性工作，还有跟开发有关的平台工作。
在运维工作中，跟业务有关的稳定性工作基本上就是围绕不同业务做相同的模版型工作，所谓模版就是流程以及内容基本固定，比如如何发现问题、如何容灾、如何提高其稳定性，其实具体而言就是监控报警、容量规划、止损预案、限流降级等等。
稳定性工作，一般而言就是以上所述的这些，说起来也是孰能生巧，并没有什么特别高深的内容，不同业务情况不同，不同板块能做的可能会略有不同。
开发工作，就是针对运维工作中的各方面的工具或者平台开发，这些平台比较多，有些可能是运维同学开发，有些可能是基础架构部门开发，开发中也是比较考验设计能力，好的设计往往会决定产品是否好用，不过运维产品本来用户就不多，往往质量也一般，并且不会有专门的pm，有些甚至需要进行全栈开发。
工作职责
运维工程师的职责，根据我的理解，其最根本的目的是对故障进行止损，问题的定位和处理一般都应该是业务来进行，并且配合业务处理问题；但是在实际操作中，有部分问题可能不需要业务干预、以及部分业务本身定位能力一般，就导致运维工程师自身需要有一定的定位能力以及利用稳定性意识来把控故障处理的节奏，以免发生次生灾害。
工作展望
运维工程师服务的是实际的业务，所以一般而言团队的扩张与收缩都会随着业务的扩张和收缩而变化，通过描述我们可以发现，运维工程师的大部分工作中，开发工作以及可以开发的时间一般不会超过一半，所以开发时间也比较有限，开发团队跟实际的业务开发团队存在很大的不同，一般的小平台不会有产品和QA，基本上就是全栈。
工作内容上，其中以稳定性中的架构稳定性和容量规划具备深度，从产出上，容量方向更容易产出数据，并且自主性较强，稳定性方面，由于架构稳定性运维可以干预的极少，并且受限于框架能力，具备局限性。
另外，运维工程师需要跟各方面的人打交道，因为服务是业务开发、服务依赖的环境是基础架构负责，而运维就是需要协调基础平台同学和业务同学，一起解决问题，但是运维本身并解决不了最根本问题，因为运维并不掌控这些实际的代码和应用，运维的工作更多是在应用层，就是应用各种平台来达到服务稳定和正常运转。
一般来说，对于运维来说，成长路径就是运维工程师、高级运维工程师、运维负责人、高级运维负责人，在能不能成为运维负责人方面是一个节点，然后能不能同时管理多个产品的运维又是一个节点。
从岗位上来讲，运维的岗位是比较少的，一般而言，运维的岗位跟业务开发的人数比例是100:1左右。
从赚钱方面来讲，运维本身并不赚钱，但是话说回去，容量成本是一个例外，通过省钱，同样也是赚钱。
从技术方面来讲，运维工程师是一个跟计算机技术相对来说不需要特别深入的岗位，但是可能运维的系统不同，可能略有不同，比如业务运维和机器运维，可能日常要做的工作和用到的知识不太一样。
暂无评论内容