对于移动技术来说，2017年是继往开来的一年。一方面，移动技术领域进入深水区，另一方面，移动技术的边界和内涵也在不断被重塑。阿里巴巴希望进一步推动移动应用研发事实标准的落地，为全行业的开发者赋能。在2017杭州云栖大会上，蚂蚁金服资深技术专家朱光分享了蚂蚁金服移动端在高可用技术方面的具体实践。以下内容根据演讲视频和PPT整理而成。本次分享的内容主要分为以下四个方面：亿级APP易用性挑战APP在线运维开发演进亿级APP易用性挑战易用性的概念很简单。可用性是指当用户想要使用一个应用程序来做某事时，做了就可以用，没做就不能用。为什么没有成功？可能的原因有很多，比如使用APP时可能会闪退，或者使用支付宝支付时，后台某个环节出错导致支付失败等，这些都可能导致APP无法使用。如果各种不可用情况都没有出现，那么它就可供客户使用。虽然每个开发者都希望自己开发的APP是100%可用的，但现实中这是不可能的。所以开发者真正需要做的是让APP越来越不可用。亿级APP的可用性挑战目前APP开发技术已经比较成熟，所以很多开发者会认为自己的APP可用性应该不是什么大问题，因为APP经过了相关的测试程序、灰度验证和其他保障措施。但是现在情况发生了变化。和以前相比，APP的用户量大了很多，很多APP的用户量都达到了1亿，所以一点点的可用性问题就可能影响到大量的用户。比如APP的闪退率提高了千分之一。虽然这个比例不是很大，但是对于一亿用户来说，乘以千分之一就是十万人。你可以想象，如果有一天你在超市用支付宝支付，10万人出现闪退，那影响是绝对不能接受的。现在手机APP的开发讲究动态，业务要求实时动态在线变化。可以说，今天的支付宝与昨天的支付宝大不相同。每一次上线改动其实都增加了上线可用性的风险，而且一天内可能会有很多次改动，这种情况下风险会变得非常大。尤其是保障APP可用性的一线人员，压力会特别大。正是因为存在如此多的问题和挑战，才有必要通过移动端的高可用技术体系来解决这个问题，以保证在线客户端的高可用。APP线上运维的发展演变，如上图所示，是支付宝客户端这几年在易用性运维方面的发展历程，大致可以分为三个阶段。随着支付宝的成长，可用性运维也在不断进化，***进化到了移动端高可用的状态。第一阶段是简单的闪回监控。绝大多数APP也都这样做了，就是在本地收集一些闪退信息并上报，在APP后台监控闪退率，解决闪退较多的问题，并在下个版本做相应的修正app的修改，***让闪退率保持在某个指标以下。但是现在来看，这个阶段离实现高可用的要求还很远，因为闪退只占用户遇到的不可用问题的一部分，所以在可用性方面，解决闪退问题只是一个小小的提升，还有大部分问题没有解决。第二阶段称为阿里巴巴内部的稳定性监控系统。与第一阶段相比，稳定性监测系统可以说是向前迈进了非常大的一步。首先，可以监控的问题大大丰富了。通过对各种问题的监测，我们可以了解在线用户在稳定性方面的可用性，而不仅仅是一个用户。第二方面，稳定性监测系统具有相当程度的诊断和修复能力。当发现问题时，可以通过诊断日志等相应的方法分析故障原因并尝试修复。稳定性监控系统一开始效果很好，阿里巴巴内部也用了很长时间，但后来逐渐出现问题。举两个例子，一个版本的APP在X86的机器上运行时出现了很多问题，但是那个机型的用户量很小，所以很晚才发现问题。这个问题是通过监控发现的，也就是说，因为监控的只是具体的问题，所以已经无法发现某些人的问题了。第二个例子，在做双十一这种大促值班技术支持的时候，因为监控问题比较多，需要运维人员通过不断的翻监控来发现问题。我不确定APP的可用性是否有问题，有时确实会遗漏一些问题。第三种方案，发现问题后，能否快速修复，还是需要运气。可能很快就修好了，也可能不好修。你需要等到下一个版本，这使得一些问题受到影响。用户数量会非常庞大??。以上就是2.0阶段遇到的问题。这说明稳定性监测体系还不够完善，需要完善。这也是支付宝在3.0阶段继续做移动端高可用的动力和动力。移动端高可用的定义、目标和核心策略移动端高可用的重新定义高可用本来是属于服务器端的概念，阿里巴巴的服务器端都在讲高可用。服务器的高可用侧重于停机时间短，服务不可用时间短。移动端的高可用是从服务端借用后重新定义的，因为客户端没有宕机的概念。因此，移动端高可用的定义是指通过特殊的设计和一套完整的技术体系相结合，保证用户遇到的技术不可用的总数非常低。移动端高可用的目标简单来说，移动端高可用的目标就是达到99.99%的可用率。这里的可用率是支付宝自己定义的一个概念。其中，可用率达到99.99%。这意味着用户使用支付宝的10000次中有9999次是可用的，最多只有1次不可用。为了实现这个目标，任务也会拆解成不同的子目标，分别去克服。在移动端实现高可用这一游戏核心目标还是比较困难的，因为要达到99.99%的可用率是一个非常高的指标。为了能够努力实现这个目标，支付宝还打造了核心玩法。主要分为以下四个部分：客户端可用性监控。当用户遇到不可用时，必须收集和报告导致不可用的问题，并提供足够的诊断信息以供分析和解决。高灵敏度的监控报警平台。需要注意的是，当线上问题刚刚出现时，是可以第一时间发现的。快速修复能力。当发现问题时，不仅要保证能够修复，还要保证修复速度足够快。对于一些高级别故障，支付宝要求一个小时内快速修复。故障演练。支付宝在移动端的高可用技术实践如上图所示，是支付宝实现的移动端高可用技术架构图。可以看到，支付宝移动端的高可用技术架构设计也是围绕着以上四个核心策略展开的。客户端可用性监控问题收集客户端可用性监控的第一步是问题收集。当APP变得不可用时，它必须能够感知和收集问题。如何保证在用户不可用的情况下也能收集到问题？这个比较难，因为我们不能保证能收集到所有类型的不可用问题，但是我们还是会尝试通过各种方式做到全面覆盖。支付宝将不可用问题分为两个方面：稳定性不可用和业务不可用。对于稳定性不可用问题，通过2.0阶段的逐步探索，以及各种反馈渠道和问题收集渠道的补充，目前已经可以收集各类稳定性不可用问题。比如传统的闪退、卡顿等，还有黑屏、白屏、不易监控的非闪退异常退出等。到此为止大部分题都收集到了，当然可能还有遗漏的地方。对于这些遗漏的问题，需要不断收集并添加到系统中。对于业务不可用，在开发过程中会埋点业务不可用问题，通过将业务不可用埋点纳入系统，可以基本覆盖最重要的业务不可用问题。统一管控问题收集后，需要通过统一管控形成客户端可用性指标。通过这个指标，你可以综合评估某一类人群的在线可用性，而不是像以前那样一个一个地去检查每一个指标，最后给出一个不太准确的评估结果。通过统一管控，可以设计整体的监控告警机制和多种算法模型，其扩展性更好。埋点上报埋点上报功能是非常核心的，因为以后要利用不可用的埋点做高灵敏度，所以对埋点的实时性、准确性、到达率要求特别高。而对于不可用的埋点，需要在客户端已经变得不可用的时候上报，而此时客户端的情况很可能非常糟糕，甚至客户端此时可能无法启动，即便如此，也要确保埋点可以上报。为了实现这一点，我们使用了一些技巧。比如对于Android系统，支付宝通过一个独立的轻量级进程单独上报埋点。即使主进程死了，埋点也能实时上报。对于iOS系统，采用onlinehold流程，让它在退出前上报埋点，后续有补偿机制，即使埋点漏了，最终也能上报。通过问题收集、统一管控、埋点上报，基本保证了用户遇到不可用的问题时，可以收集问题上报给服务器，为第一步打下良好的基础。高敏系统模型采集到问题时需要使用高敏系统模型进行监控告警。监控告警在2.0时代就已经存在。例如，当市场上监控的闪回率异常时，就会发出警报。但高灵敏度系统模型需要做的是在线上问题刚出现时就发现，而不是等待市场出现波动。因此，这个模型的关键在于分析和决策的过程。它会根据用户人群和问题的特点，对网上收集到的不可用问题进行聚合分析，通过一些预制的算法模型和规则来判断是否存在问题。异常，如果最终判断确实有异常，则输出异常事件。比如线上业务新发布H5离线包版本，其中一个页面卡顿率很高。那么使用这个页面的用户就会形成一个特征组，这个特征组的页面卡顿率就会出现异常波动，此时就会输出异常事件。但此时行情并没有太大的波动，因为特征群体的数量并不多，但可以在后台捕捉到异常事件。异常事件输出后，可以通过附带信息准确匹配到相应的负责人和开发测试人员。报警系统会通知负责人进行处理，并会根据问题的严重程度采用不同的报警方式，可以通过邮件、钉钉、电话等方式进行报警。在非常严重的问题情况下，如果几分钟内没有反应，就会有人打电话给负责人。通过这样的告警机制，可以保证无论什么时候，只要线上出现异常问题，都能被快速感知到。高可用容灾平台通过以上内容，我们已经可以实现对可用性问题的感知。接下来分享如何通过高可用容灾平台修复异常问题。这个通过整个故障恢复流程来分享，如下图，当有故障进来的时候，会向相应的负责人发出告警。这时候负责人就需要检查故障是怎么产生的，是否是由于线上改动导致的，是客户端本身的BUG导致的。如果是线上变更引起的，就比较容易处理，因为现在的系统比较敏感，一旦出现故障，负责人可以在短时间内收到告警。之后可以去发布记录查看这段时间发生了哪些变化，可以快速基本了解是哪些变化导致了失败，并采取相应的处理策略。能回滚就回滚。如果无法回滚，则需要紧急释放。如果无法紧急发布，则需要依赖客户端修复。更麻烦的是与变化无关的情况。这时候就需要通过异常携带的诊断信息或者获取一些日志来排查问题的原因。有时问题的发生是因为兼容性问题。比如某厂商发布了一批灰度不兼容支付宝的系统，导致出现各种问题。这种情况下，就需要通过动态修复来解决。也有可能是部分客户本地出现严重错误，比如一些脏数据，或者安装时由于市场暂时性的bug导致大量安装失败，最终导致支付宝打不开。这种情况下，可以通过本地容灾做一些恢复工作，进而实现客户端的自动恢复。总之，通过以上过程，故障就可以解决了。从下图可以看出，支付宝在高可用容灾上致力于两点：希望每个故障都有相应的方法来实现修复。希望过程尽可能清晰顺畅，希望不要在过程上浪费太多时间，尽快解决故障。高可用动态修复系统移动端高可用与服务端高可用的主要区别在于移动端发布难度更大，需要依赖动态修复技术。动态修复并不是一个新概念。hotpatch等技术已经非常成熟，目前有很多可选的动态修复方案。不过hotpatch虽然是高可用动态修复系统中的一个重要点，但并不是最重要的一点，因为它也有一定的局限性，有时并不适用。目前，支付宝已经构建了基于多种修复方式的高可用动态修复系统。支付宝高可用动态修复系统主要由以下三部分组成：修复方式修复方式有很多种，有轻有重。轻方式可以通过在线进行一些配置来解决线上不可用的问题，重方式可以完全重新部署整个模块。选择哪种修复方法要根据故障的情况，选择效率最高、风险最大的修复方法。分发渠道有点类似于上报埋点的需求，同样要求实时性高，可靠性高。当用户不在了，常规方式无法拉取在线修复方案的时候，再多的解决方案也没有用，所以需要保证再糟糕的情况下也能拉下修复方案。实施分销渠道的方法有很多种。最后只要能连上网络，就可以拉下修复方案。如果暂时无法连接网络，则必须在连接网络后下拉修复解决方案。发布平台设计动态修复的发布平台最需要注意的事情之一就是把修复方案推送给真正需要的用户，也就是把修复方案推送给已经体验过或者可能有这个体验的用户问题。之所以这样，是因为每次动态修复其实都是在线更改，也是有风险的。如果是推送给所有用户，需要很长时间灰度来保证安全，但是如果只针对小众人群和特色人群推送解决方案，这样灰度时间会很短，修复时间也会要短。当客户提出报修方案时，支付宝会根据客户人群的特点，是否出现过该问题，是否可能出现该问题，判断是否向其推送报修方案，以便快速完成推送过程.图中这叫“智能修复”，更准确的说法是“定向修复”。高可用实战经验这里给大家分享两个支付宝高可用实战案例，一个比较成功，一个不是很成功。案例一：商家推送了错误的菜单配置，但客户端没有得到很好的保护。操作推送配置后10分钟内，相关负责人接到告警，很快查明是这个配置引起的。之后，该操作将立即回滚配置。这个过程影响的用户比较少，所以是一个比较成功的案例。这也是支付宝最期待的运维流程，实现及时发现、快速修复、受影响用户少。案例二：大促期间，商家开启限流，客户端弹出限流页面。本页面存在bug，会导致黑屏，导致用户无法操作。但由于当时可用性监测不完善，没有监测到这个问题。只是因为有用户的反馈，我们才知道有问题。到问题出现的第三天，反馈的数量已经累积到一个显着的水平。刚发现这个问题。之后我们迅速分析解决了这个问题，最终定位到了限流的问题，在一个小时内确定了问题所在，暂时先关闭了限流，之后修复了这个bug。然后开启限流，这样客户端就恢复正常了。虽然最后完美解决了问题，但是这个过程却有非常明显的破绽。首先是它发现得太晚了，因为没有涵盖可用性问题。此外，由于信息不充分，决策过程相对缓慢。分析需要1小时才能止血。到现在为止，我们不知道这三天有多少用户受到了影响，但这件事肯定会对支付宝的可用性造成负面影响。造成了很大的伤害。但是现在，支付宝已经实现了移动端的高可用，以后不会再有这样的事情发生了。当出现故障时，支付宝第一天就能在很短的时间内解决问题。故障演练中有一句话叫“避免故障最好的方法就是不断地进行故障演练”，所以我们要在可控的成本下在线模拟一些故障，进行故障演练，测试高可用系统是否可靠。相应的学员对系统、工具和流程更加熟悉，真正出现问题时能够快速处理。为了更好地测试这套东西，支付宝采用了攻防对抗演练的方式，组建了虚拟团队。他们会想办法模拟线上可能出现的故障，而另一组则利用移动高可用性技术连接Move，快速处理对方开发的问题。经过这样的准备，当真正的故障需要处理的时候，我们已经能够熟练地处理了。前行中探索***说说客户端易用性运维未来的思考：智能化上面提到的高敏模型，可以看到决策过程往往需要依赖预先设定的算法模型、规则和数值等等，这些都是从这些年积累的经验中推导出来的。但也有一些缺点：第一，可能存在误报；第二，为了防止误报太多，这个模型不敢弄得太紧，所以模型的灵敏度是比较敏感的，不是特别敏感。我们期待通过人工智能和机器学习的方法，将决策过程智能化，可以变得更灵敏，发现问题的时间可以再提高一段，这在目前不仅仅是一个想法。支付宝已经开始在很多场景使用智能报警了，我们也在调研尝试接入这个东西。这部分自动化主要是指容灾过程的自动化。我们想让上图的容灾过程顺利进行，但是很多步骤需要人来完成，所以时间成本和决策成本会非常高。因此，我们希望尽可能多的步骤自动化，至少是半自动化，让容灾过程更顺畅，让恢复时间大幅跨越。对于产品化，我们希望当客户端的可用性更加成熟的时候，可以赋能给其他类似的APP。通过这个过程，我们可以积累更多的经验，发现更多的问题。并且在未来合适的时候，或者当3.0版本的客户端可用性不能满足需求的时候，我们会搭建一个4.0可用性的运维系统。
