一、云卓越架构：稳定性解决方案
1.阿里云卓越架构五大支柱
首先简要介绍阿里云原卓越架构中关于稳定性的解决方案。在谈及原卓越架构时，有必要对其定义进行说明。云卓越架构是阿里云去年推出的一项综合性解决方案，希望从客户用好云的角度出发，解决客户所关心的安全稳定、成本最优等问题，提供设计的最佳实践和解决方案。其中，稳定性是五个支柱中极为重要且基础的一个支柱。今天将详细阐述稳定性支柱的相关内容。
2.云上常见的稳定性风险
在座的各位要么是开发人员，要么是运维人员，或多或少在日常工作中都遇到过一些故障。作为开发人员，也曾从事运维工作，经历过不少故障。在此大致列举了一些云上常见的稳定性风险，如架构问题、单点问题、在系统设计时没有考虑单点和容灾切换问题以及容量规划不足等，这些问题都可能导致单节点出问题后，业务也会受影响，包括订单类、交易类的系统。可能再上线的时候没有考虑到容量的规划，因为容量的问题导致业务受影响。
内部也曾做过统计，云上超过50%以上的故障都是由变更导致的，包括代码发布，发布了有bug的代码，上到云上可能就影响到了业务，还有一种是运维做配置的变更引发的线上故障等。再一个是客户在现场出了问题后，第一时间并不是监控告诉他的，而是你的用户，比如说这个网站打不开了，或是不能下单了，是你的客服人员或直接用户打电话告诉你出了问题，所以监控是不够全面的。另外一个是真的出了问题后，也没办法第一时间把这个问题解决掉，缺少应急的预案，所以这个是稳定性里面常见风险。
3.云上稳定性设计原则
针对这些风险，运维人员每天可能都在忙碌地处理各种事务，那么对于稳定性，能否有一个体系化的解决方案呢？从几个方面来看，如果这些事情都做完了，能否使系统的稳定性上一个台阶，达到甚至超过四个9乃至五个9的水平呢？这也是基于阿里巴巴多年双11等大促活动的保障经验总结得出的。
总结主要从以下几个方面入手：一是架构设计时要考虑容灾性、容错性和容量规划，即在系统第一天的时候，就设计、考虑这些点；二是实施变更时要遵循“变更三板斧”，因为很多的故障是因为变更导致的，在变更的时候要考虑代码的灰度发布、可观测性和可回滚性；三是出问题后要做到快速响应和恢复，即我们内部所说的“一五十”，尽管这非常难以实现，比如银行对灾灾难的恢复要求非常高，他也做不到“一五十”，他能做到三十已经非常厉害了。
我觉得今天我们做SIE、做运维，目的是为了做好稳定性，并且会从这几个方面不断的精进，做好日常的工作。这个是在卓越架构中、在学习板块中定义的设计的思路，包括一些设计的原则。
4.云上稳定性度量检测
基于这样的设计原则，在云卓越架构的学习板块中，还有一个重要的组成部分叫做“度量”，即识别风险。直观地度量今天的架构是否存在问题。度量分为三个方面：一是客观度量，客户做授权，并帮他做数据分析，即分析云账号中的资源，比如资源快到期了，你买了一个核心的数据库快到期了，我帮你去看一下这个资源是不是快到期了，是否要续费，或是你的系统非常的核心，但是版本或规格只适用开发环境，不适合生产环境，这些都是在客观度量中，可以通过云计中心直接做度量；第二个是指当无法通过数据度量的方式来评估时，可以采用问卷调查的方式。作为架构师，时常会自我审视系统的稳定性，不断通过自身的经验或最佳实践来进行双重检查。
在团队架构中，也包含了许多设计问题，需要进行类似的考量。第三个除了上述两种度量方式，还有一个非常重要的环节，即巡检。这涉及日常的配置检查，例如ECS（弹性计算服务）的时区设置，是否偏离了时区，这是需要检测的内容之一。此外，还包括网络拓扑、网络流量等方面的检查。这些都属于监控类产品范畴，通过这些工具来发现潜在的稳定性风险。这是度量这部分。
5.稳定性场景相关方案
在识别出这些风险后，接下来就需要进行治理和优化。在优化方面，主要阐述两个关键点，这两个点均围绕之前讨论的几个方面展开，并基于最佳实践方案。
第一个是容灾，在系统设计的初期，应全面考虑整个系统的灾备。在云上，这一点有些特殊。例如，使用的云产品、网络产品（NLB、CLB、ACK、数据库rds、regas等）以及OSS等，它们都提供了多可用区的版本。如果从一开始就具备这种概念，那么当某个可用区出现异常时，我们就能迅速切换业务，确保服务的连续性。此外，在ACK（阿里巴巴容器服务Kubernetes版）中，也可以将应用的Pod均匀打散到不同的可用区，以提高系统的容错能力。这些都是架构师在系统设计之初就应深入考虑的问题。
第二个是可观测。对于许多客户而言，他们的业务可能同时部署在IDC（互联网数据中心）和云上。在这种情况下，如何实现IDC与云上业务的统一监控和观测便成为了一个关键问题。云上很多监控产品，如云监控、ARMS等，它们通常具备开箱即用的特点，只需简单配置即可投入使用。然而，监控的实施并非易事，它需要结合企业的业务设计监控指标、设置告警策略等，这些东西都需要有一些设计在里面。
在卓越架构的实践中，也有相应的最佳实践，结合企业的现状做设计。
6.基于客观度量出来的风险进行专项治理
接下来进一步阐述之前提及的度量问题，即通过发现风险并寻求解决方案。在运维中心，存在一种自助方式，通过一个案例来说明。之前有一位客户将代码仓库自行建立在ECS（弹性计算服务）上，并部署于该代码仓库。然而，由于运维的疏忽，未对ECS的数据盘进行快照备份，也未开启ECS的实例保护。
某日因误操作，该ECS被删除，且由于数据未备份，导致客户的许多代码难以恢复。因此，对于此类重要资源，无论是ECS、数据库还是操作系统，都应利用之前提到的度量工具来评估其是否存在风险。若存在风险，在原级中心中，可以迅速的一键修复。
此外，除了客观度量，还存在主观度量。作为架构师，经常需要自查系统。在自查过程中，可能会发现一些问题，例如应用架构是否实现了容灾。容灾架构的考虑因素众多，包括网络容灾和应用容灾等。通过自问自答的方式，可能会发现系统在某些方面尚未达到容灾要求。此时，需要思考如何做到容灾。后续，我们还将探讨在网络场景和应用架构场景下，如何实现微服务的容灾。
7.总结
稳定性是运维、研发和架构领域一直面临的问题。他是没有嬴荡的，没有一个嬴荡解决这个问题，责任性是责任共担的模型。作为厂商，有义务确保原产品和机房的稳定性。同时，客户也可以结合自身的业务特点，在使用原产品时进行合理的设计。作为客户侧应如何确保稳定性呢？识货的运维总监徐总将结合识货在稳定性方面的最佳实践，来分享他们的经验。
二、识货APP业务稳定性最佳实践
本次分享的主题是识货APP业务稳定性最佳实践，由上海识致信息科技有限责任公司质量运维部总监瞿晟荣分享。
1. 识货APP的发展历程
首先将详细介绍识货APP的发展历程。在此也借此机会为识货APP做一次简短宣传。识货APP的发展已历经十年。在这十年间，从一个不起眼的小型论坛板块起步，自2014年起，逐步开发出APP，直至如今，我们的整体装机量已突破2亿，整体月活跃用户数量也已超过5300万。
2.识货APP简介
识货APP作为电商导购平台，在领域中分的也很细。在2023年，交易额已突破200亿，日活跃用户数也超过了350万。在此过程中，我将与大家分享如何设计并实施稳定性保障措施。
3.识货云旅程历程
在此之前先谈谈与阿里云的渊源。这一渊源颇为深远，已近快十年了。在2018年，虎扑公司整体推进上云进程，而这一时期恰好也是识货APP发展的高峰期。从2018年至2019年，是电商也是我们快速增长的阶段。在这一阶段，也面临了诸多问题，如服务不可用、上云过程中，运维团队也遇到了许多令人头疼的问题。由于快速增长，问题层出不穷，很容易被暴露出来。同时，阿里云在此过程中解决了许多在快速扩张中遇到的性能问题，以及团队建设方面的问题。
目前，无论是推荐引擎、AI智能技术、数据库，还是大数据集群，均在阿里云的平台上了。此前，周总已概述了稳定性设计的原则，包括阿里云的“三板斧”。在此，我将借他们的PPT来讲解，并回顾整个过程。
一个稳定的系统主要涵盖三大方面：一个是架构，怎么设计一个运维架构或开发架构、另外两个分别是变更管理和应急响应。这三者对于构建稳健的系统至关重要，是很重要的核心平台，是非常有价值的。
4. 关于运维的架构或开发的架构
在2018年初次上线时，采用的是一体化架构。例如，早期的论坛都是discuss论坛，数据库、代码等全部集成在一台服务器上。随后，逐步实现了静态与动态的分离，这是最原始的架构。接下来，关于架构的演变，实际上变成了多模块的，拥有了多个模块，每个模块可能被部署在一台独立的服务器上，以此构建了一个分布式系统架构。时至今日，对于整个云架构，无论是云计算、容器技术，还是微服务架构，甚至是云原生态架构，其本身并未发生根本性变化。
这些变化主要体现在计算层、计算网络以及存储这三个底层逻辑在做变化的过程，只是对规模不断进行变化的过程。规模从原来的单体规模，到应对高流量需求的整体扩容过程，在这个过程中，最主要的一点是要想清楚如何进行有效的容灾设计、容错以及容量规划。把这三块想清楚，以及架构设计想清楚，在架构中最核心的是围绕这三点把整体架构想清楚或理清楚的过程。
第二个方面是变更管理，近年来面临的最大挑战在于变更的频繁发生，而故障往往也伴随着变更而来。因此，对于变更的精心规划显得尤为重要。怎么做流程化的变更策略，实施灰度发布，加强监控，并准备充分的回滚措施，以从监控和变更两个维度提升业务的稳定性。
最后是应急响应，这一点正如阿里巴巴所提及的“一五一十”原则，确实难以轻易实现。然而从过程来看，仍需要往这个方面做尝试，或做整个的业务的规划和导向。
如何实现是很大的一个点，可以跟大家分享一下，首先，“一”即指一分钟内发现问题，需要拥有一个全面且高效的监控系统，确保能够迅速定位问题所在。其次，“五”即指五分钟内组织问题。发现了这个问题，怎么去组织，组织过程是消耗整个问题排查当中最大的一个问题。一旦知道了问题，我可能找不到人，我怎么去把这些人，把他全部都盘起来，这才是真正意义上在运维保障中很重要的考量点。最后，“十”即指十分钟内恢复问题。能找到人恢复问题这点还是比较简单的，在这个过程当中，怎么去找到相关的干事人这点是比较大的困惑点。后面也会讲识货怎么做组织的过程。
5.稳定性
该话题将围绕“稳定性”这三个词展开。在阐述过程中，对“稳定性”这三个字进行了重新定义，“稳”是业务的整体的稳定；“定”，会涉及可观测，即“定心”；“性”即性价比，怎么做稳定性，而不是性价比高的稳定性的系统，是要怎么做稳定性的一个概念，在探讨稳定性的过程中，常被提及的观点是需要大量成本投入或怎么做。在接下来的内容中，会讲如何实现成本的管控的逻辑。
接下来，将概述识货业务的整体情况。识货的电商业务场景与其他电商平台相似，今年双十一提前至12号开始，整个双十一乃至双十二期间，都是电商业务最为繁忙的期间。关于业务，会有一个过程。而且是一个瞬间的过程的值，要完成大量的交易过程。那么面临流量突增怎么去做？今年的双11是12号就开始了，这整整一个月的时间，怎么怎么实现高效且经济的稳定性保障？整体的扩容扩一个月，那么这一个月的成本也是非常巨大的成本。怎么做这些保障？在整个架构或运维架构中，是一个新的挑战过程。
6.识货运维的整体架构图
识货经过十年的迭代发展，从虎扑的一个小板块，成长为独立的APP平台。特别是在2018年至2019年间，识货经历了快速的发展，但同时也面临着严峻的问题。因为原来是PHP＋manyseco的架构。当时运维团队有一个话即“每逢佳节倍思亲”，而我们是每逢佳节服务必挂，即一到佳节了服务就开始不稳定了。各种因素、各种告警天天催命似警告。这是运维团队巨大的压力，所以在这个过程中，从2020年开始，进行了容器化的改造，在整个容器化改造完成后，到2024年可用率已经做到99.8%左右了，做到99.8这个过程，怎么再做整体的提升，这也是对运维团队的一个巨大挑战。
为此在内部做了一些系统，完成了对2020年开始，随着容器的整体改造的过程。在内部做的这些系统，帮助我们更好的管理了整体的过程，在这个过程当中，内部建立了“三统一”的发布体系，即统一的发布体系、统一的告警体系和统一的扩缩容体系。为什么会做“三统一”的体系建设呢？第一个是为什么先做统一的发布体系，因为在整体稳定性方面，最为突出的问题源自变更。而变更的主要来源，则是发布体系。因此，我们对整个发布体系进行了全面建设，从前端的发布到变更、回滚、灰度等环节，均建立了完整的平台。这使得代码在变更中能够迅速止损，一旦出现异常，便能快速进行回滚。同时也支持整体灰度和蓝绿部署的过程。
目前每周大约会在线上发布200个不同版本的业务。整个发布过程运行得非常顺畅。
7.告警系统
告警系统是在多个平台和工具上一直关注的功能。为此建立了全面的告警体系，以确保在出现问题时，能够迅速获取告警内容，在整个告警中最主要的一点是怎么去组织告警。在设计平台之初怎么去快速组织过程。
并针对所有服务进行了整体梳理。每次告警产生后，会进行认领，并由用户快速在群内拉群，会迅速协助他们组织相关人员，包括告警用户的上级以及该服务所涉及的所有上下游关系的人员，以便在群内进行高效沟通。在问题解决后，还会进行复盘，基于群聊的方式，能够迅速将部分人员组织起来，提高了告警处理的效率。这也是一个非常大的分享的过程，在告警的过程中，要着重考虑组织这个点。
此外，关于扩缩容的问题。很多人会疑惑，为何要进行统一的扩缩容。考虑到业务特点，如双十一等大型活动，业务准备期和高峰期可能各持续一个月左右，成本巨大。在这个过程中，运维团队在进行扩容操作时，很容易遇到线上故障。因此基于这一现状，采取了模板化的方式。具体来说，我们为双十一等特定场景制定了一个固定的模板，包括预估的QPS、每个服务的容量规划、数据库的容量规划、Pod容量规划以及中间件容量规划等。基于这些模板能够自动化地完成整个扩容过程。
当双十一活动结束后，会在下午两三点钟开始整体的缩容操作，并在晚上进行完整的过程。整个过程都是基于自动化和标准化的，大大提高了效率。在此之前，可能需要花费两个月左右的时间进行双十一的准备。而现在，基于统一的扩缩容体系，整个扩缩容的时间可以控制在2个小时以内。也就是说，在双十一前的2小时，即双十一基本上8点钟开始抢购，那么基本上会提前到4、5点钟开始，扩容完成后，到晚上11、12点的高峰期过后，还会进行完整的缩容。对于成本管控，基本上就是6到7个小时，共6个小时左右的整体的一个费用的成本，其他的成本上都是一个常态水位的成本。基于这个逻辑，整体的成本节省了非常多。同时，这种方式也帮助我们节约了很多的成本并避免了很多在扩容运维操作过程中可能出现的故障。
8.系统可观测性方面的设计
作为运维负责人，我经常被老板们询问系统当前的状态，包括哪里出了问题、线上哪里有问题、问题在哪里、用户体验如何、故障在哪里以及何时能恢复等。这些问题一直给我们洗脑，在我后面不断的催这个事情。在思考这个问题时会发现这个问题其实很难去快速的告诉老板哪里出问题了、怎么做以及这个问题什么时候能恢复，因此，我们考虑构建一个可观测的系统，在此提出一个观点，在构建一个可观测系统时，需要采取自上而下的整体观测设计的逻辑，而不是从下至上的逻辑。为什么是这个逻辑？你会发现一个问题，如果我们做一些监控或做一个监控平台的时候，只做ECS、服务，会发现监控的逻辑内容会非常凌乱，东西会非常的多，如阿里云上可能已有数百乃至数千种产品，尤其是在多云环境下，产品间存在叠加逻辑，使得统一梳理变得极为困难，从而难以迅速建立起全面的监控可观测平台。
因此可观测平台设计要从上至下，从业务线出发，贴近业务实际，从业务层面发现问题，并据此梳理系统，包括ECS等服务维度。整体设计思路应自上而下。他最大的一个问题，正如周总之前提到的，什么地方出问题了，运维同学再去查问题在哪里。所以我们要从这个维度上来思考整个产品，要从业务的产品上来思考业务监控是什么样的？能不能从业务上先发现问题并快速的解决问题。
9.两部分设计思路
一是线上问题排查的过程，二是我们基于微服务体系构建的可观测体系。我们的可观测体系主要包括五个模块：服务列表、服务链路、DB数据情况、数据SQL指纹、Redis Key、SLS Trace微服务状态和微服务链路调用。为什么整个体系会基这五个模块做这样的事。
在这里分享几个逻辑的思路，首先，分享一个运维团队在故障处理时面临的情境。当出现故障并触发告警时，运维人员往往会面对大量的告警信息，难以迅速确定问题根源。因此，从业务逻辑出发，我们需要能够快速整理服务列表，展示所有服务的QPS和当前健康状况，进而逐层深入，查看上下游关系或服务及其数据库情况。这样的逻辑能够帮助我们迅速定位问题。这就是怎么做快速定位。
10.系统指标中的“数据SQL指纹”环节
在这个角落中，为什么会做SQL指纹这个事？这个事也是运维的一些经验，或是内部的一些故事，在数据库发布变更的时候，会发现在变更过程中，很多时候是服务端的故障，它相对容易发现，但往往问题最后会深入到数据库层面。这些故障点通常会高度集中，或者难以解决。此时，我们常常会遇到一个问题，即需要明确是哪条SQL语句导致了问题，即要准确找出责任源头。为了明确这一点，我们需要追溯SQL语句的来源。
在构建整个运维体系的过程中，我们发现某些SQL语句在执行过程中，可能会偶尔出现一句导致整个表被锁定，或者产生慢查询。那么，如何快速定位这些问题呢？
基于我们的服务发现、容器以及微服务的监控体系，我们会对所有SQL语句进行标签化处理，以追踪这些SQL语句是在哪个服务中产生的，产生了多少次，以及谁是第一个产生这些语句的。这样的逻辑使得DBA同学能够快速的发现有新的SQL语句上线，可能会对其进行进一步审计，包括分析语句中可能存在的问题，以便进行定向优化和SQL语句的优化方式，基于上述逻辑，解决了我们在SQL层面遇到的许多风险和运维问题。这是在整个运维过程中的经验分享，即要准确找出是哪个开发人员编写的SQL语句导致了问题。
最后，在探讨了服务端可观测性之后，客户端的可观测性同样至关重要。客户端可观测性面临的一个主要挑战是处理白屏事件。会发现很多的客户端反馈过来给我们一个白屏。那这个白屏事件怎么处理？白屏又是什么样子？往往再跟研发沟通的时候，研发说我这没问题，这肯定是运维的问题。那怎么去证明你的白屏是没有问题的？之后会找CDN供应商说我有白屏的事情，你帮我看一下，这个时候，CDN供应商会下IP地址等，帮你去排查。但是这些信息在我们客户端中是完全没有的，或在服务端数据上是没有的。所以基于这个体系，把所有CDN日志进行揽色，并把用户和服务端的日志进行串联。基于这些逻辑，把整体的网络数据从trans数据链路把它打通后，就能快速知道这个问题到底是由哪个CDN商的产生的。而怎么快速的定位整个过程？
11.UG的性价比
关于稳定性怎么做成本的平衡这是非常重要的，稳定性和成本是不平衡的点。关于稳定性，需要用大量的成本服务器去堆。并且还需要有成本的考量。关于识货，把整个稳定性和成本定义了4个月。规则是成本的计划，之后还要做资源的管理和监控、分析、成本的整体优化。围绕这四点，在整个过程中做了一个成本大盘，然后基于成本大盘，会对所有的云服务进行成本监控。包括对单用户的成本监控。控制整个运维过程中成本的维度，另外一个是会把所有的成本进行业务化的拆分。
因为业务团队是成本中心，而怎么把成本中心快速进行业务降本，不然的话永远会有一个问题是业务在挑战你，为什么要做降本。降本的原则是什么？因为业务是没有办法沟通的，是不平等的。因为一个是成本中心，另一个是业务利润中心。所以要把整个成本中心的成本进行转嫁，把它转嫁到业务中，并跟业务讲清楚优化的原则是什么。基于这个逻辑，会把整个业务进行拆分。最后一个是整体的预算。整体预算的管控是非常重要的。在初期，定义了整体的预算后，怎么把这些预算做整体的规划，使用量是什么样的，每个季度的使用量是什么样的，会把它进行整体的复盘。
最后是资源，因为现在的云厂商非常多，怎么把这些资源的进行整合是非常重要的。这四块是基于成本的管控。对于技术也会做成本的管控。包括在ECI、超卖，也会做突发的EC扩缩容。基于这些逻辑，也做了整体的规划。在这个过程中发现资源利用率从7%提升到了20%，基于扩缩容和超卖做整体的规划。稳定性这条路还是比较长的，我们也是刚刚开始做。
12.神盾安全管理
最后讲一下最近做的一些神盾的认证平台、磐石的上海的认证行动，其都符合安全合规的逻辑，关于稳定性将分成四块业务，分别是架构的稳定、可观测、性价比和安全，其中安全是稳定性中不可缺少的一部分。
