系统管理自测32问之10:有关故障信息报告

译文
运维 系统运维
故障发生之后,你会将各项细节记录下来以便日后查询、还是希望问题随着时间逐渐淡出人们的视野呢?坚持撰写故障信息报告有助于维护稳定的运行环境,每次故障发生后都应拿出至少一套可行的预防性措施。你的监控系统能及时检测出标志性异常,进而使管理者能够先用户一步意识到故障的存在吗?

【51CTO精选译文】本文是《Limoncelli的测试:有助于提高系统管理员团队工作效率的32个问题》当中的第10题:一旦发生问题,有没有一套机制专门用于记录故障信息?

故障发生之后,你会将各项细节记录下来以便日后查询、还是希望问题随着时间逐渐淡出人们的视野呢?

一份合格的故障信息报告中应该包含完整的时间轴,详细记录发生何事、由何人引起、曾如何尝试修复、业务受到了何种影响并具备详尽的解决方案列表,以防止此类问题的再次发生。每项提案都必须在bug跟踪或者项目管理系统中有所体现,以保证此次结论切实改进未来的处理流程。

坚持撰写故障信息报告有助于维护稳定的运行环境,每次故障发生后都应拿出至少一套可行的预防性措施。你的监控系统能及时检测出标志性异常,进而使管理者能够先用户一步意识到故障的存在吗?问题的先兆又是否明确?通常情况下,系统在一切就绪之后会进行整体的带电测试(例如在源代码库中执行‘预提交脚本’)。大家有办法将用于检测新生故障的工具顺利添加到现有系统中吗?

出现问题并不只意味着耻辱或者指责。在良好的系统管理员文化体系中,我们应该毫无顾虑地将自己的名字填在“故障起因”的章节中。作为一名***,我们应当实事求是,力争通过自己的疏忽为其他员工敲响警钟。

如果大家的管理层打算以故障信息报告当做惩罚责任人的证据,那么他们显然还不理解正确的操作并不意味着总能带来理想的结果;这份报告存在的真正含义在于指导大家逐渐提高自身的业务能力。任何一位能够因为非恶意的停电事故就将相关员工踢出门外的管理者,都不可能将企业带向成功的彼岸。

故障信息报告应该派发到每位员工手中。也许大家会因为“披露团队失误”而对此感到尴尬,但实际上这样做会让企业的用户表现出更高的敬意。透明终将带来信任。

当然,要想真正发挥上述作用,故障信息报告与bug跟踪及项目管理系统的整合效果仍然非常关键。

 

【51CTO.com译文,转载请注明原文作译者和出处。】

原文:http://everythingsysadmin.com/the-test.html

Limoncelli的测试:有助于提高系统管理员团队工作效率的32个问题:

【编辑推荐】

  1. 红帽Linux故障定位技术详解与实例
  2. 《Linux运维趋势》第12期:服务器故障排除
  3. 十个Nagios故障解决技巧

 

责任编辑:yangsai 来源: 51CTO.com
相关推荐

2011-09-29 09:41:24

系统管理项目管理系统

2011-09-29 11:09:00

系统管理设计文档标准化

2011-09-30 09:50:55

系统管理服务监控

2011-09-30 10:36:07

系统管理测试

2011-09-29 10:49:39

系统管理Bug跟踪系统

2011-10-19 10:22:17

2011-09-30 09:31:22

2011-09-29 10:39:29

2011-10-20 15:32:07

系统管理访问管理

2011-09-29 10:28:07

系统管理维基

2011-09-29 10:35:35

2011-09-29 10:01:08

系统管理策略

2011-09-29 10:54:11

系统管理优先级

2011-09-30 10:12:58

2011-09-29 10:13:13

系统管理指标量化

2011-10-19 11:01:30

系统管理灾难恢复

2011-10-19 11:17:39

系统管理电源控制

2011-10-20 14:25:24

系统管理账户管理

2011-10-19 10:49:07

系统管理备份自动化

2011-10-09 14:00:23

点赞
收藏

51CTO技术栈公众号