标签归档:稳定性

关于复杂系统的思考:从语雀服务中断想到的

在 10 月 23 日,语雀服务出现了一次重大故障,中断时间超过 7 小时。具体来说,这次故障的起因是在执行系统升级操作期间,新的运维升级工具出现了 bug,导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧,无法直接将其上线,这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作,但由于数据量大,恢复方案有限,恢复过程耗时 4 小时,数据检验耗时耗时 2 小时。这次故障给用户带来了严重的影响,也让我们重新审视关于本次故障带来的思考。

我将整个复盘报告输入给到 chatGPT,其给我的回复如下:

从语雀的这次事故中,我们可以学到以下几个关键的教训:

  1. 重视运维工具的测试和质量保证:在这次事故中,新的运维升级工具的 bug 是导致故障的主要原因。这说明,即使是运维工具,也需要进行足够的测试和质量保证。在实际使用之前,应该在相似的环境中进行充分的测试,确保其稳定性和安全性。
  2. 灾备和恢复系统的重要性:即使有了数据备份,恢复仍然可能需要花费大量时间,这会导致服务中断时间过长。因此,除了定期备份数据外,还需要建立有效的灾备和恢复系统,以便在灾难发生时,能够快速恢复服务。
  3. 灾难恢复演练的必要性:定期的灾难恢复演练可以帮助我们在真实的灾难发生时,更快地恢复服务。通过演练,我们可以发现并解决恢复过程中可能存在的问题,提高恢复的效率。
  4. 高可用架构的重要性:高可用架构可以保证在部分系统组件发生故障时,整个系统仍能继续运行。在这次事故中,由于存储系统的故障,导致了整个服务的中断。如果有高可用架构,即使某个组件发生故障,也可以通过其他的组件提供服务,从而减少服务中断的可能性。
  5. 灾难通信的重要性:在灾难发生后,应该及时向用户通报情况,说明故障的原因,修复的进度,以及预计的恢复时间。这样可以增加用户的信任度,减少用户的不安。在这次事故中,语雀做了很好的灾难通信,及时向用户报告了故障的详情,以及修复的进度。
  6. 持续改进和学习的重要性:每次故障都是一次学习的机会。通过分析故障的原因,我们可以找出问题,改进系统,避免类似的故障再次发生。在这次事故中,语雀提出了一系列的改进措施,这表明他们有持续改进和学习的意识。

但是从复杂系统的角度来看这个事件:复杂系统的性质使得它们在面临故障时,能够以我们意料之外的方式表现出来。尽管我们可能已经在设计和实施阶段做了很多工作来确保系统的稳定性,但是在实际运行中,仍然会出现我们没有预见到的问题。

高尔在讨论复杂系统时提到:「具备故障防备能力的系统出故障的原因恰恰就是故障防备能力的失灵」。这是因为在设计防备系统时,我们往往会基于我们对系统的理解来设计,但是实际上,系统的行为可能会超出我们的理解范围。当系统的行为超出我们的预期时,我们的防备措施就可能会失效。

这与这次语雀服务故障的情况非常相似。尽管语雀设计了一套备份恢复机制,但是在实际的故障中,由于对系统的理解不足,这套机制并没有发挥出应有的效果,反而延长了恢复时间。

在许多情况下,一些复杂系统的故障并不是单一的、孤立的事件,而是由一系列的因素相互作用、相互影响的结果。这通常包括了系统设计、运维策略、人为错误等多个方面。

具备故障防备能力的系统,其设计和运营目标是提供连续、稳定的服务,即使在面临内部错误或外部攻击等影响时也能持续运行。这种系统通常包含冗余的组件、自动故障切换机制、灾难恢复策略等措施,以保证系统的正常运行。

然而,这些故障防备能力本身可能成为系统故障的源头,原因可能有以下几点:

  1. 复杂性故障防备能力会增加系统的复杂性,复杂性本身就可能带来故障。例如,冗余的组件需要保持同步,如果同步机制出现问题,可能导致数据不一致,进而产生故障。

  2. 人为错误故障防备能力的维护和操作需要人工参与,人为操作错误可能导致防备能力失灵。如语雀故障案例中,运维工具的 bug 就是人为因素导致的。

  3. 预期和实际的差距:故障防备能力的设计和实施都是基于对可能故障的预期,但实际发生的故障可能超出了预期,导致防备能力无法应对。

面对一个每天都在演化的复杂系统,我们应该做些什么呢?

面对复杂,我们第一个能想到的原则应该就是 KISS 原则了。

「KISS」 原则是 「Keep It Simple, Stupid」 的缩写,这是一种广泛应用于工程、设计和决策过程中的设计原则。其最主要的理念就是保持事物的简单性。

KISS 原则主张:

  • 避免不必要的复杂性
  • 优先选择简单、清晰和直观的解决方案
  • 不要添加不必要的特性或功能
  • 简单的设计更易于维护、理解和修改

这个原则并不是说所有的事物都必须以最简单的方式来完成,而是鼓励我们在设计和决策过程中,优先考虑最简单和最直接的方法,除非有充分的理由去选择更复杂的方案。

简单性是一个非常重要的设计目标,因为它可以降低错误的可能性,提高系统的可靠性,减少维护的难度,提高效率,以及其他许多好处。

我们如果应用了以下的一些建议,应该可以往 KISS 原则靠近一些:

  1. 明确需求:首先明确我们试图解决的问题是什么。这有助于避免在设计和实现过程中添加不必要的功能或复杂性。

  2. 简化设计:在设计过程中,始终问自己是否可以把事情做得更简单。避免过度设计,只实现真正需要的功能。

  3. 模块化:把大问题分解成小问题,每个小问题都可以用简单的方式解决。这样,每个模块都保持简单,而整个系统则由这些简单模块组成。

  4. 避免不必要的优化:过早的优化可能会增加复杂性。除非确定优化会带来显著的好处,否则最好先实现功能,然后再考虑优化。

  5. 使用已有的解决方案:如果有已经存在的工具或库可以满足我们的需求,那就使用它,而不是从头开始创建。这样可以降低复杂性,同时节省时间。

  6. 代码和设计的清晰性:代码应该易于理解,设计应该直观。这不仅提高了可维护性,也让其他团队成员更容易理解你的工作。

  7. 定期回顾和重构:随着时间的推移和需求的变化,我们可能需要调整或简化现有的设计。定期回顾我们的代码和设计可以帮助我们找出可以简化的地方。

作为一个技术管理者应该作些什么呢?我认为最应该做的是拒绝那些让系统变得复杂的不合理需求,守好技术实现的大门。

面对复杂系统,我们需要对系统有深入的理解,尽可能地简化系统,避免不必要的复杂性。通过模块化设计,将复杂系统分解为相对独立的部分,每个部分都可以单独理解和测试。并且设计出健壮的错误处理和恢复机制,同时也需要进行持续的监控和回顾。只有这样,才能提升系统的稳定性,减少服务中断的可能性。

研发管理之生产环境的变更管理

2017 年,Amazon S3 服务在美国东部区域发生了大规模的故障,影响了许多依赖于 S3 的服务和应用。这次故障的根本原因是维护人员在执行一个操作时,错误地将更多的服务器脱机,这超过了系统设计的冗余容量,导致了该区域S3的部分子系统开始备份,进一步扩大了故障的影响。

2018 年 10 月 31 日 GitHub 通过官方博客发布了 2018 年 10 月 21 日「挂掉」的事件分析。GitHub 指出此次事件发生的原因是在 10 月 21 日 22:52UTC 进行日常维护——更换发生故障的 100G 光学设备时导致美国东海岸网络中心与美国东海岸数据中心之间的连接断开。更具体地 GitHub 分析,虽然两地的连接在 43 秒内恢复,但这次短暂的中断引发了一系列事件,这才导致了长达 24 小时 11 分钟的服务降级。

2020 年 7 月,Cloudflare 的 DNS 服务遭受了大规模的中断,影响了许多依赖其服务的网站。该故障的原因是 Cloudflare 的路由器中的一个错误配置。

以上是在网上搜索各大平台的故障描述,可以看到这些故障都是由于生产环境的变更导致的,有些是网络设备变更,有些是配置变更,有些是维护人员在线上执行了某个操作…… 如此种种。

这些问题最终都是开发人员通过系统化的建设,一个坑一个坑的填完了,但是当我们带着一个团队急速前进时,可能来不及做这些系统化的建设,此时通过流程对生产环境的变更进行管理,快速解决或规避一些问题以控制线上故障的出现。流程能保证的是我们做事的下限

在做生产环境变更管理流程之前一定要明晰生产环境的概念和范围,在团队内达成共识,然后再去做流程,以规避因为对生产环境的概念和范围不一致,导致的误解和乌龙。

1 生产环境的概念

生产环境,也称为「产品环境」或「线上环境」,是指实际运行并对外提供服务的环境。这个环境中的软件版本、配置和数据都应该是最新的、经过充分测试的,以保证系统的稳定性和性能。线上环境需要提供24小时不间断的服务。

一个应用或环境是否属于线上环境,主要取决于它是否直接对外提供服务。例如,如果一个应用接收并处理来自最终用户的请求,那么它就是线上环境的一部分。同样,如果一个环境中的数据被用于生产服务,那么这个环境也应该被视为线上环境。

通常,生产环境包括以下 4 个部分:

  • 硬件资源:例如服务器、网络设备、云服务中的硬件部分等;
  • 软件资源:包括操作系统、数据库、中间件、云服务中的软件部分等;
  • 应用程序:实际运行的业务代码和与之相关联的部分,如 CI/CD 工具;
  • 数据:实际的用户数据和业务数据。

定义了生产环境,从生产环境衍生出生产环境的变更。

2 生产环境变更的概念和分类

生产环境的变更是指在生产环境中对任何一部分进行的修改,包括应用程序的更新、配置的修改、硬件设施的更换等。而线上故障大多来源于生产环境的变更,对生产环境的变更进行管理和控制,在较大程度上可以减少对系统稳定性产生影响。

生产环境的变更从其组成出发,再加上外部流量,可以分为 5 类:

2.1 硬件资源变更

硬件资源变更主要包含所有与物理硬件和云服务硬件配置相关的更换、升级或维护。

  • 硬件规格调整:例如,升级处理器(CPU)、扩充内存(RAM)、更换硬盘等。
  • 网络设备更新:包括替换路由器、交换机或进行固件更新等。
  • 存储设备变动:磁盘扩容、存储设备更换等场景会包含在内。
  • 云服务硬件调整:如云计算服务中服务器规格的调整、增减虚拟机实例、增减 POD 数、网络设备变更等。

2.2 软件配置变更

软件配置变更涵盖了所有与操作系统、数据库、中间件以及云服务软件设置的修改。

  • 操作系统参数调整:比如,优化操作系统性能通过调整系统参数等。
  • 数据库设置变动:例如,数据库参数调整或修改索引,导致数据库负载提升甚至锁表导致的无法读写等线上事故。
  • 中间件配置更新:如修改消息队列的设置,调整缓存策略导致缓存穿越或者缓存雪崩等线上问题时有发生。
  • 云服务软件配置调整:包括了云服务的安全规则更新、网络配置变动等。

2.3 应用程序变更

应用程序变更主要包含了所有与业务代码和将业务代码发布到生产环境的 DevOps 工具的更改。

  • 代码变更:代码变更是我们最最常见的变更类型,主要是通过修改代码改变应用程序并通过发布系统发布到生产环境。这也是我们变更管理中风险最大的地方,因为变更的人,变更的位置和逻辑等都是不确定的。除了正常的发布变更,应用的回滚也是应用变更的回滚,因为其改动了线上的应用。实际中,代码变更在逻辑上包括了修复 bug、优化性能、增加新功能等,都需要对应用程序代码进行更新。
  • 配置变更:指应用系统的配置变更,一般是通过配置系统来变更,触发线上应用的热更新或滚动,配置如果是写死在代码中,会变为代码变更。
  • 依赖库更新:实际业务中需要对应用程序所依赖的库或框架进行更新,有些更新可能需要改代码,或者代码本身已经是这么个逻辑,在构建的时候就会带出去。
  • DevOps 工具变更:例如,升级工具版本,或者对某些功能进行调整。
  • DevOps 工具配置变更:如发布脚本中对于 dev 或 prod 环境的配置修改等等,都是高风险操作,线上有着血淋淋的故障。

2.4 数据变更

数据变更很少被人当作变更处理,因为很多时候就是正常的业务操作,如管理后台的批量操作这些,但是这些批量操作如果发生在高峰时期,可能会对线上业务带来较大的影响,轻则速度变慢,重则线上事故。数据变更可以分为线上数据的清理、迁移、更新等操作。

  • 数据清理:如定期删除过期数据,清理无效数据节省成本等等,基于不同的目的,将数据清除,除了可能会影响性能,如果清理错了,将会导致用户丢失,以至用户资产的损坏,这将会是很大的线上事故。
  • 数据迁移:如将数据从一个数据库迁移到另一个数据库,或者因为业务升级,数据需要从一种逻辑迁移到另一种逻辑,除了负载压力,更多的可能是数据错乱或者数据丢失,这两种情况都会引发用户投诉。
  • 数据更新:如前面说的管理后台批量更新,或者上线新模块在已有的数据库上初始化数据等等,这种最多的情况是其引发的 DB/ES 等存储类中间件的高负载导致服务的异常或引发线上事故。

2.5 流量变更

流量变更和上面四个类别不同,其是从外部来看的,主要包含了流量变化的情况。这里不考虑攻击类的流量。流量一般是带来高负载,或者由高负载引发的链路异常或雪崩,从而导致整体服务异常或线上事故。

  • 负载调整:如对调整负载均衡策略,更改流量路由等由于考虑不周引发某些节点过热或流量过大,引发级联反应,从而出现异常或事故。
  • 后台投放或大型促销活动:如没有提前通知的后台投放或大型促销活动、特殊事件导致的流量激增,可能需要进行负载调整或资源扩容等,如果某些链路存在容量上限,或者达到扩容的上限,就会引起线上异常或事故。

以上 5 种类型画成简单的脑图,如下:

图片

3 变更管理

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更,从而减少变更对业务和服务质量的影响,快速处理变更可能带来的问题,提升系统的稳定性。

变更管理,咱们从组织和流程机制两个方面来看。

3.1 组织

一个事情要想有力的执行下去,一定是有一个组织来保障事情的整体节奏和推进。

从组织的角度,整个变更管理的组织成员角色可以分为以下几种:

  • 变更管理主导者:一般来说,这个角色通常由技术团队的高级管理者来担任,并且这个事情它本身是一个从上向下的事情,需要更上层的负责人来推进事项,一般是 CTO 或 VP,或质量的负责人。他们需要确保变更管理策略和流程的成功实施,对整个变更管理过程负责,并需要对所有的变更决策拥有最后的决定权。

  • 变更管理委员会:这是一个跨部门的团队,包括来自业务、开发、运维、质量保证等部门的代表。他们的任务是评审即将进行的变更,评估其对业务的影响,以及是否符合公司的战略目标。他们还负责改进变更管理流程,并对变更管理的效果进行监督和评估。在实际的实施过程中可能没有正式的名称叫委员会,可能叫 XXX 质量小组,或者就是某个研发中心的管理团队兼任。

  • 变更经理:这个角色负责确保变更管理流程的日常运行,是实际的变更控制推进者,他们需要协调变更的执行,确保所有的变更都通过了必要的评审,已经准备好了回滚计划,并且变更后的效果已经得到了验证。在实际的实施过程中,变更经理大概率是某个 Leader 或者质量的负责人,或者 PM。

  • 变更执行人:这个角色负责协调变更的具体实施,例如安排变更的时间,通知相关人员,收集反馈,等等,一般这种变更由一线的开发,SRE 来做,也有大一些的公司有专门的职位。

3.2 流程机制

变更管理有一个理想状态的标准流程,其大概如下:

  1. 变更申请:在我们的流程中可能是创建发布记录,或者申请紧急发布
  2. 变更评审:变更评审主要是检查变更过程是否完备,以降低变更的风险,其包括如下内容:
    1. 就绪分析:材料是否完备,人员、设备、软件、网络是否就绪,测试是否达到上线要求等。
    2. 风险分析:架构、性能、业务、合规等方面的风险评估,变更内容是否属于需求范围,变更是否可控。
    3. 重要程度:变更属于一般、重要、紧急、标准哪一种。
    4. 变更审查:内容是否满足业务需求,内容是否通过测试,测试是否全面、有效。
    5. 应急管理:变更步骤、应急方案、回滚方案、应急预案是否完备。
    6. 变更实施:变更计划时间如何安排,发布及回退操作步骤是否完备,自动化步骤情况。
    7. 变更验证:变更涉及的业务、技术验证方法与时间安排。
  3. 变更审批:相关负责人对于变更评审的结果进行确认,并审批通过。
  4. 变更执行
    1. 根据发布计划执行发布操作,一般应该有一个灰度的过程;
    2. 验证线上功能并回归主流程;
    3. 持续灰度,观察用户直到灰度完成。
  5. 变更验收
    1. 对发布的功能进行验收,对于影响范围内的功能进行验收,对业务主流程进行回归验收;
    2. 留守,并观察日志、监控服务负载等,这个操作是为了及时发现验收检查漏掉的问题,或者及时处理隐藏的问题,以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰,还是僵化的惯性,还是能真正地解决问题,是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前,即我们变更线上环境前需要自己做 Code Review,以及交叉的检查,以尽量减少问题流转到后面的操作中,节省问题的处理成本。

在标准流程之外,另外还有两个特别重要的点,一个是周知,一个是盘点。

周知在形式上可以是邮件、群通知、群消息,通过这些方式,将研发自己做的前面所定义的线上变更周知给相关方:「我们做了 XXX 操作,可能会影响 XXX ,你们看下对你们自己有没有影响,如果有相关告警可以找我。」

变更虽然有流程,但是流程保证的是过程,对于过程中的问题通过变更盘点的方式,阶段性回顾问题和成果,在变更委员会中达成共识并继续迭代。在每次迭代的时候我们可以问自己如下的一些问题:

  • 与上次回顾相比,变更对线上的影响有更严重吗?有影响到稳定性吗?
  • 变更流程是否有什么问题,是否需要专项来解决?是否应该解决?
  • 上次回顾安排的事项落实了吗,对应的情况如何,是否有更新到流程或系统中?

以上的回顾操作我们建议以某个管理系统来承载,并且这个管理系统是带有通知等功能,以更好的将变更相关的信息周知出去。当然,也可能直接共享文档+群通知来搞。

4 小结

上面的变更管理只是流程方面的,对于实际中变更管理最好是能在类似于 DevOps 系统中的落地,最少也是在项目管理或流程系统中落地。

生产环境的变更管理是一项复杂而重要的任务。通过对生产环境的良好理解,结合有效的组织、流程和系统工具,我们可以实现对生产环境变更的有效管理,保证业务的稳定运行,提升用户的使用体验,同时也提升了我们自身的运维效率和质量。这也是我们做研发管理必须要完成的任务之一。