在完成对“每日优鲜”大促的支持后，ucloud服务部门写了一篇文章分享给同事，还给那篇文章起了一个意味深长的标题：“大促的背后，远不止双11”。
在经历了那场规模空前的电商大促“攻坚战”后，ucloud的每个团队，都希望能从经验中提炼出一些什么来。于是就有了服务团队写出的那篇文章。
服务差异化推高竞争壁垒
今天，尽管公有云服务商面对了同样类型的用户，同样类型的应用场景，甚至同样类型的服务需求，但以差异化核心能力为行业赋能却一直是云服务商的追求。
公有云也需要个性。无论是产品性能、价格，还是服务体验，要让用户不离不弃，云服务商总要展示出一些自己的与众不同。
季凯是技术保障平台线技术服务中心的负责人，相当多的时间里，他需要与事业部、研发、运维等部门合作，支持客户重点活动的维护和服务工作。在他看来，再没有什么，能比服务能力更具吸引力的差异化了。
那些客户通常会是大型客户或新客户，也是ucloud“重保（业务护航）”服务最主要的服务对象。这项服务中，季凯的团队会深入参与到以上那些部门的协同中。
在ucloud公司级的重保项目中，研发和技术支持团队都会指派专人值班，并在重要时间段——通常如电商促销活动，或游戏的上线期间提供技术侧支持等。
和人们熟悉的如“双十一”大促一样，游戏公测上线因为“开局即高峰”，提供充分保障的重保服务，已经成为用户必不可少的服务需求。
另外，在如“每日优鲜”那次双十一重保服务中，从9月的资源扩容，到11月的保障驻场，ucloud服务团队整整筹备了3个月。
“从测试到上线，大家用自己热情和能力，诠释了大u服务的价值所在，也从各层面透传了ucloud的良性工作机制与优越的产品特性，进一步增强了客户与我们的互信。”服务团队在那篇文章中写道。
固化的大促保障模式
ucloud服务团队所提到的良性工作机制，对应了一个公有云服务商从前台到后台的“大促保障技术配合模式”。
在该模式下，除基础资源和产品侧的保障外，ucloud服务经理首先深入了解客户大促核心业务，即促销场景中，提前了解到了客户发券量、业务qps等信息。
由于用户的优惠券数据库为1主8从架构，大量的优惠券发放导致系统峰值时数据库插入操作高达7000＋条。因为前期的信息到位，负责数据库的同事将方案调整为“将4个从库挂载到高可用备库”后，大大降低了延迟，最终大幅提升了客户的满意度。
从前线到后台，深度的大促保障技术配合模式就此展开。服务团队从业务架构分析开始，通过日常的各产品基础数据观察，并结合客户预估大促流量及压测情况，来做系统容量评估。
同时，ucloud服务团队针对udb／natgw／云主机／安全等产品的高风险点进行妥善优化和改进，最终确保了活动的平稳进行。
不难发现，对服务体系的统筹规划是这一类服务十分关键的一环。事实上，在如“双十一”等促销高峰期到来之前的更早阶段，ucloud负责售后的技术服务中心就会例行收集各个事业部的重点客户维护列表，通过协调研发、运维、各事业部和产品方等，将项目前中后期服务联系在一起，最终形成服务预案。
这些经验中相当部分都来自于那次“每日优鲜”大促的“攻坚战”。那次战役之后，ucloud在重保服务之下，固化出了“大促保障标准化模式”。之后但凡同类项目，ucloud服务团队会完全按照既定的闭环服务模式为客户提供服务。
这个标准模式涵盖了业务相关的各个方面，大致流程是这样的：客户大促信息收集——客户业务系统能力基线评估——客户大促系统扩容资源预估——ucloud 产品侧风险排查——客户大促业务关键场景／系统风险排查——规避方案——驻场支持——经验总结。
这种服务体系统筹规划的必要性，通常源于客户问题的复杂性本身——大客户的售后问题对应了一个系统性的服务要求。也正是因为这个原因，跨部门的协同能力也已经成为考验公有云服务商服务能力的一项重要指标。
“需要随时跟进，例如进行定期回访和新品同步等工作。”王梦娜就职于线上架构部，以服务游戏客户为主，参与重保服务是她日常工作中的一部分。
当有大客户新项目上线时，她所在部门会推进线上架构师的前期介入、分析优化和资源协调等工作。最常见的问题如技术支持人员不了解客户背景，这时候就需要线上架构部介入处理。
以正确方式应对紧急故障
有趣的是，像线上架构师这样通常作为“售前售后结合”的支持岗位，有时候也会成为客户扩大采购的动因。
线上架构师主要负责从测试到上线以及上线后的维护工作；在项目前期，与架构师配合帮助客户优化架构、提供最合适的解决方案；项目上线稳定运行后，与技术支持配合处理客户遇到的各项问题和紧急故障；并长期与销售合作通过线上线下维护好客户关系。
一个在重保期间的游戏项目，客户发现问题后，将出现问题的ip一股脑地发到了与ucloud进行日常沟通的群组中，并急躁地催促快速解决。收到反馈后，立即将问题描述于内部重保群，这个群里有ucloud的运维、研发、销售、架构师、服务经理和技术支持等众多角色——几乎所有单个客户可能会需要的沟通对象。
“多方排查后，流量、tcp连接数等负载都不高，问题很可能出在客户业务自身。向客户日常沟通群组反馈了结果后，并电话向客户分析解释，耐心引导客户自查”王梦娜回忆说，焦虑的客户在ucloud快速的响应和有效的反馈面前，最终平复了情绪。
按照ucloud给出的建议，那位客户的研发人员进行了一轮自查，最终发现那是一次自身业务导致的“问题”。最终，该款游戏准备在其他地域上线时，这位客户毫不犹豫地选择了ucloud，并提出了明确的要求——提供之前同样级别和水准的服务支持。
游戏客户具有出现问题紧急、线上影响范围广等特点，一般问题都来得特别紧急，对处理问题的人员不仅是技术能力上的要求，对于心理素质也有较高要求。不仅要处理问题，更要以客户能理解且接受的方式进行沟通。
现在，ucloud的重保流程共设定了4大步骤，从前期信息收集、申请重保、各方保障准备和上线驻场等环节，详细规定了服务内容。
在最新版本的流程标准中，为客户经理、架构师和线上架构指定了资源需求评估等多达十余项的特别关注事项，以确保多维度支持的高效率。
从复杂的重保体系中，人们已经可以看见公有云服务商服务体系水准所能给客户带来的价值。不过，重保仍只是ucloud完整服务体系之下“售后4s”中的一款服务产品。
在该服务体系中，还有ucloud著名的服务“铁三角”，以及“cre服务元件”等组件与“售后4s”相配伍。
主动运营的服务才是极致的服务
林万境所在技术服务部门是“重保服务体系”整理和输出的主要部门之一。作为技术服务经理，他是“铁三角”中的“一角”，负责售后运营维护工作；同时，在责任制原则下，协同另外“两角”——客户经理与架构师共同为客户提供本地化的服务支持。
在这个“铁三角”服务中，技术服务经理所承担售后运营维护工作中，最鲜明价值在于“主动运营”。由于能有效地缩小“事前和事后”的风险，这一价值为客户端带来了明显的差异化服务体验。
“解决问题是基础，但我们更关注在故障发生前解决问题；以及在发生后优化问题并确保故障不再发生。”林万境说，技术服务经理会以项目制的形式，为客户做“主动扫描”，包括了解客户业务架构，以及由此去分析业务风险等——在这一点上，技术服务经理的工作内容，接近或包含了具有行业特征的技术咨询服务。
这是ucloud服务体系所追求极致服务的组成部分。林万境认为，所谓极致服务，不仅需要围绕自身产品提供服务，而且需要有确保“用户业务优先”的制度化思考和流程落地。
“只看自己的产品？”他说，“那是不对的。”
