今天网上问题爆发，一天内接到5个局点现场反馈的问题，不是告警收不到就是性能不达标，或者设备告警状态不对，很是烦恼。静下来想想，为什么我们会有那么多网上问题？难道是我们的质量太差导致事故频繁，我看也不见得。网管告警系统是一个什么样的系统，为什么我们会如此困难？我想，这可能和告警系统本身的特点决定的，并非我们这个项目组人员能力就比其它模块差一节。告警系统的主要特点有下面三点：
1） 高稳定性要求，在全天候运行过程中不能出现哪怕一丁点的错误，任何小的数据状态错误，都能很容易被用户觉察到。
2） 高动态性。在网管运行的过程中，多达5000台设备会不断向网管发送Trap告警，速度基本是每秒300条之多。这么多的数据，在通过相应的动态苦解析后，进入故障子系统的处理流程，这里的数据交互非常频繁，在解析，入库，转发，上报等一系列的流程中都不能出任何错误。如果某一时刻，系统资源不够，cpu，内存紧张等，难免会出现各种异常情况。
3） 和周边系统的高度依赖，数据交互频繁。告警是网管的核心子系统之一，它需要将收到的告警信息有选择地向北向接口，拓扑字系统，产品业务模块等转发，计算各个设备资源的告警状态等。这里一旦出现数据消息丢失，错误很容易出现。
从前面收集到的问题分类来看，主要几种在以上三个方面，我们该如何解决目前的困难？
我主要想到以下几点解决思路，故障系统如此复杂，那么难道就没有办法把它做到稳定，高效，不出错，从软件设计的角度来解决这个问题。我想是可以的，而且是完全可以达到的。
主要从以下几个方面进行着手：
一是：故障系统要把各个处理流程进行整理，设计成几个大的核心模块，功能内聚性强，模块之间有清晰的接口定义。
二是：故障子系统和周边系统的接口要清晰，数据的交互要有实时日志信息可查，保证出了问题能够很快从日志定位出具体原因。
三是：整个模块的日志输出要采用单线程处理，所有线程，功能模块中的日志输出都仍到这个专门的线程来处理，避免资源冲突，日志信息的时序正确。
看了程朝晖的博客里面的一句话，很受感触。原话是这么说的：“在软件的世界中，一个系统的实现是由多个子系统，到模块，到功能函数等不同的级别而组成的。其实与我们的管理组 织非常的相像。父模块在调用子模块时是非常清楚子模块能实现的目标，并且子模块可以自我控制。应该说，在企业中每个岗位和人都至少是一个自我管理者，几个 子模块子功能组成了功能更强的小组，再组成部门，再到公司。如果公司中存在很多不能自我管理和负责的岗位和人，那么这个公司的效率是非常低的，因为别人必 须来补这些岗位的缺失，并且存在很多的风险。在软件中如果运行到的任何一个再小的模块出问题，整个系统就会出问题，甚至于瘫痪。”我想如果我们的软件设计到这种程度，那么上面的这些所谓的困难，其实应该是不存在的。
