【作者】彭华盛,10年+的金融领域运维工作,期间负责参与运维组织、流程、工具建设,包括重大业务系统与数据中心工程性项目实施,标准化工作流程构建,平台工具体系的规划与研发、数字化转型研究与实施相关等,对金融领域的运维有较全面理解。
一.背景
2.关于运维左移
运维左移恰逢其时。运维左移强调在确保系统稳定性的基础上,运维团队应在软件交付到生产环境之前加大投入,以实现运维的价值创造。在当前变更风险复杂、交付速度加快以及稳定性SRE转型的背景下,运维左移的意义愈发凸显。在实践中,运维人员需要跳出传统运维的框架,利用自身接近一线生产数据的优势,以更主动的姿态参与软件开发的全生命周期。包括在系统设计和部署阶段就进行埋点,以便在运行阶段预见并解决潜在风险,实现从被动响应到主动预防的转变。左移是一个跨团队的协同过程,需要与开发、测试、基础设施平台、外部供应商等各方资源联合,共同推动技术平台的可扩展性和弹性,提升应用系统架构的韧性,以及交付相关可运维性需求。运维左移不仅提升了系统的稳定性,还有助于企业内跨团队的角色更好地理解运维工作,消除对运维岗位在技术序列中位置靠后的误解,并激励运维人员更深入地参与到具体应用层面,形成良性循环。
左移是稳定性保障工作的演进产物。它并非一项全新的工作内容。早在十年前,我所在的运维团队就提出要走出运维的”舒适区”,提前介入软件的立项可行性、概要设计、详细设计、变更评审等阶段。目标是在上述阶段更早地介入,以发现潜在的变更风险并提前做好资源准备。随着组织的发展,运维参与上线前的工作事项越来越多,可以说运维左移是组织在稳定性保障工作中不断深化的成果。同时,许多组织在一系列事件的驱动下,不断对运维管理进行”加法”,形成了包括架构韧性设计、非功能性需求、业务与技术风险评审、部署架构、资源规划与交付、非功能性测试、功能性测试、变更评审、变更发布、上线保障、线上稳定性保障、成本优化、系统下线等全流程的工作内容,这些内容要做深做透单靠运维效果不好。我们也能够发现在左移工作的协同过程中,由于运维与研发之间的协同不足,许多工作的深度和投入产出比并不突出。所以,当前提出运维左移,需要运维从业者具备软件工程师的思维(相较于具备开发能力,更易转型),加强跨部门的沟通与合作,真正深入到软件设计、研发、测试阶段,提升各项工作的深度和效果。
3.运维价值的调整
上面提到的“故障的可恢复性、性能的可扩展性、运行的可观测性、系统的可运维性”这四个目标,主要是为了更好地实现“系统稳定性保障”这一底线价值。然而,在实践中,运维组织还涉及其他方面的价值左移。从运维的角度来看,稳定性保障是基本要求,是确保组织能够持续运营的基础。而用户体验、成本优化、支撑技术创新等方面,则是为了实现更高的目标,是运维组织创造“额外”绩效的重要方向。
因此,许多组织会利用外部政策、公司战略、生产故障等事件作为触发点,来增强左移的范围和深度。同时,也有不少企业从IT的技术、产品、服务角度出发,引领企业转型并创造价值,从而确定运维左移的重点工作。在《运维数字化转型》一书中,我提出运维价值主要包括”提高业务连续性保障、提升业务交付速度、辅助提升客户体验、提升IT运营服务质量”等方面。在这个过程中,有朋友向我提出了一些很好的问题和建议,我将这些反馈汇总为几个要点:
“IT服务质量、客户体验”是一个比较大的范围,容易与其他产生包含关系,建议将这两点归为一点“提升用户体验”,其中用户包括内部用户与外部客户,运维直接面向内部用户,间接提升外部用户的体验。
“提升用户体验”包括提升软件交付速度、提高软件质量、推动外部客户体验的提升。
现在行业特别重视成本优化,并推动各种优化措施,提升IT资产效能;
运维需要想尽办法,支撑、推动IT技术创新。
基于上述几点,我对运维的关键价值创造进行了调整。首先,保留”稳定性保障”,这是运维组织生存的基石,至关重要。其次,整合”提升用户体验”,这不仅包括在软件开发和资源服务交付速度上的提升,也包括提高交付质量。第三,新增”提升资产效能”,重点是通过数字化手段进行成本优化,提高IT资产的收益,并降低成本。最后,新增”支撑业务创新”,这涉及到角色的转变,通过平台建设和数据利用,支持业务的创新发展。调整后的运维关键价值创造是以下四点:
加强稳定性保障
提升用户体验
提升资产效能
支撑业务创新
4.稳定性保障
围绕稳定性保障,运维不仅要构建和完善能够支持稳定性保障的技术平台和基础设施,还需要与软件架构师、研发人员、应用运维、平台软件运维以及基础运维等不同角色进行有效沟通和协作,共同深入到 SDLC (软件生命周期)中,增强应用架构的韧性。在稳定性保障方面,左移的工作可以从以下四个关键点着手:
(1)故障的可恢复性
故障的可恢复性指的是,当IT系统因内部或外部因素导致业务中断或面临故障风险时,系统应具备感知故障的能力,并能够迅速采取应急措施以恢复业务连续性。过去,运维工作主要集中在容灾、服务、主机等维度的高可用性上。而运维左移则需要进一步考虑“系统关键业务功能”的容错能力设计,包括关键业务功能的路径涉及哪些服务节点和关联基础设施,依赖哪些通用技术平台和上游服务等。同时,还需要评估这些节点在部分或全部异常情况下,系统功能是否具备容错能力。也就是说,系统的设计应将预测、识别、隔离等能力嵌入系统中。可恢复性左移的一些关注点包括:
定义应用服务的可用性目标。
制定评价系统容量的关键指标。
在容灾、主机、服务层面实现系统应用的高可用性。
确保系统应用依赖的服务、基础设施、应用平台的高可用性。
对关键功能自身不可用或依赖服务不可用时的业务健康进行监控。
在关键功能层面实施限流和降级措施。
在技术架构层面实现隔离、熔断和冗余高可用。
在软件设计层面采用解耦、并发、超时机制、重试、以及文件或数据可用性检测。
在容灾层面实施BCM。
发现异常并触发恢复策略的能力。
(2)性能的可扩展性
性能的可扩展性是指确保系统在业务增长、用户流量突增或遇到生产性能故障时,能够通过灵活调整资源和服务配置来满足不同的性能需求,从而展现出架构的韧性。这要求系统在设计阶段就具备评估容量的能力,并能在不同负载下实现自动化的弹性伸缩功能。此外,系统的可扩展性不仅局限于自身,其运行所依赖的基础设施也必须具备足够的弹性,以便快速响应资源需求的变化,确保服务的高可用性。同时,系统还需要依赖自动化工具和监控系统来实时监控性能指标,并在必要时触发资源的扩展或缩减。运维左移在性能可扩展性方面,除了在架构层面确保性能的可扩展性外,还应制定性能扩展预案,并定期进行压力测试和演练,以确保系统在实际业务增长或高流量事件中能够平稳过渡。性能可扩展性的关注点包括:
具备弹性伸缩能力的基础设施和依赖的技术平台(如应用平台、数据库、中间件等)。
支撑并实现自动、半自动、手动的弹性伸缩能力,包括纵向资源扩容、横向集群节点新增或复制同类型节点,以及应用层面的降级与限流等。
应用能够感知性能瓶颈,具备监控和压力测试能力,及时发现性能瓶颈并触发相应的扩展或缩减操作。
制定性能扩展预案,并定期进行压力测试和演练,确保在故障发生时能够有信心执行预案。
参与系统设计阶段,重点推动系统可扩展性的需求,采用模块化、微服务等架构设计,便于未来的扩展和维护。
与研发团队紧密合作,确保系统设计时就考虑到性能扩展的需求,并在系统部署和运行过程中能够快速响应性能问题。
与研发沟通容量评估指标,并在生产环境中设置监控点,使系统具备容量评估能力,准确评估当前系统的性能容量,并预测在不同负载下的表现,为资源扩展提供数据支持。
(3)运行的可观测性
运行的可观测性,从狭义上讲,是指利用系统生成的数据来观察系统内部状态,以便进行故障排查的能力。目前,许多监控和APM供应商正在其以metric和event为主的解决方案上,融入OTEL标准,重点增强trace功能,并尝试与log关联,以实现一个综合性的技术方案。与监控方案相比,可观测性技术方案的最大区别在于,监控通常是从系统外部进行监测,而可观测性则是从系统内部进行剖析,提供排障定位辅助。
可观测性技术方案之所以吸引行业关注,是因为它采用一种“通用”的技术方案来发现“未知”的异常,这为方案的发展前景提供了广阔的想象空间。由于系统可观测性需要深入到系统应用逻辑,这与运维左移的思路非常契合,需要在研发过程中推动数据埋点。不过,由于我在狭义可观测性的实践上还不够充分,我对这种技术实现还持比较保守的态度。另外,可观测技术方案已初步形成了一个生态系统,并持续在降低了数据采集和控制的门槛,但与外挂式的监控相比仍存在一定的门槛。此外,可观测技术方案的推行者或供应商有时会试图忽视专家经验的作用,这在企业推动中可能会产生不利因素。因此,在金融企业中,我认为可观测方案能否落地需要考虑以下几个假设背景:
企业重要的业务系统是否已经完成了向分布式架构、云原生架构的演进。
系统复杂到仅凭专家经验进行故障排查已经非常困难。
传统的监控手段是否已经难以满足复杂分布式系统的调试和监控需求。
运维专家是否接受这种可能绕过专家经验的可观测性排障方案。
端到端的系统是否能够遵循链路标准,并进行数据埋点。
是否已经梳理并达成了关键交易链路的共识。
上述假设成立后,我认为金融公司的可观测性解决方案还需融合现有的监控、主动探测等技术与专家经验,而不是完全替代它们。毕竟,目前结合“专家经验”和“监控+主动探测”的技术方案已经能够应对大部分生产故障的界定或定位,而采用“指标+日志+追踪”的技术方案的成本有多高,效果在企业中还有待验证。运维左移可以考虑关注以下事项:
制定相关技术标准,确保从管理决策层到一线专家、从运维到研发岗位都能达成共识。
建立或采纳可观测性的行业技术标准。
提供涉及数据采集和控制的运维平台能力,以便在软件设计阶段进行数据埋点。
寻找符合组织特点的可观测性最佳实践。
(4)系统的可运维性
系统的可运维性涵盖了设计、发布、运行保障等全过程中的关键要素,具体表现为易管理性、强大的监控能力、故障应急响应、高效的变更管理、完善的文档交付、良好的可扩展性、安全性以及其他关键要求。我特地将“可运维性”作为一个独立点来强调,原因有三:首先,为了更全面地推进系统稳定性,需要在“故障可恢复、性能可扩展、系统可观测”等重点之外,对其他稳定性要求进行全面考虑;其次,为了继承并发展当前运维左移的工作重点,将这一理念融入整体的运维体系;最后,尽管运维组织经过多年的积累,已沉淀出许多运维管理要求,但很多内容仍局限于内部视角,因此需要重新梳理和明确一个全面的系统稳定性保障要求。
为了确保这些稳定性保障要求得到有效执行,运维部门应将其细化为具体的CheckList任务,并在软件交付生产前尽早地安排相关角色进行落实。这样做可以有效避免“变更评审后风险未解决,系统带病上线”的情况发生。具体而言,可运维性的关注点包括:
可监控:确保对业务(功能、数据、拨测)的全方位监控。
可应急:制定并维护应急预案,确保架构的韧性和降级功能的可用性。
可操作:提供便捷的数据维护和参数配置功能。
可变更:实现高效的CD、调度和参数管理。
可运营:涵盖知识管理、容量评估、性能管理、风险评估等技术运营方面。
可恢复:参考前述。
可扩展:参考前述。
可观测:参考前述。
5.提升用户体验
以提升用户体验为核心驱动力,企业数字化转型对运维组织提出了更高要求。为了满足这些要求,运维组织需全面致力于多个关键领域的优化。首先,在确保系统稳定性的同时,运维可利用生产系统运行数据,分析软件交互行为的分析和监控, 更早的发现影响客户体验的功能性问题、功能使用频度等信息,并作出相应的应对措施。其次,运维组织应加速软件与基础设施资源的交付,确保业务或客户的需求更快的交付生产。最后,运维组织需持续推动IT服务质量的提升,确保服务的可靠性和用户满意度。
很多运维组织推动了IT服务管理来落地用户体验提升,通过在服务交付方式上建立清晰的服务目录,梳理服务及其特点,以便内部团队能够便捷地选择和使用。运维左移可聚焦在下图服务目录的“软件交付服务”层,一方面通过增加自动化和数字化投入,减少人工干预,从而提高交付速度并降低操作风险。另一方面,运维组织还需对变更风险进行严格管控,通过精细化的变更管理,从计划、实施到验证的每个环节都实施严格的风险评估和管理措施,确保变更的平稳进行,避免对系统稳定性造成不良影响。
(1)向左控制变更风险
变更是对生产环境中程序、配置、参数、数据等进行的干预,这种干预行为往往是生产故障的重要诱因。很多金融企业的运维组织的整体工作计划性主线就是围绕变更管控,并在软件交付前投入大量精力的领域。其实质是一种跨周期、跨团队的生命周期管理,形成月、双周、周迭代的循环“变更计划、变更申请、变更评审、变更发布、变更验证、首日保障、故障应急、复盘优化”的工作主线。在运维左移的背景下,变更控制应着重考虑以下共识性内容:
无论是稳态系统还是敏态系统的 灰度发布 ,都应实施统一的变更计划管理,确保变更的协调性和一致性。
变更申请需遵循严格的“仪式感”,即要求变更满足基本的准入条件,从源头上确保变更的合理性。
严格管控变更评审过程,包括实施方案、变更风险、影响分析、资源准备、问题跟踪以及配套监控等,确保变更的可行性和安全性。
提升变更实施的管控能力,包括但不限于实施手段、工具的选择、发布频率的把控,以及出现异常时的应对能力,确保变更过程的高效和稳定。
严格落实变更后的验证工作,特别是重要变更项的当日技术验证,以及变更后到开业、首日保障、首笔业务等关键节点的验证,确保变更效果符合预期。
加强变更行为过程事件的采集与控制,利用事件驱动机制,实时监控变更过程中的各项事件,确保变更的透明度和可追溯性。
增强对变更对象变化的感知能力,通过实时监控和数据分析,及时发现并应对变更可能带来的潜在风险。
(2)向右提升交付速度
有效的变更管控不仅能显著提升IT需求的交付速度至业务部门,同时也是防范生产事件风险的关键所在。为了确保变更的顺利进行,我们需要采取全方位的管控措施来降低风险。在强化变更管控的同时,我们还应积极推动原有人工操作的自动化,并增加风险控制点的自动化程度。以下是具体的优化措施:
变更日历与研发过程管理对接:通过将变更日历与研发过程管理紧密结合,确保变更信息与研发流程的无缝对接,提高信息的准确性和一致性。
变更申请与研测过程连接:将变更申请与需求、提测等研测过程直接连接,避免重复录入信息,提高工作效率,减少错误发生。
变更评审项CHECKLIST数字化:将变更评审的CHECKLIST进行数字化管理,尽可能实现自动化处理,减少对专家临场经验的依赖,提高评审效率和准确性。
发布自动化:实现发布的自动化流程,支持灰度发布,实时观测异常,并具备快速应急响应能力,确保变更的平稳进行。
验证工作任务化:将验证工作的CHECKLIST移至线上进行,提高验证工作的透明度和可追溯性,确保变更后的系统稳定可靠。
6. 提高资产效能
近年来,随着经济的波动下行,业界对降本增效的期待日益增强。在我之前的[《互联网大厂SRE招聘]一文中,不难发现各大企业纷纷将IT资产的成本管理作为一个独立的部门来运营,并且FinOps技术方案在行业内也得到了广泛分享。以下摘自Gartner研究显示:
提升IT资产效能,越来越成为企业考量IT部门的重要内容
目前全球只有不到25%的公司具有适当的IT资产管理规划
全球70%的企业计划库存和实际库存间存在30%的偏差,通过有效的资产管理,就能够节约高达30%的IT预算
实施IT资产管理企业的总拥有成本可以至少降低15%,缺少或质量低下的IT资产管理每年还会增加10%以上的资产成本
有40%的客户IT资产没有通过任何工具来跟踪监测,只有10%的资产通过公共数据库来协调。
更充分利用现有资产、更严格地控制资产、获得更高的投资回报,不仅是企业对IT部门的殷切期望,也越来越成为企业考量IT部门的重要内容。
大多数公司使用复杂的人工跟踪监测方式,或者根本不清楚自己的IT资产基础,而不够了解自己IT资产的公司,往往软件管理的质量也很差,成本花费也就会更高,并给公司带来时间、资金以及系统性能上的损失。”
从上述描述中,我们可以明显看出,在业务迅速扩张的阶段,对资源成本管理的重视度普遍不足。系统的稳定性固然是企业生存的基础,但成本优化则是企业保持竞争优势的关键。在ISO27001标准中,IT资产涵盖了有形与无形资产,如基于信息技术的硬件资源、软件系统、IT流程、人力资源以及数据资源等。目前,主流的FinOps技术方案主要聚焦于云上资源的成本优化,通过财务视角对云资源的预算、成本分摊、核算及优化进行全方位管控。从运维左移的视角出发,我们应特别关注IT软硬件资产的效能。在软件开发的初期阶段,就应对IT软硬件资产进行细致规划和有效管理,以确保其整体效能的显著提升。为实现这一目标,我们可以考虑以下举措:
以CMDB为中心建立IT资产台帐管理,建立详细的IT资产清单,包括硬件、软件、许可证等,以便更好地规划和管理资源。
从平台支撑角度建立硬件资源资源池、数据库及中间件平台、签订更优惠的许可协议、提升虚拟化与容器化比例、做好测试资源的利用等;
制定统一的硬件和软件配置标准,使用模板化的方法来部署和管理IT资产。
参与立项与需求分析阶段,推动支撑资产的评估,以及后续容量评估数据指标与埋点的技术方案;
在开发阶段就进行性能基准测试,确保软硬件配置能够满足性能要求。
利用自动化工具来部署和管理IT资产,减少人为错误和提高部署速度。
实施实时监控,以便及时发现性能瓶颈和资源使用情况,进行必要的优化。
根据业务增长和IT需求进行容量规划,确保软硬件资产的扩展性和灵活性。
制定IT资产的生命周期管理计划,包括采购、使用、维护、升级和淘汰。
定期进行成本效益分析,评估IT资产的投资回报率,优化资源配置。
7.支撑业务创新
关于运维支撑业务创新的价值,我过去一直有些模糊。首先,运维部门在确保系统稳定性的基础上,常常面临提升绩效的难题。虽然成本优化和用户体验优化一直是运维团队的核心工作,但即使做得再好,这些往往只被视作额外的绩效贡献。其次,从企业的视角来看,运维部门往往被视为后台服务的后台,而业务创新更多地关联到产品、需求和研发部门。然而,我认为运维组织凭借其独特的优势,可以转变角色,从后台支撑转变为推动者。这需要通过平台搭建、数据分析和工具创新等层面,深入挖掘对业务流程优化、用户体验提升、数据消费增值以及辅助决策等方面的业务创新潜力。接下来,我将从直接参与和间接支撑两个维度,探讨运维在业务创新中的发展方向。
(1)间接支撑业务创新
传统运维组织在稳定性保障、成本管理、安全保障以及IT服务管理等方面,主要扮演着间接支撑业务创新的角色。然而,从运维左移的视角出发,除了这些基本的运维保障工作,还可以关注以下几个方面来更好地支持业务创新:
提升IT需求敏捷交付能力:有条件的运维平台团队应积极推动平台工程能力建设,通过实施DevOps的CI/CD等工程实践,加速业务创新的周期,确保需求能够迅速、准确地转化为实际产品。
搭建云化基础设施与 PAAS平台 :通过构建云化的基础设施IAAS平台和PAAS平台,提高资源的交付效率,为业务创新提供灵活、可扩展的IT支撑。
推动系统运行效率评估与成本优化:深入分析系统运行效率,推动FinOps成本优化管理,提升成本优化的绩效,从而帮助企业建立更高的市场竞争力。
建立IT与业务部门的桥梁:基于IT服务经理的角色,围绕系统建立IT与业务部门之间的沟通桥梁,促进跨部门间的沟通与协作,为业务创新提供协同效率。
识别与管理业务风险:通过业务监控与数据分析,运维部门可以帮助企业及时识别和管理业务创新过程中可能出现的风险,确保业务创新的顺利进行。
提供受控的实验环境:为业务创新提供受控的生产数据与运行环境,为业务团队提供实验和快速迭代的空间,降低创新过程中的风险。
(2)直接的业务创新
运维团队也可以在直接创新方面发挥作用,比如通过深入理解用户需求和系统运行的细微之处,能够直接参与到产品的创新设计中。以下是运维团队直接创新作用的几个具体方面:
监控分析,推动用户界面和交互创新:通过对用户使用模式的监控和分析,运维团队能够迅速发现影响用户体验的问题,并针对性地提出改进方案,直接推动用户界面和交互设计的创新,提升用户满意度。
流程优化,提升业务效率:通过对现有业务流程的分析理解,识别出流程中的瓶颈和冗余环节,提出优化方案,并通过自动化工具和技术手段实现流程的优化和重构,直接提升业务处理的效率和质量。
数据驱动,支持业务决策和创新:收集运营数据,并对这些数据的分析和挖掘,能够提供业务洞察和趋势预测,为基于数据的业务决策和创新提供有力支持,帮助企业实现更加精准的市场定位和产品开发。
传递运营数字化理念:运维的数字化水平往往是企业内部较高的,可以将这种数字化工作理念传递给企业中后台的运营部门,如将ITSM扩展至ESM,将监控技术应用于运营管理等,提升整个公司运营管理的数字化水平。
工具赋能:通过运维平台构建场景工具、自动化操作工具(比如rpa)、数据可视化、ChatOps等工具,帮助业务运营人员更快的感知、决策、执行运营工作。
转化客户反馈为创新动力:作为客户及分支机构反馈的前线接收者,可以直接将客户的声音转化为产品改进和创新的动力,确保产品始终与市场需求保持同步。
8.小结
欢迎点击文末阅读原文到社区阅读和讨论交流 觉得本文有用,请转发或点击“在看”,让更多同行看到
资料/文章推荐:
https://www.talkwithtrend.com/Topic/4549
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点,不代表社区立场