感悟---故障级别应该怎么定？

作为一名运维工程师，难免会遇到各种各样的，大大小小的故障，说起这个故障，什么样的异常情况就构成了故障，就如同犯罪一样，什么样的行为构成犯罪，可是作为服务性质的互联网电子商务平台,以什么样的标准来评定呢？跟钱挂钩还是跟服务质量挂钩呢？这两者绝对不等同,一分钱都不影响，一天不能提供服务到底哪种算故障？

2013年1月5号，21:30接到一个产品工程师的电话说，有故障了，需要协助恢复
然后技术支持创建临时讨论群召集相关技术人员确定故障点，以及恢复操作。其级别确定为3级，这个级别应该算很普通故障的级别

过程是这样的
1.1 13:30变更完，由于应用的特殊性，在办公室的网络里测试都是正常的。（那就坐等投诉吧）
    其实团队中的其他人可不止一次有这样的问题，莫非人以类聚？？哈哈，开玩笑，还是继续说故障过程吧。
1.2 下午15：30又变更了一个，跟上一个是关联的，只是这个变更影响的范围比较大，自己下意识的斟酌了一会，前思后想，理清思路了就处理了，结果到晚上20点30 微博上陆续有人抱怨说访问***异常，公司内部人有看到的就下意识去试，毕竟是自己公司的应用，不试则罢，一试果然尴尬了，就开始找相关责任人，看是不是自己网络问题还是个别点的问题
1.3 到21:30 才定位是IP地址ACL问题，一个对公网服务的应用，竟然ACL权限是只针对办公网开放
1.4 如果遇到网络ACL的问题后，到底应该怎么去恢复才算最快，或者影响最小，如果要我是这位产品工程师，肯定第一时间是恢复最后一步的变更，可他的思路却是补充ACL漏掉的部分，其实遇到每个问题后都是不同的可是接到通知就赶紧恢复吧

从故障各个点来看，第一反应就是产品工程师的问题，这个问题很明确，让变更人或者网络的人替你判断应用需要的ACL权限，那很不现实，所以有多少SA，NA都不够使，因此他们不是一个合格的产品工程师，是一个纯发布工程师，有问题时找开发，有需求发布时，赋权限给开发.就这样的运维工程师反而会给填麻烦，毕竟多一道沟通环节。那么应该怎么做呢？我觉得应该具备冷静的头脑，全面分析问题的能力，还有学习业务的能力，不要做一个纯技术的产品工程师

还有一个点就是故障级别定义，记录故障的属于A部门，参与确定级别的是B部门，造成故障的A部门，而且B部门项目的任何进度起决定性作用的都需要看A部门产品工程师脸色，高兴就配合好点，那不高兴自然就......像这种错综复杂的互相牵制，怎么能公平的对待一个人员失误而造成的损失呢

就拿这个故障来说吧，从中午1点半到晚上9点半，而且在微博上都有人叫唤了，应该定成什么级别呢？或者说应该怎么定义，谈钱？一分不少，谈重要性，那自然不用说，谈时间，8小时，那该怎么定义呢？到现在为止还是摸不着头脑呢！

比如发布一个应用或者是新的项目上线，作为产品工程师需要考虑的以下几个问题，
1，新的项目上线需要什么样的架构来支持，其实在开发的前期就需要 沟通清楚，这样有充分的时间准备硬件、软件环境的测试支持等，在开发的同时，自己也需要把环境部署完成，包括环境的测试来验证架构是否合理，或者产生瓶颈 的地方,这里包括程序运行软件环境的各个版本号，以及通用，可移植性
2，等到产品真正发布的时候需要拿到一些数据来保障应用正常的运行，压力测试结果，业务量评估数据，以及功能测试报告是否符合预期
3，后期维护相关的工具开发，包括应用的监控点，服务器资源，日志管理等
4，不是项目上线完成就万事大吉了，要做个有心人，去看看这个应用之间的调用关系，一般配置文件中都会有配置的，这样把这个应用理顺后，画出来一个完整的调用关系图。等到有告警的时候，你始终会领先一步判断出来故障点的。

本文出自 “champion” 博客，谢绝转载！