方案Action

服务合理拆分，通用服务提炼，减少冗余调度与外部依赖。
资源评估：基于历史经验、当前压测服务性能、未来资源水位预测，评估上报&扩增基础设施资源如容器数(单模块下日常200+机器,高峰扩容)、持久存储、tair、rdb、blink、metaq、精卫等，成本条件允许的情况下，在高峰点至少预留三分之一的负载。
除全链路性能压测和仿真压测外，需对关键节点进行单链路压测，方式如通过pas平台，对于特殊场景可自建压测链路；尽可能参与每一次全链路压测，类同高考前的N模，基于压测结果调整资源和预案。
充分讨论列出每一项潜在风险点，尤其是关键链路，悲观方式准备方可结果乐观，完备的预案(包括提前预案和紧急预案)可从容不迫，如机器重启&磁盘预清理、日志降级、延长缓存时效&缓存预热、非关键链路的定时任务关闭、非大促能力的临时能力停用等多种降级手段。
运行状态可掌控，检查基础监控和自定义监控是否齐全，如eagleeye、xflush、sls、normandy容器运维、各中间件运行状态(如blink、notify、adb)、外部依赖等，关注流量、异常、gc、内存、磁盘、负载等。
关键信息巡检如重保品成本，是否有缺失和错误的数据，缓存与内存的一致性校验、主备缓存预期校验等可防患于未然。
故障切换，假定关键节点依赖均可能发生故障，故障注入演练，关键依赖的切换方案与兜底。
严控变更，变更即是风险点，多时间点deadline，由松到紧，不仅是应用变更管控，还包括中间件管控、系统配置管控、业务配置管控、黑白名单变更管控等。
提高人效：机器人答疑、常规sop、各项运维工具、作战流程，用户自助解决或系统自动化处理的问题尽量不重复投入人力，另对于投入资源的人员需backup。

场景Case

此章节仅选取几个方案细节简介。

瞬时流量

大促整点流量瞬时抵达，风控对实时订单消息即时处理后，立即触发系统决策。
流式批处理选型blink，极小步长内的消息合并。
缓存预热、热点分散、日志降低等方式共同作用。

日志清理

当流量激增且系统日志级别不高时，则出现日志占用磁盘过多导致磁盘利用率过高，进而出现异常如xflush统计失败，scheduleX2任务执行失败，系统响应时间较长。
应急止血如日志升级、sls扩增后，则开始清理磁盘日志。
清理方式选择，先通过诺曼底定时脚本批量清理日志，若磁盘使用率过高至100%，则此方式无法生效，此时使用pgm日志清理。
pgm为内部运维批量命令，申请机器组权限后，跳板机登录后，运行命令示例如下，注意先在预发和安全生产环境操作验证。

pgm -A -b -p 20 `autoget 替换应用名host_spe` "sudo cp /dev/null /home/admin/替换应用名路径/logs/替换占用高的日志文件名.log"
或
pgm -A -b -p 20 `autoget 替换应用名host_spe` "sudo truncate -s 0 /home/admin/替换应用名路径/logs/替换占用高的日志文件名.log"
或
pgm -A -b -p 20 `autoget 替换应用名host_spe` "sudo dd if=/dev/null of=/home/admin/替换应用名路径/logs/替换占用高的日志文件名.log"

清理磁盘时若删除了仍在使用的日志文件(执行了rm -rf操作),需在文件删除后重启机器(释放句柄占用)来恢复资源水位。
若少量机器负载过高，可进行机器置换。
此日志清理为紧急操作，关键是日常治理，如代码删除无用日志、日志分散转移、调高日志级别、日常定时清理脚本等。

BigKey

接口rt过长的突发事件，主要为缓存bigKey问题，加上redis节点流量分布不均、读请求集中且qps高等原因促使。
解决方式为压缩存储，去除大值无用字段，变更缓存读写约定的极限压缩；请求合并，适当降低实时性，时间换空间，引入限流器和延迟队列；主动清理未过期的失效数据；热点数据前置于内存等。

答疑自助

尤其在人力资源不足时需建设此能力，包括运维自助排查工具如单流程各执行状态透出、群机器人插件可将热点问题归类、sop公示等。