故障预案

会议已经开完，并且梳理出下列几个方面的规划：

1. 事故处理预案

   从最近几次事故看，我们业务是被动型业务且行业用户量不大，自身很少出现高负载，基本上是恶意访问。

   故事故发生时按照下列步骤快速响应：

   (1) 预先建立运维、新房、二手房、基础部应急处理群

   (2) 有事故发生第一时间通知各负责人，各负责人必须第一时间召集本部门人员进行停止所有工作进行处理；

   (3) 检查GW入口网络各项负载指标 -- 运维负载

       - 分工：专人负责盯监控，专人负责运维操作，实时喊出监控变化和所作操作

   (4) 个业务负责人检查各业务状态 -- 个业务模块负责人 

       - 专人负责检查服务器负载，定位异常服务

       - 每个模块负责人报出自己模块的访问量(Throughput)和响应时间(Latency)情况，平时应该多少，现在是多少。

   (5) 15分组后未定位问题，必须采取强制措施

       - 封IP  -- 运维

       - 暂停服务 -- 个模块负责人

       - 重启DB  -- 运维

2. 运维监控告警

   我们目前的事故都是靠线下反馈才知道，缺乏有效及时的监控预警机制，因此监控和告警非常重要。

   下列监控和告警须先做起来。

   (1) GW入口网络的IP段频繁访问告警

   (2) 连接数告警

   (3) 数据库告警 (已有-Review完善)

   (4) 各服务器负载告警 (已有-Review完善)

   (5) 业务层面告警 (业务部门配合开发，下周一前给出时间点)

2. 业务层面优化

  （1）监控：每个业务需监控

       - Throughput

       - Latency

       - 错误率

   (3)其他改进

       - 日志规范

       - 压力降级

       - 告警

3. 安全认证

   (1) 我们的APP有被模拟嫌疑，我们需对自己的APP接入进行认证 (你采用亚马逊AWS方案****给出方案，并进行培训 - 下周三)

   (2) Web安全认证待讨论 - 请其他人给出方案。