本书为商业银行构建运维体系和掌握核心运维技术提供了指导。以一家中小型的商业银行为蓝本，讲述商业银行运维涉及的技术以及运维体系的搭建。
全书一共9章：
第1-3章抓哟讲解了商业银行运维在当下面临的挑战，以及传统银行的IT基础架构的前世和今生；
第4章详细介绍了商业银行运维的各项主要工作和技术；
第5-7章介绍了自动化运维和智能化运维，以及全链路监控；
第8-9章介绍了同城双活数据中心以及下一代数据中心的架构。
凝聚多位一线技术专家实践经验，全面揭示银行业运维架构，
探索高效的运维技术和方法
从IT基础设施架构、立体化监控、自动化运维、智能化运维、
双活数据中心等多个维度讲解银行IT运维实践
传统银行业在IT建设层面推进的原动力是信息化，关键字是“信息”，这一细节在很多方面都有所体现。对于拥有信息科技部门的商业银行机构，其IT部门的负责人称为CIO（Chief Information Officer，首席信息官），而互联网公司、科技公司则更看重“科技”，其IT部门的负责人称为CTO（Chief Technology Officer，首席技术官），从中可见一斑。商业银行IT组织架构过去往往是按照“一部两中心”进行设计。“一部”通常是指“信息科技部”或者“信息技术部”，作为专门的科技部门负责全行信息科技工作的统筹管理。“两中心”则分别是开发中心和数据中心。开发中心负责制定全行软件开发的标准和流程，组织实施全行各应用系统的需求分析、设计、开发、测试及技术支持等相关工作；数据中心负责全行信息系统生产运营管理和基础环境、网络通信及各系统平台的维护和技术支持，为全行的业务发展提供安全、持续、高效、优质的信息系统服务。
长期以来，很多商业银行的信息科技部门被定位为中后台部门，作为成本部门，每年花了多少钱很清晰，为全行创造了多少价值、赢取了多少次业务机会却很难估算，对业务价值的贡献只能定性而无法定量，长期被视为辅助角色。与此同时，部分商业银行受人员指标限制，许多IT相关的工作，包括设计、编码、测试、运维等方面大量采用外包服务，甚至升级、扩容、容灾都由外包单位实施，行内科技人员更多是担任与外包商打交道的项目经理角色。随着互联网金融业务的迅猛发展，近年来一些高科技公司借助自身的互联网优势跨界金融，广泛运用如人工智能、区块链、云计算、大数据等新兴技术，采用敏捷研发模式，在金融领域重构了客户关系、业务模式、运营体系，甚至对金融格局产生了深远影响。相比之下，传统银行的科技水平给人一种落后、落伍的感觉。
不过，不要低估银行在信息科技方面的实力，银行业历来是先进技术应用的先行者，在经历了电子化、信息化、移动化阶段后，如今已进入数字化阶段。借由共生式发展关系，现代金融体系也发生了很大变化。银行业始终紧跟科技发展浪潮，在寻求差异化竞争、推动企业数字化转型的征途中，越来越重视信息科技方面的投入和建设，积极实施金融科技战略，重构科技创新体制机制，力求以科技激发传统金融的供给侧输出能力，进而推动银行商业模式乃至发展方式的变革。在数字化时代，金融科技已经成为数字化转型的重要驱动力，科技引领的金融变革将是时代的主旋律。
2016年年底银监会在《中国银行业信息科技“十三五”发展规划监管指导意见（征求意见稿）》中明确声明要让CIO进入决策层，共同参与制定银行的未来发展整体战略规划；2018年Gartner在报告《2018 CIO Agenda》中指出：CIO的职责发生了巨大转变，从原来的 “交付型”高管变成了“IT和业务相结合”的高管——CIO的角色从交付执行者转变为业务执行者；2019年8月，中国人民银行印发《金融科技（FinTech） 发展规划（2019—2021年）》，明确指出金融科技是技术驱动的金融创新，要加强金融科技战略部署，从长远视角加强顶层设计，把握金融科技发展态势，做好统筹规划、体制机制优化等工作，全面提升金融科技应用水平，将金融科技打造成金融高质量发展的“新引擎”，充分发挥金融科技赋能作用，推动我国金融业高质量发展。
名正则言顺，在多家商业银行最新的组织架构中，信息科技部已然进化成金融科技部，部分实力较强的商业银行更是纷纷组建金融科技公司，不仅对内提升科技力量，还要对外做科技能力输出。
我国商业银行类型众多，数量巨大，包括政策性银行、大型国有商业银行、全国性股份制商业银行，以及多达数千家的地方性银行，这些银行的业务开展形态迥异，在信息科技建设投入和模式方面更是差异巨大。过去银行的信息科技建设整体偏保守，无论是监管机构的监管条例，还是商业银行内部的运行要求，对信息系统的要求都是“数据不丢失、业务不中断”，即能够接受系统慢，但绝对不能惹麻烦。
传统信息系统架构倾向于集中，采用All in One模式，以及昂贵但成熟稳定的商业化解决方案。但是，这种集中式架构的建设和运营成本高昂，且运行风险较大。随着经营模式的变化和业务的拓展，在面对基于互联网产业的高并发、大数据量场景时，集中式架构一旦出现处理能力瓶颈则极难扩展，在关键节点负荷高企的情况下，其发生故障的影响面较广，运行风险巨大。相对于集中式架构，以x86 和云计算为基础的分布式架构在运营成本、伸缩性、风险分散控制等方面优势明显，所以采用分布式架构是商业银行应对成本和运营风险的必然选择。
互联网天生就是去中心化的分布式模式，其业务系统采取服务化和无状态的设计理念，易于横向扩展，且并发处理能力和伸缩性远强于集中式架构。不过，采用分布式架构挑战更大、困难更多。在可用性保障方面，分布式架构下使用的x86服务器的可靠性远不如小型机，必须在服务器层和应用系统层等均采用负载均衡以及高可用设计，使系统服务的总体可用性能达到更高标准。同时，要重点关注基础设施层，包括云计算平台、网络、存储以及跨机房同步复制等设施的可靠性。在数据一致性方面，根据CAP理论，一个系统不能同时满足一致性、可用性和分区容错性这三个要求，如何平衡读写分离带来的可用性和一致性矛盾，也是分布式架构设计必须解决的问题。分布式架构下系统数量和服务器数量都会迅速增长，应用系统之间的关联关系更为复杂，这也给商业银行数据中心的稳定运维、持续运营提出了更高要求。
本书作者大都就职于新兴的民营体制银行。这家位于我国西南部的民营银行，麻雀虽小，五脏俱全：既有传统银行科技团队的特点，深度运用成熟稳定的商业化解决方案，又有互联网科技公司的特点，从互联网的基因出发，大量选择互联网模式下成熟的开源分布式解决方案。在银行业“安全可靠和合规运行”总体要求的基础上，在当前互联网金融需求极度旺盛，人工智能、云计算、大数据等新兴技术不断涌现的新形势下，作者所在团队积极推动内部IT运维服务和设施标准化、可视化、容器化、资源池化，充分运用分布式、自动化、云计算、智能化等手段，构建DevOps体系，打通从需求分析、编码、构建、测试到发布、部署、运营、监控的全生命周期敏捷产品研发，快速变更、快速交付，降低故障修复耗时，提高资源利用率，助力金融企业数字化转型。
本书第1章主要介绍银行信息系统的建设背景、IT服务理论的演进路径、IT运维支撑团队面临的挑战以及IT运维变革如何助力数字化转型；第2章和第3章从主机、存储、网络、备份及多机房容灾架构等多个方面，讲解商业银行基础设施层架构的变迁；第4章主要讲解商业银行IT运维日常，以及在重复、烦琐工作中的破局之道；第5章主要讲解如何构建一套覆盖基础设施、应用系统、日志、流量追踪等的立体化监控体系；第6章主要讲解商业银行自动化运维体系；第7章主要讲解AIOps方面的探索和实践；第8章主要讲解商业银行同城双活容灾架构；第9章从软件定义数据中心、下一代云计算技术、混合云、边缘计算等方面介绍下一代数据中心技术。
本书作者是科技自动化的忠实使用者和推广者，推崇通过科技手段让一切都能够“自己动起来”。对于研发，团队通过企业级开发框架、脚手架和代码生成工具、统一封装的各类组件库来统一开发标准，提升开发效率；对于测试，团队通过提供统一的自动化测试框架，提高代码单元测试覆盖率，提高自动化测试用例占比，提升质量团队的执行效率和质量保障水平；对于运维，团队通过构建自动化装机、自动化发布、自动化巡检、全链路监控、CMDB等系统建设DevOps体系，提升运行保障的效率和水平。
这些让一切“自己动起来”的手段并不是要取缔流程、摆脱人员，而是要转变视角，充分运用科技，将流程隐匿在科技（系统）的背后，选择适合企业现状的数字化手段，以科技管科技，让工作自动流转，让消息自动通知，让信息自动同步，让状态自动变更，让数据自动更新，让数字自己跳动。
我们不希望重复劳动，而是希望把一些最佳实践、流程、方法固化成代码、工具、平台，用这种方式来应对数字化时代金融业务的规模扩张，平衡IT系统复杂度提升带来的影响。我们将自己在信息科技领域实践过程中的思考和探索展现出来，希望能供商业银行、证券、基金等行业的信息科技团队或互联网企业及科技公司的朋友参考。在《充满生机的技术》一书中有这样一段话深得我心：我们还期待着这本书能超越科技书的范围，获得更多的读者，让普通大众知道，在与满足于有形无实的制度、对名利无休无止的追逐完全背道而驰的地方，有很多人每天都在群策群力，对技术进行着反复的思考和实践。
李丙洋
计算机\网络
在金融科技蓬勃发展的浪潮下，如何将新兴技术转化为生产力和竞争力，是包括银行在内的传统金融机构面临的一项重大课题，也是传统金融机构能否顺利实现数字化转型的关键因素之一。
本书的作者团队是科技实现自动化的狂热推动者，鄙视“重复劳动”，推崇“通过科技手段让一切自己动起来”。他们既能像传统银行的科技团队一样，深度运用成熟稳定的商业化解决方案，又能像金融科技公司的技术团队一样，自如地使用互联网模式下成熟的开源分布式解决方案。
他们推动内部IT运维服务和设施标准化、可视化、容器化、资源池化，并充分运用分布式、云计算、自动化、智能化等手段，构建DevOps体系，实现快速变更与快速交付，帮助银行提升系统的可靠性和资源利用率，助力金融企业数字化转型。
通过本书，你将收获以下核心内容。
银行运维团队面临的挑战以及如何助力数字化转型。
银行的传统IT基础架构：基础设施、网络架构、灾备架构。
银行的新兴IT基础架构：云计算架构、存储与网络架构、安全架构、备份架构。
银行IT运维工程师的主要日常工作。
银行立体化全链路监控体系，自动化及智能化运维体系的构建。
银行同城灾备及双活数据中心的架构设计与建设实践。
银行下一代数据中心技术：软件定义存储、软件定义网络、混合云和边缘计算等。
前 言
致 谢
第1章 商业银行运维路漫漫 1
1.1 商业银行信息化建设背景 1
1.1.1 背景的背景 2
1.1.2 道路有些崎岖 3
1.1.3 驶入平坦的快车道 5
1.2 IT服务理论演进路径 6
1.2.1 ITIL 7
1.2.2 ITSM 10
1.2.3 DevOps 11
1.2.4 ITIL与DevOps对比 14
1.3 IT运维支撑团队面临的挑战 16
1.3.1 业务模式变革的挑战 16
1.3.2 拆IT系统“烟囱”的挑战 17
1.3.3 新形势下网络安全的挑战 18
1.3.4 IT架构快速演进的挑战 19
1.3.5 IT服务可靠性及服务流程的挑战 20
1.4 IT运维变革助力数字化转型 22
1.5 本章小结 25
第2章 商业银行IT基础架构的前世 26
2.1 传统架构从无到有的演进 26
2.1.1 分散式架构 27
2.1.2 集中式架构 28
2.2 商业银行的传统IT基础架构 30
2.2.1 商业银行的传统IT基础设施 30
2.2.2 商业银行的传统网络架构 31
2.2.3 商业银行的传统灾备架构 36
2.3 本章小结 44
第3章 商业银行IT基础架构的今生 45
3.1 商业银行IT架构的变革 45
3.1.1 总线+微服务架构 45
3.1.2 容器化架构 47
3.2 分区分层：网络架构 47
3.2.1 网络架构设计思路 47
3.2.2 数据中心网络架构 49
3.3 “矛”与“盾”：网络安全架构 52
3.3.1 金融网络安全要求 53
3.3.2 金融网络安全体系 53
3.3.3 金融网络安全技术 56
3.3.4 小结 59
3.4 “云”：计算架构 59
3.4.1 信息系统分级 59
3.4.2 整体架构 60
3.4.3 分布式计算 62
3.4.4 “云”资源管理 62
3.4.5 容器环境的计算架构 65
3.5 分久必合、合久必分：存储架构 66
3.5.1 分：直连存储 66
3.5.2 合：集中存储 68
3.5.3 合：存储虚拟化 72
3.5.4 分：分布式存储 73
3.6 有备无患：备份架构 75
3.6.1 备份对象与技术 75
3.6.2 数据备份系统介绍 76
3.6.3 数据备份方案 78
3.6.4 数据备份优化 79
3.6.5 备份管理 80
3.7 本章小结 81
第4章 平凡的运维日常 82
4.1 运维组织管理 82
4.2 自动化巡检 83
4.2.1 自动化巡检分类 84
4.2.2 自动化巡检实现 84
4.3 系统变更 89
4.3.1 发布方式 90
4.3.2 发布策略 93
4.3.3 发布实践 95
4.4 组件化 96
4.4.1 配置管理 96
4.4.2 日志收集 102
4.5 系统监控 106
4.5.1 基础设施层监控 107
4.5.2 系统层监控 107
4.5.3 应用层监控 108
4.5.4 业务层监控 109
4.5.5 用户体验层监控 110
4.6 事件管理 110
4.6.1 什么是事件管理 110
4.6.2 事件管理流程 111
4.6.3 事件应急处理 112
4.6.4 事件管理制度及分级 113
4.6.5 事件管理优化 114
4.7 运维标准化 115
4.7.1 域名化 116
4.7.2 做好基线配置 117
4.7.3 基础运行环境标准化 117
4.7.4 网络标准化 120
4.7.5 数据库标准化 122
4.8 本章小结 126
第5章 构建立体化监控体系 127
5.1 为什么我们“没有”发现问题 128
5.2 构建立体化监控体系 129
5.2.1 流行监控系统面面观 130
5.2.2 规划监控体系 139
5.2.3 监控实践 147
5.2.4 事件响应与监控告警 158
5.3 全链路监控 160
5.3.1 原理扫盲 160
5.3.2 全链路监控实现方案 162
5.4 云/容器时代的监控系统 169
5.4.1 试用新一代监控系统Prometheus 171
5.4.2 服务监控 179
5.4.3 监控告警 184
5.4.4 容器监控 189
5.5 再谈监控 200
5.6 本章小结 202
第6章 构建自动化运维体系 203
6.1 自动化运维概述 203
6.1.1 传统IT运维的现状 203
6.1.2 自动化运维的发展因素 204
6.1.3 自动化运维的发展阶段 204
6.1.4 自动化运维体系的规划 205
6.2 自动化运维建设的经验分享 207
6.2.1 CMDB 207
6.2.2 离不开的自动部署 215
6.2.3 容器云平台的建设 223
6.2.4 为DBA减负 240
6.3 自动化运维体系中关于安全的思考 244
6.3.1 平台设计方面的安全保障 244
6.3.2 功能测试验证的安全保障 245
6.4 本章小结 245
第7章 智能化运维探索 247
7.1 运维方式的演进 247
7.1.1 从手工到智能化 248
7.1.2 运维的现状和未来形势 249
7.2 智能化运维的基础 251
7.2.1 运维基础工具及平台 251
7.2.2 运维开放平台 253
7.2.3 运维大数据平台 255
7.3 新型运维协作方式 260
7.3.1 ChatOps介绍 261
7.3.2 ChatOps的应用与实践 265
7.3.3 人工智能与ChatOps 277
7.4 智能运维机器人 284
7.4.1 运维工程研发体系 285
7.4.2 智能运维大脑 286
7.5 本章小结 304
第8章 银行双活数据中心架构 305
8.1 双活建设评估 306
8.1.1 容灾建设目标评估 306
8.1.2 双活建设方案评估 307
8.1.3 成本投入评估 308
8.1.4 科技能力评估 309
8.2 双活建设要点 311
8.3 双活建设方案 313
8.3.1 存储级双活 314
8.3.2 应用级双活 318
8.3.3 业务级双活 321
8.3.4 双活建设方案总结 325
8.4 双活基础架构改造 325
8.4.1 应用层改造 326
8.4.2 中间件层改造 329
8.4.3 网络层改造 349
8.4.4 存储层改造 354
8.5 双活应急场景 355
8.5.1 业务系统故障 358
8.5.2 数据库宕机故障 359
8.5.3 网络中断故障 362
8.5.4 自然灾害场景 364
8.6 本章小结 365
第9章 下一代数据中心技术 366
9.1 软件定义数据中心 367
9.1.1 软件定义服务器 367
9.1.2 软件定义网络 368
9.1.3 软件定义存储 373
9.1.4 超融合 376
9.2 下一代云计算技术 379
9.2.1 Kata Containers 379
9.2.2 Service Mesh 381
9.2.3 Serverless 383
9.3 混合云 385
9.4 边缘计算 386
9.4.1 基于Kubernetes的边缘计算技术 387
9.4.2 边缘计算安全 388
9.5 本章小结 389
