如何量化平台稳定性？——我的运维积分计划

各位运维人员都要处理故障，那大家觉得有没有必要把故障的“量”定义出来哪？

现阶段是无论出现多少故障，我们的内部/外部客户都觉得故障太多，而我凭感觉总觉得自己已经尽力做好了。

如果我们运维水平符合某个标准则某月的工作就是合格，不符合某个标准就是工作不合格，这样多好？

于是我就做一个运维积分计划，通过这个积分计划，我从客户感受的角度把每月的故障率用积分数字统计出来。如果当月积分比上月积分低，那就说明本月比上月平台稳定性有改善；如果我们跟客户约定每月积分不超过100分则为合格，那他们也就没必要在每次小故障后都特别敏感特别激动了。

 

 

接下来我们举一个详细的范例说明技术人员该如何去记录问题积分列表

 

注释1：这个编号是用年月日+01/02/03/04的格式进行记录的，通过这个记录我们可以知道大概故障时间，且将来进行年度排表时编号不会重复。
注释2：在本案例中，虽然我们只用3分钟处理了故障，但故障耗时3分钟，我们登录到服务区耗时两分钟，所以这个故障客户体验到的是8分钟的故障时间。
注释3：在本案例中，因为是网络问题，责任不在公司内部，故障扣分打三折。
注释4：在本案例中，因为是非工作时间问题，故障降级处理，降级后扣分再打三折
注释5：重启tomcat需要超过一分钟的时间，所以故障应该是B级别，但重启作业发生在非业务时段，就降级为A级别，而且提前通知过相关人等，扣分减半后四舍五入仍然是1分。