，可以做到分业务、分服务(更细粒度)等等;复杂的方法在模拟数据的基础上，可以把事件系统记录的时间数据拿过来作为评估的标准。另外可以把可用性上升到质量层面，这个里面涉及到的评估维度(成本、用户体验、满意度)就更多了，数据获取的来源也变得更多，有些是来自于客服系统，有些是来自于舆情监控，有些是来自于运维容量系统，有些是来自于事件系统等等，不过最终呈现的指标就是一个---质量。

运维的数据看板，最好能变成产研侧KPI的一部分，同时在运维和研发侧，需要周期性的把这份数据推送到他们面前。有了KPI，同时有了持续滚动机制，一定能建立起很好的业务质量意识。

一直觉得，数据文化，是运维能够建立影响力的重要一步，否则你就是一个支撑的支撑部门!

2、故障发生前，设定技术准则和要求

运维需要和研发建立整体的技术标准和规范要求，这块是腾讯做得非常好的地方，把海量服务提炼成多个关键词【海量服务运营之道】，网上可以搜索到。当然这些关键词对于很多企业来说，想理解准确，也会非常的困难。因此从运维的角度来说，我们需要设定一个路线图，最终服务于这个技术目标。比如说之前我提到的【运维三部曲】里面讲到了先做标准化(修炼运维内功)，然后做公共服务化(修炼架构内功)、最终服务无状态化(修炼业务内功)。

运维一定要把标准化作为核心要务来推进，建立标准化的运维环境，建立标准化的技术栈(和研发确定)，建立标准化的高可用方法论，最终这个业务的可用性一定是有保证的。

3、故障发生时，恢复是第一要务

故障发生的时候，“恢复、恢复、恢复”必须是运维人脑子里面要时刻记住的。

在故障的当下，定位故障原因是大忌，这往往让故障时长变得不可控，因为会直接影响MTTR(平均修复时间)，影响用户的业务使用。不过有人会有疑问，不知道故障原因怎么知道如何解决?从经验来看，你一定有一些简单粗暴的原则去隔离故障，比如说服务器重启，链路禁用，DNS切换等等。

4、故障发生后，仔细的复盘

每一次故障发生后，运维人需要牵头去复盘故障，刚刚说了我们恢复是第一要务，所以故障的根本原因我们可能还不知道，此时就需要运维、测试和研发一起仔细的去看整个的故障过程，看看到底哪儿有什么问题?基本上也是从刚才说的四个方面来评估。不断的审视我们运维的能力和IT的能力，说“故障是运维最好的老师”的原因也在于此，它能够不断驱使我们走向更高的成熟度。

运维是复盘的首要负责人，复盘是为了找到根因(Root Cause)，根因和故障现象不同，举个例子，故障现象是交换机故障，根因是因为技术架构没有对交换机故障做到容错，根因是运维对这种故障缺乏有效的临时应对机制。

复盘是为了让我们走向更好的运维阶段!

5、故障发生后，复盘措施有讲究

故障复盘后，我们一定会写改进措施，对于这些改进措施，还是有些讲究的，看过一些故障报告，非常的不合要求。我个人的经验如下：

故障的措施必须是可落实，且具体的，要落实到具体的负责人，具体的时间

故障的措施优先是必须技术的，然后是流程，最后是人的

故障的措施可以分为长期措施和临时措施

故障的措施一定要仅仅扣住故障的根因，避免流于形式和表面

故障的措施切忌“亡羊补牢”式的，需要全面细致的分析

故障的措施一定要保证后续的持续跟进

一叶可以障目，但也可以一叶知秋，就看我们是否真的去认真对待。你们真的重视故障了么?你们真的重视运维了么?故障不能带来运维人的春天，从根本上去意识到运维的重要性，那才是运维人真正的春天。