聊一聊，如何做好垂直域稳定性（2）

✪ 1.2.5 数据治理

与数仓领域的同学不同，稳定性同学很少会对数据质量去做管理，这里提到的数据治理，主要是指治理一些会影响到稳定性情况的一些数据。比如，某业务发品时，由于逻辑没有对齐，有些情况下虽然发品成功，但是会认为发品失败，会不断进行发布重试，一直失败一直重试，也没有设置重复上线，导致同样一个商品最多发了上百万次，使线上某核心链路查询货商关系时大量full gc。

一句话总结：由于链路不合理、黑灰产、外部胡乱操作或线上问题产出的阻塞链路、扩大成本的大数据内容，都算作线上不合理的数据治理范围，每年固定的时段，稳定性同学会统一对这些数据做一次治理，降低成本，提升链路稳定性。

1.3 一个稳定性同学需要的能力

来打个比方，业务同学好比前线打仗的韩信，攻占地盘，为公司创造业务价值，而稳定性的同学则是维护大后方的萧何，为前线的同学提供保障，维持系统的稳定运行。如果业务发展不好，则公司无法维持好经营，但是如果前方断粮，系统的性能和稳定不足以承载这么大的业务体量，那么无论业务再怎么发展，都是白费功夫。保证系统稳定安全的运行，是稳定性同学最重要的工作。稳定性的工作强度很大，同时对人的心、脑、体考验也极大。它需要多元能力：

✪ 合格的技术能力

衡量一个稳定性同学是否能cover住垂直域稳定性工作的第一个重要指标，就是他的技术能力，对于技术能力要求的细节。日常要保持一直学习的心态，养兵千日，用兵一时，不能临时抱佛脚。在此我不做过多描述，这里只放一张关于java基础核心能力的图供大家感受一下：

✪ 临危不乱的心理素质和强大的身体素质

从事稳定性工作，不论与你是否有关，相关业务是否了解，遇到的所有问题及故障永远都是第一处理人，因此见到的问题故障会比一般同学多出很多，同时集团对于故障处理的要求非常严格，这时候就需要你有强大的心理素质。身体素质自然不用多说，如果说稳定性是业务发展的“1”，那么强壮的身体则是稳定性同学需要的那个“1”。

✪ 熟能生巧

如果说技术能力是排查问题需要首要条件，那么熟练度则检验了一个稳定性同学是否足够老成；一个问题新人定位&处理可能需要几个小时，但是成熟的稳定性同学凭借经验和工具可能瞬间定位到问题的根因，确定解决方法。

✪ 拉通 & 人际交往能力

稳定性同学大多都会参与到横向任务，如大促保障、跨域稳定性专项等事情中来，因此，优秀的人际交往、协调，拉通的能力，也是稳定性同学需要拥有的，与其他团队紧密协作、积极配合，也会为自己和团队留下较好的口碑，以后推进其他事情也可以事半功倍。

02

稳定性体系建设

2.1 防线建设

✪ 2.1.1 架构设计

稳定性工作本身偏向于底层技术，对于小、中公司而言，稳定性同学的定义更偏向于“技术架构师”的角色，所以底层技术架构上的设计是稳定性防线建设的一部分，简单举几个例子：

⍟ 容量评估

什么情况下需要进行容量评估？我理解有以下两种场景：

• 新发应用：应用建立之初，需要根据预估上游的流量，计算容器、中间件的吞吐率，在计算结果的基础上加上一些兜底的机器后，给出应用所需的容量。
  
  
• 业务变化较大：当上游或者应用内部有较大的流量或性能变化时，要调整之前的容量，如大促期上线下线，或业务链路有重大迭代变更时。
  

容量评估是架构设计中比较重要的一环，容量太多会浪费成本，容量太少则会对线上可用性产生影响。

⍟ 部署架构 & 容灾

在分布式系统大行其道的今天，容灾的场景基本在集团每个应用中都可以见到，比如集团的多单元部署，现在比较常见的架构主要是由中心A地（中心 + 混部集群）和单元B地（单元 + 混部集群）两个比较大的单元构成的，也就是所谓的“两地”，流量从入口端进行转发。

容灾的重要性不言而喻，如果单纯在一地做集群化，若遇到天灾人祸等不可避免的物理损失，将会导致服务不可用，事实上也经常出现某单元由于网络运营商的问题导致服务挂掉的情况，这个时候就可以通过从入口处切换跨地调用来解决。

虽然多地部署的理论比较简单，但是部署架构的一个重点在于将流量按照不同的作用去划分分组，如上图中的读、写流量分组是分离的，且读、写按照不同的上游业务也有单独拆分分组，这样就可以保证不会因为上游某一个大业务出问题导致整个集群不可用的场景出现。

当然，每个应用所面临的场景是不同的，那么如何部署、如何容灾，也是这个垂直域稳定性同学需要考虑的问题。

⍟ 数据一致性保证

当今的分布式系统，设计时绝大多数都会碰到异步链路，不管是业务上需要异步的去处理数据，还是中间件的数据同步机制，如果涉及到异步那就有可能会出现数据一致性问题，这与高可用问题分别是两个方向，但是他们两个本质上一样重要，甚至数据一致性出现问题产生的影响、恢复的难度要远大于高可用问题。

所以，在系统架构设计之初，就要做好数据一致性的保障措施，完善对账机制，并通过建立的防线发现存量和增量的问题。每个域面临的数据一致性问题场景不同，对于偏数据存储的部门，往往无法完全厘清模型与模型、数据与业务之间的关系，因此防线总会有疏漏，而一旦数据出现问题，往往是最难解决的：

• 历史数据提取困难，如果没有数据留痕平台，只能通过数据离线表拉取，会导致数据可能有一定误差，如果故障时间线拉的很长，数据的提取会更加困难。
  
  
• 复杂的业务逻辑，往往让人不知道该如何回滚数据，一旦回滚逻辑出现错误将直接导致二次故障。
  

整个数据一致性问题是一个非常大的专题，这里只是让大家稍微有一些体感，想要聊透这个问题需要很长的篇幅，在这里先放一张之前总结的资损防控方法图，供大家参考：