摘要：广发证券数字化运维研发团队，致力于通过数字化技术推动SRE转型，赋能稳定性保障，负责数字化运维体系的规划与建设，包括数字化运维体系规划、流程规程制定、运维平台研发、效能管理、持续交付、智能运维等工作。
作者介绍
广发证券数字化运维研发团队，致力于通过数字化技术推动SRE转型，赋能稳定性保障，负责数字化运维体系的规划与建设，包括数字化运维体系规划、流程规程制定、运维平台研发、效能管理、持续交付、智能运维等工作。
引言
为应对证券行业数字化转型、重要系统架构升级、云原生技术发展、信息技术创新，以及行业重大故障频发等多重复杂因素的影响，广发证券愈发重视系统稳定性和可靠性建设。系统稳定性不仅是证券行业软件开发的基石，更是贯穿从研发到部署的每一个环节，与整个软件生命周期紧密相连。接下来我们将围绕系统稳定性保障工作，针对软件生命周期在上线前的运维左移工作，总结工作思路与实施策略。
运维左移的七项关键能力
传统的运维团队主要聚焦于变更管控、容量优化、风险挖掘等例行工作，以及系统故障应急发现、定位、处置、恢复等能力建设。在日常的生产运营中，发生连续性故障会大大降低客户体验，而仅靠出现故障后被动应急的方式很难满足证券行业对客户体验的高要求。因此，我们团队认为系统需要具备韧性，以应对可能出现的生产故障。
为此，广发证券信息技术部运维团队的工作不局限于传统运维部门快速处理故障和发布变更等被动性工作，而是积极推动转变角色定位，并将工作重心左移。运维左移要求运维人员需要参与到软件设计开发阶段，包括从架构设计到关键功能逻辑实现的环节，从而构建一个具有良好可运维性的软件交付机制。其重点是推动系统具备以下7项能力（后面简称“7支柱能力”）。
故障可恢复 (Fault Recoverability)性能可扩展 (Performance Scalability)业务可监控 (Business Monitorability)问题可观测 (Issue Observability)变更可管控 (Change Controllability)部署可感知 (Deployment Perceptibility)效能可评估 (Effectiveness Evaluability)运维左移这七项能力与当前行业主流的SRE转型思路相似，SRE转型是指从传统运维角色向Site Reliability Engineer（网站可靠性工程师）角色的转变过程。在广发证券运维团队的业务建设中，我们积极汲取行业SRE的最佳实践，推动组织架构、人员能力、流程机制、平台能力、运维场景的建设，比如今年运维团队积极推进的一些运维左移的举措，如SRE三线风险挖掘、业务监控、运行评估、系统效能评估、“周三架构韧性评审日”、数字化变更管控、数字化预案、智能化容量评估、智能化日志模式分析等工作。
运维左移关键思路
运维左移恰逢其时。运维左移强调在确保系统稳定性的基础上，运维团队应在软件交付到生产环境之前加大投入，以实现运维的价值创造。在当前变更风险复杂、交付速度加快以及稳定性SRE转型的背景下，运维左移的意义愈发凸显。
在实践中，运维人员需要跳出传统运维的框架，利用自身接近一线生产数据的优势，以更主动的姿态参与软件开发的全生命周期。包括在系统设计和部署阶段就进行数据埋点，以便在运行阶段预见并解决潜在风险，实现从被动响应到主动预防的转变。同时，左移是一个跨团队的协同过程，需要与开发、测试、基础设施平台、外部供应商等各方资源联合，共同推动技术平台的可扩展性和弹性，提升应用系统架构的韧性，以及交付相关可运维性需求。运维左移不仅提升了系统的稳定性，还有助于企业内跨团队的角色更好地理解运维工作，并激励运维人员更深入地参与到具体应用层面，形成良性循环。
左移是稳定性保障工作的演进产物。左移并非一项全新的工作内容。早在很多年前，行业很多运维团队就提出要走出运维的“舒适区”，提前介入软件的立项可行性、概要设计、详细设计、变更评审等阶段。目标是在上述阶段更早地介入，以发现潜在的变更风险并提前做好资源准备。
随着组织架构的发展，运维参与上线前的工作事项越来越多，可以说运维左移是组织在稳定性保障工作中不断深化的成果。同时，许多组织在一系列事件的驱动下，不断对运维管理进行“加法”，形成了包括架构韧性设计、非功能性需求、业务与技术风险评审、部署架构、资源规划与交付、非功能性测试、功能性测试、变更评审、变更发布、上线保障、线上稳定性保障、成本优化、系统下线等全流程的工作内容，这些内容要做深做透单靠运维总有欠缺。因此，运维左移需要运维人员具备软件工程师思维（相较于具备开发能力，更易转型），加强跨部门的沟通与合作，真正深入到软件设计、研发、测试阶段，提升各项工作的深度和效果。
SRE正在重塑运维左移。SRE专注于提升系统的可靠性和稳定性，通过设定明确的SLO和SLI，激励团队采取一切必要措施来实现SLO目标。SRE倡导的从被动到主动的思维转变，将更有效地推动左移目标的实现。其次，SRE聚焦于系统的稳定性，就需要深入到软件生命周期的各个环节，并达成一些共识，比如我上面提到的“7支柱能力”。此外，运维左移是一项重要的跨团队协同工作，它推动了协同机制和平台能力的支持落地。例如，SRE倡导在工程方面的投入，通过增强运维平台的工程能力，降低研发团队在配合落地“7支柱能力”方面的数据埋点、非功能性需求的门槛，并让研发团队也能在这个过程中受益。这种共赢的方式有助于促进左移机制的有效实施，确保团队能够更高效地协同工作，共同提升系统的稳定性和可靠性。
运维左移重点措施
为了确保系统的稳定性，运维团队不仅要构建和完善支持稳定性的技术平台与基础设施，还需要与软件架构师、研发人员、应用运维、平台软件运维以及基础运维等不同角色进行有效沟通和协作。通过共同深入参与到SDLC（软件生命周期）的各个阶段，我们可以增强应用架构的弹性。
1、故障可恢复
故障的可恢复性意味着，在IT系统因内部或外部因素导致业务中断或面临故障风险时，系统应能够感知到故障，并迅速采取应急措施以恢复业务连续性。以往，运维工作主要聚焦于容灾、服务、主机等维度的高可用性，但这些措施并不足以应对当前复杂脆弱的生产运行风险。例如，在近期的突发行情中，我们深刻认识到限流与降级对于交易、终端等系统来说是必要的故障可恢复能力。因此，运维左移需要考虑“系统关键业务功能”的容错能力设计，这包括了解关键业务功能的路径涉及哪些服务节点和关联基础设施，依赖哪些通用技术平台和上游服务，以及在这些节点部分或全部出现异常时，系统功能是否具备容错能力，系统设计是否具备预测、识别、隔离等能力。可恢复性的一些关注点包括：
定义应用服务的可用性目标。制定评价系统容量的关键指标。在容灾、主机、服务层面实现系统应用的高可用性。确保系统应用依赖的服务、基础设施、应用平台的高可用性。对关键功能自身不可用或依赖服务不可用时的业务健康进行监控。在关键功能层面实施限流和降级措施。在技术架构层面实现隔离、熔断和冗余高可用。在软件设计层面采用解耦、并发、超时机制、重试、以及文件或数据可用性检测。在容灾层面实施BCM。发现异常并触发恢复策略的能力。2、性能可扩展
性能的可扩展性指的是，在业务增长、用户流量突增或面临生产性能故障时，系统能够通过灵活调整资源和服务配置来满足不同的性能需求，展现出架构的弹性。这要求系统在设计阶段就应具备评估容量的能力，并能在不同负载下实现自动化的弹性伸缩。系统的可扩展性不仅涉及自身，还包括其依赖的基础设施，这些基础设施必须具备足够的弹性，以便快速响应资源需求的变化，确保服务的高可用性。此外，系统还需依赖自动化工具和监控系统来实时监控性能指标，并在必要时自动触发资源的扩展或缩减。在性能可扩展性方面，运维左移不仅要在架构层面确保性能的可扩展性，还应制定性能扩展预案，并定期进行压力测试和演练，以确保系统在实际业务增长或高流量事件中能够平稳过渡。性能可扩展性的关注点包括：
定义系统容量性能评价目标与指标。具备弹性伸缩能力的基础设施和依赖的技术平台。支撑并实现自动、半自动、手动的弹性伸缩能力，包括纵向资源扩容、横向集群节点新增或复制同类型节点，以及应用层面的降级与限流等。应用能够感知性能瓶颈，具备监控和压力测试能力，及时发现性能瓶颈并触发相应的扩展或缩减操作。制定性能扩展预案，并定期进行压力测试和演练，确保在故障发生时能够有信心执行预案。参与系统设计阶段，重点推动系统可扩展性的需求，采用模块化、微服务等架构设计，便于未来的扩展和维护。与研发团队紧密合作，确保系统设计时就考虑到性能扩展的需求，并在系统部署和运行过程中能够快速响应性能问题。与研发沟通容量评估指标，并在生产环境中设置监控点，使系统具备容量评估能力，准确评估当前系统的性能容量，并预测在不同负载下的表现，为资源扩展提供数据支持。3、业务可监控
监控是确保系统稳定运行的核心措施，其能力构建应从基础设施层向上延伸至客户体验层，涵盖基础设施监控、硬件服务器监控、平台软件监控、应用可用性监控、应用功能监控以及性能和客户体验监控。在基础设施、硬件和平台软件层面，以及部分性能监控方面，可以利用通用技术方案来提升监控的广度和时效性。然而，应用可用性、功能可用性和客户体验的监控往往依赖于运维团队基于经验和事件驱动的“打补丁”的解决方案，这种方法存在诸多不足。为了提高业务监控的效率和准确性，需要在系统设计阶段就融入业务监控功能。这要求产品和研发团队，凭借对系统业务、组件、接口、功能和用户体验的深刻理解，设计出更为精准的监控方案。通过这种方式，可以系统性地提升应用层面的监控质量，减少依赖“打补丁”的监控模式，从而更有效地保障业务连续性和客户满意度。业务可监控关注点包括：
明确不同业务类型信息系统的业务监控覆盖面要求；业务影响面监控，比如业务黄金指标、技术黄金指标、用户体验指标、安全与风控指标、废单数量等。
性能容量监控，比如关键性能指标、同环比与基线分析、趋势分析、容量预期、行情及时性等。
业务状态监控，比如上下场状态、订单状态异常、参数状态异常、内存加载异常等。
业务拨测监控，比如终端拨测、站点拨测、登录拨测等。
接口拨测监控，比如接口可用性、接口性能、接口正确性等。
数据正确性监控，比如回库数据一致性、上下场数据一致性、清算数据一致性等。
业务链路监控，比如上游依赖服务堵塞、依赖服务异常、下游系统请求过多、关键链路成功率与耗时等。
4、问题可观测
运行的可观测性，从狭义上讲，是指通过系统生成的数据来观察其内部状态，以便进行故障排查的能力。目前，许多监控和APM供应商正在其以metric和event为主的解决方案上，融入OTEL标准，重点增强trace功能，并尝试与log关联，以实现一个综合性的技术方案。与监控方案相比，可观测性技术方案的最大区别在于，监控通常是从系统外部进行监测，而可观测性则是从系统内部进行剖析，提供排障定位辅助。可观测性技术方案之所以吸引行业关注，一方面是因为分布式系统和系统依赖变得越来越复杂，需要有一种简洁的方案来实现复杂系统的问题剖析。另一方面，由于可观测主流方案采用一种“通用”的技术方案来发现“未知”的异常，这为不想过多定制化的可观测供应商提供了广阔的想象空间。由于系统可观测性需要深入到系统应用逻辑，这与运维左移的思路非常契合，即在研发过程中推动日志、链路、指标的数据埋点。当前，可观测技术方案已初步形成了良好的生态系统，并持续降低了数据采集和控制的门槛。
然而，可观测技术方案的推行者与供应商有时会忽视专家经验的作用，这在企业推动中可能会产生不利因素。我们在推进可观测能力建设过程中，在上述狭义可观测（log、metric、trace）的同时，也推动帮助专家沉淀问题剖析经验的编排。专家经验编排类似于我们去医院问诊时，医生会让病人先做一系列身体检查，即让一线运维专家与研发专家提前编排好一个系统是否健康的检查项。问题可剖析关注点包括：
明确面向业务及交易系统可观测要求。支持行业主流成熟的 OTLP v1 标准作为建设依据。
制定相关可观测数据埋点的技术标准，确保从管理决策层到一线专家、从运维到研发岗位都能达成共识。
支持一线运维专家与研发专家落地健康检测剖析的自动化编排能力。
提供涉及数据采控的运维平台能力，以便在软件设计阶段进行数据埋点。
围绕问题剖析，设计面向运维、研发、测试、供应商等多种视角的数据分析场景。
在整合系列数据分析可视化之上，推进精准定位的能力建设。
5、变更可管控
变更涉及对生产环境中的程序、配置、参数和数据进行干预，这种行为常常是生产故障的主要诱因。公司围绕变更管控制定整体工作计划，并在软件交付前投入大量精力。变更管理实质上是一种跨周期、跨团队的生命周期管理，形成了以月、双周、周为周期的迭代循环，包括“变更计划、变更申请、变更评审、变更发布、变更验证、首日保障、故障应急、复盘优化”等环节。变更管控应从软件设计阶段就开始融入，例如在研发设计阶段推动应用软件在制品、应用配置、数据库脚本的持续交付(CD)自动化发布，并进行变更涉及的风险分析和影响面评估。除了自动化变更操作外，还应准备变更操作手册和变更回滚方案，对于无法回滚的变更应作为高风险变更进行左移保障。
此外，变更管理不仅涉及软件发布，还包括环境配置、业务参数等变更操作行为，SRE应收集并重点管控这些重要参数或配置变更。对于高危变更操作，应实施严格的防御控制措施，包括变更审批流程、变更窗口控制以及变更前的自动化测试，以确保变更操作的安全性。这些控制措施应在软件部署流程中预先设计，并在变更操作前进行严格的风险评审。变更可管控关注点包括：
无论是稳态系统还是敏态系统的灰度发布，都应实施统一的变更计划管理，确保变更的协调性和一致性。变更申请需遵循严格的“仪式感”，即要求变更满足基本的准入条件，从源头上确保变更的合理性。
严格管控变更评审过程，包括实施方案、变更风险、影响分析、资源准备、问题跟踪以及配套监控等，确保变更的可行性和安全性。
提升变更实施的管控能力，包括但不限于实施手段、工具的选择、发布频率的把控，以及出现异常时的应对能力，确保变更过程的高效和稳定。
变更场景自动化，以尽可能减少直接对IT资产对象进行临时性的操作为目标，实现变更操作场景自动化。
变更影响风险分析，在变更前基于变更服务目录、上下游依赖等信息评估变更风险，为变更前的风险防范、资源调度、变更后保障等提供支撑。
变更防御策略管控，对于危险的变更操作行为进行事中的防御管控，尽可能降低操作风险。
严格落实变更后的验证工作，特别是重要变更项的当日技术验证，以及变更后到开业、首日保障、首笔业务等关键节点的验证，确保变更效果符合预期。
加强变更行为过程事件的采集与控制，利用事件驱动机制，实时监控变更过程中的各项事件，确保变更的透明度和可追溯性。
增强对变更对象变化的感知能力，通过实时监控和数据分析，及时发现并应对变更可能带来的潜在风险。
故障的变更定位，基于上述的变更管控数据建模，在出现故障时能够辅助定位是哪个变更引发的故障。
6、部署可感知
部署可感知指的是将构成系统所有软硬件及其依赖资源数字化，实现对资源对象状态及变化的实时感知。部署可感知能力使得从整体系统资产到微观的环境配置或业务参数，都能被随时观测和掌握。通过数字化系统资源和实时监控变化，不仅能够透明化的管控系统资产对象，还增强了在系统故障时定位问题和系统恢复能力。以往，系统的资源对象信息主要通过CMDB以配置项形式数字化，但在应用层面的信息管理尚显不足。研发及供应商是最熟悉一个系统的稳定运行需要哪些配置及参数设置，运维左移需在基础设施到操作系统、平台软件层面建立通用基线配置，并要求研发或供应商以系统部署说明书的方式，提供系统个性化配置。个性化配置信息应涵盖操作系统环境、应用配置、技术参数、业务参数、数据库结构及参数、中间件配置等。运维团队在接收到这些配置后，需将其数字化，并实现对配置变化的感知，以实现系统的部署可感知。部署可感知可关注以下几个方面：
建立系统在交付生产前需要有一份面向应用系统的部署配置清单；推动CMDB向应用及业务配置的扩展，构建包括操作系统环境、应用配置、技术参数、业务参数、数据库结构、数据库参数、中间件配置、应用平台配置等在内的配置项模型；
建立采集配置信息的能力，并以时间片为单位感知配置变化；
支持从系统、集群、应用到主机等不同视角，随时获取相关配置的数字化信息；
实现配置信息的实时更新和历史追溯，以支持快速的问题定位和系统恢复。
7、效能可评估
效能可评估是指通过数字化手段量化系统运营的效果，识别并优化低效的系统资源，以提升整体的系统资源效能。在经济波动和下行压力下，企业对成本管理和效能提升的需求日益迫切，IT资产的成本管理逐渐成为企业运营中的一个重要部门。Gartner的研究表明“提升IT资产效能已成为企业考量IT部门的关键内容，但全球范围内，只有不到25%的公司具备适当的IT资产管理规划。有效的IT资产管理可以使企业的总拥有成本至少降低15%，而缺乏或质量低下的IT资产管理每年可能增加超过10%的资产成本。此外，约40%的客户IT资产没有通过任何工具来跟踪监测，仅有10%的资产通过公共数据库来协调。”
因此，更充分利用现有资产、严格控制资产、获得更高的投资回报，不仅是企业对IT部门的期望，也是考量IT部门的重要内容。从运维左移的视角出发，在软件开发的初期阶段，就应对IT软硬件资产进行细致规划，一方面对评价系统效能的指标进行设计与数据埋点，另一方面需要以系统效能好坏来评价给高效及低效系统的资源配置，以更好的调度有效的IT资源。效能可评估可关注以下内容：
建立IT资产台帐管理：以CMDB为中心，建立详细的IT资产清单，包括硬件、软件、许可证等，以便更好地规划和管理资源。研发设计阶段落地评价系统运营好坏的效能指标，并落地效能数据。
对系统效能指标进行数字化评估，以挖掘低效的IT资源。
从平台支撑角度建立硬件资源池、数据库及中间件平台，签订更优惠的许可协议，提升虚拟化与容器化比例，优化测试资源的利用。
实施实时监控，以便及时发现性能瓶颈和资源使用情况，进行必要的优化，并根据业务增长和IT需求进行容量规划，确保软硬件资产的扩展性和灵活性。
定期进行成本效益分析，评估IT资产的投资回报率，优化资源配置。
展望
随着数字化转型的深入，运维左移已成为提升系统稳定性和可靠性的关键策略。未来，运维团队将持续推进SRE转型，建立机制鼓励运维人员的积极参与，通过跨团队合作，实现从被动响应到主动预防的转变。同时，运维平台化建设也将为研发和供应商提供平台服务，使他们能够基于左移的投入获得实际效益。左移不仅能够提升系统的稳定性，还能促进企业内跨团队的理解和协作，形成良性循环，共同推动技术的进步和业务的发展。
来源：dbaplus社群一点号