凌云时刻

背景

业务研发同学经常缺少全局视角，只能是单方面、单角度的关注事情，因为负责的事情只是仅此一块。希望业务研发同学能够提高视野，能够关注全链路，关注整体。因为业务研发同学是最贴近业务的，具有天然的优势，所以只要有稳定性意识，加上一些常用的手段来做，一定会做的很好。

措施

在做业务项目的时候，主要还是从两方面进行治理的，分别是可用性和资损。

这治理可用性和资损之前，要根据业务梳理出详细的用例，然后根据用例梳理出清晰的链路，此时的链路一定要端到端全链路的，而不是某部分链路，这里就是经常看待事情角度的问题，多拔拔高，提升下，明确自己负责链路在全链路中的位置。这个问题其实在业务同学视野中问题不大，关注点放在端到端全链路上即可。业务研发同学具有天然的优势，熟悉业务链路，亲手研发的业务功能。

 可用性治理

可用性还分为三趴，一趴是容量保障，一趴是功能保障，一趴是监控报警。

容量保障

先来说容量保障这趴：遵循最重要的路径是 容量预估 -> 扩容机器 -> 单压 -> 全链路压测 -> 限流

容量预估

根据产品运营同学给出的量+参考现有的量 给出一个大概的预估数据。产品运营同学给出的一般都是日活量，PV、UV等数据，其中还有注意发push的量。这些要有一套严格的计算的公式，结合一些指标数据，这样可信度比较高。参考现有的量，通过看一些现有的一些监控数据即可。

扩容机器

根据容量预估出来的数据，其中主要是增量，根据增量看下链路以及链路到下游的扩散比，分别对下游的增量是多少。下游的增量需要评估到增量不仅仅是你这一方，而是所有方。但是你只需要把你的这条链路对下游的增量是多少，压力有多大就可以了。然后根据以往数据进行扩容。

单压

扩容完，就需要压测了。压测模型尽量逼真，不要是一个数据，而且很多数据。否则，就会造成某个节点是热点，从而反映不出真实的压力情况。压测的时候要有监控大盘，机器核心指标监控，从而判断压测是否符合预期。压测要有压测报告。

全链路压测

单压一般都是在低峰期进行压测，很难反映出在高峰期时的状况。只有加入全链路压测，才能够真切的反映出高峰期的状况，从而更好的评估，流量对系统的压力，系统可否承载这么大的流量。

限流

限流是对系统的一种兜底的保护措施，当流量洪峰来了，不至于把系统打垮，需要加系统限流。这个可以在单压的时候进行看限流是否生效。

功能保障

再来说功能保障这趴：

根据链路梳理出，强弱依赖，将弱依赖增加降级开关，最好把降级开关加到预案平台，并加以说明降级之后的影响。防止随着业务人员的更新，组织架构的调整，这些预案被遗弃，当真正需要的时候不敢执行。

若是强依赖，则需要在整体功能入口加个降级，防止当出现问题时，没有相应的应对方案。

其中也要识别到降级开关的关联性，是否两个开关AB、必须先A后B，还是怎样，最贴近业务的是研发同学，这种重要的小事情要做好。

其实这里最重要的就是根据强弱依赖和功能梳理出预案，然后针对预案进行演练，保障真实可执行。预案是救命的，一定得是可执行的。最好的方式是以后也要定期演练，根据链路的重要性（可根据产生P级事故来区分）来确定演练的频次。

监控报警

监控报警，也就是发现问题的手段。

监控报警= 业务监控（QPS、耗时、成功率）+ 业务打点（核心业务链路的打点）+ 中间件（各个中间件指标不同）+ 基础设施（CPU、内存、DISK）

业务监控：

业务监控一般都是针对接口维度的，针对接口有三个黄金指标：QPS、耗时、成功率。这三个黄金指标基本都能覆盖各种异常情况。

业务打点：

核心链路打点，渠道打点，错误码打点，强依赖调用失败/重试在失败打点，超出阈值打点等等。

中间件：

DB：主从延迟、慢SQL

缓存：命中率、容量

消息队列：延迟、堵消息

基础设施：

主要用于业务机器上，主要的指标也是三个：CPU、内存、磁盘。

监控报警是发现问题的手段，仅仅是发现问题远远是不够的，核心链路上的问题，一定要有相应手段去解决。

报警的信息太多就成骚扰了，重要的报警信息会被淹没，从而发现不了真正的问题。希望大家在业务的同时，将自己的报警进行降噪。

监控收口的背景&目的

1. 监控统一化、统一收口

2. 观察一周，无大问题，拉各位研发测试入群。

3. 背景：

    一、报警信息不统一，消息闭塞，稳定性同学有些没有触达到。

    二、稳定性相关事情，之前先通过leader沟通，再协作人员跟进，稳定性工作也没有具体的收口，效率较低。

4. 目的：

    一、传达报警信息，防止处理报警时，消息闭塞，稳定性同学能够及时关注，参与，跟进，解决，优化，防止出现P级事故。

    二、便于稳定性相关工作推动，大家相互监督，流程规范化，标准化。

 资损防控 

做到可用性这里的前置条件是需求清晰，链路清晰。针对资损链路主要从两个方面来做的：一部分业务后台；一部分业务前台。

业务后台

● 针对配置要有合理性的检查

● 某个预算超了，要及时熔断。

业务前台

● 平账：上下游数据一致性的核对。若负责业务落库，就需要该业务与涉及到的上下游进行数据核对。

● 规则：针对某规则才会有某种奖励或执行某种规则，若得到某种奖励或规则的话，就需要根据数据重新校验是否符合规则。

● 趋势：涉及到资产的还需要铺资金异动，从宏观上看资金的整体情况。

其他

其中铺的一些发现手段（不限于核对，监控打点等等），只是为了发现问题，但是问题还是需要解决的，需要针对发现的问题进行修复，比如数据工厂批量修复，单个数据订正走预案。

对于发现的问题，应该与解决问题形成闭环，简单来讲就是：发现了问题，问题有一些重要的参数数据，然后针对这些参数数据就可以解决问题。

大部分业务研发同学，对可用性治理还是比较容易理解的，但是对于资损防控，意识上还是很难意识到的。我在做的过程中，经常会遇到业务研发的反驳，反驳的理由基本就是：我已经有了层层保障，为何还要加个核对。说服的理由就是：这些都是正向的流程，需要逆向的流程把这层做厚，防止出现问题不能及时发现，对于不可控的因素做到可控，例如：数据被乱写、被误删，这种如何发现？只有将发现能力这层做厚基本上就能提前发现问题。多说一句：红蓝攻防很重要的一部分就是根据数据注入来做的。

可遵循的规则

 变更三板斧

可灰度、可监控、可应急

 应急四件套

回滚、重启、降级、切流

结语

稳定性是一个领域，是建立在业务基础之上的。虽然描绘了这么多当然不仅限于此，但是在每个细分场景下都是一块子领域，做好每一块子领域并不容易。上面这些内容仅是抛转，希望更优秀有见解的同学提出建设性意见。当每个业务做好了稳定性，那么理论上整体就是稳定的。加油！

作者|蓝竹

END

长按扫描二维码关注凌云时刻

每日收获前沿技术与科技洞见

投稿及合作请联系邮箱:lingyunshike@163.com