写在前面的话

谈到系统稳定性，大家会想起什么呢？有部分人可能觉得这个词挺虚的，不知道到底指的是什么东西。还有部分人可能想到的是监控与告警、可能想到的是消除单点，动态扩容；亦或者是说在实际工作中碰到什么问题，针对问题再去想解决方案。
可是大家发现没有，在实际工作环境中，不论你怎么强调流程，强调质量，问题总是层出不穷。修好了这里，那里又出问题了
可能很少人会去思考，根据体系化的方法论，从整体上作为研发管理的一个重要事项，长期持续的建设演进。

结合我过往的经历来看

对于任何系统来说，系统稳定性都是最基本的一个要求。
每个公司都有自己的发展阶段和现实情况，比如：
--> 在公司发展初期我们要求业务快速迭代;
--> 在发展到一定阶段，业务线越来越多，服务越来越多，盘子越来越大，我们可能更多的是要求精细化运营、精细化治理;
--> 公司发展成熟之后呢，主要围绕于降本增效做事情，但是系统稳定性基本是贯穿整个项目发展周期。而且我们未来是要做SaaS产品的，稳定性更是SaaS的基石，往大了说是客户信任的基础。

引出今天我们要讨论的

1.公司发展初期，忙着给投资人、给客户做演示demo，忙着快速迭代，这个时候根本上谈不上稳定性建设，老板在这个时候也能容忍一定的错误发生。
2.公司业务快速发展，逐步有一定的交易规模和访问量了，我们需要能够及时的发现问题，及时处理问题，这个时候基于日志的告警，关键链路节点的业务告警等等，逐步的增加。
3.公司发展到了一定阶段，发现问题频发，堵也堵不住，单靠点对点的解决已经满足不了需求了，迫切需要立项来体系化的治理。
说实话，以前我对系统稳定性也不足，也没有上升到一定高度来看待问题，经历过这几个阶段，尤其是身处其中，又在牵头搞这件事情之后，有了自己新的认知，就和大家来分享一下。

先说一下SLA

服务等级协议（英语：service-level agreement，缩写SLA），是服务提供商与客户之间定义的正式承诺。SLA的概念，对互联网公司来说就是服务可用性的一个保证。
经常被用来衡量服务稳定性指标。通常被称作“几个9”，9越多代表服务全年可用时间越长服务也就越可靠，即停机时间越短。

90%（1个9的正常运行时间）：这意味着10%的停机时间，也就是说在过去的30天里停机了3天。
99%（2个9的正常运行时间）：意味着在过去30天中有1%，或者说7.2小时的停机时间。 
99.9%（3个9的正常运行时间）：意味着0.1%，或者说43.2分钟的停机时间。 
99.95%（3.5个9的正常运行时间）：意味着0.05%，或者说21.6分钟的停机时间。 
99.99%（4个9的正常运行时间）：意味着0.01%，或者说4.32分钟的停机时间。 
99.999%（5个9的正常运行时间）：意味着0.001%，或者说26秒的停机时间。

大家不要小看这几组数据，你回想你一下，你公司的服务一年会发生几次宕机，会有多少次发版，发版的时候你的服务启动快还是慢，需要多长时间可完成重启？

那到底什么是系统稳定性呢

关于如何定义系统稳定性是一个很难的问题，因为围绕于系统稳定性可定义的视角太多了，每个公司不一样，每个人也不一样。接下来聊聊我的看法。

我们不可能完全避免系统出故障

就好比程序员写的代码一样，不可能保证没有bug，你不可能盲目的拍着自己的胸脯跟你的老板保证，我的系统保证没有故障。
互联网大厂，发展到现在，基础设施和流程都建设的比较完善的情况下，还是问题频发：
还记得阿里云宕机吗，还记得微博因为某个流量明星的吃瓜新闻而打不开了吗;
2020年国庆前一天，受“2020年最难打车日”的需求影响，滴滴平台和嘀嗒平台相继出现宕机故障。
那么最后大家拼的就是谁出现的故障少，谁出现故障之后恢复的快，业务影响降低到最低。
淘宝也会出现故障，只不过淘宝做了足够的精细化划分，每次故障只影响少部分商家，发生故障的时候，如何减少影响的商家数量，行业里通常的做法是给商家分区，区和区之间是相互隔离的，一个区停机只影响自己。所以故障是天然发生的，如何缩短故障影响面是工程技术视角需要解决的核心命题。
这里面最最关键的：

系统稳定性关心的是：服务与数据。
数据要素现在已经上升到我国经济建设的核心生产要素，因为故障，你把数据丢了，试想多么严重的事故。

稳定性主要解决的是：容错与恢复。

再来脑暴一下咱们经常遇到的故障点都有哪些

未测试需求直接上线
上线的需求产品不知道
上线的新需求有 bug
频繁发布需求
发布紧急需求
上线后没有线上验证
系统设计方案存在缺陷
系统代码实现存在缺陷
漏测了某个功能
上线时操作失误
下游服务挂了
网络中断导致调用失败
上游调用流量突增，冲垮服务
应用服务器内存溢出 OOM
应用服务器 CPU 100%
数据库主从延迟了
数据库主库挂了
Kafka 消息挤压了
Redis响应缓慢
第三方服务商挂了
潜在的黑客攻击
潜在的系统漏洞

是不是很多，抽象起来，我们根据时间维度，可以将其分为三大类：上线前、上线时、上线后。

服务与数据是核心，建设要从交付全生命周期出发

到了公司发展后期，发现单纯的关注系统，并不能完全解决问题，通过上述咱们脑暴的问题也可以看出，有些问题不单单是技术引发的。

一个需求从采集、到评审、到研发、到最终交付、线上治理的全生命周期，在整个生命周期中哪些可能会影响到系统的稳定性呢？

PM进行需求调研与分析阶段

这个阶段要识别需求，规划需求，而不是一个短期或临时的需求，因为如果是一个临时需求的话，往往对应的解决方案也是临时的，如果太多临时的解决方案遗留在系统中，久而久之将会变成巨大的“技术债”，总有一天会爆发，对系统稳定性及业务迭代速度造成巨大影响。

需求评审阶段

在这个阶段，参与需求评审的技术同学，也要注意针对PM的需求进行把关，筛选一些不合理的需求，更需要考虑一些PRD之外的场景需求，比如隐含的对访问量的评估，批量导出功能考虑的数据规模等等。发生异常时的产品方案是什么。

技术方案制定与研发阶段

这个阶段最可能出现的问题是技术方案选项或是方案合理性上的问题，比如选用了一个不适合于当前业务需求场景的解决方案，看似解决了当前问题，但往往也同时埋下了一个坑。

联调与测试阶段

这个阶段对于稳定性的保障在于是否可以在QA环境尽可能的模仿线上场景，做到全链路全环节的充分测试。所以对于线下测试环境搭建是有比较高的要求的，如果测试环境搭建成本太高，就会侵占开发阶段的时间，如果测试环境不能很好的模拟线上流程，就很难完整的覆盖功能测试。

灰度与全量阶段

在完成了开发与测试环境的测试之后，我们需要将功能真正的交付到线上。但是测试环境毕竟不能很好的复刻线上环境，总会有很多问题可能直到线上才发现。比如发现高QPS写MySql过高，线下低流量就很难发现，比如发现有大量慢查询需要加索引，线下低流量就很难发现，比如线下环境没有服务之间访问鉴权控制，而线上有，导致服务之间调用大量鉴权失败。

运营与运维阶段

在需求上线之后我们还是需要持续关注功能上线的指标的，做好监控、告警机制，开天眼早于业务同学反馈问题介入，可以尽量减少事故的影响。比如发现异常数增高，慢查询过多，GC频繁，核心链路流转走势有变化等。

写在最后的话

系统稳定性在不同阶段，我们的要求可能不一样，不要一上来就指望能做到大而全，随着公司的发展，也是一个逐步演进的过程。
系统稳定性需要有个体系化的解决方案时，不要只盯着研发侧，要从需求的全链路来看。
问题不是一朝一夕产生的，也不要指望一下就世界和平了。
在建设过程中，研发流程与质量控制并重，要两条腿走路
要时刻绷紧脑袋中的弦，生产无小事，发布无小事。
建设要体系化，落地要细节化，某个环节的放松，可能导致的是蝴蝶效应。

这个就是我这几年工作中不断调整和认识到的体系化的系统稳定性建设的想法，和大家进行下分享。接下来会分专题来分享下，在各个环节我采取的稳定性建设方案~

【研发管理】-谈系统稳定性建设之认知篇