浅谈系统实现层面稳定性保障

<div id="js_content">
<img src="https://beijingoptbbs.oss-cn-beijing.aliyuncs.com/cs/5606289-7097250d6f82847ee547fac83a35b258">
<img height="200" src="https://beijingoptbbs.oss-cn-beijing.aliyuncs.com/cs/5606289-11af0364a4c1cb84e958caff5edb8892" width="416">
<h2>导读</h2>
<hr>
上海外滩建筑群包括古典主义风格的亚细亚大楼（1915年），英国古典式的上海总会大楼（1911年），欧洲古典折中主义的海关大楼（1925年），仿意大利文艺复兴风格的汇中饭店大楼（1906年）等，这些建筑历经百年风雨，仍巍然屹立固若堡垒，保持其原本风貌，让今人得以深切领略一个世纪以前的壮丽繁华。这一切，除得益于人为保护之外，最主要原因是建筑自身主体结构具备较高的稳定可靠性。 
 
而相比传统建筑工程，软件工程有两个显著特点，一是具备规模化快速复制扩散的能力，二是在竣工之后依然可以被改造并保持高速进化。这也就导致了软件工程一点点的不足也可能被快速扩散、无限放大造成大规模损失，进化中既有的稳定性结构可能会被不断打破，可能导致大量的救火投入，疲于奔命，极大地消耗有效而宝贵研发资源，阻碍软件的进行甚至带来灾难性后果。所以对于任何一家上规模的软件开发的企业来说，稳定性保障都是必须面对和解决好的课题。我个人加入阿里之初是在国际支付宝核心团队长期负责金融系统稳定性保障，其后扎根淘系技术三年有余，参与了多种不同类型系统设计与稳定性建设，以及大促稳定性保障工作。对比总结下来无论电商、金融、物流、ERP型软件工程，其稳定性保障是策略是有较多共性经验的。本文主要结合金融、电商两种场景下的个人以及所在团队实践，谈谈稳定性保障的一些思路方法。
稳定性保障围绕的核心
<hr>
稳定性保障涉及机房、网络、硬件部署到业务场景、交互设计，再到应用架构代码质量、流量与封网管控、攻防复盘等，是一项非常系统化的工程。而分工协作使得上述大部分工作流程化标准化，比如硬件问题、网络问题、Jvm监控等均可以由专业化团队提供统一配套方案，做为业务开发主要是利用这些工具更快的发现问题，干预度相对有限。但具体业务系统实现距离拖拽式批量生产尚需时日，最终产出实现方案差异可能很大，所以所有稳定性工作的核心还是围绕系统与代码本身来开展，如下图所示，无论是质量团队、各方管控平台，还是研发流程保障机制，最终的稳定性还是体现在系统代码上。因此，对于业务开发的来说，稳定性保障更应该着眼于系统设计实现环节的控制，如下橙色部分：
<img src="https://beijingoptbbs.oss-cn-beijing.aliyuncs.com/cs/5606289-3e850790f960b42f623edd24b0a21876">
而正是需求不受控、架构局限、代码扩展性不足、监控日志不统一、下游依赖不统一之类问题导致了每到大促前夕的紧张慌乱，重复的梳理、反复的打补丁，需要额外的进行压力测试，预案配置演练，消耗巨大且效果有限。所以我们需要贯穿于系统实现各环节，来制定合理的稳定性策略。系统实现核心环节与稳定性关系如下图所示：
 
<img height="369" src="https://beijingoptbbs.oss-cn-beijing.aliyuncs.com/cs/5606289-5089a7cc68a68e0aeb01f4ff2022af26" width="415">
 
接下来着重针对上图所示各环节，做一下总结。
业务大环境与业务架构稳定性
<hr>
一个人的命运必须要考虑历史进程影响，谈系统稳定性则不可以忽略大的业务环境，业务环境是指所在的部门业务现状，以及自己所在业务部门与其它业务部门的合作现状，可能发生的业务调整重组。
有时候为了满足业务上的发展目标，老板们不得不频繁的做业务调整。随之而来的是技术团队与系统架构的拥抱变化，系统拆分、合并、重建一些列工作，必然会极大地打乱既有的稳定性保障策略，所以必须要从业务环境业务架构的层面来审视并调整以跟上变化。
比如天猫技术部和淘宝技术部合并、拆分，洋淘业务下线，逛逛品牌上线，躺平业务独立，导致原有支持的统一社区运营工作台不再work，各自垂直业务线因发展需要或者被迫不得不独立出自己的运营后台管理，自己的索引，迁移兼容