在团队里兼职做稳定性保障相关的工作，有一二年了吧，有一点经验和思考，做些总结和输出吧，欢迎指正。

首先要明确对系统的稳定性保障，并非是完全不能出现问题。越是复杂庞大的系统，就越有可能出现问题。参考云厂商在提供服务的时候，会有服务等级协议 SLA ，一般承诺可用性不低于 99.9%，但不会是 100%。所以在做稳定性保障之前，要先容忍不稳定的问题的发生。

其次要知道对系统做稳定性建设，是一件螺旋向上和持续优化的事情，而非一步到位就万事大吉了。这个月的问题数量比上个月少，这周告警认领率比上周高，这次故障影响面比上次小等等，都可以算作稳定性建设的成果。

回到主题。限流降级确实重要，但当做这些措施的时候，问题已经发生了。有没有一种方式，可以完全避免问题的发生呢，举个例子：当一个危险变更上线的时候，在多重审核机制下，被其他同事识别风险并阻断流程，能不能减少一次线上故障呢。

鸟瞰稳定性保障这件事，从时间维度可以分为事前->事中->事后三个节点，事前尽可能预防，事中及时高效处理，事后再做积极复盘。

在事前的预防阶段，首先要做的就是明确核心业务的核心链路，隔离故障影响面的带来直接效果会是最好的。要为其定制高可用的保障方案，例如历史代码的技术债务清理、应用独立集群和高规格部署、流量高峰期的弹性伸缩配置、避免与非核心业务共享存储资源、设计一套保障 VIP 用户体验的灾备通道流程等等。最具价值的业务流程自然是我们保障工作的重点。当然还有研发规范、变更管控、风险巡检、压测演练等这些日常需要经常执行的事情，甚至可以定期举办一些带奖品的简单考试，使稳定性的风险意识人人具备。

在事中的处理阶段，大部分人都存在一个误区：处理线上问题的时候，定位根因永远不是第一优先级，快速恢复业务才是。举个例子：在杭州自来水异味的事件中，排查臭味来源不是第一优先级，快速恢复居民正常供水才是，毕竟没有人会想喝一周时间的藻类降解物的自来水。为了使业务快速恢复正常，变更回滚、扩容升配、应急预案、必要的熔断限流降级等等，该用的措施就该及时用上，不熟悉业务的值班人员也该紧急联系业务老手才是。

另外，与问题没有被高效处置来说，更令人可怕的是问题没有被及时发现，毕竟没有人会想经历一次毫不知情的屎到淋头的感觉。监控和告警是大型应用系统不可或缺的一部分，除了机器水位指标，关键业务指标才是更加需要被关注的。核心指标的异常波动需要结合 IM 或者电话等能力，做到第一时间触达至正确的人，并且要搭配合理的升级机制，非核心指标的短暂波动要尽可能地减少干扰，让有限的精力始终保持在核心的业务上。

还有，对问题的处理效率是减少业务影响面的关键因素，可以按照问题发现->处置->恢复分为三个阶段，给每个阶段定一个耗时指标 MTTR ，例如五分钟发现、五分钟处置、十分钟恢复，每次问题处理过程中记录这些耗时，存在几次未达成是可以接受的，但要保持整体趋势往这个方向前行。

在事后的复盘阶段，需要注意避免定级定责带来的撕逼甩锅，要从做好保障和避免再次发生的角度来推进。每次复盘的知识库要沉淀，改进项要及时跟踪，避免这次复盘的问题根因，又再次出现。

最后再说，稳定性建设是一个高维度跨团队的事情，需要从上而下地和各方协作，才能最终执行到位。虽然说了很多方法论，但都是高屋建瓴的话语，我深知稳定性保障的难做，希望对楼主有所帮助吧。

我比较喜欢 Kotlin

规范的公司都会有明确的员工激励机制，优秀个人/团队/项目奖、年终奖、晋升之类，这些事情在面试时候就可以和 hr 问清楚

su7 的 hud 投影和前车尾灯重合的时候，眼睛都要看瞎了

国际金价，机场流量，up 主粉丝数。。
https://i.imgur.com/LRD5BmY.png

这个年纪还是开轿车吧，等娃娃出来之后，有的是机会开 SUV

正脚刹车，斜脚油门，敬畏速度

路口不超齐头车，注意 A 、B 柱视野盲区

让速不让道，远离大货车

学会预判性驾驶，提前规划路线，进入匝道及时加速，退出匝道提前变道

好看

用户订单表里需要冗余一个大 JSON 类型的快照字段，包含商品和商户的当前信息

@solitude1942 #33 嗯，是他自己选的，那边还有爷爷奶奶，小时候被呵护得多，可能更加习惯吧

@solitude1942 #30 唉，老婆本家好像就小舅子一个男丁，丈母娘其实很想带走的。老丈人确实如你所说的一个人，老婆说她爹妈经常吵架，从她小时候就开始了。你揣测的更多内容，我也不清楚了，毕竟严格了说，我也只是个外人，也不想插手太多。

@joy33 #27 ？请举证。只是生活里的小场景，夜里回想起来有些触动而已，这有什么好编的
@sir283 #28 后面只是日常寒暄和叮嘱，没有过多剧情，说多了有些琐碎，就不展开了

@lloovve #1 劳碌太半辈子，没挣到钱，生活矛盾自然就多了

感谢总结和分享，祝好。另外博客没有 RSS 吗，想订阅一下

这种人严重违反直播规范啊，这种人严重违反直播规范，我第一时间给他挂掉，这种人疯了吧这种人，这种人是不是疯了，我的天哪这种人太可怕了这种人，这种人肯定有人找他的，这种人肯定有人去找他，有人找他，这种人疯掉了这种人，你怎么能违反直播规范你呢，我的天哪，我第一时间给他挂掉了啊

当下市场行情，还是别把年终当回事，按月 base 来考虑比较妥当

毛遂自荐一下我的项目吧，挺符合楼主的需求场景。之前写过一个把 csv 内容转换成 ical 在线订阅链接的服务，支持公历和农历的日历事件，以及周岁和虚岁的计算。自己一直在用，配合苹果日历的提醒，会在朋友的生日当天，祝福和叙旧一下，还挺好的。

例如，原 csv 数据文件是 https://github.com/fantasticmao/csv-to-ical/blob/main/csv/testdata/calendar_test.csv ，转换之后的在线订阅链接是 https://csv-to-ical.fantasticmao.cn/remote?lang=zh_cn&url=https://raw.githubusercontent.com/fantasticmao/csv-to-ical/main/csv/testdata/calendar_test.csv ，导入到苹果日历之后的效果 https://i.imgur.com/mLQzmIt.png

不依赖通讯录来维护这些日历事件，可能更独立一些。项目基本开发完了，楼主有兴趣的话，我把 readme 再维护一下，顺便做点推广 >_>