jackl

从理论、方法、实践多维度阐述稳定性、从全局视野出发、由内到外、从组织到文化，从风险识别到风险预防、从面向失败到主动失败多个阶段，多维度去描述如何打造一个高可用的系统。

因此，在设计秒杀系统时，需要考虑如何处理高并发请求，以及如何避免系统崩溃或性能下降。事务处理：在秒杀系统中，商品的库存数量是有限的，需要保证库存的准确性和一致性。因此，在设计时需要考虑如何采集、存储和分析采购相关的数据，并提供可视化的报表和指标。在系统架构设计上，采购系统和秒杀系统是两种不同的应用场景，它们在设计上会有一些区别。负载均衡：秒杀系统需要考虑如何进行负载均衡，将请求均匀地分配到不同的服务器上，以避免单点故障和提高系统的可扩展性和可用性。具体设计时还需要根据实际需求和业务场景进行综合考虑。

在谈容量规划之前，首先要知道我们的系统处理能力有限的，不可能是无限的，处理能力的限制取决于资源的限制，生活中很多这种例子，例如喝水的水杯，也是有容量限制的，超出容量限制，则溢出，再例如高速公路双向四车道、六车道、八车道等等，那么可以并行的车辆限制这取决于车道数，这里的车道数指的则是资源，那么在建设高速公路时，肯定会做相应的规划是四车道还是六车道合适，结合当下和对未来的预测从而规划和设计，对于我们的系统也是如此，要清楚的了解系统处理能力，资源使用率、容量规划等情况。

故障处理流程大致可分为预防、发现、定位、止损几个大阶段，其中发现、定位、止损这三个阶段是处理故障现场的重要阶段，决定了处理故障的处理效率，能否在最短的时间内止损，故障处理效率也和我们的架构设计及基础建设有着密不可分联系；架构设计决定了我们的系统是否面向失败设计，基础建设决定了我们处理故障的效率，是否能够通过基建的可观测性先于用户发现问题、定位故障的根因、做到及时止损。

在复杂的分布式系统中，无法阻止这些故障的发生，我们应该致力于在这些异常行为被触发之前，尽可能多地识别风险。然后，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。

在分布式软件系统中，故障的发生时必可避免的，故障处理时每个系统都要面对的现实问题，但是随着系统越来越复杂，故障的发现、定位、处理难度也就随之增大，从可靠性的角度故障可以分为两个方向：主动预防故障发生、防止故障在系统扩散，本章节主要讲述如何防止故障在系统扩散、故障的发现、定位、止损的处理方法。

流程机制旨在于提高工作效率，使流程规范化，上线日是很严肃、很正式的事情，要能够敬畏线上，为了降低发布过程中可能面临的风险，通常情况下良好的上线流程机制来帮助我们少犯错误，约束上线流程，并将整个上线的工作准备更严谨、充分，能够让我们更重视此次上线，因为在上线的过程可能面临很多意想不到的问题，这都将为我们上线带来很多风险。

随着用户规模逐渐增长、产品的更新频繁，新版的每次上线，各方都要承受极大的压力，一旦产品发布出现事故，可能影响的范围和损失都比较大，为了解决产品发布过程中的风险控制，要有部分的用户参与到新产品中，体验使用观测其真实反馈，如果没有用户的参与，直接面对全量用户，那么风险是可想而知的。

在很多互联网公司依然凌晨才能够上线，上线那天面临各种突发情况，导致通宵上线，这些问题都很常见，经常因测试不周且频繁版本变更，及未经充分验证的代码，在线上直接运行出现故障屡见不鲜，适当的变更有助于减少故障的发生，但是无法杜绝后患，在这种情况，如何降低或减少未经验证的代码出现在线上环境，如何在上线日释放人力并有效改善现状。...

通常我们谈到稳定性，必然能够想到SLA，谈到SLA离不开SLO、SLI这两个，SLI是衡量系统稳定性的指标，SLO是服务等级目标，也是我们设置的稳定性目标，例如3个9、4个9等，那么SLA更多是其实对付费的客户的承诺，多数情况下我们聊的是SLO服务等级目标，通过衡量SLO来判断系统的稳定性。

对于跨服务通信，而服务所有者归属不同团队所管理，服务等级协议提供了服务间沟通期望机制，也称之为期望管理，服务等级协议是提供某种级别服务可靠性和性能的承诺，对于业务双方是一种约束，双方在这样的约束下开展后续的工作，服务等级协议还可用于企业与用户之间法律或者合同协议，本章节更多讨论内部之间服务等级协议，如什么是服务等级协议，服务等级协议作用。......

服务分级是稳定性建设不可缺少的一环，通过上述章节我们了解到服务分级、服务分级的方法，服务分级目标是为了能够清晰知道我们的服务分布情况，哪些服务一旦出故障是必保的，哪些服务出现故障时可熔断、降级、隔离的，只有通过服务分级通过标签来识别系统的级别，这样在架构设计上不论是关注程度还是资源都需要更倾向高级别的服务，高级别服务的稳定性也是整个系统价值的体现，服务分级的重要性主要体现在以下几方面。......

服务如何分级理应是明确产品或者系统为用户提供的最核心价值是什么，什么是附加值，核心价值是为了解决用户最核心的问题，而附加值可能是为用户增加更好的体验。每一个产品或者系统中都有会那么几个点是最最核心的，真正为用户解决痛点问题的，通俗说也就是产品中哪些功能是用户经常用的，不能缺少的，而并非所有的功能用户都是核心的功能，例如在线教育产品，最核心功能肯定是购课、上课、课后报告，其他的都是围绕这些去建设的，丰富提升用户体验；...

服务分级是通过识别服务对于业务影响的重要程度，为服务关联标签，通过标签区分出各个服务的重要程度，哪些服务是关键服务和非关键服务，我们系统中的所有服务都必须要有对应的标签，不论什么样的服务，服务分级某种意义是上让我们更清晰和管理服务依赖的方法，只有划分不同的级别服务，这样不论在架构设计还是资源上都会更倾向和关注级别高的服务。如果不能对系统中的服务分级，那么所有服务的级别都是一样的，这样就导致在架构设计时区分不清主次，一视同仁，一旦某个服务出现故障，可能是因为边缘服务，影响整个系统，影响也是非常的恶劣。...

你知道什么是长尾问题吗，带来的影响有哪些，应该如何去解决它呢

告警与可观测性有这密不可分的关系，告警是先于用户发现问题的手段之一，如果没有告警系统，只能通过人工进行定期检查，即便是能够发现问题也不能立马定位到问题出现的原因，而且成本和效率也非常低下。告警用途主要有两个方面，首先是通过监控数据，能够做到先于用户发现问题。告警系统通过对监控数据指标量化，监控数据变化，一旦发现问题之后，可以快速报给相应的工程师，快速处理问题，这样能够提升解决问题的效率，从而提升用户体验，而不用等着用户过来反馈问题，其次是能够通过聚合相关指标快速定位问题，结合可观测中的Log、Metrics

在互联网高速发展的过程中，随着分布式、微服务、容器化架构的流行，互联网已全面进入云原生时代。构建系统的方式由最初的单体大应用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把系统运行状态可视化的难度。为了应对上述情况，希望能够对系统进行360全方位立体化的监控，于是可观测性概念应运而生，可观测性的提出最早来自于 Google 著名的 SRE 体系和 Apple 工程师 Cindy Sridharan 的博文《Monitoring and Oberservability》也就是说在可

什么是黑/白监控黑盒监控所描述的是监控外部用户可见的系统行为，主要关注的现象，重点在于对正在发生的故障进行监控告警，例如，某某网站打不开了，或者服务挂掉了，无法为用户提供服务。白盒监控所描述的是监控内部暴露出来的关键指标，主要关注的原因，重点也是关注其发生的原因，例如服务挂掉了，是什么原因导致的呢，是内存溢出还是服务过载，这些是导致服务挂掉的原因。两者区别是一个对外，通过外部现象、另一个对内，通过对内究其原因，两者监控维度也不相同：监控维度不同，黑盒更偏向外侧，可以理解通过某个功能或者接口来

在传统的软件开发方法中，每一个小的功能更新或Bug修复都会每隔一段时间分开发布，这极大地增加了变更在部署时被耦合的几率。随着时间推移，问题开始增多，给整个团队带来了更多的挑战。最糟糕的是，所有的流程都是手动的，而且这些产品大多是单独开发/测试的。很显然，它将变得更容易出现人为错误。往往变更是主要引发系统故障的主要因素之一，故变更的可见性变得尤其重要，常见的变更包括服务变更、配置变更、数据变更；变更可见性是通过各种手段对变更的内容、行为、时间进行多维进行管理和监控，便于后续的审计和分析。变更是引发系统

监控在稳定性建设起到很重要的作用，在Google SRE中有一个描述系统可靠性基础和高层次需求，金字塔那张图的底层就是监控，这个是一个系统对问题稳定性最基础的要求，缺少监控的系统，如同蒙上眼睛狂奔的野马，无从谈及可控性，更遑论稳定性，其中可见可观测性包括服务可见性、变更可见性、系统可观测性，如何利用可见可观测性来全方位的观测我们的系统呢，下面让我们一起学习。服务可见性服务可见性顾名思义是将我们暴露的服务通过某种形式就展现出来可视化，例如 服务本身元数据，服务所有权、服务SLA、服务所有权，服务注

自我保护自我保护是字面意思就是，通过对自身的防护，将自我保护好，避免受到外界伤害，在软件行业对架构设计时对系统本身的自我保护，防止服务因各种原因导致自身挂掉，从而提升系统的健壮性和鲁棒性。生活中这种例子也有很多，比较常见，如骑摩托车时，必备的防护装备有：头盔、护膝、护腕、手套等，通过这些行为来对自我的安全防护。健壮性健壮性是指软件对于规范要求以外的输入情况的处理能力。所谓健壮的系统是指对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式，健壮性有时也和容错性，可移植性，正

稳定性之面向失败设计【过载保护】在互联网架构中，高可用架构设计很重要的一个抓手就是过载保护，所谓的过载保护，是指当系统负载超过该系统或服务的承载能力时，系统会自动采取保护措施，确保自身不被压垮，从而提供有损服务，如果系统不能进行自我保护，很可能会导致雪崩现象。下面通过12306网站的案例，详细解释下过载保护的重要性，12306初期开始网络订票时，每次春运抢票，12306网站都会卡顿，瘫痪，网站打不开等各种情况，原因是流量突发剧增，系统未做过载保护，才出现以上的情况，那么后来它是如何改进的呢，改进

鲁棒性（robustness）其意思是健壮和强壮，就是系统的健壮性。它是指一个程序中对可能导致程序崩溃的各种情况都充分考虑到，并且作相应的处理，在程序遇到异常情况时还能正常工作，而不至于死机。所谓“鲁棒性”，是指控制系统在一定（结构，大 小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。比如说，计算机软件在输入错误、磁盘故 障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性

前言在互联网系统中，每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，那么就需要各种手段或者策略，来保证系统的稳定性、可用性，系统以牺牲部分请求或延迟处理，来提供有损服务，从而保证系统整体或者核心服务是可用的，本章节讲解关于稳定性设计的一些方案，包括高可用的三大利器，例如限流、降级、熔断，另外讲解关于稳定性的方面架构设计技巧和方法。“Everything fails, all the time”，无论是在传统软件时代还是在互联网、云时代，系统终究会在某个时间点失败

及时复盘复盘，本是一个围棋术语。指下完棋，棋手重新摆一遍下棋的过程，探讨得失，总结有无更好的应对招数。而现在，这个词已经被泛化，许多企业把它赋予了管理学意义。联想最早引入“复盘”这个概念，是在上世纪80年代。那时候，更多的叫法是“总结”。什么是联想式“复盘”？在这里，复盘分为四步：回顾目标、评估结果、分析原因、总结经验。复盘的过程有四个步骤，简而言之就是：第一，回顾目标，时刻别忘了当初出发的目的，需要一遍一遍的回顾和澄清；第二，对照当初的目标回顾过程、评估结果；第三，剖根问底分析原因

提前预防提前预防是告诉我们从失败中学习，防止同样的故障再次发生，海因里希法则告诉我们，一次重大事故的背后必然有一百次未遂事件和几十次轻度损失。这个法则对于我们有两个启示：一是事故的发生必然有其关联起因和先发信号；二是事故发生前一定有足够的提示，我们要及时遏制苗头，防患于未然。从失败中学习吸取经验教训，例如每次出现事故，都需要对事故进行复盘，分析和总结事故原因，包括事故处理过程，包括后期的改进措施，海因里希法则，通过本次事故发现其他可能存在的隐患，而非针对此次事故。例如：数据库慢SQL，拖

稳定性之提升团队潜意识【减少人工操作、敬畏之心】

循环依赖：是一个非常容易发生的坏味道，对系统的健康具有巨大的危害；谨慎变更：是为了提高系统的稳定性，也是稳定性建设尤其重要的一环，原因是线上90%的事故或故障都是变更引起的，对于谨慎变更这块，一方面通过变更规范性加文化意识宣贯引导，约束变更让变更更加的规范性，尽可能将风险提前暴露和消灭掉，另一方面通过变更三板斧对变更过程中的故障进行管理，包括变更过程的故障发现、故障预警、及时止损，减小影响范围。

稳定性之如何提升团队潜意识植入根【及时止损、监控报警】

架构设计首先依据是基于业务需求，其次架构设计是经过系统性地思考, 权衡利弊之后结合现有资源约束下的最合理决策，最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则. 并由它来指导团队中的每个人思想层面上的一致。可以包括但不限于以下几方面：1、系统性思考的合理决策：比如技术选型、解决方案等。2、明确的系统骨架：明确系统有哪些部分组成。3、系统协作关系：各个组成部分如何协作来实现业务请求。4、约束规范和指导原则：保证系统有序，高效、稳定运行。什

系统高可用建设，如何有条不紊地应对风险？

什么是高可用，如何度量系统的可用性，构建高可用系统面临哪些难题，及影响高可用的因素有哪些呢