+

第一，故障防范。

在新零售故障防范阶段，GOC重点关注三方面问题：一是数据运营，二是平台管控，三是日常演练。

首先，看看新零售的稳定性数据运营。稳定性数据主要是围绕业务连续性，一般来说，包含故障情况、处理时长、监控占比、改进落地等维度，然后分析实际数据，出具规范的稳定性分析报告。但具体到新零售业务时，区域门店、智能硬件、采配物流等功能的流畅体验变得尤为重要，因此我们也加大了对其稳定性情况地分析，比如统计故障具体影响多少门店；门店营业期间的故障耗时及占比；故障中多少比例是门店投诉上来的，还是由监控先发现的。

其次，新零售平台的管控。核心产品是ChangeFree，它是阿里巴巴基于数据运营实现变更管控的平台。当新零售业务的故障刚出现时，线下用户刚刚有感知，通过快速回滚就可以进行故障恢复。

这中间有两个关键点：一是，看变更能否发到线上，期间会有一系列的管控，可以通过严格的变更红线来衡量线上变更；二是，看变更到线上后是否符合预期，这是非常关键的。符合预期不是说是否符合变更人的预期，而是指它是否符合不影响线上业务的预期。这是客户最在意的，也是GOC最关注的。比如阿里巴巴中台的某技术团队做了一个非核心的边缘变更，但这个变更通过几层链路的传导，可能会传到新零售交易的核心链路，那么整个线下交易就会被阻塞。在出现这种情况时，如果没有一个好的平台作为支撑，用户很难找到引发这个故障的具体变更。而GOC通过大量的实际案例，以及算法，可以轻松解决这类问题。

最后，日常演练很重要，要把它当作日常的事情来做。特别是对于新零售业务来说，日常演练必不可少。

第二，故障感知。

对于故障感知，GOC有三点心得。

首先是新零售业务监控。业务监控是监控的一种，它与故障等级定义相关联，在保障新零售业务的稳定运行方面特别有用。例如，故障等级定义为当新零售交易量下跌超过5%达到重大业务故障级别，那么一旦发生新零售业务某处量值异常下跌10%，全链路上某些系统稳定性偏低的团队就会比较紧张，怕是自己的原因导致的，会采取措施尽快响应并恢复，否则时间久了，就会发酵成更大的问题。现在，大家都已认同业务监控的重要性，通过大家公认的业务监控，很多很复杂的故障，也能有效集中力量去快速恢复。

其次是全维度监控，即从各个维度，包括在IDC、网络、应用、系统和业务等层面进行监控。业务层面还可以再细分，不是所有的接口都是很“致命”的接口，有些接口的重要性会降级。比如，“双十一”时，会把购物车中是否已收货的状态接口降级，用户暂时不可见，但是不会影响下单和支付。

最后是智能监控，其核心是为了解决报警不准的问题。一般来说，新零售业务刚开始的时候，业务量不太大，但很关键，会出现经常抖动的情况。GOC主要通过智能监控来解决频繁报警的问题，即通过算法计算预测业务的基本趋势形成一条业务基线，与业务实际值进行比较，报警可以只设一个相对于预测基线的水位有没有下跌即可，不仅方便，而且准确。

第三，应急响应。

在新零售运维保障上，GOC做了非常多具有挑战性的事情，比如7×24小时应急。新零售业务通常不会7×24小时营业，但是在非营业期间，往往会有更多的生产环境变更、演练等操作，7×24小时应急可以更好地保障新零售的业务连续性。

现在，GOC已经在美国的硅谷，以及北京和杭州实现7×24小时应急响应。未来，GOC希望在中东或者欧洲也能拥有一支具有快速响应能力的团队，真正实现日出而作、日落而息的7×24小时应急服务。

第四，快速恢复。

对于新零售业务来说，快速恢复是最重要的事情。不管是故障感知，还是应急响应，其最终目标都是要快速恢复。往往快速恢复还有一个误区：不是故障恢复了，业务就自然恢复了，有时故障可以先不恢复，而业务先恢复了。

这其中有一个关键点，就是隔离，隔离后就可以让用户不受影响。因此GOC推出了“一键恢复”，非常方便，在很多场景下，应急响应同学轻松一键，便能快速恢复故障。

第五，故障定位。

故障定位包含初因定位和根因定位。这是一对矛盾。

初因定位对于我们来讲，最浅层的故障原因就两种可能：要么是容量不够，要么就是有变更。这里的变更是指非常广义的变更。阿里巴巴对于变更的定义是集团通行的，即生产环境中的一切操作都属于变更，比如从跳板机登录生产机的操作也属于变更。

GOC对于变更的定义十分严格，很多开发人员并不理解。曾经发生过这样的案例：较早前出现过一次影响面较大的复杂故障，详查原因，原来是有人在线上改了一台机器JVM的参数，产生了连锁反应，影响到上下游很多应用。因此，在实际工作中要“敬畏”生产环境，严格把控。

第六，故障复盘。

故障复盘有两个方面：总结沉淀和措施改进。ITIL中也有故障复盘，就是把导致这个故障的前因后果按照时间序列列出来，并且列出所有故障改进的Action。

GOC会关注故障改进的及时完成率，而不是看完成率。为一个故障推出改进措施时，这个改进措施会影响故障的再次发生，如果及时将故障消除，那么这个故障再发生的概率就会降低很多。如果不能及时消除故障，那么第二天该故障很有可能再次发生。这个风险必须及时消除。新零售业务的很多团队，在每次故障之后能够及时核对和检查改进措施是否已完成，及时发现线上的风险，并将其消灭。

第七，演练验收。

演练验收有一个悖论，每次运营人员问开发人员，优化措施是否完备，得到的答复都是没问题，但故障仍旧再次发生。而开发人员对此的解释是，这是意外情况。

解决这一问题，应该通过演练进行验收，跟进具体改进措施的结果是不是达到了预期。相比于淘宝、天猫，阿里巴巴的新零售业务虽然开展不久，但演练已经做了很多次。

演练验收的一个核心点是，要具备隔离环境的能力，以及完善的演练机制，切实将线上的Action尽快落地到演练中，变成日常性的工作，只有反复演练，才能在故障发生时做到心里有底。通过演练系统，可以很快地落地，并且形成闭环，这对新零售业务团队是非常宝贵的经验。

+