作为双十一购物狂欢季中消费者和物品见面的最后一个环节，快递柜、快递驿站是包裹到达消费者最后的500米，我们的客户就是这个行业的头部客户。客户因被收购，正在进行内部组织调整。
10月20日，接到客户通知，要求公共云技术服务团队进行双十一护航，此时距离双十一第一个高峰（11月1日）仅剩11天，于是我们展开了这次急速双十一护航活动。
10月20日晚，经与阿里云客户服务团队沟通，以目前剩余的时间，并且在不具备压测环境的情况下，客户仍坚持护航。此时每个护航人心中都有一个一定要保证业务稳定的信念，当晚立即对客户生产环境进行了第一次循序护航全链路巡检，深挖客户资源层面问题及风险。
10月21日晚，约定客户进行双方护航的KO会议，客户组织调整后，原来的研发团队和运维团队核心人员已经流失大半，客户已经失去对系统详细了解的能力，这也是客户需要我们急速护航的重要原因。我们针对之前客户的护航经验和积累材料，收集客户业务系统风险，支撑架构风险。当晚KO会议后明确了客户侧护航负责人及后续的工作安排；阿里云同步进行经典网络资源报备。
10月22日，和客户护航负责人电话沟通了相关资源情况，今年双十一购物季是双业务高峰，以往年护航的经验来看，快递柜第一次业务高峰是11月4日、5日，第二次业务高峰是11月13日、14日，客户封网时间为10月31日到11月6日，11月10日到11月15日；我们决定在25、26日进行相关资源的扩容，在28、29日预选一天进行资源兜底扩容。
10月23日，客户根据阿里云技术团队的建议进行核心rancher集群扩容准备，梳理扩容操作步骤和各个集群的业务关系，做好rancher集群业务迁移准备；阿里云技术团队再次核对全链路评估列表，给出扩容建议；双方通过日例会形式同步进度及新发现风险。
10月24日，通过日例会沟通第一批资源扩容协同动作和后续监控情况，并根据客户的业务形态和资源情况编写护航应急预案；沟通近期主业务流程变动情况，判断是否有新的业务风险。
10月25日，客户进行核心ECS资源扩容，并给出扩容后的核心ECS资源列表。
10月26日，客户进行RDS、REDIS资源的扩容，给出数据库层的资源列表；阿里云技术团队配置核心资源的监控大屏，根据监控大屏评估扩容后生产核心业务链路资源的情况，并展开第二次全链路评估，进行底层资源层风险的查漏补缺。
10月27日，通过日例会沟通资源扩容后水位情况，并通过监控大屏对核心资源的使用情况进行监控，针对使用较高的资源进行排查。
10月28日，根据资源排查的情况，进行资源扩容沟通，明确29日进行节前（11月1日）最后一次资源扩容；沟通并确认生产应急预案，生产关键时刻按照方案进行执行。
10月29日，进行第一波业务高峰前最后一次资源扩容，并更新核心实例监控，更新业务大屏；进行第三轮全链路巡检，巡查是否存在比较大的生产隐患。
10月30日，生产风险报表下线，该报表在618护航期间造成大量带宽占用，影响业务下单。
11月1日到11月6日，客户生产环境封网，阿里云进行值班护航，随着双十一正式开始，每天的业务量上升，出现数据库磁盘空间增长过快、ECS内存使用率较高等情况；第一轮业务高峰度过，订单量增长明显，生产运行稳定，生产0故障；但是真正的业务高峰马上就要到来。
11月7日，跟客户电话沟通第一轮业务高峰护航情况，并说明护航过程中发现的业务资源风险点，决定8号再次进行资源升级。
11月8日，客户进行资源升级，阿里云进行核心资源梳理，更新监控大屏，并发出全量核心资源，核查是否有生产资源遗漏。
11月9日，资源核查完毕，监控大屏覆盖全部生产核心资源。
11月10日至11月15日，进行双十一第二波业务高峰护航。
11月11日，通过监控大屏发现客户生产REDIS主实例RT明显下降，该实例正在执行批量的删除动作，紧急拉通客户，确定因生产业务逻辑导致历史数据删除，数据删除完毕后，REDIS的RT恢复正常，双十一护航期间暂停该业务。
11月12日，天猫双十一4982亿交易，打破纪录，我们知道护航即将迎来更大的挑战。
11月13、14日，这两天是本次护航预计的业务最高峰，阿里云护航团队至客户处进行现场护航；业务高峰如约而至，而我们也做好准备，系统各项指标运行正常，快递柜下单，取件、付费流程平稳如常。最终以生产0故障、业务0影响完成了此次急速护航。
作为双十一准备时间最短的护航，经过整个护航团队的通力合作，依然出色地完成了护航任务。至晚上8点，订单量曲线已经回归日常平均水平。

11月16日，针对本次护航我们总结如下：
成功的关键：

1. 第一时间明确了客户侧负责人，并获取客户的信任与全力配合；
2. 通过成都-深圳两地日例会沟通的形式，小步快跑，快速跟进并解决问题；
3. 充分利用以往服务和护航经验，将业务风险点和以前资源评估的结果直接应用在这次护航上，大大缩短了护航的准备窗口和客户环境的依赖情况。

不足之处：

1. 对客户的业务架构还不够清楚，护航中几次资源风险都是该原因造成的；
2. 客户组织架构调整，我们跟客户新的领导层沟通不够充分；
3. 监控大屏仍是基于资源的，没有贴近客户的业务进行从业务到资源层的监控。

最后送大家一个3米高的快递柜，希望里面有自己双十一的战利品，愿所有期待都如约而至。

图1： 大容量快递塔

我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。