书接上回：
各种事件、事故和问题的发现也应做到主/被动相结合。即：由系统自动勘测主动以多种通讯方式告知相关角色人员和由一般用户或其他IT人员通过Web界面、电话或邮件等方式所被动产生。此处特别值得强调的是Web界面设计或选型上应体现如下特点：
1. 各项条目尽可能的是菜单选择式，并有默认值，这样既方便对提交者进行“提问思路”的引导，也方便系统对后台“问题和知名错误知识库”和CMDB〔配置管理数据库)的自动配对和自动流转。
2. 从系统的投资回报率（ROI）的角度来看，越容易提交就越会被用户所频繁使用，例如仅通过三五步操作便可完成。这样既快捷又高效。
3. 为每一个案子（ticket）都自动设置计时/倒计时，截止时间的功能以方便后期评估。
4. 在系统建立之初，运用传统的“紧急程度”和“影响范围”的二象图，定义并设置各种优先级，影响范围和紧急程度等选项。
5. 预先设置的分类越有条理越丰富，越节约处理人员定位和解决的时间。
6. 设定一些预定义的处理路径并能准确读取系统目录里IT角色信息，以方便案子的自动流转和必要时各部门的联动。
7. 通过类似SOAP（Solution Option Analysis Process）的预定义书写格式来规范诊断和处理人员的工作日志并实现智能的导入数据库。这里特别分享一下哥的一个运维经验：如果在案子的整个处理过程中使用了“受影响的配置项（CI）”和错误代码等方面的信息的话，该案子对于事后查找与借鉴将十分有用。因为问题描述不尽相同，但这些特征字段却是很容易定位的。
8. 案子解决后，能通过邮件的形式向用户发放调查问卷，这样既能获取反馈和满意度，又能为时候的考核与审计提供第一手资料。
可以按照“录入-分类-分级-诊断-处理”的基本原理来设定一个通用流程（参考下图）：
可见，通过设定和规范流程，运维人员的处理步骤和责任显得更为清晰。
