SRE，DevOps，PE的运维本质和价值都是为产品和业务服务

重大事件及故障管理,公司有问题的时候怎么快速的解决,有很多的细则要做,我们设有服务台、监控这样的岗位,通过数据更准确的定位问题,大家一同协作、排查.缩小排查范围有法可依,比如根因分析法,排错法.不是简单的沟通好就行了,还要检查变更记录、收集问题.

事件处理流程

很多时候,现场处理问题动作比较快,后面分析时复原问题说不清楚.操作前尽快的把问题现象记录下来,包括监控信息、堆栈信息等等,以便于后面分析.处理流程尽量梳理清楚,对应的做分类,看问题是常见的还是非常见的.常见的问题有对应的应急案,快速的进行处理就好,如果是非常见的,需要技术和决策人参与,看到底是紧急的问题还是日常的问题,快速决策和解决.这里更多的还是需要有协调,有应急预案,应急的预案需要经过演练.

故障分析会

分析会也叫复盘,有了故障以后组织故障分析会,目的是为了避免相同的问题重复的出现,做改进.这时,前面收集的信息就有用了,根据收集的信息复盘故障,大家看看当时发生了什么问题,怎么解决的,有没有更好的办法去定义故障级别,然后分析根本原因,这很重要.开故障分析会应该放松心态,开放共享,不要用指责的态度,而是追求事实,去看根本原因,共同提高、改进,分清因和果.很多时候分析出的问题并不一定是真正的原因,可能有更深层次的原因.

五问法,?就是要多问,大家一起讨论,不要停留在表面.每一个人从自己的视角去看当时发生了什么,可以提出很多问题,引导进入深度思考.

琐事—50%时间去做开发或虚拟技术小组的事情,SRE说50%的时间做开发,但是我认为50%的时间不一定全做开发,开发的时候也可以做一些技术的事,只要是长远讲,对你的组、对公司有好的影响的事,我觉得就可以了,目的是一样的,多做自动化,促进大家提高能力.

自动化—减少重复性工作,减少手工操作带来的不确定性.很多公司做自动化的同时,导致风险也变多了,所以怎么样做正确的自动化?正确的自动化减少了重复性的工作,减少了错误,解放了人类,但是错误的自动化对应的只是把人类机械化了.以前手工做很多次的,现在变成一次就执行了,系统没有给你正确的反馈.这和DevOps说的一样,不仅能更快速迭代的发布,还要有反馈的信息,收到有反馈的异常信息以后能快速的回滚,这点很重要.

很多的DevOps平台都只是做了自动化,但是风险是不是控制好了?系统能否有效反馈?发布失败的时候能不能停下来?要做好对应的信息反馈.错误的自动化对应的会给出错误的信息,导致决策失误,这是一定要注意的.比如金融证券行业,做了一定的自动化交易(量化分析),程序自动做投资、买卖股权、买卖股票,完全自动化.但是如果系统没有做好,就是灾难性的,风险还是很严重的.核心系统一定不要缺少人工干预,并不是完全自动化就不需要运维了,决策或者风险非常高的地方,还是需要人去做.

最后一点,理解构建的东西,设计任何一个系统一定要知道下面具体的实现.发布的时候告诉研发的人后面有什么风险,系统是怎么设计的,懂了原理之后才能规避更多的风险.

数据化运维

现在都说数据化运维,有点类似于运营,有些运维做得比较好的话还是可以往公司的运营方向转.很巧的是,运维和运营的英文的单词都是“operation”,都是偏运营的方向,目标也是一样的,做运维做得好的时候,应该有更多数据化的东西给公司做决策参考.尤其是监控跟线上处理相关的,对应的数据都是你的来源,这些来源都会做智能运维的数据采集,比如说网络监控,操作系统监控,DNS等服务监控,基础组件的监控.基础技术组件服务,像DB、缓存、消息等,架构的组件都需要做数据化的参考,没有这两部分数据的话,做应用级性能分析的时候就很难.

（编辑：宁德站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!