会议已经开完,并且梳理出下列几个方面的规划:
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安全认证待讨论 - 请其他人给出方案。