经过了前面的各种准备，大促终于到了，在大促当天要关注的事情也是相当多的，需要有条不紊的按部就班的执行。
1.值班安排
大促期间执行、验证、观察的事项还是比较多的，最好是有两个人进行主备，每一件事情最好能够double check，并且做好事项的分工。
2.应用服务器磁盘空间清理|重启
系统在运行过程中通常会打印多种的日志，日志打印的速度要比系统的执行速度慢上不少，如果在打印日志的过程中发现磁盘空间不够用，还需要进行磁盘清理，将老的日志文件给清除掉。这种操作是很占用cpu和io资源，严重的话会把系统夯住，导致请求大量超时。因而在大促高峰前需要对应用服务器的磁盘进行清理，只保留最少量的文件，降低高峰前因为打印日志引发的系统的不可用风险。
对于采用java语言的系统，服务器重启主要是为了释放内存，避免在高峰期发生old区gc或者full gc，使得系统暂时不可用，影响上游系统的调用
3.限流推送和验证
在日常情况下，限流的模式可能是监控模式，在大促高峰期需要设置为拦截模式，避免系统雪崩。
主要是根据线上确切的服务器数量和大促预期峰值，确定单机限流值，而后推送到全集群。推送之后就是验证了，这个验证一方面是单机抽查，另一方面靠系统的监控。
4.预案推送和验证
在临近高峰期前，会推送预案，通常会设置定时预案执行集，这样不用一个一个预案的推送，减少工作量也能统一管理，因而要确保自己系统的预案配置在了预案集中了。
虽然预案的验证工作量相对会多些，但是按照之前确定好的验证list按部就班的验证就可以了，可以做到忙而不乱。
5.监控准备
大促高峰期主要需要监控的事项比较多：error、rt、cpu、load、gc、db、tair、message、限流、下游主要系统等、上游主要系统等，需要根据之前的分工来监控不同的事项。在高峰来临前将对应的监控打开准备好观察，同时web形式的监控因为会涉及到日志的打印、传输、计算、展现等操作，会有一定的延时，因而最好能够打开相应的终端，登录上对应的服务器，使用脚本或者命令实时查看服务器的状态。
6.高峰期观察&应急
虽然前面经历了大量的准备工作和各种各样的预案，我们也期望大促能按照我们的期望来进行的。但天有不测风云，仍然有可能发生预料之外的事情，这个时候更多的依赖系统owner的平时的积累了，综合评估情况在很短的时间内采取应对措施。
常用的手段就是限流、降级、熔断，还有一种就是静观其变，等待高峰期自己过去，具体采取哪种措施要依问题严重程度、是否会持续等来综合评估，别人都是旁观者、建议者，真正能做决定的就是系统owner，要为决策负责的也是系统owner，也真是这种决策的压力促使owner成长。
如果没有预料外的事情发生，就静静的观察监控，分析思考高峰期的种种现象。
7.大促数据记录
这次的大促是对前一段工作的检验，也是下一个大促的起点，这次大促高峰期的各项数据将会对下一次的大促的准备提供非常好的基础，因而要对大促期间的数据做好记录并备案，供以后进行分享参考，记录的数据主要有两类：
1）高峰数据，了解各种峰值
2）全天数据，了解全天的变化
8.预案、限流回滚
当大促高峰或者活动结束后，通常会把之前推送的预案和限流进行回滚。回滚通常也是配置在预案集中的，进行集中的回滚。回滚的时候同样要注意观察，特别是上游降级预案的回滚，很可能是会导致自己系统的调用量猛增，相当于又来了一次高峰，千万不要因为大促过去了就掉以轻心，在最后的关头出故障。