前言
对于大规模的核心系统来说，安全生产是基本要求。相比to c的消费者业务来说，to b的稳定性要求更高。to b的业务中稳定性是业务。
稳定性、服务高可用方面在学校和很多公司来说，都缺乏很多经验和培养，大家都是从零开始摸索怎么做稳定性建设。特启了一系列文章来说明；
服务端稳定性体系
重点介绍服务端稳定性需要考虑的关键要素和策略，重点介绍变更之外的稳定性保障。
主要包括：
1、事前：消除潜在风险，确保系统稳定运行不出问题。上医治未病，所以这一点要重点投入。
2、事中：监控快速感知和响应的体系，包括风险的感知、控制，并且团队要训练有素才能最快速度消除风险。
3、事后：深度复盘和改进，这里不深入讨论；
变更过程中的风险更多来自变更前的设计、代码质量、review、自动化测试等，而不是仅仅依靠灰度、监控和回滚。
稳定运行
1、机器健康度：磁盘空间、网络抖动、流量不均引起单机风险等。尤其是磁盘空间满，对于成熟团队来说应该是低级事故，不应该出现。应该有完善的平台、机制确保一定不会出现磁盘满。
2、容量规划：计划中的大促等，需要提前规划好容量。在规划前需要准确压测摩的系统性能数据。
3、自愈能力：这是一项高级但也非常必要的能力。可以举一个典型的发面案例：系统异常导致内存中的任务队列大量堆积，异常清除后还在持续消费内存中堆积的任务，必须人工重启来干预。这种情况下，应该设置合理的队列最大长度、丢弃过期的任务、背压等手段来实现自愈，避免依赖人工干预导致故障恢复时间拉长。
4、极限压测：理想的压测应该是常态化进行极限场景压测、每次变更前后进行压测、定期进行线上流量回放压测以及时发现流量特征变化对性能的影响。实际中，因为自动化程度不够高，不能完全做到，但是要持续往这个方向发展。
风险感知
1、监控：监控这部分需要单独做系统性设计，后面单独分享。原因是平时还是经常看到核心系统都有监控，但是监控的覆盖面、问题诊断能力严重不足。做的稍微好点的有调用量、成功率、耗时等监控，做的差的只有几个调用量的监控根本不具备问题感知能力。
2、预警：预警首先要覆盖所有故障场景，直接造成故障风险的一定要有电话告警。而且预警要持续优化，降低到大家每条都能处理的程度，过度告警等于没有告警了。
3、反馈：收到预警后要能快速处理，可以值班也可以由指定人跟进。
风险控制
1、容灾切换：如果有同城容灾、异地容灾、单元化、区域化等容灾手段的话，切换到其他可用区是一个可用快速恢复服务的手段。
2、限流：当DB出现大量慢sql，突发流量造成容量风险时候，限流是避免系统彻底崩溃的有效手段，限流能力必须提前做好建设。
3、降级：降级通常会有一定的牺牲，但是可以确保核心的功能可用，比如牺牲一定体验。
4、故障隔离：通常是最后没有办法的时候的手段，比如新设备上线后会在很长一段时间里会有独立的接入点，避免新设备的访问异常造成无线大的访问冲击影响其他存量设备接入。
团队训练有素
以上的风险感知、风险控制手段能否有效执行，取决于团队是否训练有素。平时头脑清醒，重大故障期间慌的不知所措时很容易出现的，即使有预案也想不起来或者不敢执行。
1、应急预案演练：前面讲过，只有反复演练过的故障才敢真的去执行，尤其是有损预案。
2、突袭演练：突袭更接近于真实场景的演练，日常可以团队内互相突袭，也可以找风险团队协助联动做红蓝对抗突袭。
3、故障响应演练：专业的故障响应过程，一定要有多个训练有素的角色高效配合才能最大限度压缩故障时长，要有指挥员负责整体把控、资源协调，通讯员负责信息收集、对组织内和客服甚至公关口径及时传递有效信息，要有专人去执行预案尽快恢复服务，也有要人去分析原因确保元无法消除影响后进一步处理。最典型的不专业表现是故障后所有人都扑上去寻找原因，这是大忌。如果看过足够多集团重大故障的话，应该能够发现我们有不少的故障原因是十几个人数天时间才能真正分析清楚的。故障期间，原因分析之要能满足故障恢复即可，不要强迫自己一定要分析到根本原因。比如服务异常后，定位到是db异常，这个时候如果有提前db降级预案，就可以快速评估是否执行了，而不是分析db异常的根本原因，我们有些db异常最后分析到是mysql内核层的bug,如果要分析到这种级别的根本原因才能恢复服务那对业务来说绝对是灾难。
稳定性建设（一）--服务端稳定性体系
[稳定性建设（二）--稳定性之监控]
[稳定性建设（三）--稳定性之系统自愈能力]
[稳定性建设（四）--稳定性之应急预案建设]
[稳定性建设（五）--稳定性之预案规范]
[稳定性建设（六）--稳定性之统一错误日志规范]
[稳定性建设（七）--稳定性之故障应急处理流程]
