一、为何要践行ECS实例稳定性最佳实践
首先了解为什么要践行ECS的稳定性最佳实践，用户在使用ECS的过程中，业务的稳定性依赖于ECS底层的稳定性以及用户使用ECS方式，共同努力保障业务稳定性。ECS作为S层的底座基础设施，通过一系列的工程化的方法来建设稳定性。而在此基础，可以给客户提供优质的稳定性SLA，用户在该稳定性底座，能够通过ECS稳定性最佳实践，用好ECS则可以充分发挥这些稳定性的能力来保障自己的业务稳定性，从而来助力自己业务的发展。
1.ECS稳定性底座
观察完整大图，通过系统化的功能方法来建设稳定性，在自研的数据中心网络以及服务器这些基础设施，是整个启动工程的基座，是数据和算法仲裁。在此，是线下预防体系和线上守护体系以及事件驱动的客户联动体系三大体系。线下预防体系是来对问题进行风险预防的，这里面会通过在产品的设计适配以及产品验收三个阶段去进行稳定性风险预防，在产品设计第一天就会去明确稳定性的要求，以及可运维性的这些要求，从而形成的稳定性的标准，和硬件标准，并且在产品的设计过程当中，从ECS业务角度以及技术设施的维度去进行相应的适配，在产品验收的过程当中严格的验收的稳定标准是否达标，产出相应的报告，这样就可以让的ECS在产品上线之前就能得到很好的质量保证。左移稳定性的保障。如进入到线上生产的环节，就依赖于线上的守护体系三大能力，这里分别是智能故障预测，灰度发布能力用来避免在变更过程当中引入的规模故障的风险，监控诊断能力是线上识别风险以及去进行对应诊断的核心的能力，异常调度能力对识别到的这些异常进行风险的规避；故障快恢能力，在故障能力下能进行快速有效的故障恢复。
事件驱动的客户联动体系，与最佳实践密切相关。在此基础是在特定场景，特定时期可面向特定用户之下的稳定性保障体系，包括的稳定性保障的产品，以及稳定保障的机制和对应的技术支撑平台。
二、用户践行ECS稳定性最佳实践
了解概览后，了解稳定性的基础用户能够践行ECS的稳定性最佳实践的方法，帮助大家更好的用好ECS来充分发挥的稳定性优势。按风险的规避，问题的容错，以及问题诊断方面进行归纳。首先，风险规避，首先需要进行合适的规格选择，这样可以尽满足的业务的需求，同时又可以去平衡成本，通过弹性的计算能力去规划的容量，这样子既满足容量安全，又可以去平衡的相应成本。同时还建议去保持的操作系统以及驱动的更新，保证稳定性和安全性的支持。特有的事件响应的能力是在ECS发生风险之后，通过事件的交互方式，可以给的用户进行交互，响应事件就可以去解决对应风险。
问题容错方面，建议去建设高可用架构来规避对单实例，或者是极端场景下的容灾。同时还建议去通过设置合理的访问超时或者网络抖动或者是其他的性能抖动，短暂的去影响应用性能，还有方式说可以通过灵活的去选择的，如部署机或者是专有速度机去灵活的控制的部署的方式去实现实际想要的聚合或者打散。提供了业务工具来帮助大家实现自己业务层面的故障演练，从而来检测故障识别以及恢复能力。问题诊断阶段，一旦说异常发生了，可以通过实例在控制台自诊断的功能去自助的定位根因，并且根据控制台上的引导去帮助大家解决这些问题。典型的场景如：GuestOS以及gpu异常诊断。
1.典型场景样例-实例Panic风险消除
通过典型场景介绍相关细节。实例Panic指用户操作系统崩溃，如蓝屏，出现四国语言的界面，或crash报错。底层会出现重启行为，用户视角为中断了业务的延续性。Panic原因多种，如内存OOM，内核Bug，驱动不见，AI的中断响应。进行风险联动的消除的原因为问题发生在GuestOS用户的操作系统内部，这些问题的定位依赖于在授权的情况下去获取内核的日志，内核参数等等。这些话必须要跟底层进行联动，才能够去协助用户完成消除。
2.如何进行实例Panic风险消除
了解如何进行实例Panic风险消除。按照问题处置阶段分为多部分。准备工作阶段，推荐配置Kdump，PANIC发生时可以有效的收集到系统失败，提供更充分的信息进行问题的排查。当时无panic事件之后通过系统事件，上报给用户，用户视角获知该问题，当收到事件之后，此时就要进行实例的对应的诊断，对于熟悉操作系统的用户可以自行的去进行的判定原因分析，同时也可以通过控制台上的自诊断功能来利用单元的能力去进行自助的原因分析。此时的后台会对core dump进行相应的自动化解析与定位，同控台给客户反馈具体的原因和对应的处置方案，在下阶段，根据提供处置方案，一步一步的引导，可以利用不同的产品的功能去进行异常修复，这里面就包括如通过服务迁移中心来进行操作升级或者是补丁管理，功能进行驱动升级转，包括参数优化，或者是内存的管理优化。
3.实例Panic异常检测与事件通知
了解如何发现实例panic出现异常以及对用户去进行通知。异常监测阶段，GuestOS 发生panic，会通过训练法组件qemu识别到事件，如果的实例当中有云助手插件，云助手会采集到相应的系统日志，在内部会形成GuestOS panic内部事件，进行相应上报并对接ECS事件体系。该事件体系为跟用户去进行相对交互消除风险，ecs事件指的是当ecs状态发生变化的时候，给客户发起了通知，在今天的情况下，panic事件会汇聚到事件系统的数据源当中去，通过一系列加工形成instance Failure，即实例发生事件会进一步上报到的ECS的事件服务，给大家提供相应的试点推送和查询能力，建议用户通过控制台或者open aPI的方式去进行相应查询，或者通过云助手的方式来进行相应的订阅。
4.实例Panic根因自动分析
这一类问题的风险的消除是依赖于去定位到根因的，如何去帮助客户自动化的去定位根因，并且进行供应消除。在控制台提交了根因的诊断之后，诊断需求之后，后台会进行文件解析，并且去结合日志去进行解析，形成文本化信息结果，是一种典型的文本分类工作。通过前期积累的这些数据形成的训练集，进行特征工程，进行相应的文本的预处理，最后形成文本表示，对分析进行训练，最终形成了的对象匹配的规则，或特征匹配的规则。同时还产生panic知识库，包括从根因到解决方案。当新的painc需要进行检测的时候，经过的一切解析和分类器的定位，最后给客户返回的，在控制台能够呈现的是的根因以及对应的解决方案，此时再根据解决方案中一步一步的操作引导，或者是文档，或者是在系统上进行引导。根据做的方式去可以解决panic的风险。
5.案例分享-某制造业客户Panic风险消除
介绍某制造业的客户的具体案例。在今年年初的时候1月22号，后台系统时常监测到的panic的数量，每月的数量会发生突增，在客户的视角来看，会大量的受到ECS的panic事件，而后台是不同的实例，每个发生一次有大量的实例产生事件，逐渐构成风险，用户视角会形成重视，在相应的控制台形成明确cfs的大的根因，并在系统上会给出了可以去升级阿里云ALINUX3方案，在产品的支持下进行比较高效的升级，最后可以看到在1月26号之后，线上painc开了明显减少整个风险落地，解除了风险。
介绍相关细节，如事件在控制台的样式。在非预期控制台事件当中会看到因实例错误而重启的类型。收到该事件后可以在自助问题排查界面上去提交自诊断，这里可以获取到明确结果，操作系统崩溃导致实例的重启，底下还有对应的处置建议的提示，如果说建议是要进行操作性升级，也可以在的服务迁移中心当中进行按照的一步一步的操作指导进行具体的操作升级，但这只是其中一种修复方案的案例。通过这样方法，用户在一周之内的就解决了线上大规模panic风险。
三、稳定性最佳实践插件工具应用
由吕文天为分享如何利用最佳实践的工具，高效的去落地的更多场景的最佳实践来帮助用户用好ECS解决现场的问题。
1.为什么需要最佳实践工具
介绍制作最佳实践插件工具的原因。与客户进行交流介绍稳定最佳实践场景时，客户存在对不需二次开发可直接利用的工具的需求。如客户操作系统出现core down时，core需要配置希望直接提供脚本达到效果，或者在推动客户进行主动响应事件，进行自动化建设时，客户也经常提问题，能否提供自动化的响应方案避免额外二次开发。这些都是客户在进行最佳实践场景时面临的问题。因此希望结合客户的需求场景和最佳实践的方案，以及当前解决通过最佳实践工具集帮助客户无需开发，直接执行，成本低，解决客户实践最后一公里的问题。
2.稳定性最佳实践工具集
最佳实践工具集是基于云助手开发，云助手是阿里云用ECS打造的自动化利用工具，可批量下发命令和上传文件。同时，云助手也提供插件的能力，通过把最佳实践的方案集成在插件的内部，客户只需要调用通过一条命令调用对应的插件就可以实现对应的功能。因此，操作方式非常简单，云助手不需要客户额外安装，代码是开源的，最重要的方式咱们是通过命令，命令执行方式非常简单，同时在业务运维的场景，结合稳定建设体系，在故障预防，感知与分析，故障处置和演练以及日常用的角度梳理需要给客户提供的插件的能力，在故障预防角度，阿里云会对的速度机做内存和CPU的故障预测，针对可能宕机，通过提前的内部运维解决掉，其中95%的实例可以直接解决，5%可以直接发送给客户，客户可以通过主动响应对应事件来完成风险规避的能力。
在感知和分析阶段，把对应的监控到异常，通过系统事件发生的客户，客户可以通过诊断能力，通过自诊断系统来监控当前出台证的问题，通过诊断之后获取到对应的诊断结论，以及后续的改进措施。在故障处置阶段，提供了业务进程异常的快速恢复能力。在稳定性建设阶段，提供了给客户故障演练的插件，客户可以通过故障演练的能力来验证系统的稳定能力，比如在ECS系统宕机，通过宕机故障插件来验证。在ECS系统宕机情况下，业务系统的容错能力，或在网络进程异常的时候网络情况，以及CPU负载内存较高容错能力是否正常。除了这些稳定能力之外，在日常运维角度客户可能会有些比较繁琐的操作，如配置超线程，固定更新，将这些都集成到操作系统内部，客户只需要通过一条命令要对应的插件名就可以完成对应的操作方式。
3.通过云助手插件监控ECS系统事件
首先介绍故障预防阶段的时间，响应查检，如宿主机可能异常，有情况可能会发生的，需要客户去主动响应，客户可以在控制台上受到事件之后，手动的点击响应，或要用open API建立自动化的程序，自动化的响应。在线下做问题收集的时候，发现客户在反馈的控制台点击的时候，容易出现遗漏且操作成本高，同时调用API需要二次开发即额外的程序去开发。为解决客户的过程的问题，开发了个事件响应的插件，核心思想是把事件通过日志的方式写入到操作系统内部，客户可以向采集自己的系统日志一样，直接采集到事件，不需要客户额外的通过外围的系统开发程序。同时基于日志的采集系统，可以直接对接客户已有的自动化方案。
存在客户可能采集之后就可以对标自己的分化系统，但是有的客户对标之后，并不具备自动化的处置能力，因此也基于当前主流的K8的场景，介绍K8字场景下自动化响应ECS系统事件的最佳实践。首先最佳实践的方案是由事件检验的事件，加上k8s场景draino autoscaler开源场景进行实践。首先安装对应的云助手插件，安装之后在ECS抽到事件的时候，会自动的把事件写入到日志内部，提前配置好的策略的npd就会把日志采集到平时把节点状态标记为不可调度，并且把节点作为异常的状态，autoscaler会检测节点异常状态，同时最后可以结合autoscaler可以把ECS实例释放掉并新建实例，最终完成事件响应。
准备K8s集群，master节点和两个node节点。首先可以在内部安装对应的产品，需要一条命令，如果实例较多，可以批量的分发执行，可以查看到对应的系统日志下已经产生对应的文件目录，可以按照最佳实践的文档去安装开源的NPD插件，安装完成之后，可以查看当前节点的状态为正常维度下的事件维度。安装draino NGINX（测量运维驱逐情况），Nginx部署在node1和node2两个节点，向NODE1发送主动运维事件，收到事件后，控制台已收到。再查看K8S-NODE01状态，节点状态为异常不可调度。观察Nginx部署情况：已部署在NODE02，NODE1节点已被清空。结合相关场景通过autoscaler将节点进行释放并新建完成事件响应过程。
4.故障诊断-GPU异常诊断
当前使用比较多gpu异常简单的插件，客户可以在控台下发，或在操作系统内部直接执行下命令来诊断当前急需的异常。可以，诊断CPU的卡异常驱动，或常见的问题，当前的诊断可以卡日常95%的客户咨询相关的问题，发起简单之后，会生成简单项简单结论以及对应的诊断措施。GPU异常诊断的优势体现在与运维系统进行联动的，如发起接收异常诊断之后，如果检测上是异常，同时客户可以自己解决，客户可以按照的文档一步一步解决。如果说需要阿里云配合解决，如客户GPU卡异常需要通过运维迁移实例解决，此时运维系统会监测场景，自动发送事件，用户及时响应即可。可以与运维系统联动快速解决客户面临的问题。
5.提升服务容错能力
存在故障难以避免。如宕机或者业务进程被误差或OM的相关的异常都会，导致业务中断，降低业务的连续性。业务可以通过提升业务的容错能力，提升快速恢复能力降低中断时间，提升业务的连续性。因此在如何提供让业务快速恢复和协助客户做业务容错能力验证角度，让客户可以去提升自己的容错能力，分别提供了容错恢复插件和不断输入相关插件。
服务自恢复插件：通过守护进程，保证业务进程异常的时候可以实现快速的拉起，包含服务保活和宕机自启动自动拉起能力。保活的是通过插件启动的服务，可以守护进程，在业务进场费异常的中断或是OM可以立刻拉起异常，降低中断的时间。宕机自启动指的是ECS宕机或panic启动，此时快速拉起业务进程，降低业务进程时间。服务自恢复插件是基于系统的systemd，建立对应的systemd service来实现的，客户可以通过一条命令完成整体的配置，降低客户的操作成本，提升运维的效率。
宕机故障注入插件，基于内核系统的sys rq直接注入内核崩溃的故障造成操作系统的雪崩.模拟ecs实例异常内容情况，客户可以通过此验证ECS宕机容错能力。
了解宕机故障注入与服务自恢复插件组合场景。包括ECS A ECS B两个实例。同时在b模拟业务进程，通过服务保护插件进行启动，此时可以内部查看业务进程，目前处于正常运行的状态，在b的实例里注入宕机故障的插件，注入之后可看到实例A就能够完成，自动拿起，实例B不通出现宕机。操作系统崩溃预计十秒内会拉起，此时a与b可通。再去登陆终端查看刚才业务情况，可以看到刚才通过服务的恢复查点启动进程已经开始正常运行了。同时在控制台可以刷新，查看b实例，由于宕机故障出现的ECS宕机事件。通过演示帮助客户在自己维度建设自己的业务容错能力，同时通过故障注入验证能力持续迭代能力来在文件业务能力得到持续的提升。
总结：介绍做实践的原因，以及最佳实践的场景。最后介绍了为解决客户最后一公里的操作问题，开发的最佳实践的工具集。客户在阿里云不仅可以获取到最佳实践的方案，同时可以得到最佳实践供给的操作方式，不需要进行开发。可在ecs文档搜索稳定性最佳实践找到演示的文档和插件的方式。
四、ACK高可用稳定性和应用数据灾备最佳实践
由技术专家刘佳旭和苏雅诗进行容器稳定性最佳实践讲解。
分享的主题是ACK高可用稳定性和应用数据灾备最佳实践。首先会来介绍ACK稳定性最佳实践概述。随后会介绍ACK单集群以及多集群场景下的高频架构，以及相关的最佳实践,会介绍container native的应用容灾手段。最后回答迁移业务，实现集群大部分跨度无缝升级。
1.ACK稳定性最佳实践
ACK的稳定性有很多维度，下面会着重从两方面进行介绍，首先是集群的高可用以及业务的灾备。集群的高可用，会阐述K8S集群的高可用场景的常见的错误配置以及相关的痛点。随后会介绍ACK单集群以及多集群的高可用最佳实践以及架构。在业务灾备这块，介绍业务容器化要求以及ACK备份中心最后会demo集训大版本跨度无缝升级。
（1）Kubernetes集群的高可用场景的错误案例和痛点
高可用架构容灾设计是k8s基石，尤其在生产环境高可用容灾设计尤为重要，先来看K8s集群的常见的高可用场景的错误配置案例，以及相关的痛点，第一个案例集群的节点，K8s集群的节点都是按单孔去进行部署的，如果集群出现了可用区级别，如网络故障以及硬件故障，会导致这些节点整体受影响，进而导致整体的服务下限。第二个案例是集群的节点，虽然是按多孔去进行部署，但是业务套的没有配置成，按可用区均匀打散，有可能按照K8s调的规则，会将大量的主多数的调到某可能区，如果可用区故障，这些大部分业务都会受到影响，甚至会影响服务的产生下线。第三个案例，对集群的应用性应用的可用性，以及可用区维度节点可用性的健康监控告警能力的缺失或者不足，K8s层面应用的高可用监控对业务至关重要，需要在业务部分受损，就能构建出来，就可以提升对1-5-10应急处理和告警通知的能力。同时，如果对可用区级别的健康节点进行观测，就可以感知到集群底层资源的可用性，以及进行及时的应急处理。第四个案例多集群场景，在多集群场景下，多个集群的应用分发安全策略，流量控制，全局监控以及作业分发。如果没有统一的平台进行纳管，会显著增加整个系统和系统的复杂度。
（2）单集群高可用架构
了解针对相关痛点问题 ACK通过架构上的设计以及最佳实践的解决措施。左边框图是典型的ACK集群的架构图，在图当中包含两部分，一部分是上面这部分是ACK k的vpc，在当中部署了ACK的源集群，上面是承载着用户托管的控制面组件，下面是用户的vpc，是承载的用户的ACK集群的用户侧资源节点，还有slb等等。同时这些资源都横跨在不同的可用区。
以某一ACK客户集群为例，进一步分解客户集群的控制面，部署在ACK的原集群当中，以pod的形式进行托管，ACK的源地群本身专业版集群，所以是可以用K8S的方式去管理用户托管在ACK控制面的这些托管组件，即ACK负责组件的全生命周期。
了解数据面。数据面包含用户vpc以及用户UID下面的资源。数据面ACK用户提供了丰富的可配置的高可用产品能力以及最佳实践。
介绍ACK的控制面。控制面实现是可以做到了可用区级以及节点级的高可用的保障能力。全部的控制面组件，实现与阿里云ECS的可能区能力对齐的高可用打散。
以API server为例，ACK控制面是以pod的形式存在多个pod的是多副本跨ACK，跨节点进行高合并部署。任何ACK的实效不会影响控制面整体的服务可用性。同时对etcd做了增强了治理能力,即后端能自动检测端点健康程度。如果后端三个etcd出现了网络分区导致异常，致使出现no leader的状态，pod的会自动从API server移除，这样保障API server可以正常的对外继续提供服务工作，所以可以有效的应对etcd分区异常的问题，在总体上在控制面试，基于k ok架构，以pod的形式来自动化管理托管的组件。可以自动化的做强制的跨AZ打散，探活健康检查以及自愈，自适应的副本弹性以及升级管理，节点异常自动迁移等等。在3AZ地域 ACK的拓宽集群控制类的sla ACK Pro是99.95%，所以不具备3AZ的地域ACK托管为99.5%。数据面ACK基于产品能力与k8s调度中的拓扑分布约束可实现不同等级的高可用策略，实现负载均衡，虚机节点以及云盘等功能。
针对用户策略进行详细介绍，了解相关最佳实践。图为容灾反亲和容灾能力的示意，通过结合K8s本身的调度能力，还有ACK，ECS产品能力，可以做到如下的最佳实践。
首先是业务按节点进行打散的分布，可以配置pod的按节点反亲和调度策略，实现业务的节点级高可用的容灾能力，业务可以按部署级节点的方式进行打散分布。部署级是控制ecs实例，分布的策略，可以将ECS实例分散部署在不同的物理机器上，避免因为一台物理机的宕机所以影响了多个物理机上的ECS的实例，通过策略和方式，产品能力，可以将pod的分散部署到不同的底层的物理机上实现物理机级别的高可用的容灾，再通过多可用区的打散的叫做策略，可以实现业务的高可用。
下面来看工作负载高可用的最佳实践。首先是配置pod的拓扑分布，约束，可以通过配置Topology spread constraints确保pod的在不同的可能区节点等等这些故障率上进行打散，提升应用的高可用。再可以配置pod的反亲和，把pod调度到不同的节点，还有可以配置pod的PDB，可以防止过多的副本同时终止，尤其适合于多副本处理流量型的场景。还可以配置pod的健康检查，以及自愈，配置不同的探针来监控和管理容器的状态和可用性。具体探针包括存活检查，就绪检查以及启动探测。
了解企业版容器镜像服务高可用的最佳实践，通过配置企业版容器镜像服务，可以去实现跨可用区容灾以及跨region级的容灾。跨可能区级的容灾，是其使用企业版镜像服务以及同城冗余OSS bucket，生产环境一定要使用企业版容器镜像服务，而不要使用个人版容器镜像服务。前者支持高可用产品能力。对于企业版镜像服务，在支持OSS同城冗余的地域默认创建的实例会联动创建，支持同城冗余的OSS8K，这样进而实现跨省区的高可用。如果后期OSS在地域新增了支持的同城冗余，用户也可以在OSS控制台将镜像服务相关的把给转换成同城冗余，进而提升镜像服务提供同样的能力，还有跨地域容灾，如果用户在多个地域都使用企业版容器镜像服务，而且还把镜像也同时推送了。这些地域的镜像服务上，就可以实现跨地域的容灾，具体来说就通过自定义域名，镜像同步规则以及为实地配置防控控制，通过切换域名解析来实现跨地域的容灾能力。
用户也可以通过云资源的高可用，以及K8S的配置界面进行整体的高可用的配置，以负载运动高可用为例，负载均衡ClB NLB和alb均支持跨AZ的容灾，用户会通过K8S界面进行指定clb的主备可用区以及指定NLP的多可用区，也可以通过NLB的cr来指定ALB多可用区，还需要注意保持一致减少跨可用区数据传输。
学习系统中配置最佳实践。可以通过下面这些方式，首先来看应用副本，不可用的监控报警库，symmetric提供了一系列与工作负载副本相关的指标，包括具体包括工作负载，不可用副本数以及工作负载的总副本数。可以通过这类指标进行综合的处理，如可以去获取工作负载当中不可可用副本数和总副本数的总的占比的百分比，这样可以实现部分服务受损和全部受损的告警，ACK是默认开启的告警能力的同时，还可以通过K8s的KcM的组件，有透出可用区内不健康节点数，健康节点百分比等等，可以获知整个集群维度的节点的可用区。
（3）多集群高可用最佳实践
多集群场景下的最佳实践，可以通过ACK one进行多集群管理，这ACK one整体的架构图，用户可以通过统一的控制面，对多个集群进行应用分发，流量控制，安全策略，全局监控等等多集群管理。纳管的集群包括公有云等等多种集群形态，通过多AZ,多ACK集群实现集群容灾，通过ACK ONE GITOPS多集群应用发布实现应用容灾以及ACK ONE多集群网关实现同城GLOBAL INGRESS和流量容灾。
介绍最佳实践的客户案例：小红书案例。小红书对线上生产环境有非常高的稳定性的要求，可用性，稳定性都有非常高的要求，小红书针对自己的集群自己的ACK集群上构建使用多种策略包括按程序集的打散，结合自己的业务，按程序去打散，按部署，就可以充分去抵抗可用区，节点级别的故障以及物理节点级别的故障实现，确保服务的高稳定性的运行。
总结：ACK高频最佳实践高可用架构容灾设计是K 8s的系统稳定性的基石，ACK服务集群在全网有数万，控制链和数据面都进行了充分的高可用的架构设计，还提供了稳定性最佳实践，都经过了大规模的场景，丰富的线上环境的验证，目前已经成为ACK稳定性基石。基于KOK的架构自动化企业管理组件的生命周期，同时提供有sla的控制面服务保障。数据面，支持了节点，打散能力以及结合k8s的调度能力，支持更高级的打散规则。还有支持应用可能性的可观测以及多集群ackone的产品福利形态。
（4）从高可用到灾备
分享集群灾备相关的内容。高可用的配置是集群稳定性的基石，可以保障在基础设施突发故障的时候，应用仍然能够稳定的运行。但业务快速迭代，以及集群日常运维期间藕发出现故障，如集群资源的误删除，需要对比较重要的业务去进行周期性的以及在集群高危操作之前去进行单次的备份，去有效的降低在相关故障发生之后，集群业务的恢复的rto和rpo，因此可以说集群有效的灾备手段，是稳定性的最后一道防线。在业务容器化之后，对灾备有什么新的特性，首先从对象来说，因为的业务已经经过了K8s的编排，因此需要备份的对象是以工作负载，容器组为核心的经过编排之后的K8s集群资源，灾备目标应该是恢复之后的工作负载能够有效的服务，运行配载保持不变，达到整体的恢复，可能是在同集群，也原地恢复，也有可能是跨集群的恢复，对于的有状态应用来说，还需要额外去考虑数据存储区内数据的灾备。
（5）ACK备份中心
针对这些需求， ACK推出的备份中心container native的一站式的应用维度灾备方案，集群的运维人员可以在控制台一键对需要备份的应用去创建周期性的定期备份或单次的备份与etc备份相比，整备份是可以支持特定的资源类型的种种维度去备份内容。对于有状态应用可以一键去勾选，同时备份存储圈内的数据，对于有比较完整的流程或是手段的集群，提供了数据保护的功能，可以谨针对的存储器数据去做相关的个备份，在恢复之前，可能需要去调整备份的这些内容，如最简单的像spACKe以及进项仓库地址的配设，如在恢复之前，是希望去对的服务欠流的相关配置，应用的副本数，以及配置文件等等相关的内容进行调整，这些都可以去通过策略的制定在恢复之前去做相关的支持，做完这些这些可选的步骤，在之后就可以在控制台一键的针对某备份去恢复全量或者是部分的内容，做自适应的调整，使跟的ACK的系统组件以及整阿里云的生态更加的兼容。
（6）k8s资源灾备难点及解决方案
从集群的资源以及数据两个维度去介业务的灾备面临的难点以及备份中心是怎么去做解决的。以MySQL为例，在部署MySQL应用的时候，可能需要secret去记录的账秘，以及需要config map去记录，提供配置。可能还需要还有其他领域相关的资源记录与存储网络相关资源。备份的时候可能面临的挑战资源的遗漏，任何资源的遗漏都可能导致在恢复期间没有办法把pod正常的拉起。备份中心会根据K8s的资源的定义去找到资源之间的依赖链，备份时会自动追加。如在备份应用的时候，他使用了自定义的资源，在备份的时候会自动的追加相关的crd去保证在新的集群环境也能够正常的拉起业务，但是完整的备份并不代表能够做完整的恢复，如果恢复的顺序不当，可能会导致备份的业务运行期间的状态丢失。举例：首先恢复一个deployment，根据k8s的control的配置，可能会迅速的拉起副本，这就会导致备份的应用，相关的追加的4段，或者是状态丢失，导致整个业务没有办法恢复一开始运行的状态。此外，如果尝试过使用其它工具，会发现拿到的运行期间的资源，里面有非常多的字段，需要在apply进行清理或者重新的调整，如在调度之后pod会有node name字段，字段如果直接恢复会导致的pod没办法进行调度，对于问题备份中心同样是会根据k8s资源去做自动的策略，以及相关字段的调整。
（7）有状态应用数据保护难点及解决方案
以MySQL为例，可能需要云盘去存储MySQL实际DB里面存储的数据，可能还需要像OSS共享存储去记录的相关的日志，不同的存储的底层使用的更原生的灾备手段是不一样的，备份中心会将所有的存储的类型进行快存储的抽象以及文件系统的备份，并且整备份对用户是屏蔽的。但是存储卷的备份以及恢复，应用并不能直接去感知到变化，因为在应用跟数据源之间，还有PVC以及pv去作为桥梁，所以备份中心在做存储数据备份的时候，同时会将的PPC pv记录下来，并且在恢复的时候，动态的去调整，指向存储源的变化，使对存储源的变更能够变得无感。对于ACK的老客户，可能还会碰到的问题：存储驱动的迁移，会导致相关的资源里面字段都需要重新的调整。针对问题，备份中心也会去做相关的兼容恢复。
（8）备份中心原理概述
介绍备份中心的原理，关于多类型的备份数据存在哪，数据是有哪些云产品去保证的sla，以及创建了周期性的备份，这么多数据每天都在备份，这开销会不会比较庞大。每一次的备份都有可能会分解出三个不同的部分，包括了集群资源的备份，以及快存储数据的备份以及文件系统数据备份，这三个子任务之间，备份策略以及恢复策略式的共享的，如的周期或者ttl相关的配置等等。对于集群资源的备份，是基于开源VELERO社区，会去兼容ACK以及阿里云的生态，让用户在备份以及恢复的时候只需要关注他们业务的本身。这些相关的资源会存储在抽象出来的备份仓库的概念，实际指向的是用户去提供的OSS BUCKET。快存储数据是基于阿里云云盘，广泛使用的ESSD是支持极速可用的功能，能够保证在备份以及恢复期间都是秒级的备份，以及拉起。同时还有更通用的能力，如一致性快照和增量快照。
文件系统的数据是基于阿里云的云备份服务，能够提供增量，压缩去重功能，为整文件系统数据的备份，以及保护相关的内容，都是支持增量备份的，在每日的备份期间，能够有效的降低备份的时间和成本的开销。控制台的简单展示，在控制台里会有流程的指引，在创建了相关的备份仓库之后，就可以去对需要备份的应用去做创建备份计划或者单次的备份去做的像ttl或者是指向的配置之后，再创建完备份之后，就可以在控制台去检查这些实际备份的内容等相关的信息，如果在有需要去恢复，可以在当天集群或者是在其他的集群里面去做单个备份的恢复 。
（9）混合云场景的灾备实现
ACK提供的云上灾备的能力，同样能够帮助云下的集群去做相关的原地的容灾。如果有idc其他云厂商的K8s集群都可以通过ACK one的注册集群接入进来，去部署备中心的应用，去实现应用与存储的云端的备份。如果在本地的集群去做相关的备份与恢复，能够在上云的场景去做云端的迁移。备份中心在发布之后，也有很多的客户在灾备之外，会去实现更多的功能，如像去做跨大版本的集群的迁移，像跨vpc上云等等的更复杂的场景，这里列举了在这些场景中客户关注的其他更多的能力，如存储类型的转换，另外版本的切换，如一点一几的集群版，有非常多的API，是不支持直接恢复如1.30的集群，这些备份中心都会去做相关的调整，以及不同的场景下，牵流可能会有不同的需求，如是否要去新建的负载均衡实例，是否要去做主动的切流等等，这些都支持客户进行配置。恢复如果资源已经存在，会去使用更加安全的同名资源。但如果客户有需要去做回滚或者是更新，也会去通过其它方式去做更新。
进行相关概括。对三副本的读写MySQL有状态应用，从1.16集成到1.30集群的备份，差了14个大版本，易出现无法主动去切换的API version，并且还会有其他的系统变更以及系统组建的切换，对于应用来说，也会有像要复用端口以及的LB实例，但不主动牵流，以及对于云盘存储需要去做数据的备份。但是oss是直接复用更高级的要求。两个备份已经恢复的集群，分别是1.16的集群，是1.3的集群。先看1.16集群的装的系统组件，首先备份中心的组件，看存储使用的是旧的fACKebo的存储，以及网络使用。需要备份的MySQL的状态应用，这是三副本的MySQL应用，是他的相关的服务，这里是有三种不同类型的surfACe的资源，其中advance类型是使用了08结尾的负载均衡实例，以及相关的 inverse资源，存储其中云盘是需要去做数据备份的，oss会直接复用。直接进到培训中心的控制台，已经有流程的指引，创建过了相关的变成仓库了，做单次备份，去选择使用的备份仓库，选择应用所在的default的命名空间。这里勾选了存储圈备份，相关的高级配置保持不变。存储券备份的状态，可以看到跟预期一样，是做了云盘的个备份。
Oss是通过打标的方式已经排除掉了，同时也可以去看到实际备份的集群的资源，组都是1.16兼容的版本.此为单次备份，也可以通过周期备份去做。现在切到了已经切到1.30的集群，可以看1.30集群，默认使用是CSI的存储插件和相关网络插件。检查default的状态下相关是没有任何的业务的，没有应用在运行的。在备份中心去做相关的恢复，可以看到备份已经同步到了当前的1.30的集群，点击立即恢复，选择了csi类型的新的云盘的存储类型。在恢复之后，存储数据已经切换到了Csi的云盘的存储类，去检查恢复出来的应用，三副本的MySQL已经处于running状态，三种类型的网络也是恢复，可以看到LV实例还是已经结尾并没有设置强覆盖监听。整个业务已经running之后再去做手动的切流。，无论是被动的数据的云盘，还是没是还是直接恢复的都已达成转移。 去验证模拟的数据是否已经恢复，可以对比相关的数据，在云盘中已经恢复了。
最后是快速的总结，去讲了 content native的业务，灾备，有哪些新的个特性以及要求，首先是以工作负载为核心的，需要去备份的集群资源。对有状态应用还需要去备份相关的存储券的数据，以及相对的解决方案，ack的备份中心作为一站式的灾备方案去做备份以及恢复的相关的配置和自动的调整去实现应用正常，拉起，对外服务恢复其状态一致的，恢复的预期，对于混合云场景也可以通过开关的注册集群去将云上的灾备能力助力线下的集群，并且去提供了更简便的上云方案。
