突发重大事故，我们运维这样进行处理(1)
2016-02-20 19:34:04   来源： 余何 高效运维    评论：0 点击：

作者介绍

余何，外号：众神的大师兄，运维心灵捕手，十余年IT金融运维经验，一直任职于某世界100强企业，参与并主导过各大神秘项目，热爱开源、感悟运维、痴迷于IT技术。

前言

It is the time you have wasted on your rose that makes your rose so important.

这是平凡的世界，不平凡的运维专栏的第一期，我很难以一种感性的方式告诉别人运维是做什么的，以至于对不同人会有不同的譬喻。

对于父母，运维是当前世界上很稳定的工作(让老人安心)。

对于妻子，运维是计算机世界的特工组织(熬夜不归的好理由)。

对于朋友，运维并不是帮人装杀毒软件(告诉别人它不是什么也很重要)。

对于业内人士，运维是可用率99.99%(我觉得以后要换一种方式)。

对于公司老板，运维是一门并不需要知道它有多精彩，但必须重视的岗位(这真的很难，也很矛盾)。

好了，让我们开启今天的主题，运维事件处理经验谈。

运维是一朵需要花时间照料的玫瑰

UIOC

为了保证可用率99.99%，除了在应用架构、资源容量上做足功夫外，运维人员还要面对一个事实，那就是异常、故障、突发事件总会发生，这在管理上必须有一个流程方法来应对之。

在我们组织内部有两个处理流程，对于突发重大事件，有专门召集各方联合诊断的UIOC(ugency incident office center)，紧急事故处理中心。而一般事件，我们通过事件管理通道满足用户需求。

多团队合作

UIOC的目的在于快速调动IT资源，高效协同诊断事件，在这个过程中，开发关注应用逻辑、运营关注业务影响、运维关注底层资源、DBA关注数据库。

流程启动的第一步是将大家召集就位。沟通工具、渠道有多种，面对面沟通、邮件列表、即时通讯、视频会议等，不同团队类型有不同的处理习惯。但在事前，我们就应当将这些通道提前建立，并验证随时可用。

UIOC是一个联合诊断、积极配合过程，通常会有一个经验丰富的人员来现场指挥、协调各团队间的工作。

UIOC沟通工具很重要

UIOC六步骤

UIOC流程启动后，如没有统一管理，则很容易陷入到一片混乱中，我们一般会参照下面五点次序进行问题分析：

1.问题描述

启动UIOC后，会对问题、异常进行一个简单描述，如xx系统的xx功能无法使用。

另外，高层会关注业务影响，在这个步骤中，运营人员应当迅速的抽取出业务变化率。

2.应用架构

在问题、业务影响描述清楚后，下一步是系统负责人对应用的整体部署架构进行说明(对于问题所在模块一目了然的这步可省略)。

这个整体部署架构中包括了主要的配置信息、关联方等，其主要目的在于缩小问题范围。

3.版本变更

依据应用架构的输出来判断在这个范围内是否有组件版本发布、基础资源变更。

大部分故障都是由“变”而起，不是外部(访问量、安全攻击)，就是内部(版本、变更)。

该步骤帮助我们发现内部变化，如若找到相关影响对象，可以考虑准备回滚步骤、方案。

4.信息收集

以上三步应当是习惯性地快速完成， 如仍无法准确定位到问题点的话，极有可能陷入到僵持状态中。

信息收集阶段，各团队开始各自挖矿，开发人员查看用户访问量、应用异常日志，运维人员检查基础资源情况，包括性能数据、日志信息，DBA检查数据库等待事件、top sql等，再将各自发现的可疑点共享出来，尽可能形成问题关联，比如存储发现IO延时比较高，请DBA确认是否有影响(不是所有的延时都影响数据库)。