二、 集群运维Flink Cluster
• 一方面，Flink平台上运行着一个非常典型的业务，就是双11大促当天GMV媒体成交翻牌器，也就是家喻户晓的成交额大屏，这个业务对于稳定性要求非常高。除了GMV翻牌器，Flink还承载了阿里内部全部重要的实时计算业务，包括阿里妈妈、广告计量计费、搜索推荐、机器学习平台等核心电商业务的实时场景。这些实时场景既重要又实时敏感，稳定性是第一大挑战。
• 另一方面，由于平台规模体量巨大，涉及到几万台独享机器，多地域的部署，平台体量增长带来的平台复杂部署度的增加，所以局部异常又会成为常态，这是对稳定性的第二大挑战。
业务重要又敏感、平台规模体量大且架构复杂，面临这样的双重挑战，如何去维护集群的稳定性是一大难题。
一开始Flink集群是用故障数来度量稳定性的，但实际上粒度很低，因为有很多未达到故障时长标准的稳定性异常是没有办法在最终的故障数中体现的，导致稳定性存在着盲区。后面我们就打造了几套基于分钟级可用率的SLA可用率来度量整个集群的稳定性。
SLI是用来计算SLA的黄金指标，它代表着Flink Cluster的可用性，因为集群是一个虚拟的逻辑概念，所以我们定义了Flink作业状态来代表SLI。Flink作业状态本身非常复杂，但是我们可以简单抽象出三种状态：调度中、运行正常、运行异常，每个作业都能计算出这三种状态，然后汇聚到集群层面形成作业的比例，一旦异常的比例超过某个阈值，就代表集群不可用，从而度量出SLI再算出全年的不可用时长。
最终SLA的可用率度量可以表示成一个简单的数学公式，SLA可用率=SLA异常数*SLA平均每次异常时长，来实现分钟级可用率精细度量衡集群稳定性。
有了精细的量化，接下来就是提升的路径，也可以从上述公式入手去优化两个因子：分别是既做好稳定性的预防，来减少SLA次数；同时也做好了SLA的快速恢复，缩短SLA时长，最终提升整体的可用率。
首先是SLA异常预防部分，关键的思路是做好集群的巡检，主动发现异常隐患，及时消灭隐患，从而减少SLA异常的次数。
导致SLA异常隐患有哪些？比如一堆超大作业突然启动，导致集群几百台机器load打高或者磁盘打满，引发大量作业心跳超时；再比如说某一个Flink版本存在重大的稳定性问题或缺陷，影响了线上近千个作业。这些看上去很冷门的故障场景，实际上在一个超大规模的集群里和丰富的业务场景形态下几乎每天都在发生，这是平台发展到一定规模必然会出现的挑战。而且集群规模越大，越容易出现蝴蝶效应，影响面往往更大。此外，每次集群异常定位的复杂度和耗时都非常久，如何去消灭这些SLA异常？
我们的思路是打造一个Flink Cluster的异常自愈服务，通过定期扫描线上全量作业的行为数据比如作业的延时、Failover、反压，然后对这些海量数据做异常分析和决策找到隐患。总的来说可以分为两大类异常：
• 一类是由于用户侧自身作业行为导致的，通知用户去更改相应的作业，比如资源配置不合理导致OOM、作业反压导致延迟等。
• 另一类异常是由于平台侧问题版本导致的，平台侧会进行大规模的主动升级来消灭这些问题版本。
最终在平台侧和用户侧双管齐下，形成SLA异常自愈的闭环，从而减少SLA异常次数。
在异常自愈服务里，其实最复杂的是背后规则的识别和决策。经过大量的积累，我们沉淀了几十种业务侧最高频的异常规则和治理方案，来全自动化地识别和消灭之前“看不见”的隐患，真正做到稳定性预防。
根据SLA异常的公式，除了预防来减少SLA次数，另外一个手段就是缩短SLA发生后的异常时长。
挑战在于线上一个集群就有近万个作业，但凡是集群级的故障都表现为定位困难、恢复时间久，再加上集群数量众多、分布广，故障的概率又增大，两者叠加，一年发生几次故障几乎就成了常态，稳定性整体很被动。我们需要转被动为主动，如果能在故障场景将业务的快速切流做到集群级的容灾能力，SLA异常恢复不仅能够缩短，而且还能增加其确定性。
容灾体系主要分成三部分：
• 第一，是往哪里切，实时计算对于网络的要求都是毫秒级，跨城有几十个毫秒肯定无法满足实时的要求。所以在平台侧部署架构上做了计算同城双机房部署，两两容灾，互为主备切流布局，解决了故障场景有地方可切。
• 第二，资源容量是有限的，平台这么大的体量不可能有容灾资源做预算，所以就需要做取舍。取高优先级的业务舍低优先级的业务，如何区分优先级？平台根据业务的场景建立了一套Flink作业的优先级标准，并配套着从申请到治理到整改，降级推出全过程的自动化管理体系，在业务侧精细化地区分优先级，确保真正高优业务的质和量。在资源有限的条件下，重保高优业务，以实现资源换资源。
• 最后一步是最复杂的，如何透明切走作业。核心的思路是复用存储，保证计算透明切换来确保业务的无感。
Flink作业都是长生命周期的，带着state中间计算结果。首先要在集群的部署架构上做到计算和存储集群在物理部署上分离。计算集群出现故障时，比如基础设施出现异常等，可以通过切流将所有Flink作业平迁到另外一个灾备集群，但是state存储还是指向老的存储集群，就可以从原来的state点位恢复来实现真正透明的迁移，对用户做到无感。
除了日常的稳定性以外，双11更是稳定性的一场大考。Flink双11的专项保障可以总结为4大块8个字，分别是压测、限流、降级、热点。每一块背后我们都沉淀了一套成熟的保障体系。
• 第一块压测指的是压测平台，首先提供给用户将生产到影子作业一键克隆的能力，其次还会提供大量大规模精准的造压、控压、稳压能力，并提供作业自动化性能的调优，以及最后一步生产一键上线全自动化的一站式压测解决方案。
• 第二块降级指的是降级平台，因为在大促0点峰值，需要将低优先级的业务快速降级来实现水位的合理控制。
• 第三块限流，还有一部分中优或高优业务，在大促状态不允许降级，但是能接受短时间的延迟，所以平台还基于Linux内核的Cgroup实现了作业Pod资源的隔离和限制，从而达到作业粒度计算精准限流的效果。
• 第四块是热点机器，也是大促最复杂的点。从集群层面看，集群卖出的资源和用户使用的资源是存在差异的，比如1个Flink作业申请了10个CPU，而实际使用了5个CPU，还有波峰波谷会导致集群层面水位不均衡。
上图第一个图显示，集群调度层面所有机器资源水位非常平均，CPU和内存几乎在一条线上。但实际运行在集群上的所有机器的物理水位却参差不齐，因为调度是不感知物理使用的，所以随着集群水位不断提升，比如大促零点峰值的到来，集群的热点机器就会往更高去平移，某些机器在某一维度的资源会达到性能的瓶颈比如CPU使用了95%或者更高，从而就导致了热点机器。
而在分布式系统里，所有机上的业务是有状态并且有关联的，局部的热点机器不仅会影响集群稳定性，还会成为集群性能提升的瓶颈、造成成本浪费，也就是说，热点机器会是集群稳定性和水位提升的短板。
热点机器的解决是一个很棘手的问题，一般需要经历4个过程：
• 第一步是发现热点机器，包括热点机器的CPU、内存、网络、磁盘，难点在于热点机器的阈值是来自SRE线上丰富的经验。
• 第二步是分析，我们做了一系列的机器诊断工具来定位热点的进程，包括CPU到进程、IO到进程，难点在于要求用户对于Linux整个系统的原理有深入的理解和分析。
• 第三步是业务的决策和策略，从热点机器进程关联到业务的数据做决策，不同的优先级能接受的策略是不一样的。
• 最后一步，才是真正的解决热点机器，低优先级通过降级或均衡，中高优先级则通过径流来实现热点机器的下降。
这个过程背后涉及的东西包括对业务的理解比如优先级、资源、配置画像，对调度的原理的理解比如资源的分配策略、调度的策略，以及对系统内核的深度排查分析，还有业务的经验和策略——到底是限流还是降级。这样全链路的界定和分析决策是一个非常复杂的技术难题。
我们正在做的是将热点机器的完整解决方案全部沉淀下来，打造一个基于K8s云原生的Flink Cluster AutoPilot来实现热点机器的全自动化自愈。
从部署形态上来看，AutoPilot的服务是基于K8s进行全托管，按集群维度进行轻量化的部署，通过配置文件来方便地管理和运维。而执行阶段则是由K8s来保证面向终态，保证最终一致性。从AutoPilot的技术能力上来看，它是通过将热点机器的全面度分析流程抽象成6个阶段，包括热点机器的定义、感知、分析、决策、执行及全过程的可观测性，来实现整个热点机器全自动化自愈和高可观测性，提升集群的稳定性以及降低成本。
在过去的几年里，围绕着运维稳定、成本、效率三大核心价值，SRE在Flink Cluster超大规模集群运维上沉淀了大量运维能力和更好的运维平台。但是随着云原生化大浪潮的到来，运维能力如何基于云原生变得更标准化，运维的交互界面、操作模式、执行模式以及运维过程的可观测性如何建立更加统一的标准，都会成为我们未来的重点发展方向。Flink Cluster AutoPilot会成为云原生下新技术的载体，来承载运维体系的不断演进和升级。
