- 综合排序
- 最热优先
- 最新优先
- 来自专栏老张的求知思考世界
为什么要做稳定性保障？
以前写过不少和稳定性相关的文章，其中介绍了不少稳定性保障的实践案例和方法，比如全链路压测和服务治理，这些案例和方法更多的是技术层面解决问题的方法和手段。但为什么要做稳定性保障？如何理解稳定性保障？ 这篇文章，我想聊聊我对于稳定性保障的理解，以及稳定性保障对团队带来的价值。 什么是稳定性保障？ 通俗来说，稳定性是一个很抽象的术语，各人有各人的解读。 如果要给稳定性保障一个比较通用的定义，那这个公式大概是成立的：稳定性保障=良好的架构设计实现+完善的软件研发交付流程+持续的线上应急机制和方法+专业的技术团队+优秀的项目管理和团队协作。 为什么要实践稳定性保障 基础技术设施和稳定性保障体系的建设，是业务长期倒逼的产物。举个典型的例子：双11大促。 总的来说，稳定性保障对业务的价值在于：保证用户体验，满足业务诉求，支撑业务目标达成。
83620编辑于 2023-08-09 - 来自专栏Java技术栈
微服务如何保障稳定性？
注册中心如何保障稳定性 注册中心主要是负责节点状态的维护，以及相应的变更探测与通知操作。一方面，注册中心自身的稳定性是十分重要的。 节点信息的保障 我们说过，当注册中心完全宕机后，微服务框架仍然需要有正常工作的能力。这得益于框架内处理节点状态的一些机制。 本机内存 首先服务消费者会将节点状态保持在本机内存中。 服务消费者如何保障稳定性 一个请求失败了，最直接影响到的是服务消费者，那么在服务消费者这边，有什么可以做的呢？ 服务提供者如何保障稳定性 限流 限流就是限制服务请求流量，服务提供者可以根据自身情况(容量)给请求设置一个阈值，当超过这个阈值后就丢弃请求，这样就保证了自身服务的正常运行。 重启与回滚 限流更多的起到一种保障的作用，但如果服务提供者已经出现问题了，这时候该怎么办呢？ 这时候就会出现两种状况。
1.6K20发布于 2021-05-11 - 来自专栏CNCF
Kubernetes 稳定性保障手册 -- 日志专题
不论对于软件的用户还是开发者，日志都是很重要的信息源。日志可以用来表征软件的运行状态，在软件运行不符合预期时提供丰富的信息，也可以用在开发阶段调试软件，方便定位问题。
74010发布于 2021-03-15 - 来自专栏得物技术
系统稳定性与高可用保障
今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。 > 本篇文章只聊思路，没有太多的深入细节。阅读全文大概需要5~10分钟。 要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。 三、影响稳定性的因素 首先我们先梳理一下影响系统稳定性的一些常见的问题场景，大致可分为三类： 人为因素 不合理的变更、外部攻击等等 软件因素 代码bug、设计漏洞、GC问题、线程池异常、上下游异常 硬件因素 四、提升稳定性的几种思路 4.1 系统拆分 拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。 如何做好稳定性和高可用保障是一个很庞大的命题，本篇文章没有太多的深入细节，只聊了整体的一些思路，主要是为了大家在以后的系统高可用建设过程中，有一套系统的框架可以参考。最后感谢耐心看完的同学。
1.2K21编辑于 2023-06-06 - 来自专栏云计算与大数据
Kubernetes 稳定性保障手册：洞察+预案
作者 | 悟鹏 《Kubernetes 稳定性保障手册》系列文章： Kubernetes 稳定性保障手册 -- 极简版 Kubernetes 稳定性保障手册 -- 日志专题 Kubernetes 稳定性保障手册 -- 可观测性专题 Kubernetes 稳定性保障手册 -- 洞察+预案（本文） 综述 稳定性保障是个复杂的话题，需要有效、可迭代、可持续保障集群的稳定性，系统性的方法或许可以解决该问题。 为了形成系统性的方法，可以梳理出稳定性保障复杂性的源头，制定数据模型来对其进行描述，然后在数据模型的基础上对集群的稳定性保障进行数字化和可视化，以数据模型为内核来持续迭代对稳定性保障的理解、实践以及经验的固化 基于上述4 张图和3 张表的数据模型，形成对集群稳定性保障的洞察+预案的内核，可以衍生出一种全局可视化的稳定性保障服务。 一种实现 1）部署形态 Region 化部署 面向 Region 内单集群或多集群提供服务 2）使用体感 根据稳定性保障的最佳实践，将稳定性保障分为如下几个栏目： 运行链路图： 该栏目是日常稳定性保障高频使用的区域
97420发布于 2021-07-08 - 来自专栏CNCF
Kubernetes 稳定性保障手册 -- 极简版
对于基于 Kubernetes 的云产品，稳定性保障已成为基本诉求，稳定性缺陷会给产品带来巨大的损失，如用户流失、用户信心下降、产品迭代速度变慢等。 虽然基于 Kubernetes 的稳定性保障很重要，但业界缺少基于实践的标准化稳定性保障方案，导致同样的问题在同一产品或不同的产品中重复出现，最佳实践不能应用在更多相同技术栈的产品中，不同产品形成的稳定性保障最佳实践也不能互补 为此，基于过去的开发实践以及基于 Kubernetes 的稳定性保障经验，尝试形成《Kuberentes 稳定性保障手册》，将稳定性保障最佳实践进行沉淀，使得人人对 Kubenretes 稳定性保障的理论形成全面的理解 本篇文章作为《Kubernetes 稳定性保障手册》第一篇文章，抽象稳定性保障中的核心内容，作为稳定性保障最简使用手册。 ? 极简手册目标 1min 理解稳定性保障目标 3min 把握稳定性保障全局视图 一站查找稳定性保障推荐工具或服务 ? 稳定性保障目标 满足服务或产品对稳定性的诉求 加速服务或产品的迭代 ?
1.3K30发布于 2021-03-15 - 来自专栏高可用
活动期间MySQL稳定性保障思路
马上十一、中秋双节，很多客户开始做节日活动，基本都有一个共性需求：活动期间，流量预计翻N备，由此引发了一轮MySQL的容量治理与保障。 相对于Redis，功夫最好做在事前(参考 重大活动期间Redis稳定性保障思路-腾讯云开发者社区-腾讯云)，MySQL可以在事前和事中同时做一些事情，用好云平台的能力，往往会有意想不到的收获。 2.2 容量 保障容量，主要考虑保障cpu/内存的冗余，用空间换时间；一方面要根据压测结果，做好扩容，另外一方面做好快速的弹性扩容及应急库容。
1K111编辑于 2023-09-27 - 来自专栏为了不折腾而去折腾的那些事
Docker 稳定性保障：Ubuntu 环境版本锁定方案
Docker 作为许多开发或生产环境中的基础设施的重要组成部分，其版本的稳定性直接影响着整个系统的可靠性。本文将介绍如何有效地管理和固定 Docker 的版本。 有时是配置文件不兼容，有时是命令参数变化，有时甚至会影响到整个应用的稳定性。 如果你追求极致的环境稳定性，并且不打算对宿主机做任何补丁更新，你当然可以把所有相关的软件包都锁定版本。 不过我建议你三思。 将所有程序都锁定版本，可能会导致错过 Ubuntu 系统的重要安全更新，也可能错过一些系统稳定性的改进。
56410编辑于 2025-02-06 - 来自专栏性能与架构
Twitter是如何保障系统稳定性的？
用作紧急情况下的指导文档 虽然不可能想到所有的情况，但至少会列出测试中发现的那些问题，并指明如何处理 还有一个巨大的玻璃墙，上面记录着关键信息，在问题发生时能够帮助进行快速决策 提前做好准备、想好出现问题时如何处理，是保证稳定性的重要思路
1.1K60发布于 2018-04-03 - 来自专栏高可用
重大活动期间Redis稳定性保障思路
马上十一、中秋双节，很多客户开始做节日活动，基本都有一个共性需求：活动期间，流量预计翻N备，由此引发了一轮Redis的容量治理与保障。 所以最好还是做好事前的保障。 2.2 容量保障cpu/内存的冗余，用空间换时间副本只读2.3 慢查询监控这里主要的监控，是指把慢redis配监控，基于业务可以接受的超时时间；proxy-slowlog的配置阈值和监控的阈值一致，方便排查
920101编辑于 2023-09-26 - 来自专栏为了不折腾而去折腾的那些事
Docker 稳定性保障：Ubuntu 环境版本锁定方案
Docker 作为许多开发或生产环境中的基础设施的重要组成部分，其版本的稳定性直接影响着整个系统的可靠性。本文将介绍如何有效地管理和固定 Docker 的版本。 有时是配置文件不兼容，有时是命令参数变化，有时甚至会影响到整个应用的稳定性。 如果你追求极致的环境稳定性，并且不打算对宿主机做任何补丁更新，你当然可以把所有相关的软件包都锁定版本。不过我建议你三思。 将所有程序都锁定版本，可能会导致错过 Ubuntu 系统的重要安全更新，也可能错过一些系统稳定性的改进。所以我的建议是：只锁定 Docker 直接相关的软件包，其他系统组件就交给系统的包管理器去维护。
51710编辑于 2025-02-05 - 来自专栏Takin应用
被动防御→积极防御，系统稳定性保障思路启发
那么究竟该如何保障庞大复杂的分布式系统的稳定性，走出故障频发的困局呢？ 分布式系统的稳定性保障本身就比较难，再加上高峰流量场景，比如常见的双 11 或者是突发疫情导致行程卡的访问比平常多 20 倍的情况，我们该怎么保证系统的稳定性？ 同理系统稳定性保障也是如此，主动进行峰值流量系统全链路压测、容量演练是解决主要矛盾的关键一步。 该企业从2017年开始发展快递业务，到2021年Q3， 收入从70亿快速增长三倍到现在的200亿，随着业务的不断扩张，企业的IT系统也在经历着天翻地覆的变化，为了保障业务的稳定发展，系统的稳定性保障也逐渐从被动防御转向积极防御 映射到系统稳定性保障领域，当企业具备这种主动验证系统稳定性的能力，验证的次数越多，你收获的价值就越大。
98220编辑于 2022-03-18 Dubbo服务降级：保障稳定性的终极指南【六】
欢迎来到我的博客，代码的世界里，每一行都是一个故事 Dubbo服务降级：保障稳定性的终极指南【六】 前言 在构建分布式系统时，不可避免地会面临高流量、网络故障和服务不可用等问题。 就像驾驶一辆高性能赛车一样，我们需要一套有效的服务降级机制，以保障系统的稳定性。本文将带你进入Dubbo的服务降级世界，探索如何应对各种挑战，让你的微服务系统始终高效运行。 服务降级概述 1. 在分布式系统中，面临高并发请求、资源瓶颈或故障时，服务可能无法正常运行，这时服务降级可以帮助系统继续提供基本的核心功能，避免完全崩溃，从而保障用户体验。 2. 这有助于提高系统的稳定性和可用性。 服务降级最佳实践 服务降级的最佳实践包括流量控制和故障处理，以确保系统在高流量和故障情况下能够稳定运行： 1.
31700编辑于 2025-05-30- 来自专栏漫谈测试
聊聊如何保障自动化测试的稳定性
除了表面的问题，他们可能还关心如何从流程和工具上提升稳定性，比如持续集成、监控报警这些方面。 稳定性问题的根源可能包括环境不一致、测试用例设计不合理、异步操作处理不当、依赖服务不可靠、数据问题、框架本身的缺陷，以及缺乏维护。 七 、监控与维护稳定性看板：监控测试通过率、失败原因、执行时长等指标，发现异常趋势。定期用例评审：清理过时用例，优化冗余或低效的测试逻辑。 自动化测试的稳定性需要从环境控制、用例设计、依赖管理、流程规范和持续维护等多维度保障。关键是通过工具、流程和团队协作，减少不确定性因素，同时对失败用例进行快速响应和修复，避免测试套件逐渐“腐化”。
61220编辑于 2025-03-24 - 来自专栏Apache Doris
Apache Doris 是如何保障系统稳定性的？
引言稳定性是数据价值实现的根本保障。数据从采集、传输、存储到计算处理的每个环节都需要系统的稳定运行支撑。数据库作为数据生命周期的核心载体，其稳定性的构建一直是业界公认的最大挑战。 一、稳定性面临的核心命题ApacheDoris稳定性之所以难以保障，其实是受多方面影响：1.1广泛的应用场景Doris主要面临以下五大应用场景的挑战：Real-TimeAnalytics：包括BI报表、 这种“高复杂度+高迭代速度”的双重考验，正是Doris在稳定性建设中需要持续攻克的核心命题。二、多维测试体系为应对上述的多重挑战，测试工作作为保障Doris稳定性的第一道防线，发挥着关键作用。 三、全方位的稳定性保障体系在构建多维测试体系的基础上，我们意识到单一手段无法应对复杂系统的稳定性挑战，还需要将工程实践、社区共建、系统重构与文档建设融为一体，形成全方位的稳定性保障体系。 通过这四个维度的协同发力，我们构建了全方位的稳定性保障体系，让Doris能够在高速迭代的同时，也能持续提升系统的可靠性与健壮性。
18500编辑于 2025-11-19 - 来自专栏得物技术
浅谈系统稳定性与高可用保障的几种思路
今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。 本篇文章只聊思路，没有太多的深入细节。阅读全文大概需要5~10分钟。 要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。 三、影响稳定性的因素 首先我们先梳理一下影响系统稳定性的一些常见的问题场景，大致可分为三类： 人为因素 不合理的变更、外部攻击等等 软件因素 代码bug、设计漏洞、GC问题、线程池异常、上下游异常 硬件因素 四、提升稳定性的几种思路 4.1 系统拆分 拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。 如何做好稳定性和高可用保障是一个很庞大的命题，本篇文章没有太多的深入细节，只聊了整体的一些思路，主要是为了大家在以后的系统高可用建设过程中，有一套系统的框架可以参考。最后感谢耐心看完的同学。
2.4K141编辑于 2022-11-02 - 来自专栏Python自动化测试
新人手册系列：思考篇-稳定性&大促保障
质量保障设计的三位一体 如何思考 水平：通用的平台测试方案，不限于具体行业，通过技术手段形成通用化能力。 行业：具有特定业务形态的业务测试方案，结合业务特点形成针对性解决方案。 专项：对具体问题深挖解决方案，专项保障的测试方案，例如资损、预案、全链路压测等 ? 大促质量保障 全链路压测 全链路压测是以全链路业务模型为基础，将前端系统、后端应用、中间适配层、DB等整个系统环境，完整得纳入到压测范围中，以http请求为载体，模拟真实的用户行为，在线上构造出真实的超大规模的访问流量 全链路压测自2013年诞生至今，一直稳居大促质量保障核武器地位。 基本原理： 入口：前端http请求，如detail页面、确认订单页面、提交订单等。
1.6K20发布于 2020-09-27 - 来自专栏数据库干货铺
数据库和缓存稳定性保障-扩容及升级规范
背景 数据库和缓存是系统的核心组件，保障其稳定性是确保整个系统稳定运行的基础。 本规范分别对数据库及缓存硬件扩容、软件升级的前置条件进行说明并期望后续按照此规范进行优化、硬件扩容及软件升级，保障升级操作规范、升级过程平稳。 2. （用于异常回退） 如新主库运行正常2周以上，则进行原主库升级 2.6 数据库架构升级 因数据库版本的迭代及新架构方案的出现，在当前数据库架构出现如下问题时，需要考虑升级数据库架构： 影响数据库稳定性 ： 如正在使用的数据库架构方式存在BUG，导致数据库集群 无法正常切换、异常切换、不满足数据库可用性及稳定性要求时，需升级软件版本或 替换数据库架构方案 部署及维护成本高：如当前架构方案在部署及维护成本均较高 用于异常回退） 如新主库运行正常2周以上，则进行原主库升级 3.4 架构升级 因Redis版本的迭代及新架构方案的出现，在当前Redis架构出现如下问题时，需要考虑升级Redis架构： 影响Redis稳定性
15210编辑于 2026-01-07 - 来自专栏老张的求知思考世界
双11在即，分享一些稳定性保障技术干货
每年一次的双十一大促临近，因此上周末公司组织了一次技术交流闭门会，邀请了电商、物流、文娱内容、生活服务等知名一线互联网公司的技术大牛，一起探讨了一些大促稳定性保障相关的技术话题。 大促典型场景及优化方案 1、云资源稳定性保障 单云模式存在一定稳定性风险，混合云架构在容灾方面效果更好； 核心链路梳理，可以将历史大促或者峰值的访问URL存储起来，经过处理后作为核心链路参考； 验证线上的性能容量搭建单独的仿真环境 /代码块耗时大，不断压测优化验证； 2）业务优化(深库存场景) 为了应对秒杀场景高并发，可以通过缓存+数据库方式来解决； 90%库存放缓存应对高并发； 10%库存放数据库应对超卖； 3、数据库稳定性保障的 数据库层也需要做好监控； 比较好的实践是双机热备，在数据同步方面需要有专门的保障机制； 5、高并发下，MySQL主备同步会有较大延迟，该如何处理？ 身份识别和业务隔离： 1）RPC group分组：假设有100个节点，40个给核心业务(交易)，60个给其他业务； 2）业务身份：中台架构可通过业务身份把订单秒杀等应用打上标记，便于隔离区分； 业务稳定性保障
3.3K20发布于 2021-11-16 接口请求重试策略：保障稳定性的必杀技
接口请求重试策略：保障稳定性的必杀技 前言 你的应用程序是否对接口请求失败有足够的应对措施？接口请求重试机制是确保数据可靠传输的关键。 总的来说，接口请求重试是提高数据可用性、用户体验和系统稳定性的关键策略。它允许系统更好地应对各种故障和不稳定情况，从而确保用户能够顺畅地访问所需的数据和功能。 总之，接口请求的幂等性是确保系统在接受重试操作时保持一致性和稳定性的关键要素。它有助于应对网络中的各种问题，确保重试操作不会引发不良影响，同时提供更好的用户体验。 第六：超时和延迟 处理超时和延迟是关键的策略，用于更好地应对网络不稳定性。网络不稳定性可能导致请求超时或响应延迟，以下是一些处理超时和延迟的策略： 1. 采取适当的策略，如设置超时、超时重试和异步请求，可以更好地应对网络不稳定性，确保用户能够访问所需的信息，并减少不必要的等待。
90810编辑于 2025-05-31
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号