分布式系统大势所趋，银行运维如何与时俱进？

之前我们分析了银行等金融机构的运维组织架构现状，讨论运维组织敏捷化转型的背景，最后解释了什么是敏捷型的运维组织以及如何打造敏捷型的运维组织。本文我们重点来关注架构实施层面：金融业分布式系统运维实践。

分布式系统，无论在互联网行业亦或是传统行业，都不再是新兴事物，互联网公司推行较早，传统行业近几年也开始发力建设。对于运维人来说，分布式系统的运维与传统集群式系统的运维大相径庭，我们今天就来探讨一下分布式运维的建设。

01. 分布式运维挑战

1.分布式系统的定义

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。—— George Coulouris 《分布式系统概念与设计》

一个分布式系统是一些独立的计算机的集合，但是对于该系统的用户来说，系统就像一台计算机一样。—— Tanenbaum 《分布式系统原理与范型》

分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。——百度百科

如下图是几种典型的分布式系统架构：

2. 分布式系统呈现如下特征

分布性：由多台计算机组成，在地域上是分散的；系统功能分布在各个节点上，具有数据处理的分布性；
自治性：各个节点都包含自己的处理机和内存，具备独立处理数据的功能，通常彼此地位平等，无主次之分；
并行性：一个大的任务可以划分为若干个子任务，分别在不同的主机上执行；
全局性：存在单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信，同时还有全局的保护机制。

3. 分布式系统的运维挑战

与相比传统单体架构相比，分布式架构提高了整个系统的可用性，可以从容应对大规模应用场景，但也对运维提出了以下挑战：

1）运维不确定性显著增加：

系统中有大量的服务器及设备，各模块之间存在错综复杂的依赖关系，存在更多的不确定性。

2）故障率指数级增加：

整个系统的故障率会随设备的增加而呈指数级增加,单一节点问题可能会被无限放大，日常运行过程中一定会伴随“异常”发生。

3）运维日常复杂性大增：

分布式系统节点分布范围更加广，节点数量更多，物理位置不统一，非常依赖于网络，这对日常运维过程中的日志采集、变更升级等都带来了新的挑战。

4）运维架构复杂度：

随着技术角色分工越来越细，技术专业化程度越来越深，分布式系统稳定性落地因其架构特性，对架构设计思路、组织设计等带来了新的挑战。

5）运维新模式：

要保障分布式架构下的系统稳定性，需要系统化地探讨稳定性建设新模式。

分布式系统建设追求稳定性，分两个目标、四大模式、四项路径。

图源：中国信息通信研究院《分布式系统稳定性建设指南（2022年）》

02. 稳定性建设目标

1. 建设目标主要有两个：

降发生：事前的管理，通过建设“高可用、高性能、高质量”的系统来降低故障发生的概率；

降影响：事后的管理，在故障发生后，“早感知、快定位、急止损、优改进”，降低影响范围。

量化评价指标三个：

业务可用程度；
用户影响程度；
资产损失程度。

03. 稳定性运维建设模式

分布式运维建设模式主要分为：架构设计、容量设计、运维设计、安全设计。我们主要看下和运维相关的要点。

1. 架构设计

一般情况下，架构设计主要由研发部门主导，但是运维人员不能只是作为后端被动承接系统的运维，最好在架构设计阶段就提出规范，满足稳定性运维的要求：

① 去除单点

② 依赖设计

高等级服务不允许强依赖于低等级的服务或资源。

③ 数据保护

数据保护的主要目的是提升数据安全性，业界一般通过RPO（恢复点目标）与RTO （恢复时间目标）两个指标进行度量，核心目标是尽可能缩短数据恢复时间（降低RTO），避免数据丢失（RPO接近于0）。

针对不同的业务系统、分布式系统里面不同的服务模块，需要有对应级别的数据保护考量。

服务器单点保护：基于本地盘跨机房异步复制数据，但服务器出现不可恢复故障时将存在数据丢失
存储单点保护：基于单存储数据库系统跨机房异步复制，但存储出现不可恢复故障时将存在数据丢失
同机房内多点保护：基于同机房多点保护的数据库系统，同机房多份redo及跨机房异步复制模式，但机房故障时存在数据丢失
同城异机房保护：基于同城异机房保护的数据库系统，采取同城异机房内多份redo保护及跨机房DG，但城市出现灾备时存在数据丢失
异地异机房保护：基于异地多点保护的数据库系统，采取跨城跨机房数据保护，但出现人类灾难时存在数据丢失

④ 灾备设计

当故障或者灾难发生时，可通过灾备技术保证业务不中断、数据不丢失。针对不同的业务场景，综合成本与效果的考量，选择相应的灾备设计。

灾备技术发展历程

⑤ 弹性设计

故障隔离标准：防止故障传播；
访问量控制标准：对服务资源有效的SLA控制；
服务降级、限流与熔断：保护系统影响进一步恶化；
容错设计：本着不信任外部资源（外部服务、DB、网络设备、存储、消息等）100%可用的原则。

2. 容量设计

系统上线之前，最好能有一个比较严谨的测试，比如全链路压测，模拟用户真实流量，对容量和性能等做测试。

3. 运维方案设计

提前考虑系统上线后的运维诉求，做到变更可控、系统可观、演练到位。

① 变更设计

分布式系统发布频率较高、颗粒度较小、发布量较大，变更引起的系统问题一般占大部分比重，所以需要有一套严格的自动化发布机制。

② 可观测设计

可观测，以前叫监控告警，是分布式系统里面提出的一个新概念。应用系统观测需要覆盖的资源类型如下：

可观测的核心主要是四个维度：拓扑、Metric指标、trcae链路、log日志。

横向看，从业务访问端到端的整个链路做数据的分析和展示，纵向看，把整个的资源、资源的指标和日志拉通；横向是业务层次、纵向是技术层次，一横一纵，就构成了可观测。

③ 演练设计

相较传统架构系统，分布式系统发生故障的概率较高，我们需要提前进行演练设计。

④ 安全设计

系统安全是系统稳定的基础，主要有如下四个方面：

系统设计安全
部署和操作系统安全
数据安全
网络安全

04. 分布式系统运维工具落地建议

稳定性保障能力建设是一项非常庞大而复杂的工程，落地非一朝一夕可完成，运维人员可以结合业务发展不同阶段所面临的关键风险形势进行规划，拟定合适的建设优先级及实施路径。

1. 一体化综合管理工具

微服务化日甚的当下，故障影响往往是复杂多样的（单一节点故障可能导致全线业务出错），往往需要多个技术团队的协同保障系统稳定。需要统一的系统化稳定性管理能力作为“连接器”实现多团队协同“透明化”作战，并进一步通过故障应急过程及结果数据复盘，“数据化”风险趋势以确定建设重点，“标准化”故障管理流程以提升故障管理效率，定义业务或服务的SLO ( Service Level Objective，服务等级目标）以“结构化”组织稳定性保障能力。

2. 故障预防工具

① 可观测能力

如果直接选用一套大数据平台来进行全局可观测能力的构建，几乎是行不通的。主要原因在于：

目前在银行等企业里面，或多或少都已有Zabbix、APM等来自不同厂商的监控工具，数据格式等均不一样，无法关联
市面上现有的大数据平台，基本都是裸的或者比较笨重的大数据平台，只对数据处理比较在行，但对不具备监控管理能力，如果启用大数据平台做监控数据的分析，需要先清理监控数据
监控消费的场景是不断增长的，后续的对接集成开发和维护成本非常高

那么比较好的建设模式甚至是最好的建设模式，是选一个具备大部分监控能力和数据处理的产品，同时兼容性较强，其他没有的能力可以通过对接补足，这样比较容易落地。

或者也可以选一个兼容性比较强的分析系统，本身能够支持市面上常见的成熟产品，来做集中对接，这种方式也可行但相对难一点。

② 变更管理

变更管理能力建设中，信息标准化和变更风险控制属于ITIL管理的范畴，全量接入、变更中控和变更环境控制属于执行的范畴。

我们在实际落地的时候，属于管理范畴的，建议在ITSM里面建设；属于执行范畴的，在变更工具里面落地。

管理流程和管理工具，可以基于同一个运维管理平台进行对接。