SRE网站稳定性建设
什么是稳定性？
面对任何未知的变化，整个系统仍然能够正常平稳地运行并对外提供服务。
为何会不稳定？影响稳定的因素有哪些？
人为因素
编码问题
- 代码有bug
- 代码逻辑有问题
- 异常处理不完善
- 第三方库使用不正确导致的bug
- 没有遵守开发规范
配置问题
- 配置错误（如将测试环境的配置带到线上）
- 微服务架构中的配置问题
架构设计缺陷
- 服务雪崩（限流、降级、熔断）
- 流量突增
- 微服务之间的循环调用
存储问题
数据库：
- 慢查询与索引优化
- 死锁问题
- 数据库连接打满
缓存：
- 缓存与数据库的双写一致性（提升命中率）
资源不足
- CPU、内存、磁盘、网络溢出
自然因素
- 网络故障
- 服务器故障
- 第三方服务问题
稳定性衡量标准
SLA（服务等级协议）
性能：站点的打开与响应速度
可用性：网站可以正常运行的时间与总时间的比例
- 目标：4个9的SLA可用性（99.99%的时间可用）
- 2个9（99%）：停机时间87.6小时（基本可用）
- 3个9（99.9%）：停机时间8.8小时（较高可用性）
- 4个9（99.99%）：停机时间53分钟（技术容灾能力，机房级别）
- 5个9（99.999%）：停机时间5分钟（极高可用性）
OKR设置
有了目标之后，接下来就是对目标的实现进行拆解，拆解的结果就是让每个团队都背上绩效指标。
O：Objectivve（目标）
KR：Key Results（关键成果：要达到目标具体要做哪些事，需要有量化指标）
注意：不是凭空设定的，先对公司内部的bug、事故平台进行分析，将问题进行归类统计。由哪些团队负责哪些问题。
例如个团队的OKR：
开发团队：
Objective:优化软件质量和开发流程，将由于软件bug引起的不可用时间从100分钟减少至15分钟
Key Results：
- 减少bug的数量:例如，每个季度需要减少20%的bug。
- 提高自动化测试覆盖率:例如，达到90%以上的单元测试覆盖率，80%以上的集成测试覆盖率。
- 减少部署失败的次数:例如，每个季度需要减少10%的部署失败。
测试团队：
Objective：加强软件测试力度和质量，将由于未发现的软件bug导致的不可用时间减少11分钟。
Key Results：
- 提升自动化测试覆盖率至90%，更早地捕获可能的软件bug
- 强化对高风险模块的测试深度，提前发现难以检测的bug
- 提高测试报告的质量，更有效地帮助开发团队找到和解胄bug
运维团队：工作就是确保系统稳高效的运行，所以提高系统的可用性、减少恢复时间和提高故障预防能力就成为了运维团队的关键结果
Objective：
提升服务稳定性和运维效率，将不可用时间减少至13分钟。
Key Results：
- 提升系统监控的覆盖率和效率，90%的故障能在1minute内被检测到
- 建立并优化故障恢复流程，确保70%的故障能在5分钟内开始恢复3、针对热点问题进行深度排查，减少重复故障发生的几率
安全团队：
Objective：提高系统安全性，将由于安全问题导致的不可用时间减少至10.4分钟。
Key Results：
- 定期进行系统安全检查，及时修复安全漏洞
- 引进和优化安全工具和软件，提高安全防护和攻击检测率
- 提升全员的安全意识，减少由于人为操作不当引起的安全事件
产品团队：
Objective：提高产品设计质量，将由于产品问题导致的不可用时间减少至2.6分钟。
Key Results：
- 提高需求质量:例如，每个季度减少10%的需求修改，
- 提高用户满意度:例如，每个季度用户满意度提升2%
稳定性建设的关键要素
要素一：人（规范+制度）
参与者：老板带头，开发、测试、运维、DBA、安全、产品团队共同参与。
降低犯错率：
- 开发规范
- 提测规范
- 测试规范
- 上线规范
- 复盘规范
确保规范被遵守：
- 奖惩机制
- 日常考试
定责：最好有第三方团队介入。
要素二：工具
日志采集分析检索平台（如ELK、EFK）
监控告警平台（如Zabbix、Prometheus）
分布式链路追踪系统（如Zipkin）
CI/CD平台：自动化打包部署平台
提升系统健壮性/稳定性：
.服务降级系统：一些故障能自动控制和恢复，而不需要人工去处理，提高系统的稳定性
在微服务架构下，解决高流量问题三剑客：限流、熔断和降级
预案平台：预定义一些故障应对方案，发生相应故障时，能快速执行预设方案
p0:致命问题
整个系统不可用
p1：严重
某些核心功能无法正常工作，严重影响系统的可用性与性能，系统整体是可用的，只是某些关键业务无法正常运行
p2：重大
系统整体仍然可以运行，非核心业务出现问题
p3：一般
一些小故障，对系统影响较小，但也需要解决
px：轻微
根因定位平台：记录所有故障发生前所有系统变更事件：发生问题时。能够进行历史查看和滚顶复盘，以确定问题的根本原因，提供有效的故障排查支持。
放火平台（混沌工程）：
chaos—>混乱 （前提：确保系统的基本可用性）
目标：先于用户发现问题、解决问题
要做的测试：常规的测试不是混沌工程要做的事，混沌工程应该做的是去制造一些非常规的问题，以便发现未知的问题
例如：模拟整个IDC挂掉，随即让软件的一些功能出现异常、强制ntp时间不一致、生成IO错误、榨干CPU、
要素三：预案
- 故障发生时，要通知该故障可能影响到的上下游相关的人
- 处理故障的协调者
- 协调者的职责：统筹全局，避免做重复工作，甚至还需要持续与客服保持沟通，该故障可能影响的上游研发人员
- 操作开关的决策者
- 常见故障及应对的止损方式
- 止损原则和善后方案
要素四：目标
- 围绕SLA稳定性目标（如4个9）设置OKR
微服务架构下的高流量问题解决方案：限流、熔断与降级
高并发场景下服务雪崩问题
访问链路A—》B—》D
D故障，B请求D得不到响应，而导致B服务中的请求大量积压而无法回收资源，直至把B资源耗尽，导致B不可用，进而影响B的上游A,以此类推===》雪崩效应
如何应对雪崩问题
限流、熔断、降级
针对B来说如何解决
1.对上的请求进行限流（流量达到阈值后限流）
2.对下游
采用熔断机制（访问多次超市，则熔断对下游的请求）
3.对自己
降级：把自身的一些非关键功能关掉，丢车保帅，优先确保核心功能的稳定运行
一般情况：
1.对核心功能：需要采取限流
2，对非核心业务应采取熔断与服务降级
限流
限流：
在当前服务承受不了高流量时，对上游的请求进行限制，通过设置阈值，例如tps、qps达到一定的阈值，则触发限流
实现方法：令牌桶算法
令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。
优点：
1.放过/放行的流量比较均匀，有利于保护系统。
2.存量令牌能应对突发流量，很多时候，我们希望能放过脉冲流量。而对于持续的高流量，后面又能均匀地放过不超过限流值的请求数。
缺点：
1.存量令牌没有过期时间，突发流量时第一个周期会多放过一些请求（因为此时桶内的令牌必然是满的），可解释性差。
2.实际限流数难以预知，跟请求数和流量分布有关。
降级：
- 降级就是服务降级，当服务器压力剧增时，为了保证核心功能的可用性，选择性的降低服务自身的一些不重要的功能，或者直接关闭该功能。等到流量高峰期过后再开启
熔断：
- 在微服务架构中，服务之间相互调用，某个服务的故障可能会导致调用链上的其他服务也出现问题。熔断机制可以快速隔离故障服务，防止故障扩散。
监控与测试
监控：
- 流量监控—》流量毛刺—》代表系统某个风险点
- 业务监控
- 机器监控：CPU、内存、硬盘、带宽
回归测试：在修改或更新软件后，验证先前正常工作的功能是否仍然正常，确保新改冻没有引入新错误
冒烟测试：指在一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否是否实现，是否具备可测性。所以也叫可测性测试。
开展工作时，可以分两个步骤
1.目标
先定制全年目标
然后让相关部门的okr都设置稳定性相关
2.具体的工作
人（规范+制度）—-》防问题
工具——————–》防问题、提高处理问题效率、提升稳定性
预案——————》遇到问题如何解决
工作重心划分
开发、测试、运维团队的规范：
设计评审
设计评审的原则是，既要将最终的设计方案，也要讲淘汰的设计方案
提测标准
开发人员先完成自测，达到提测标准后进入正式的测试
测试流程
1.尽可能的自动化测试
2.测试的覆盖率要高
上线准备
准备号回滚方案—出问题就回滚
灰度发布：小范围尝试，没问题在发布到线上
补充：
UE：软件交互设计—》决定软件好不好用 UI：界面设计 ——》决定软件好不好看
FE: 前端开发工程师—》负责把ue与ui的设计成果转成代码（html、css、js）
RD：后端开发工程师
QA：测试工程师
OP：运维
沙箱环境：高度隔离，用于高风险或早期阶段的开发和测试。 测试环境：模拟生产环境，用于常规功能和性能测试，通常更接近真实的生产环境。
日常工作：
持续完善监控与告警
1.手动添加，持续更新
2.一些老监控阈值的调整
及时处理日常报警
对事故进行复盘，总结经验
总结经验、梳理文档、确保下次不会出现
定期召开稳定性周会、月会
预案：
- 预案要针对不同场景设计好预案，如果之前没有预案，那优先把一些历史上经常发生的线上事故总结下来
- 预案要精简、清晰
- 通过放火平台在预发布环境中制造某一场景的故障，验证预案是否可以正常执行，不断优化预案
容量问题：
- 全链路压测
- 定期扩容演练
- 机房级别高可用
总结
- 稳定性建设的关键在于规范、工具、预案和目标的有机结合。
- 限流、熔断、降级是解决微服务架构下高流量问题的核心手段。
- 监控与测试是确保系统稳定性的重要手段，尤其是回归测试和冒烟测试。
- 日常工作中，持续完善监控、及时处理隐患、定期复盘事故是保持系统稳定的重要环节。
- 预案的设计和执行是应对突发故障的关键，确保系统在故障发生时能够快速恢复。
No responses yet