稳定性综述(精)

关于后台稳定性建设的系统性思考

稳定性建设的根本目标是保证后台系统持续、可靠地为业务提供服务。具体来说,需要从以下几个维度来考虑:

  • 可用性:系统在约定时间内正常提供服务的能力
  • 可靠性:系统在规定条件下和时间区间完成规定功能的能力
  • 可维护性:系统易于进行故障诊断和修复的能力
  • 可扩展性:系统能够通过扩容来适应业务量增长的能力
  • 安全性:系统抵御各种外部攻击、非法访问、数据泄露的能力

基于过去的一些经验,对稳定性的建设做一个相对系统性的思考,

总共有 7 点:运维、高可用架构、容量治理、变更管理、风险治理、故障管理、混沌工程。

 https://mp.weixin.qq.com/s/1Yy5axBTiaH9q-AaM7cH0g

 

换个角度聊系统稳定性建设

对于任何系统来说,系统稳定性都是最基本的一个要求,只不过每个项目都有其发展周期,

每个周期都有其主要的发展目标,比如业务爆发初期我们要求业务快速迭代,业务发展中期我们可能更多的是要求精细化运营、精细化治理,业务发展后期我们主要围绕于降本增效做事情,但是系统稳定性基本是贯穿整个项目发展周期。而且我们未来是要做SaaS产品的,稳定性更是SaaS的基石。

系统稳定性关心的是:服务与数据。
稳定性主要解决的是:容错与恢复。

原则

  • N+1设计原则:系统中每个组件都应做到不会出现单点故障;

  • 可回滚原则:确保系统可以向前兼容,在系统升级有问题时,可以快速回滚版本;

  • 可禁用原则:应提供控制某个功能是否可提供服务的配置,在出现对应故障时,可以快速禁用该功能;

  • 可监控原则:确保核心指标、核心链路可监控,开天眼在问题发生之前发现问题;

  • 数据库多活设计:如果系统有极高的可用性要求,可以考虑多机房、跨地域的容灾保障,保障在自然灾害或是机房断电时,系统仍然可对外提供服务;

  • 采用成熟技术:新框架或新技术往往存在一些未可知的bug或问题,如果没有很好的文档或是商业支持的话,尽量避免过度采用新技术;

  • 水平扩展设计:系统只要做到可水平扩展,就可以有效避免瓶颈问题;

  • 非核心则购买:非核心功能如果需要占用大量的研发资源才能解决,可以考虑购买成熟的产品或解决方案;

  • 小功能快迭代:将系统拆分成多个具有单一职能内聚的模块,减少牵一发动全身的风险,快速开发,尽快验证,早发现问题降低交付风险;

  • 代码Review:每次迭代上线,团队尽量做到Review代码,多一双眼睛便于发现一些潜在问题;

  • 高峰期值班制度:每个业务的流量峰值可能不同,有的业务高峰期如果出现在上下班时间段,很多同学在路上,出现问题之后没人值班,无法操作降级预案,就不能快速止损;

  • 例行压测:如果你的业务是每天面对流量洪峰的,那么例行压测很有必要;

  • 例行演练:有了预案要例行执行,判断预案是否还可用,不然哪天有问题了,预案反而不敢操作了;

 

https://mp.weixin.qq.com/s/tctMx3FxmrJ-Jy3X7W8dWw

 

如何构建坚不可摧的服务可靠性体系?

 

 

 

 https://mp.weixin.qq.com/s/idP_uz7IYRf9eUzDOq6tag

 

系统稳定性实践50篇

https://mp.weixin.qq.com/s/cm1VNLtVPaM4XNJsuvLeQA 

 

 

 

 

关于前端稳定性建设的系统性思考

https://mp.weixin.qq.com/s/0jQR2BP78XReMjZDgE1WgA

 

拒绝组团宕机!关于缩短MTTR的万字探索

https://mp.weixin.qq.com/s/oxnp6M8rmzsHI4qTNDgdxA

 

B站点

 https://mp.weixin.qq.com/s/gZAuZy4hsmJAeA0tFuAhGA

 

可用性治理

 

升级手段

 

 

 

 

 

 

 https://mp.weixin.qq.com/s/OQcWdK_x0DOjQNR2G7nDTQ

 

深刻理解软件系统的复杂性-业务,技术,管控治理三者的多维叠加

软件复杂性=业务*技术*治理

对于业务复杂性,我们经常说的思路或解决方案包括业务建模、领域建模、MDA(模型驱动设计)、组件化、模块化、SOA横向分层,包括当前主流的微服务架构设计和微服务的拆分。这是从业务角度我们要去做的事情。

对于技术复杂性,更多的是我们在谈纯技术架构上面,如何支撑整个软件系统的高可用和高并发。对于这一块,我们经常谈到的类似于集群、分布式架构,负载均衡、数据库底层的水平拆分垂直拆分、读写分离、消息中间件、缓存、分布式事务处理等,我把它纳入到技术复杂性。

对于治理复杂性,则是一个系统上线完成后,你怎么样去运维、监控、观测它,以及如何应对软件系统后期的变更。在这个地方更多的解决思路首先是要做好底层的过程支撑,类似于研发过程管理、当前谈的比较多的DevOps的持续集成和持续交付,包括从资源到服务、从服务到应用的整体IT资源服务、应用链路监控,包括类似于混沌工程、面对可观测性的设计,都可以把它纳入到管控治理层面。

https://mp.weixin.qq.com/s/nMAi2Q4QYU3sn70e5U9M2g

posted @   人在江湖之诗和远方  阅读(62)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
历史上的今天:
2018-07-30 经典场景的设计方案整理
2018-07-30 redis的底层数据机构
点击右上角即可分享
微信分享提示