这是一个创建于 71 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 skyemin OP 我能想到的就是做好限流，监控，降级这些 |
 | 2 seers 71 天前 via Android 压测，找到脆弱点，然后就是做好监控，熔断，排队了 |
 | 3 lscho 71 天前 还有故障恢复、水平扩展/垂直扩展、灾备呢 |
 | 4 acvrock 71 天前 分：事前，事中，事后。有不同的措施， 搜索一下 SRE 自己学习 |
 | 5 dode 71 天前 收集总结问题列表，排查小问题原因，采取措施优化 |
 | 6 istomyang 71 天前 via Android 学会转换问题：分布式系统的 CAP 。 不是分布式系统？：那就 A 呗。 |
 | 7 fengsi 71 天前 事前、事中、事后 分别采取了什么样的措施来保障。 比如事前 流量评估、压测；事中监控报警、熔断降级、准实时对账；事后，离线对账、复盘、形成 sop 等 |
 |
 | 9 levelworm 71 天前 via Android 观测系统稳定性靠下游在群里吼，修正系统稳定性靠重启机器，这回答基本上什么公司都能用。 |
 | 10 fantastM 71 天前  9 在团队里兼职做稳定性保障相关的工作，有一二年了吧，有一点经验和思考，做些总结和输出吧，欢迎指正。 首先要明确对系统的稳定性保障，并非是完全不能出现问题。越是复杂庞大的系统，就越有可能出现问题。参考云厂商在提供服务的时候，会有服务等级协议 SLA ，一般承诺可用性不低于 99.9%，但不会是 100%。所以在做稳定性保障之前，要先容忍不稳定的问题的发生。 其次要知道对系统做稳定性建设，是一件螺旋向上和持续优化的事情，而非一步到位就万事大吉了。这个月的问题数量比上个月少，这周告警认领率比上周高，这次故障影响面比上次小等等，都可以算作稳定性建设的成果。 回到主题。限流降级确实重要，但当做这些措施的时候，问题已经发生了。有没有一种方式，可以完全避免问题的发生呢，举个例子：当一个危险变更上线的时候，在多重审核机制下，被其他同事识别风险并阻断流程，能不能减少一次线上故障呢。 鸟瞰稳定性保障这件事，从时间维度可以分为事前->事中->事后三个节点，事前尽可能预防，事中及时高效处理，事后再做积极复盘。 在事前的预防阶段，首先要做的就是明确核心业务的核心链路，隔离故障影响面的带来直接效果会是最好的。要为其定制高可用的保障方案，例如历史代码的技术债务清理、应用独立集群和高规格部署、流量高峰期的弹性伸缩配置、避免与非核心业务共享存储资源、设计一套保障 VIP 用户体验的灾备通道流程等等。最具价值的业务流程自然是我们保障工作的重点。当然还有研发规范、变更管控、风险巡检、压测演练等这些日常需要经常执行的事情，甚至可以定期举办一些带奖品的简单考试，使稳定性的风险意识人人具备。 在事中的处理阶段，大部分人都存在一个误区：处理线上问题的时候，定位根因永远不是第一优先级，快速恢复业务才是。举个例子：在杭州自来水异味的事件中，排查臭味来源不是第一优先级，快速恢复居民正常供水才是，毕竟没有人会想喝一周时间的藻类降解物的自来水。为了使业务快速恢复正常，变更回滚、扩容升配、应急预案、必要的熔断限流降级等等，该用的措施就该及时用上，不熟悉业务的值班人员也该紧急联系业务老手才是。 另外，与问题没有被高效处置来说，更令人可怕的是问题没有被及时发现，毕竟没有人会想经历一次毫不知情的屎到淋头的感觉。监控和告警是大型应用系统不可或缺的一部分，除了机器水位指标，关键业务指标才是更加需要被关注的。核心指标的异常波动需要结合 IM 或者电话等能力，做到第一时间触达至正确的人，并且要搭配合理的升级机制，非核心指标的短暂波动要尽可能地减少干扰，让有限的精力始终保持在核心的业务上。 还有，对问题的处理效率是减少业务影响面的关键因素，可以按照问题发现->处置->恢复分为三个阶段，给每个阶段定一个耗时指标 MTTR ，例如五分钟发现、五分钟处置、十分钟恢复，每次问题处理过程中记录这些耗时，存在几次未达成是可以接受的，但要保持整体趋势往这个方向前行。 在事后的复盘阶段，需要注意避免定级定责带来的撕逼甩锅，要从做好保障和避免再次发生的角度来推进。每次复盘的知识库要沉淀，改进项要及时跟踪，避免这次复盘的问题根因，又再次出现。 最后再说，稳定性建设是一个高维度跨团队的事情，需要从上而下地和各方协作，才能最终执行到位。虽然说了很多方法论，但都是高屋建瓴的话语，我深知稳定性保障的难做，希望对楼主有所帮助吧。 |
 | 12 sk217 70 天前 1 系统稳定性 还是先做整体的业务架构分析吧，你核心业务流程是什么，得搞清楚，说白了就是赚钱的流程，得保障这个流程不出毛病，像 apple 云，你云服务同步挂了，时间同步服务挂了，iMessage down 了，对 apple 来说也就是挨骂而已，你见过几次 app store 不能支付的？ 像 B 端查询或者一些功能，就不要跟 C 端共用一套数据仓库， 非核心业务流程调用核心业务服务要做管控、降级、限流，尽量保障用户下单顺畅，即使页面上图片、优惠券、等系统都挂了，都要保障正常下单可用性，主要是底线思维 给老板赚钱的 一定要保障，隔离 分布式系统要做监控提升链路可观测性，日志要严格分级，使用 INFO DEBUG ERROR WARN 避免开发人员对日志完全没有敏感性，像我之前工作的地方，动不动就给你来个 ERROR 级别的日志，导致 ERROR 根本没人关注，一堆需要关注的 ERROR 被埋没在一堆本来是 WARN 或者业务操作异常的 INFO 里面 然后就是要能做到弹性伸缩，以及经常做压力测试检查，压力测试的 case 尽量要多，能拿线上的流量进行清洗后再重放是最好的，因为并不是所有的 case 能被检测到 最后，对于大的服务，面向 C 端的应用，服务能拆得越细越好，一定要有降级 灾难思维，有的时候测试包括压力测试也不是万能的，像我在携程的时候，隔壁组的老哥，给线程池直接最大线程数核心线程数配置个 2 ，上线后一点毛病都没有，因为根本跑不到他的 case ，当时所有的线程池参数配置纯靠开发人员的手感，没有任何监测，一个线程跑几个小时，把单个 CPU 打满了也没人知道，例行压测也没毛病，等春节那几天，刚好开通了啥功能，然后流量全跑他那个 case 上面了，结果服务器起来一波被打垮一波，你还没法回退，因为他的那个 commit 不知道哪个版本就发上去了，回退根本没用，生产出了毛病 定位问题又慢 |
 | 14 hancai2 70 天前 做了多年运维，我竟然无法回答。可能是这个问题太大了，类似于”如何写好代码？“ |
 | 15 visper 70 天前 问题太大，那就大点回答。1.做好质量管控监控。2. 准备好补救方案。 |
 | 16 zwlinc 70 天前 长文本就是 AI ？有些人真的是，我是没看出来什么 AI |
Select Language