稳定性建设

本文是根据业内分享、公司规范、个人经验整理而来,希望能为您在提升系统稳定性方面提供参考。稳定性的建设有人的因素,也有技术的因素;对于人的因素,从流程和规则的角度去治标,见效快;对于技术的因素,结合具体业务,从编码和架构的角度去治本,但是周期长。

一. 熟悉系统业务

稳定性建设的前提是熟悉您负责的系统和业务,请尽用一切方法熟悉系统和业务,理清上下游依赖。

 

系统业务属性

您必须熟悉所负责的系统业务,明白该业务在公司技术体系中的作用和价值,是否为核心应用,即涉及公司核心业务的应用;熟悉其部署、架构和维护,并对源码有较好的掌握。以电商场景为例,涉及用户登录、搜索、浏览、购买、交易等的服务均为核心应用,对于核心应用,请保持谨慎和敬畏之心。

 

上下游依赖

规模越大的公司,其系统越是繁多,依赖关系越是复杂,往往环环相扣。对于您维护的系统,你应当理清上下游依赖,特别要知晓,自身服务故障对下游的可能产生的影响范围和程度。对于故障后果严重的业务,请保持审慎意识。对于上下游依赖,要明确交互方式,做好异常处理,做到合理依赖。

  • 严禁依赖闭环:服务依赖关系应当类似向无环图,禁止服务依赖闭环,严禁服务之间调用闭环。
  • 上游依赖(您依赖的应用):熟悉上游 API 的特性,如:retry 机制、timeout、幂等性、异步回调等等,采用合理的姿势调用上游的 API。对于非核心应用的上游,一般要做好熔断和降级措施,尽力避免上游的故障影响您的服务。
  • 下游依赖(依赖您的应用):让下游采用正确的姿势使用您的 API,对于流量大的服务建议做好限流措施,如果您的系统故障不会影响下游的核心功能,建议督促下游做好熔断和降级措施。

关于熔断和限流,在本文第三节会进一步讲解。

 

二. 变更的规范性

SRE has found that roughly 70% of outages are due to changes in a live system.

在本文中,变更指修改代码、配置、数据等操作。

 

变更流程规范

  1. 严格遵循本地开发环境 -> 开发环境 -> 预发环境 -> 线上环境的发布流程,严禁未经上一个环境测试的代码提交到下一个环境。
  2. 可分批次的发布务必遵循分批次灰度发布,每发布一批应观察一段时间,确保无误后再执行下一批发布,如此在故障场景下可减小故障范围。同时做好回滚措施,异常场景下可缩短故障时间。
  3. 发布的过程中,必须关注业务监控指标、告警等。
  4. 存在风险或者重大的变更必须通知受影响业务方,做好应急措施。

 

变更时间规定

  1. 严禁在重要活动、节假日前后发布,默认情况下,周五也不准搞事情(发布)。
  2. 严禁在业务流量高峰时间段发布,对于一般的变更,请在周一至周四中低峰时间段发布,对于重大变更,请在凌晨发布。

 

变更频率规定

每次发布可能会耗费较大的精力和时间,更多的发布往往会带来越多的故障次数,故需要控制变更频率。一般而言对于同一个应用,建议其发布次数控制在一周一次以内。

Coding

  1. 大特性开发、架构的设计等必须有设计文档,必须经过小伙伴们的评审。
  2. 规范编码,您的编码风格必须遵循业界或者公司规范,并养成注释习惯。
  3. 充分测试,包括单元测试,集成测试,越是动态的语言,越需要关注单元测试。
  4. 互相 Review,养成良好的提交规范。
  5. 逐步建设好 CI/CD 平台,并基于 CI/CD 平台固化开发,测试,上线流程。

 

告警

  1. 日常告警明确 Owner,Owner 必须关注手机短信,保持电话畅通。
  2. 太多的告警等于无效告警,优化告警配置,减少误报、漏报的概率。

 

三. 架构的规范性

或许因认知、或许因项目紧急,有些应用的架构设计的不够合理和规范,埋下了隐患的种子。架构的优化和建设是一个长期投入的系统工程,也是一剂治本的良药。

 

应用标准化

如果您的公司针对 Java 等常见语言制定了项目规范,请遵守该规范,否则请遵守开源的项目规范,良好的处理代码、文件、配置等目录结构。

大部分应用为非存储服务,请务必将其设计成无状态,即数据和业务逻辑分离,以便横向扩容和故障恢复。对于状态数据,必须存储到对应的存储服务中。

 

遵循基础组件的使用规范

对于各种基础组件,如数据库(MySQL,NoSQL 等)、中间件(Tesla、Kafka、Redis 等)、大数据等服务(HDFS、Spark、Storm 等),请采用严格遵循公司或者业内的良好实践进行使用。例如:

Redis

  • 严禁用于存储持久化数据。
  • 注意雪崩、缓存穿透问题。
  • 致力缩短数据不一致的时间,变量数据一定要设置 TTL。

 

MySQL

业务量小的应用可以直连数据库,业务量大的应用可以以中间件访问数据库,以获得更高的性能。

  • 删除、变更数据请谨慎操作,务必 double check。
  • 其它规范,如命名规范,表设计规范,外键规范,字符编码集等规范。

 

高可用

线上系统应该设计成高可用架构,避免单点故障影响业务。无状态应用的高可用建设相对简单,有状态的高可用会复杂许多,高可用的建设和优化应当充分分析和评审、逐步建设。

 

限流 & 熔断 & 降级

对于高流量的核心在线服务系统,应该有限流、熔断、降级相关方案。业内有非常多的开源项目,如 Google Guava 项目,SpringCloud 中的 Hystrix,请可以基于这些项目快速实现限流、熔断和降级。

 

故障演练 & 压测

对于核心系统,特别是在线系统,待高可用、熔断、降级等方面有一定基础后,可在业务低峰时期做好预案措施,进行故障演练。故障演练是一项系统性的工作,需要针对各自业务特点设计演练方案,从演练中发现薄弱点,并进行改进。

您可以使用压测系统来专门压测您的服务,分析性能瓶颈、评估容量,但是压测过程中不得影响业务。

 

最后

防火胜于救火,请严格遵照上述措施防范未然、尽力避免故障。当故障发生时,根据情况决定是否要第一时间通知受影响的业务方,首先恢复服务、恢复服务、恢复服务,其次恢复数据,最后才是定位问题和整改,即缩短故障时间、减少故障范围、降低故障影响面。

总而言之,我们应该降低系统复杂度、增强系统健壮度、提升对系统的熟悉程度,按规范操作。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

昵称 *