稳定性保障的一点总结

原创
2020/08/20 14:19
阅读数 60

业务系统最重要的是什么?

“稳定,稳定,还是tm的稳定”

什么样子的系统才算做稳定的系统?

假设一个场景A,你需要上线一个新的需求A,涉及功能B的改动,有依赖于B功能的服务C和D,你上线的时候不确定B的改动是否会影响C和D的业务,这种系统是稳定的系统吗?

再假设一个场景B,有用户反馈,有时候操作A功能的时候,响应比较慢,但是比例非常的小,上线为止收到过几起这样的反馈,那么这种情况下,系统是稳定的吗?

最后一个场景C,业务A上线之后,切流了一部分用户使用,目前没有相关使用不良的反馈,现在这个功能或者说这个系统能接入核心链路吗?

系统稳定的几个特征

可预测,可监测,可处理

可预测:

可预测包含正常流程处理(关联方影响范围预估),异常链路处理,灰度流量切换数据影响等等;总结起来简单就是一句话,上线的业务需要清楚影响范围是什么。

可预测范围内的结果,不仅仅是在设计阶段的可预测,还需要能够进行预测结果的验证。进行线上故障的模拟包括(存储、应用、第三方资源的异常模拟),用来确认预测结果的正确性,以及预案处理的正确性。

可监测:

这部分更多的是系统运行态的监测;更多的用来感知系统健康度的,也是实操性比较强的部分,就像医院有多种仪器来检测你的身体状态;监测指标有多项,主要包含 业务监控、系统应用监控;

业务监控:一般上线都需要对于核心业务进行大盘监控,来进行相关业务指标的监控,包含流量监控,异常监控等等
系统应用监控:这部分可能更关注于细节或者技术方面;
    例如是java系统,机器/容器相关的指标需要进行监控,内存,负载,磁盘io,网络流量,gc情况;
    外围接口的访问成功率,RT,流量 等指标也是需要关注的,包含环比和同比;
    中间件相关的指标,MQ的堆积,SQL的执行频次及效率;
    应用系统自身异常日志的打印,分布式应用集群的负载及整体健康状况。整体链路多阶段的任务巡检(例如核心流程较长,需要异步化处理导致可能部分数据假死情况,也需要巡检机制介入)。

可处理:

这部分的关注点是系统运存不符合预期后续的处理措施,需要是及时的,有预案的,简单可实操的;例如灰度过程中产生异常能够迅速的处理;上线功能A和B之间有关联影响,有兜底策略处理,有相关的止血方案;

系统的稳定一些实践:

1、架构设计阶段:

  1.    明确系统间交互的依赖关系,核心链路系统不依赖非核心系统,系统间要有合理的解耦方案;
  2.    异常流程有兜底处理,保证数据的完整性;
  3.    接口设计/调用 之间预估流量,做好系统的保护;
  4.    做好资源、服务相互之间的隔离性,对于中台化或者多租户的业务场景,需要尽可能的控制故障发生的爆炸半径,这个需要做到隔离性

2、编码阶段:

   编码设计阶段,使用相关设计模式,遵守开闭原则,降低功能修改带来的业务不确定性;
   统一的内部编码规范,模块之间相互独立,层于层之间有明确的界限;业务日志/系统日志打印的规范性,对于业务流程点做好相关埋点,为及时发现问题、定位问题、解决问题提供一手的现场;

3、上线运行阶段:

   统一的上线流程规范,降低上线中的风险;
   线上运行必须要相关的监控机制,谨慎对待线上的每个异常情况;
   建立自动化的业务分析(之前的大盘等),提供分析数据来源,建立数据化,可视化的系统概览;
   系统依赖的基础设施,需要分析(大部分基础团队有相关分析,可以不用过度关注,但是对于影响业务场景的还是需要自己进行分析,例如慢sql和top sql之类的);

4、其他:

  1.    稳定性定时演练(压测、故障演练等);
  2.    变更流程化,配置变更/数据变更需要有审批或者双向校验的过程,降低人为变更带来的错误风险;
  3.    组件使用最佳实践沉淀,控制不当使用风险持续蔓延,信息交互,降低 重复问题产生风险及概率
  4.    意识大于一切,培养人员稳定性意识,面向失败设计、面向失败编码、线上问题的及时响应及关注是稳定性最重要的心智。
展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部
返回顶部
顶部