《证券行业分布式核心系统SRE运维白皮书(2022)(33页).pdf》由会员分享,可在线阅读,更多相关《证券行业分布式核心系统SRE运维白皮书(2022)(33页).pdf(33页珍藏版)》请在三个皮匠报告上搜索。
1、证券行业分布式核心系统SRE运维白皮书恒生电子股份有限公司中国信息通信研究院云计算和大数据研究所2022年4月版权声明本白皮书版权属于恒生电子和中国信息通信研究院, 并受法律保护。 转载、 摘编或利用其它方式使用本白皮书文字或者观点的, 应注明“来源: 恒生电子和中国信息通信研究院” 。 违反上述声明者, 编者将追究其相关法律责任。由于金融行业扩大开放带来的竞争环境变化, 以及用户服务需求不断提升, 证券机构核心系统技术日新月异, 网络架构越来越复杂。 证券行业为满足业务敏捷创新需求, 内部核心系统已从传统的IT集约型架构开始逐渐向分布式架构转型,这对企业内部IT运维管理带来非常大的挑战。 S
2、RE作为创新型运维方法论, 可为证券行业分布式核心系统运维人员提供一种新的转型思路。本白皮书重点关注证券行业分布式核心系统SRE运维服务体系及相关服务支撑平台工具。 首先, 白皮书给出IT运维国内外发展现状和IT分布式架构运维面临的问题和痛点。 其次, 梳理了SRE运维模式原则和思路, 并详细分析了DevOps和SRE运维方式的异同点。 接着, 将SRE运维服务体系从服务度量体系、 观测指标体系、 流程管理体系、 稳定性运营体系以及组织管理体系五方面分别展开介绍, 并介绍关键环节的服务支撑工具和平台。 最后, 白皮书针对目前SRE发展面临的问题提出相关建议, 明确了SRE运维发展趋势, 并对S
3、RE运维方法论应用在证券行业分布式核心系统中给出三种应用模式建议。本白皮书编写单位为: 恒生电子股份有限公司、 中国信息通信研究院云计算与大数据研究所、 东北证券股份有限公司、 东方证券股份有限公司、 光大证券股份有限公司、 山西证券股份有限公司、 招商证券股份有限公司。前言Foreword一、 我国证券行业分布式系统运维现状(一) 外力和内需双向促进证券行业分布式系统运维模式转型(二) 系统分布式架构给传统运维带来挑战(三) 以主动运维为核心的SRE运维模式兴起, 弥补传统运维模式缺陷二、 分布式核心系统SRE运维模式概述(一)SRE运维模式为证券行业业务系统可用性保驾护航(二)DevOps
4、与SRE异同点对比(三)SRE运维模式需贯彻五个核心原则三、 证券行业分布式核心系统SRE运维服务体系(一) 以用户体验为核心的服务质量度量体系(二) 以监控系统为基础的观测指标体系(三) 以稳定可靠为保障的流程管理体系(四) 以服务治理为目的的稳定性运营体系(五) 以持续改进为标准的组织管理体系目录Contents810121418四、 证券行业分布式核心系统SRE支撑工具和平台(一)监控平台实现故障快速定位(二)事件管理平台保障事件快速响应(三)数据服务平台支持决策以释放数据价值(四)自动化平台助力员工解放生产力(五)应用部署优化业务迭代流程(六)CMDB高效管理IT
5、基础架构与服务202021222222五、 证券行业分布式核心系统SRE发展前景(一) 主管部门完善相关政策指引(二) 证券业机构关注自身SRE能力建设(三) 服务提供机构提升SRE服务能力(四) 第三方机构构建分布式核心系统SRE标准评价体系六、 证券行业分布式核心系统SRE应用建议(一) 模式一: 内建SRE中台能力 (二) 模式二: 外引SRE咨询服务(三) 模式三: 内外结合的SRE混合体系目录Contents242424242627272426我国证券行业分布式系统运维现状1.我国政策环境良好, 金融科技推动经济新增长(一)外力和内需双向促进证券行业分布式系统运维模式转型以AI、 大
6、数据、 云计算、 区块链为核心的新技术生态正在逐步完善, 成为近年来带动经济增长的核心动力。 随着数字化转型的不断推进, 软件和信息服务业迎来新的发展机遇和挑战, 国家对各行业的软件质量及系统稳定性提出了更高的标准、 更严的要求。 工信部发布的 “十四五” 软件和信息技术服务业发展规划 中强调 “提升软件质量管理能力和软件价值保障能力” ,极大鼓励软件高质量发展。自2018年以来, 金融监管部门也先后出台 证券基金经营机构信息技术管理办法 、金融科技发展规划 (2022-2025年) 等文件, 提出应加强金融业科技应用能力, 进一步明确信息技术与业务、 风控及合规管理深度融合。 在此情况下,
7、券商对 IT 技术赋能业务的重视程度日益增加,为保障IT业务高速发展变化, 以及新一代分布式核心系统稳定运行, 更多券商机构向以保障系统稳定性为目标的自动化运维、 智能化运维的新型运维模式转型。2.证券机构核心系统向分布式架构转型促使运维模式转型证券行业核心系统架构由集约型向分布式转型。 由于金融行业扩大开放带来的竞争环境变化、 用户服务需求提升、 消费主动性增强以及科技的创新发展, 使得业务创新成为证券机构的必然选择, 因此对证券核心系统带来巨大的变化和需求。 同时, 在互联网金融模式的冲击下, 证券机构的核心系统需要面对海量客户和交易、 快速响应客户需求、 提供灵活的金融产品和服务、 经营
8、模式变化等的挑战。 目前, 传统的集中式核心系统已难以适应数字化时代的种种变化,逐渐出现运维人力成本上升、 产品迭代效率低、 故障响应处理周期长、 客户流失增加等问题。 为了应对上述问题, 支持敏捷开发、 弹性扩容、 智能灵活的分布式架构核心业务系统成为证券行业核心系统主流架构。证券行业分布式运维自动化程度较低, 被动运维普遍。 近年来, 随着分布式运维管理技术的提升, 证券行业已经开始使用简单的自动化工具, 但存在普遍程度较低的问题。 证券机构内部,1第一章分布式运维人员往往会花很多时间和精力在一些简单且重复的问题上, 加上目前普遍处于被动运维管理模式, 故障预警机制并不完善, 往往在发生故
9、障后报警才处理, 导致系统遇到障碍时不能快速排查应用系统处理交易异常。 因此证券行业亟需一套适合分布式系统的自动化、 智能化的新型运维模式, 用以保障系统的稳定可靠运行。(二)系统分布式架构给传统运维带来挑战1.分布式架构运维复杂度提升分布式架构将一个单体系统拆分为多个服务, 数据库进行多个维度的拆分, 使运维面临服务层次、 调用关系、 系统状态更加复杂的挑战。 这种情况下运维既要做到划分合理, 充分解耦,又要尽量避免复杂的数据一致性问题。 如果缺少有效的服务治理手段将导致依赖地狱, 搞不清系统间的关联关系, 一旦某个点出问题, 极易导致整个系统的崩溃。2.业务增长快速, 单一运维工具已无法满
10、足用户需求在满足系统稳定性和效率提升的目标下, 分布式架构下的运维工具需要应具备评估资源池容量、 及时故障预警与应急响应、 故障自动定位等能力, 显然单一工具无法满足, 如何形成一套完整的运维服务工具进行自动化、 智能化运维成为挑战。 例如, 随着券商线上业务的快速发展,各大券商APP的活跃用户规模不断扩大, 运维人员应及时观测和评估计算资源、 存储资源、 网络资源等, 保障在大规模用户同时下单和交易等过程中, 将延迟控制在允许范围内, 为用户提供优质的产品服务, 提高用户使用粘性。3.运维管理人员知识技能要求提高随着行业业务驱动的需求增多, 系统架构由集中式向分布式架构转型, IT 基础设备
11、种类越来越多, 对运维管理人员的知识和技能将提出更高要求。 分布式架构中各个集群节点处理的业务请求也会激增数倍到数十倍, 需要监控的环节大大增加, 运维人员如何设置监控指标形成一套全面、 准确、 实时的观测度量体系成为挑战。证券行业分布式核心系统SRE运维白皮书2一般来说, 传统的IT企业采用 “开发部 (Dev) +运维部 (Ops) ” 分离的团队模式, 该模式存在随着系统复杂度、 组件、 流量的增加, 相关的事件和变更需求也将增加的问题, 由于两个团队相互不了解对方的工作技能, 进而造成两个团队间的直接成本和间接成本不可避免上升。 在此背景下, SRE新型运维模式应运而生。SRE运维模式
12、可从根本上弥补传统运维缺陷。 SRE最早在十多年前Google提出并应用, 近几年逐步在国内外TOP互联网公司以及金融机构开始广泛应用。 SRE运维模式采用的是运维即开发、 自动化代替人工的思想。 SRE团队主要由软件工程师组成, 通过开发软件工具、 自动化流程等方法地替代传统模型中的人工操作。 在这种运维模式下, SRE运维工程师至少有50%的时间可以用于开发和学习, 通过开发自动化、 智能化工具, 可以提升运维人员工作效率并减轻运维人员工作负担, 同时帮助运维人员快速排查故障问题, 达到对系统故障早发现早治理的效果, 最终达到节省直接成本和间接成本的目的。接下来, 将针对能解决证券行业分布
13、式核心系统运维痛点和难点问题的SRE新型运维模式展开详细介绍, 包括SRE运维方法论的概述、 SRE的运维服务体系以及相关的支撑工具和平台等。(三)以主动运维为核心的SRE运维模式兴起, 弥补传统运维模式缺陷我国证券行业分布式系统运维现状第一章3分布式核心系统SRE运维模式概述(一)SRE运维模式为证券行业业务系统可用性保驾护航SRE是一种区别于传统运维模式的新型运维模式, 用于保障企业系统的稳定性和可靠性。SRE (Site Reliability Engineering) 即网站可靠性工程, 是 IT 运维的软件工程方案, 是以互联网技术产品的可靠性和性能质量为目标的 “全栈” 型技术岗位
14、。 SRE 团队使用软件作为工具, 以服务的可靠性为目的, 将IT运维相关技术与产品设计研发过程相结合起来, 利用软件工程方法来管理系统、 解决问题并实现运维任务自动化, 尽可能提高运维管理的效率, 帮助团队在快速迭代新版本和确保业务可靠性之间找到平衡。对于证券行业来说, SRE团队需要保障核心业务系统运行可靠, 如集中交易系统、 投资管理系统等。 通过了解业务本身, 深度参与其规划、 设计、 研发、 上线、 运维、 优化、 架构等环节, 制定SLA, 并围绕SLO推动分布式架构系统的运维能力实现, 确保业务服务可用性、 业务服务成功率、 业务流程体验符合目标。SRE运维模式为业务可用性保驾护
15、航。 随着近几年业务的快速发展, 国内各大互联网公司需要维护的服务器有了巨大上涨, 几乎每个公司都开始维护从几万个到几百万个服务器节点的系统, 系统频繁的上线和变更给业务稳定性带来极大挑战。 为保障业务稳定可靠运行, IT部门相应的系统运维成本投入也随之增加。 不同于其他业务部门的 “挣钱” 方式, 运维通过优化资源、 效率提升等多种方式直接地压缩业务的资源折损消耗体现价值。 如何平衡业务稳定性和成本之间的关系, 是SRE运维的一个重要目标。 相比传统的运维模式, SRE运维模式在业务团队内的价值主要体现以下几个方面:传统运维模式下运维团队是被动的, 只能应对之前已经出现过的问题, 很难及时跟
16、进新的场景。 SRE团队会不断地和开发团队沟通业务细节, 共同制定SLI、 SLO等指标, 变被动运维为主动运维。 同时, SRE团队会根据业务中断的指标, 开发控制风险的流程和运维工具, 在技术和流程上对业务中断进行预防和保障。第二章1.1.减少业务中断42.维持运维高效运行SRE相比传统的系统管理员、 应用运维工程师等角色, 很大的不同在于SRE会主动改进开发部分的能效。 SRE的任务属性使得SRE会通过工具提升运维/开发中某些环节的自动化率, 进而提升业务的迭代速度, 让业务更快地响应市场的需求。3.降低成本投入1.协作和敏捷是DevOps和SRE关注重点2.从开发和运维视角区分DevO
17、ps和SRE成本降低主要包括资源成本和人力成本两方面。 资源成本方面, 一般来说, SRE团队会要求业务团队对应用的SLI/SLO进行梳理, 使得SRE团队对业务模块的资源情况非常清楚, 可通过结合监控等数据制定业务模块扩容或缩容的策略和逻辑, 提升资源利用率。 人力成本方面, SRE运维通过引入自动化工具提升运维效率, 减少传统的需要大量人工操作的重复性工作, 降低用人成本。团队协作: SRE 和 DevOps 都致力于搭建开发团队和运维团队之间的互通桥梁, 协作是两者共同的关注点, 致力于打破不同团队间的壁垒。敏捷迭代:DevOps和SRE都可以实现更快的应用开发生命周期、 改进的服务质量
18、和可靠性, 以及缩短的 IT 应用开发时间, 通过高频、 小变动的发布, 不断的将新产品特性部署到线上环境, 带来更快的迭代速度。DevOps可以认为是一套实践理论、 指导原则和工作文化, 旨在打破IT组织中开发、 运维、 网络和安全各自为政的局面, 对上海品茶、 业务自动化和平台设计等方面进行全方位变革, 从而实现迅捷、 优质的服务交付, 提升企业价值和响应能力。 而SRE是探索的一系列工作实践的方式, 更加注重如何为企业提供的业务可用性提供运维保障。从实际工作场景来看, 如果将开发和运维分成两个区域, 那么开发和运维中间的空白可以证券行业分布式核心系统SRE运维白皮书(二)DevOps与S
19、RE异同点对比5认为是开发团队主动思变去填开发和运维之间的鸿沟, 开发团队可以兼做运维。 而SRE是运维团队突破自身局限, 从用户的角度去思考、 去贴近开发团队, 通过开发一系列自动化运维工具提升工作效率, 让开发团队聚焦于业务本身流程开发。业务连续性是SRE的根本出发点和目标。 由于软件做不到100%完全可靠, 一方面, 基础设施各部分出故障是常态, 这会影响到应用可用性; 另一方面, 软件由工程师编写, Bug不可避免,Bug出现也会引起异常停机。 SRE做到的是尽可能快地发现和处理故障, 并找到可能发生的故障, 在预算范围内以有用的方式优化应用、 基础设施, 满足用户体验的需求。SRE运
20、维不只是单纯的技术栈 (主机、 存储、 基础软件设施等) 的设备运维, SRE还逐步延伸业务运维领域, 管 务栈的递进, 体现了SRE运维体系对传统运维体系演进和拓展。(三)SRE运维模式需贯彻五个核心原则图 1开发、 运维、 DevOps、 SRE关系图1.以业务连续性为目标2.从技术到业务分布式核心系统SRE运维模式概述第二章6SRE本身是一个软件工程师以软件工程的方法解决运维问题的体系, SRE更倾向于使用代码的方式去应对各种重复性的运维操作, 通过工具打通各个运维环节实现自动化。 因此SRE运的诞生是因为软件工程师触及了运维。 目标将50%的时间用于编写代码, 30%时间用于与人打交道
21、、 20%时间用于应对紧急情况。 ”4.预防与事故应对5.平衡风险SRE运维模式中仍然有监控、 事件响度和事件回顾等环节, 与当前传统运维体系有近似的地方。 但是从整体上, SRE整个运维体系非常强调预防的重要性。 通过事件回顾、 测试与发布、 容量规划、 开发等层次的工作来持续优化应用, 提升系统的可靠性。“预防胜于治疗” 这句话, 在IT系统建设和运维领域同样适用。SRE运维体系首先认定新业务需求和新软件版本的发布无论如何总会引入bug; 与此同时,较长的开发周期与更严密的测试会发现并修正bug, 但是亦会延迟业务需求实现以及新版本发布的时间。 快速实现业务需求与由于bug引起宕机的风险之
22、间需要得到平衡。 SRE通过制定合理的SLO以及错误预算, 尝试在系统风险与业务快速迭代之间实现可量化的平衡。证券行业分布式核心系统SRE运维白皮书73.高度自动化维体系是一个将自动化提高到战略高度的运维体系模型,正如 Google SRE 书中所言: “SRE证券行业分布式核心系统SRE运维服务体系第三章上一章节对适用于分布式核心系统的SRE运维模式从价值、 运维侧重点以及运维核心原则等方面进行了介绍, 本章节将聚焦于证券行业的分布式核心系统的运维建设, 从服务质量度量体系、 观测指标体系、 流程管理体系、 稳定性运营体系以及组织管理体系五大方面展开介绍。业务的最终目的是为了满足用户需求,
23、尤其在互联网化后, 用户的体验满意度已成为业务竞争中的重要一点。 为确保用户获得良好体验, SRE运维模式需要关心业务的支撑体系是否可用、 稳定, 这是用户体验中极为重要而又极容易被忽视的, 也是IT人员对于赋能业务最具价值之处。证券行业越来越多面向终端用户的业务, 终端用户的体验至关重要, 所在区域的网络环境、服务集群, 以及进行自助业务的终端应用稳定性都是直接影响到用户体验的关键要素。 SRE可使用体验指数来描述业务流程体验状态, 指数的计算因子可以从终端应用的响应率、 响应时延、 崩溃率、 卡顿率、 错误率多项指标进行综合加权, 通过跟踪业务流程节点中应用的完整链路, 以及各节点的业务量
24、变化, 快速响应和处理影响用户体验的问题。系统的线上稳定性作为直接影响用户体验感受的性能指标, SRE在处理稳定性时引入SLI(Services Level Indicator) 、 SLO (Service Level Objective) 和SLA (Service Level Agree-ment) 用于量化线上稳定性。SLO是服务提供方与服务需求方对服务的期望, 比如系统可用性是4个9, 还是3个9, 用于定量描述可靠性程度。 SLO是SRE实践的核心, 对于进行数据驱动的可靠性管理决策很关键。 SLO既可以用于承诺付费用户的场景, 又可以用于承诺非付费用户的场景; 既可以对公司内部用
25、户应用, 又可以对公司外部客户应用。(一)以用户体验为核心的服务质量度量体系1.SLO为服务过程期望制定服务等级目标82. SLA为服务双方责任及目标约定服务等级协议3. SLI为进一步细化SLO设置服务等级指标SLA是IT服务提供方和被服务方之间就服务提供中关键的服务目标及双方的责任等有关细节问题而约定的协议。 一般用于付费用户的场景, 会具有一定的法律效力。 当一个服务和用户签订SLA时, 往往涉及服务付费、 承诺质量和违约责任等内容。 对于业务团队来说, 在理想情况下, SLA最好和业务团队的SLO一致, 这样会比较符合业务发展的实际情况。常见的SLI指标包含性能指标、 可用性指标、 质
26、量指标等方面。 SLI除了可以衡量服务的外在表现外, 还可以衡量线上业务活动的各个方面。 通过一些列SLI技术指标可以对SLO进行细化并量化, 比如上述的系统可用性可能会转化为运行时长, 故障时间等, 性能的话会转换为响应时长、 成功率等。加强运维组织的IT服务管理, 可以采用SLA为基础, 以SLO为服务质量期望, 以SLI为量化指标, 来设计自身的服务流程、 提供服务形式、 绩效评估方法, 如图2样例所示。证券行业分布式核心系统SRE运维白皮书图 2 SLA/SLO/SLI 样例9(二)以监控系统为基础的观测指标体系1.监控系统是SRE运维的基础和核心2.SRE落地应用亟需标准化的观测指标
27、体系监控建设作为运维团队的工具支撑, 在运维工作的方方面面都承担着不可或缺的作用。 合理使用监控建设能及时发现线上异常、 快速定位线上问题、 有效缩短故障时间。 除此之外, 监控建设采集的数据也成为其他自动运维工具建设的基础。 监控系统的建设应具备以下三方面特性:一、 稳定性。 稳定是监控重要的属性, 也是监控的最低标准。 运维团队保障线上业务的可用性依赖监控服务。 监控服务系统是一种典型的数据处理系统, 稳定性问题可能出现在数据流转的各个阶段, 包含数据源稳定、 网络稳定、 数据处理稳定、 存储稳定等。二、 准确性。 好的监控服务发出的警报要尽量准确, 这对监控服务而言尤为重要。 仅凭监控服
28、务提供的手段 (如同环比报警、 智能抑制压缩、 故障根源定位等) 并不能测地解决有效性问题, 需要监控服务和运维团队合作配合。 运维团队要向监控服务表达被监控业务的特征, 监控服务要将业务特征转化成各种报警能力, 最终体现在提高报警准确率方面。三、 易用性。 监控服务系统是运维团队在日常工作中频繁使用的系统之一。 随着业务规模扩大、 复杂度提升, 运维团队的线上运维压力也在持续增加。 因此, 监控服务系统有必要在产品易用性方面做更多的设计与思考, 减少运维工作的压力, 达到运维工作事半功倍的效果。监控系统的通用能力主要分为黑盒监控、 白盒监控两种。 黑盒监控主要观测系统行为, 直观地发现其可用
29、状态, 通常关注在线状态、 配置状态、 拨测状态等指标, 基于实时状态进行告警;白盒测试则依靠系统内部暴露的指标来进行观测, 具体发现系统应用逻辑层面的问题, 通常关注指标包括异常、 错误、 容量、 性能等, 此类指标除了关注实时状态之外, 还需要了解其历史状态, 分析其变化趋势, 以发现其隐藏的风险, 统计的口径包括日志分析、 HTTP接口统计分析、JAVA虚拟机接口统计分析等等。SRE需要全面观测系统的运行状态, 以达到快速发现、 快速响应、 快速定位、 快速处理。 一个证券行业分布式核心系统SRE运维服务体系第三章10好的指标体系可以帮助衡量观测是否足够全面, 参考 JR/T 0158-
30、2018 分级分类方法, 从业务条线出发, 首先对业务细分, 其次对数据细分, 形成从总到分的树形逻辑体系结构, 最后对分类后的数据确定级别, 形成完整的指标体系。证券行业分布式核心系统按照业务层、 应用层、 系统及网络服务层、 云底座/基础资源层, 进行观测资源对象的梳理, 描述各层级的资源拓扑关系, 以及层级之间个资源的关联关系, 帮助SRE快速全面地了解系统全貌, 并根据指标观测到实时状态, 实现故障的快速发现及影响范围的快速评估, 更好地进行应急响应。 对于业务层, 监测各节点关键业务数据、 体验指数变化趋势, 对比历史基线, 判断变化态势是否异常, 告警给运维管理员, 排查关联应用是
31、否存在异常; 对于应用层, 通过监测应用功能接口调用情况、 进程端口运行情况、 数据库运行情况, 判断是否存在异常指标, 告警给运维管理员, 排查应用及关联的系统或网络服务是否存在异常; 对于系统及网络服务层, 通过监测操作系统的整体情况、 网络连通性情况等, 判断是否满足阈值规则, 告警给运维管理员, 排查关联的云底座或基础资源是否存在异常; 对于云底座/基础资源层, 通过监测云平台、 宿主机、 基础硬件资源、 基础网络服务的整体运行情况, 判断是否有告警与异常信息, 通知给运维管理员, 快速进行异常排查。以上各层级的观测指标, 大致可分为异常、 错误、 容量、 性能等四种类型指标。(1)异
32、常类型指标指配置、 状态是否符合预期, 通常评估组件服务的在线状态、 配置状态, 以及服务过程中产生的异常日志等;(2)错误类型指标指请求失败的计数、 速率或者比率, 通常评估服务请求的错误数和成功率, 终端应用的崩溃率、 卡顿率等, 它直观地体现了服务的质量水平;(3)容量类型指标指支持上层业务的资源饱和程度和受限量, 通常评估提供服务的资源的运行饱和度, 包括基础资源和应用资源, 如CPU占用率、 内存占用率、 带宽使用率、 队列的积压情况、 会话的连接数等等。 容量观测为资源的合理调度、 分配、 扩缩容提供有效依据, 同时, 过量饱和的资源使用可能会导致整体服务质量的下降, 影响到用户的
33、使用满意度, 甚至可能会导致业务服务的可用性中断;(4)性能类型指标指影响或描述请求响应效率、 事务处理速率的指标, 通常评估项为时延和证券行业分布式核心系统SRE运维白皮书11吞吐量。 性能指标也体现了服务的质量水平, 对于不同的业务类型、 业务规模、 服务的用户等级, 应该有不同的时延和吞吐量水平保障。应用发布的复杂程度往往与系统的复杂程度呈正比, 对于应用系统上规模的企业, 往往使用基于自动化框架构建自动化的应用发布过程。 通过自动化发布工具, 可以构建流水线实现部署的过程中所有的操作 (如编译打包、 测试发布、 生产准备、 告警屏蔽、 服务停止、 数据库执行、应用部署、 服务重启等)
34、全部自动化, 无需人工干预解决以往手工发布存在的效率低下, 上线、更新、 回滚速度慢、 人为误操作大等问题。 SRE人员会针对每次发布内容做针对性的发布, 包括灰度发布、 蓝绿发布、 滚动发布等, 并且对每次发布过程做到效率最高, 影响最小。对于业务来说, 稳定性和迭代速度是整个变更管理的核心, 所有的变更管理本质上都是在寻找这两者间的平衡点。 为找到这个平衡点, 可以从业务发展阶段、 业务体量、 业务影响力三方面考虑。 比如业务发展初期, 大部分情况下是迭代速度优先, 以迅速满足市场对业务的需求, 此时变更控制往往是弱化的, 更多是为了方便追踪变化; 业务发展中期, 业务已经有一定的稳定性要
35、求, 业务处理方式通常是注重稳定、 兼顾迭代速度, 此时是两者关系最难处理的时期; 业务成熟期, 通常业务团队和业务框架比较成熟, 多选择稳定性优先的策略。一般来说, 在保证业务稳定性的前提下, SRE团队很重要的工作是让业务更快速发展。 因此在保证业务的SLO达标且错误预算没有耗尽的情况下, 在做变更决策时, 可以适度地偏向迭代速度优先的变更策略。 SRE需要对每次变更发布负责, 对每次变更上线做变更评审, 包括变更的准入规则, 变更的类型, 变更执行的步骤, 变更的记录等内容, 实现多角度变更管理。 同时, SRE需要总结变更经验, 优化变更流程和提高变更效率。 通过跟踪最新行业动态, S
36、RE可以引入突破瓶颈的运维工具, 实现人力成本降低和风险管控提高的双赢。(三)以稳定可靠为保障的流程管理体系1.构建自动化的应用发布流水线2.兼顾稳定和敏捷的变更管理12证券行业分布式核心系统SRE运维服务体系第三章证券行业分布式核心系统SRE运维白皮书3.平衡系统可靠和更新速度的错误预算4.定位问题根源和解决方案的on-call流程当我们设定好SLO, 需要有个可量化的数据, 用于提醒并观测SLO的情况。 而SRE中通过反向推导SLO的方式, 得出一个量化数据-错误预算, 就能达到这个效果。 它可以直白的理解其为 “提示还有多少次犯错的机会” 。 通过应用错误预算进行数据的归一化方式, 可以
37、更好的来推进稳定性目标的达成。 错误预算为企业提供了一种监测和压测的观测手段, 可以有效直观的感知某些指标或业务系统的瓶颈, 是保障业务系统稳定运行的重要方式。 例如, 错误预算能够对容量的扩缩容提供观测值, 通过侧面反映业务系统的容量水位, 实现及时调整容量并反映调整后效果。另外, SRE运维工程师与开发人员沟通系统变更频率时, 错误预算还可以作为双方共同认可的指标。 也就是说, 双方可围绕 “错误预算” 来考量是否变更, 当错误预算充足时, 可放宽对变更的限制, 开发人员可以快速上线新模块以满足业务需求, 实现系统优化和架构改进; 当错误预算不足时, 需控制变更节奏, 应以保障业务系统稳定
38、运行为目标减少变更频率。 特别地, 如果需要变更的系统本身是分布式的高可用架构且支持灰度发布, 错误预算指标并不直接影响变更频率, 可以实现敏捷开发。 错误预算可以在每个绩效周期开始时进行约定, 是减少运维和开发双方矛盾的一个重要指标, 有必要在企业内部推行。on-call的职责在于: 监控预警处理, 第一时间处理生产环境的监控预警。 紧急故障救火, 协同业务团队处理生产环境稳定性问题。 稳定性问题排查, 挖掘生产系统稳定性隐患, 进入深水区进行挖掘。 全链路稳定性巡检, 生产系统核心业务SLO指标、 错误日志、 RDS健康度、 慢SQL巡检等。 参与故障复盘, 此处的故障包括GOC故障与线上
39、的稳定性问题。 经验总结输出, 将on-call过程进行的故障诊断、 问题处理、 故障复盘进行总结。on-call意味着在一定时间内随叫随到, 并做好生产环境出现紧急情况的应对准备。 SRE工程师经常需要轮值on-call。 在on-call期间, SRE会根据需要对紧急情况进行诊断、 环境、 修复或升级事件;此外,SRE还要定期负责非紧急性生产任务。 SRE团队可以缓解事故、 修复生产问题并自动执行运维任务。 由于大多数SRE团队尚未完全自动化实现运维任务, 因此升级仍需要人工13联系On-call工程师进行处理。值得说明的是, SRE工程师并不是On-call的主导者, 而是参与者, On
40、-call的主要目的是让SRE工程师更全面了解系统, 及时发现系统需要优化的地方。 在此过程中, SRE工程师应以工程化的视角, 将精力更多放在找出问题根因和解决方法上, 比如通过改进运维流程、 使用运维工具、 进行容量规划、 灾备建设以及架构治理等手段, 实现快速发现、 响应、 排除故障、 以致彻底根治问题等, 这些都是SRE工程师需要花更多精力去思考和推动的事情。稳定性治理是个比较复杂的命题, 业界没有统一的定义。 系统稳定性是指系统要素在外界影响下表现出的某种稳定状态, 但事实上, 复杂系统中潜伏着大量影响稳定状态的故障组合。在整个运维工作中, 线上业务运营时难免会有监控指标波动的情况,
41、 当这些监控指标波动突破一定范围时, 会被定义为异常。 运维团队对异常响应, 主要分为跟进、 分析、 定位、 解决等多个步骤。 异常响应在运维团队工作中也占据了非常重要的地位。异常响应流程: 在传统运维团队中, 每个小团队对异常响应都有独立的想法和处理方式。 整个流程完全取决于处理团队自己的利益和诉求, 往往没有固定的流程。 从SRE团队的角度出发,流程应该是要固化到平台的, 而为了更好地将相关流程沉淀到平台, 必须梳理异常处理流程的设计原则, 以适应不同业务的问题处理需求。 处理环节主要分为: 异常发现、 问题跟进、 问题升级机制、 问题分析、 问题通知、 问题解决、 问题后续追踪。 实际按
42、照异常处理规范跟进时, 每个环节考虑的越细致, 在实际工作中就会有越好的处理体验。应急沟通机制: 在实际的工作跟踪, 总有些异常是超出预期的。 在传统运维模式下, 线上应急主要聚焦问题的排查和解决, 很少关注信息的整理和同步。 因此, 团队建设时需要专门对应急沟通机制进行梳理, 重点是设计一个运转良好的的信息沟通机制。 虽然应急沟通机制可能随着业务特性或当时的情况发生变化, 但是在信息同步方面还是有一些统一原则的: 需要做到分别制定问题排查任何信息同步人、 信息定期同步、 信息量足够, 不过多解释等。5.制定流程完备与沟通高效的应急事件处理机制14(四)以服务治理为目的的稳定性运营体系证券行业
43、分布式核心系统SRE运维服务体系第三章证券行业分布式核心系统SRE运维白皮书1.故障管理: 为系统稳定性和连续性提供保障1.故障等级稳定性治理的核心是故障管理, 细分为故障预防、 故障演练、 故障自愈、 灾备建设等领域。 稳定性治理的主要工作范围涵盖了可用性、 监控告警以及线上应急。所有业务系统都无法避免发生各种各样的故障, 故障管理是针对故障发生前、 故障发生时、以及故障发生后的计划和措施的管理。 针对SRE运维模式来说, 故障管理是为实现业务系统稳定性以及连续性不断提高的重要管理措施, 也是相比传统运维而言拥有更健全的管理计划、 更规范的管理流程、 更优秀的故障处理方案。 SRE故障管理包
44、括以下几个方面:故障等级是对故障发生时的一种等级划分。 故障等级通常由业务故障发生的时长而定, 随着故障时间增加, 故障等级会随着时间增加而上升。 告警的等级触发条件与SLA挂钩, 一般按业务停止时间, 成功率划分, 具体按实际情况定。2. 故障处理故障处理直接会影响故障发生时故障处理效率以及应急调度方案。 故障处理通常会分为几个阶段, 包括故障通告, 故障调度, 故障恢复, 故障记录等。 第一时间按故障等级通告, 并随着故障等级升级而不断通告。 通告发生后, 通过监控系统进行故障定位并且调用应急处理能力, 调度相关责任人处理。 并且以第一时间恢复故障为原则, 在恢复后进行故障原因排查分析,
45、防止故障扩散。 按照时间线记录故障过程, 规范故障记录文档。3. 故障复盘4. 故障经验沉淀故障复盘是对故障发生后的一次总体总结。 故障发生后, 按照故障等级召开相关人员会议,召开故障复盘会。 主要包括记录故障复盘会的内容, 确定优化、 处理、 改进事项, 明确责任人, 并不断跟进故障处理情况, 跟进落地情况。15在运维行业中, 运维人员的实践经验是否丰富直接影响运维人员的价值。 故障经验沉淀有助于经验较浅的运维人员快速成长, 这是对SRE人员良性提升与发展的重要方式。 通过故障经验共享的方式, 企业能够不断丰富内部运维知识库, 一方面, 可以在下次故障发生时有历史应急经验可循, 另一方面,
46、可以不断优化故障发生时的应急策略提高系统稳定性。线上业务故障, 故障预案是一个无法避免的问题。 在传统运维模式下, 当线上发生故障时,最常见的故障预案问题有以下两类: 不在评估预期内的故障类型和故障预案执行有问题。 从SRE团队的角度看, 相较传统运维团队, 更加注重对运维操作的提炼, 也因此更加注重自动化工具的建设。 线上测试技术的进化和SRE新理念的事件反映到故障演练上, 形成了以下两个明显的优势: 第一, 故障类型完备度。 第二, 故障模拟更加容易。 目前的演练方案也有很多包括容灾演练、 高可用演练、 容量压测演练、 红蓝对抗演练等。 针对业务系统做到更全方位的演练, 不仅可以预防故障发
47、生, 修复演练中发现的问题, 更能在故障发生时, 提前准备好应急方案。对于所有线上故障来说, 其实最好的处理方式是防患于未然, 在线上还没有出现问题时就跟进相关运维工作。 因此, 如果新系统从设计、 实现到运营就充分考虑稳定性, 例如采用防御性设计, 规范化操作和标准化运营等, 一般能规避大部分故障风险。 另外, 可通过风险评估的方式, 对可能存在且无法完全避免的风险进行提前评估, 以及通过预设风险的方式, 提前对系统功能架构的设计、 资源结构的设计等给出风险报告, 这样在故障发生时有所准备。 SRE在运维的同时, 也要对整体架构有所感知, 通过对功能到资源架构深入理解, 不断提升系统稳定性。
48、除了提前的风险评估和预防设计, 巡检作为重要日常工作, 对故障预防也有着发现和保障的作用。 巡检会对日常资源, 业务功能, 上线新功能以及历史故障等做巡检, 预防故障发生。同时, 故障预防对监控平台也有要求, SRE会针对监控平台的不影响业务系统的告警, 做处理和降噪。 分析告警的原因以及可能存在的故障风险, 做到预防故障发生。2.故障预防: 提前发现可能风险, 进行主动运维3.故障演练: 找出系统风险点, 提高系统鲁棒性4.故障自愈: 通过自动化缓冲对线上稳定性影响16证券行业分布式核心系统SRE运维服务体系第三章故障自愈不只是运维Keepalived VIP、 MySQL主从等部署, 它代
49、表的是一整套的设计理念和运维想法。 从落地方法和实现上说, 故障自愈有以下多个层级: 基于主备的设计、 基于负载均衡的设计、 基于平台的设计、 基于业务架构的设计。 故障自愈是所有SRE团队和开发团队对线上稳定性的最终追求, 故障自愈设计可以缓冲故障对线上的影响。 更重要的是, 故障自愈通过以自动化代替人工, 能够实现在保障系统更加稳定的同时减少人员精力以及人力成本。 故障自愈的方案是从对初期设计无法预想的情况下, 不断进行改进, 最终实现优化自愈。 在这个不断持续性演进的过程中, 对SRE人员素质要求很高, 需要兼备开发能力与运维能力、 丰富的应急预案能力、 根因定位能力以及解决排查的能力。
50、证券行业分布式核心系统SRE运维白皮书5.容量规划: 在成本控制和业务支撑间寻找平衡随着企业对外服务的内容和用户不断增长, 企业会不断增加对硬件和云基础设施的投入,用于满足业务发展的需要。 实际上, 企业研发部门在实际生产过程中都会面临各种各样的复杂业务场景及相应的困难和挑战, 这些汇聚到IT支撑环节, 就形成了对IT资源的需求与规划。 容量规划包括业务容量和资源容量, 业务容量需要对于业务的事务处理性能进行监测, 参考系统基础能力对业务吞吐量的支持, 对业务容量的饱和状态进行评估和预测, 以提前及时地进行容量扩缩容; 资源容量需要对基础资源的容量进行监测, 如算力、 存储能力, 通过及时地调
51、整资源池空间, 来确保业务性能、 可用性不受影响, 同时很好地控制成本。为有效进行容量分析和预警, 可以从以下三个阶段主动进行容量分析和优化。事前容量规划: 在进行年度IT资源预算规划或新业务、 新产品上线前需要仔细评估所需的IT资源。 同时, 对容量进行压测, 压测后的报告需要进行分析总结, 给出规划预期。(容量压测取决是否具备生产压测能力) 。事中容量监控: 业务和产品在服务用户过程中, 需要投入人力建设相应的容量监控和预警系统, 实时收集与容量相关的数据, 在容量水位低于或高于预先设定的阈值时, 进行容量扩缩容等优化。 其中, 扩缩容的标准可参照SLO, 扩缩容的方案可参照系统架构和系统
52、SLA制定的技术方案。事后容量调整: 根据业务情况及时调整容量, 以应对突发的流量或对处于生命周期末期的17产品进行缩容。 针对扩缩容形成容量报告, 输出系统容量水位, 扩缩容记录, 调整建议和调整后的效果。随着客户需求的多样化以及业务数量的快速增长, 企业初期设计的系统架构往往已不能满足业务需要, 甚至会频繁出现系统故障等问题, 导致运维人员工作量大幅增加。 因为SRE运维模式直接观测感知整个业务系统, 能够对企业内部系统架构有全方位的认知, 可以在系统架构治理的痛点问题上给出更切实可行的建议, 尤其是在业务应用进入实际生产环境后SRE有着更权威的发言权。 例如, SRE可从系统健壮性、 系
53、统可拓展性以及系统成本等方面进行多维度综合评估, 提出架构治理相关建议。 同时SRE也应及时跟踪最新技术动态, 对可能解决当前系统架构痛点问题的新技术进行评估, 以帮助系统架构实现不断优化治理。 诸如以上架构治理建议, SRE可通过报告等方式反馈到新一代系统架构研发过程中, 实现以运维服务系统, 以系统优化运维的目标。组建SRE团队需秉承多样化原则。 SRE团队中应有包括 “技术负责人 (TL) ” 、“SRE经理(SRM) ” 、“研发工程师 (RD) ” 和 “项目经理 (PM/TPM/PGM) ” 等多种角色。 很多时候组织内部是一个动态的环境, 各种角色之间可以动态地协商切换责任。 一
54、般来说, 越动态的团队成员的个人能力越强, SRE人员需要不仅仅是 “编写代码的运维人员” , 也应该是开发团队的成员, 通过开发运维工具的实现流程自动化, 提高运维效率, 尤其是在部署、 配置管理、 监控、 指标等方面。SRE团队需持续沟通协作改进系统稳定性。 SRE需要参与的工作大多是跨团队的, 沟通能在所有的运维系统中, 灾备建设是故障恢复最终的兜底保障。 合格的符合需求的灾备设计从技术上来讲有以下几个等级: 同机房灾备、 同城双活、 异地数据灾备、 两地三中心、 分布式多活等。 SRE人员需对内部系统架构进行综合评估, 如果企业不具备灾备能力, 应提供必要的灾备建设建议和服务。6.灾备
55、建设: 为故障恢复提供兜底保障7.架构治理: 通过观测感知全系统以优化架构设计18(五)以持续改进为标准的组织管理体系证券行业分布式核心系统SRE运维服务体系第三章是最重要的软实力能力之一。 SRE要非常重视团队协作, 尤其在故障应急上, 要协作多方团队,紧密合作, 降低故障MTTR。 而在日常工作中, SRE要积极协同业务团队以及外部依赖团队, 主导并推动稳定性相关工作的落地。证券行业分布式核心系统SRE运维白皮书19证券行业分布式核心系统SRE支撑工具和平台第四章监控是SRE最重要的工具, 为了能更好地覆盖到分布式架构系统的观测点, 并且具备快速定位和排障能力, 监控需要满足平台化、 可视
56、化、 自动化、 智能化的特性。(1)能力中台化抽象通用的监控能力, 如采集、 分析、 告警、 通知等, 统一建设和优化, 通过订阅监控服务, 快速构建指标观测场景。(2)监控自动化抽象规则明确、 逻辑清晰的工作流, 如采集能力、 分析能力、 告警合并、 通知能力的自动化,持续进行自动化改造, 提升观测效率的同时, 将人力从无价值的繁琐作业中解放出来, 投入到更有意义的业务创新中去。(3)过程可视化将监控状态、 分析结果通过可视化的手段清晰地呈现出来, 帮助运维人员更容易进行决策和排障管理。(4)分析智能化结合AI、 大数据、 机器学习等新兴技术, 对统一的运维对象、 海量数据进行智能分析, 扩
57、展运维的深度和广度, 解决原本人力难为的运维问题, 如未知异常检测、 持续恶化的指标、 告警的根因分析、 指标跟随分析等场景, 主动发现风险, 提升数据价值。监控平台还需要完整的告警台功能, 提供告警的分类分级管理, 并清晰地呈现出来。 一个好的告警台是必要的, 帮助管理人员更关注重要、 紧急信息, 驱动工作展开。 告警台可以跟踪告警的处理状态、 关联影响、 响应负责人, 以确保重要告警都能得到处理, 避免风险遗漏。 同时, 对于海量告警, 还须具备合并收敛、 根因归类能力, 以降低告警数量, 提升告警的有效性。事件管理平台负责跟踪事件的处理进度, 一般来说, 影响到系统正常运行的告警会上升为
58、(一)监控平台实现故障快速定位(二)事件管理平台保障事件快速响应20故障, 影响到业务开展的故障会上升为事件。 每个故障都应有完整的预案, 以确保在发生时能够快速地进行响应和恢复, 尽可能地降低业务中断的风险, 或减少业务中断可能造成的损失。事件管理平台需要有故障画像和预案演练能力, 对于故障从多个维度进行描述, 来区分故障的性质和本质, 对应的故障需要有应急预案和演练计划, 跟踪演练的情况, 复盘演练的问题,持续优化事件应急机制和流程。事件管理平台能够对故障发生整个环节进行流程推动, 将流程状态完整地可视化呈现出来, 确保参与的人员能够更好地理解任务、 执行任务。(1)当故障发生时, 需要迅
59、速明确出故障的应急人员, 确保相关人员在规定时间内进行到岗签到, 确保故障得到第一时间的处理。 故障的现象、 内容、 级别、 影响情况、 应急进度都需要进行相关人员播报, 确保信息流畅, 执行一致。 故障关联的资源对象须通过自动化观测的能力实时呈现状态, 以客观地呈现故障的修复效果。(2)故障结束后, 相关负责人须组织复盘工作, 确认故障发生的根因并进行根本性修复, 确保下次不再发生或能更快速地完成响应恢复。数据服务平台是决策分析的基础, SRE通过将多方数据源进行加工管理, 并在容量规划、 性能分析、 异常检测等场景中加以应用, 可充分体现数据中的价值。 数据服务平台应具备数据采集、 查询与
60、分析、 数据加工、 数据消费与投递、 可视化、 告警能力等功能。(1)数据采集从多种渠道采集源数据, 作为后续的消费基础, 包括服务器/应用日志及数据、物联网设备数据、 移动端数据、 开源日志服务软件数据、 标准协议数据等;(2)查询与分析能力是数据最基础的消费场景, 通过匹配查询、 上下文查询、 SQL语法查询、NoSQL语法查询, 可以快速地获取不同纬度的简单数据统计结果, 满足大多数统计分析场景需求;(3)数据加工主要对采集上来的数据进行加工处理, 对非结构化数据进行规整, 使其更利于不同场景的消费需求, 将多组数据进行串联结合, 富化其含义, 使其价值得到提升, 对数据进行证券行业分布
61、式核心系统SRE运维白皮书21(三)数据服务平台支持决策以释放数据价值规整, 使其更利于不同场景的消费需求, 将多组数据进行串联结合, 富化其含义, 使其价值得到提升, 对数据进行脱敏, 降低非法数据带来的安全风险, 对数据进行过滤筛查, 提升关键热点数据的服务能力;(4)消费与投递主要体现数据对外提供的开放性服务能力, 包括支持第三方软件消费、 支持java/python/Go语言消费、 支持流式计算消费、 支持投递到存储/数据库等;(5)可视化能力提供多种可定制编排的图表, 用来对数据的加工、 分析结果做具体的呈现,使应用人员能够直观地感知数据状态, 并达成理解上的一致, 辅助决策;(6)
62、告警能力可以是数据服务平台的一个具体的消费应用, 通过监控数据关键字、 数据变化等, 触发相应的告警通知, 让管理人员可以及时对数据进行响应。自动化平台帮助SRE加速了运维工作自动化的实现, 通过将逻辑明确、 规则清晰的工作流程快速构建出来, 快速积累场景, 使SRE人员能够从重复工作中释放出来, 将精力投入到架构优化、 工具研发等工作中。自动化平台一般有三个模块: 控制台、 设计器、 执行终端。 控制台负责完成具体自动化任务的下发、 调度、 编排, 以及跟踪任务的执行进度和状态; 设计器通过脚本语言、 所画即所得等方式进行自动化任务的开发、 调试、 测试执行; 执行终端负责执行接收到的自动化
63、任务, 处理任务异常, 输出任务日志等。证券行业分布式核心系统SRE支撑工具和平台第四章22(四)自动化平台助力员工解放生产力应用部署平台能够提供灰度、 升级、 回滚等相关工作的管理, 对各种不同业务类型的系统提供多样化的部署服务支撑。 也能够进行容器、 物理机部署, 支持在线、 离线服务、 定时任务以及静态文件的部署, 提供部署资源管理、 运行环境搭建、 部署流程定义和部署执行跟踪, 可以进行金丝雀发布及蓝绿部署。 应用部署平台可以加快业务迭代速度、 规避故障发生, 提升产品发布节奏。(五)应用部署优化业务迭代流程(六)CMDB高效管理IT基础架构与服务CMDB系统可以管理一个企业的全部服务
64、器, 包括物理机和各类云厂商提供的云主机资产, 以及相关对应的资源状态、 使用人员、 产品应用的环境和项目信息, 可以为其他系统, 如监控系统、 自动化发布等DevOps类系统提供有效的支撑。 另外, CMDB需要构建资源与资源之间的关联关系, 以确保运维对象、 运维数据得到有效地串联和丰富, 协助自动化和故障定位等相关工作的展开。 CMDB系统可以进一步提供类似业务线-产品线维度的资源和负载情况, 进一步供相关负责人进行分析和决策。CMDB是运维工具和运维流程的基石, 如果SRE工程师想要持续地优化运维体系, 有必要构建一个面向消费的CMDB。 为了让CMDB有助于SRE工程师, 面向消费的
65、CMDB需要具备以下三点特性:(1) 需构建资源模型和关系模型, 明确运维的资源对象, 管理资源配置数据, 以及各资源的关联关系, 同时协助监控、 自动化等工具进行快速配置、 分析和决策。(2) CMDB管理的资源需具备自动发现、 自动拓扑等功能, 以确保资源配置数据具备实时性、 一致性。(3) CMDB系统需提供标准的开放接口, 可基于资源配置数据实现运维领域的消费场景扩展。证券行业分布式核心系统SRE运维白皮书23证券行业分布式核心系统SRE发展前景第五章无论是从企业成本上考虑还从技术演化上考虑, DevOps和SRE这类主动式IT运维模式都是运维未来的发展趋势, 很多公司的传统运维团队也
66、纷纷有针对性地根据组织实际情况在跟进转型。 作为相关主管部门应积极完善主动式IT运维发展政策指引, 推动IT运维从只关注IT基础设施和系统的运行质量转向进行类似SRE模式的主动式运维监控服务。(一)主管部门完善相关政策指引随着技术运营的发展与实践落地, IT运维团队正处于从证券机构内部成本中心向利润中心转型的关键时期。 证券机构信息技术部门应积极组建SRE运维模式团队, 实现降本增效的价值。一方面, SRE团队聚焦于运维自动化, 通过自动化工具和平台提升效率; 另一方面, SRE团队通过高频、 小变动的发布, 不断地将新产品特性部署到线上环境, 实现尽可能减少变更导致的故障, 进而降低因产品故
67、障带来的经济损失。(二)证券业机构关注自身SRE能力建设过去, 我国多数 IT 运维服务提供商依赖大型或国际企业的运维工具、 产品或内容进行 IT 运维服务, 然而这些产品大多为被动式运维方式。 随着企业业务系统复杂性的提高, 以及为满足产品从开发到发布的快速迭代, SRE主动式运维模式越来越受到运维服务商关注。 运维服务商SRE团队应投入精力在一些和线上稳定性相关的平台和工具开发中, 包括基础架构稳定、 代码质量、 机器性能及安全问题等。(三)服务提供机构提升SRE服务能力“无规矩不成方圆” , 在企业的IT运维管理工作中, 运维标准评价体系的构建是非常重要的。没有标准规范的IT运维, 可能
68、会导致企业实际生产活动数据质量问题, 从而影响公司的业务发展。 目前, 业界常见的IT运维相关标准有ITIL、 ISO20000、 ITSS等最佳实践及相关标准, 但自动(四)第三方机构构建分布式核心系统SRE标准评价体系24化运维、 SRE运维相关的标准体系仍有待完善。 第三方科研机构应积极联合政府、 证券机、 运维实践领先企业等共同进行分享、 总结、 整理, 以明确SRE运维服务规范和制定相关标准体系, 共证券全行业参考执行。证券行业分布式核心系统SRE运维白皮书25证券行业分布式核心系统SRE应用建议第六章在现有的运维体系中嵌入SRE是一项大的挑战, 本文提供了下面三种模式供参考, 企业
69、可以根据自身的组织状态, 选择合适的路径来落地应用SRE运维方法论, 以达到降本增效, 提高业务可用性的目的。自建SRE中台即通过内部成立一个SRE组织, 对开发、 运维双方进行赋能和影响。 在这种 “大中台、 小前台” 的组织架构下, 处于中台的SRE组织对前台各开发团队、 各运维团队提供建议、 服务、 约束多方面支持, 包括业务可用性规范设计、 可用性方案设计、 上线方案设计、 灰度方案设计、 架构优化建议、 应急预案等等, 同时, 基于平台特性, 提供相关的工具能力建设, 如基础设施的底座、 观测能力平台、 灰度管理、 灾备管理等贴合实际业务运维的工具。在运维流程和运维观测中, 持续地进
70、行自动化和可视化, 使得流程和观测在多方服务对象形成理解一致、 执行一致的组织能力。该模式具备以下优势:提升服务质量: 由于运维服务集中化, 通用能力上可以得到有效地规划建设和迭代发展, 并一定程度上解决了理解和执行的不一致问题, 可持续地提升服务质量;共享人力资源: 通过建设统一的SRE人力资源池, 实现资源共享, 同时确保SRE人员的专业性, 缓解了在SRE模式落地过程中对于人员的需求问题。该模式具备以下劣势:缺少服务深度: 由于SRE对接所有业务系统的运维需求, 必然导致SRE人员对于业务场景了解不够深入、 服务不够深入的问题, 从而对于业务可用性建设的构建缺乏保障;沟通存在障碍: 本质
71、上SRE一定程度上解决了开发、 运维的协同问题, 增加了中台化的SRE组织后, 增加了沟通的复杂度, 在绩效设置和考核上更加困难。(一)模式一: 内建SRE中台能力26(二)模式二: 外引SRE咨询服务(三)模式三: 内外结合的SRE混合体系外部引入SRE咨询服务即依赖第三方运维服务商按照约定的范围提供SRE咨询能力, 重点在业务系统的观测指标体系、 运维优化建议等方面提供支持。 观测指标体系指围绕业务系统提供全栈的运维观测清单, 并确保供应商开放观测所需的数据; 运维优化建议指第三方服务商通过跟踪和管理业务系统的运行、 运维情况, 适当提供如可用性评测、 部署策略、 发布策略、 灰度策略、
72、升级策略、 灾备策略等方面的可用性优化建议, 以及对运维工作流程进行评测和自动化优化建议, 对系统业务容量、 资源容量的趋势进行评测并提供容量规划建议。该模式具备以下优势:提升服务深度: 对业务场景深入了解的第三方运维服务商, 可以切实地提供专业、 系统、 客观的服务和建议, 并对供应商和运维流程提供合理、 有效的约束;快速适配体系: 在不影响现有的组织架构和运维体系前提下, 通过咨询服务对分布式架构业务系统的运维能力进行加强和补充, 更好地完成适配和服务支持。该模式具备以下劣势:管理和安全问题: 第三方运维服务商深入到运维工作过程中, 在监管严格的金融行业中, 存在较大的安全合规问题, 增加
73、了管理的困难;责任边界模糊: 以咨询服务的方式, 对于IT的整体规划和实施产生影响的同时, 担负的责任与影响不对等, 使得团队之间的责任边界变得模糊。SRE混合体系, 即企业既建设自己的SRE组织, 又依赖第三方运维服务供应商提供的SRE咨询服务, 由企业自己的SRE组织参考第三方供应商的建议, 牵头完成SRE运维体系的建设和业务系统可用性保障。该模式具备以下优势:快速构建面向分布式架构系统的运维体系: 企业自己的SRE组织只需要进行相关工作的协同串联和方案实施, 并对第三方服务商进行管理, 主要方案由第三方服务商进行设计, 可以解决管理、 安全以及服务深度的问题, 快速对分布式架构系统的运维工作提供支持;证券行业分布式核心系统SRE运维白皮书27建设SRE组织能力: 通过快速运转分布式架构系统运维体系, 积累知识、 经验, 培养相关专家, 持续优化SRE组织能力。该模式具备以下劣势:增加人力成本: 同时构建SRE组织和购买第三方运维服务, 需要较大的成本投入, 具体的实施路径需要更精细地规划, 以控制成本投入;沟通存在障碍: 新构建的SRE组织依然存在与开发、 运维、 第三方服务商的沟通问题, 需要确认良好的沟通机制以确保信息和计划得以传达执行。 证券行业分布式核心系统SRE应用建议第六章28