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

我也会设一些虚拟的小组,类似于矩阵式管理,有一些技术小组做大数据、分布式缓存,Docker、Nginx 等等,目的是什么?有点像Google SRE的50%原则,50%的时间做开发任务.但是我没有办法让他将50%的时间完全去写程序,因为有很多事情要去做,而且我们也有专门的开发团队,但我可以设一些技术的小组,分离业务和技术的事.每个人50%的时间去做跟技术相关的事情,这样他们自己也会觉得有意思一点,最终的目的不仅是做一个纯业务的运维,而是给PE们提升的空间.

SLM服务级别管理

下技术管理上的实践,即使是互联网公司,ITIL这样偏传统的管理方式也有很多可取的地方,我们现在也用得着,并不是抛弃掉所有传统的理念,要根据公司的需要,不管是ITIL还是SRE,还是其它方法都可以借鉴,以此设计你的组织结构.我会保留传统的东西,像SLM,在SRE里叫SLO.为什么叫SLO不叫SLA了?

因为SLA是服务协议,更多时候是甲方和乙方签协议.公司内部没有协议,而是设定一个目标,开发跟运维间达成一致,要有数据化的考量.SLA或SLO都不只是一个可用性的目标,还包括很多的方向,比如维护的时间是否可靠?包括性能、备份、问题解决的时间这些都是考量的指标,不只是数字.我们内部的SLA会分得很细,根据业务的类型,对不同业务的影响会有很细的评估.

变更管理

80%的故障都是变更引起.变更很频繁,互联网公司里面每天可能都几十次、上百次的变更,测试环境没有测试到业务的问题的可能性是很大的.变更管理的内容可以再看一下,比如CMDB,变更的时候还是要有基础库做记录的,有了基础库后面才能做很多事情.

重大事件及故障管理

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

事件处理流程

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

故障分析会

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

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

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

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

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

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

数据化运维

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

（编辑：ASP站长网）