本文来自微信公众号“twt企业IT社区（talkwithtrend.com）”，【作者】彭华盛，10年+的金融领域运维工作，期间负责参与运维组织、流程、工具建设，包括重大业务系统与数据中心工程性项目实施，标准化工作流程构建，平台工具体系的规划与研发、数字化转型研究与实施相关等，对金融领域的运维有较全面理解。。
在数智化浪潮的推动下，SRE既面临着分布式、云化和信创等复杂环境带来的稳定性挑战，同时也迎来了新技，以及可观测性、LLMOps等技术方案带来的机遇。数字化运维的管理是由组织、流程、平台、场景综合构建而成。随着企业中运维平台的不断沉淀与发展，当前运维平台发展为赋能型平台，以“监、管、控、析、配”的通用平台形式交付。运维组织在选择通用运维平台时，除了确保平台能提供所需功能需求外，还需着重考察平台的可扩展性，比如确认平台是否遵循主流技术标准以便更好的融入行业丰富的技术生态系统，是否具备出色的开放性以确保能够与关联系统无缝集成，是否支持上层场景应用的快速构建等。本文尝试立足金融行业从业视角，分析运维平台解决方案选型方面的思考和策略。
一、平台解决方案类型
在主流的2B运维平台解决方案中，主要分为四类：纯产品型、以产品为主配合少量定制型、以产品为基础进行大量定制型，以及完全以客户需求为导向的定制型。在中型金融企业这类SRE组织中，“产品+定制服务”的结合型解决方案各受欢迎。
纯产品型的平台，即仅销售标准化产品并不提供定制服务，或只接受与产品版本迭代方向完全一致的需求，主要以SAAS和少数优秀产品为代表。这种模式是供应商最希望的交付方式，但在运维平台领域，成熟的SAAS解决方案并不多见，同时能够无需定制即可满足需求的优秀产品也相对稀缺。我认为，纯产品型解决方案适合那些标准化程度高、需求统一的市场，或者是产品能够引领市场并让客户接受的新工作理念，或者是技术门槛极高，或者是产品仅解决特定局部问题，或者是产品不直接与人交互的情况。然而，随着客户对平台的认识水平的持续提升的背景下，符合这些条件的产品极为罕见。此外，国内市场上的许多用户已经习惯于平台适应企业现有的工作机制，这种思维方式已经十分固化，不易改变。
对于“以产品为主，少量定制”型与“以产品为基础进行大量定制”型，解决方案供应商提供技术平台来满足客户的定制化需求。两者的区别在于定制化内容的程度。通常，前者的平台能更好地融入用户现有的系统，或在设计上更贴合用户的工作流程，或客户对这个平台的想法较少等原因；而后者可能需要较大程度的改造来与用户的实际工作场景相融合，后者适合需求复杂、场景多元的企业，通过与客户的共同研发，深入理解一线客户的实际需求，避免开发出仅符合伪需求的产品。这两种解决方案都体现了产品供应商对“服务”在2B运维平台交付中重要性的认可，通常更受用户欢迎，能带来持续的项目机会。从用户的项目实施风险看，选择一个在以往项目经验中获得认可的供应商，通常项目风险更小。产品的定制迭代成本的降低，是这两种模式能否持续成功的关键。
至于完全以客户需求为导向的定制型解决方案，供应商可能仅提供基础或底层技术平台，一切以客户需求为中心，接受各种定制化的开发要求。这种服务型的交付方式适合服务要求极高、需要高度定制化解决方案的企业。通过提供人力服务，完全按照客户需求进行开发和实施。如果产品设计得当，这种交付方式可以打造出与用户高度融合的解决方案，更有效地绑定用户与供应商的关系。当然，与A客户的高度融合意味着可能与B客户的融合度不会达到100%，这种方式更适合于运维平台供应商的早期发展阶段，并且要求供应商能够在交付的解决方案中提炼出通用的平台化方案。
二、运维平台的方向
很多SRE组织的“监管控析配”的通用运维平台经历了多年迭代，沉淀了企业内部的专家经验，相比于新技术平台能力带来的提升，专家经验往往更具粘性。因此，要说服企业进行更换，必须有一些明确且有说服力的因素，例如：
- 现有技术平台无法解决面临的紧迫问题，比如监控平台在应对应用架构微服务化、企业上云等挑战时，所必需的可观测性和故障排查能力；
- 团队面临新的技术架构和工作内容的要求，而现有的技术平台却无法提供相应的支持；
- 出于IT战略层面，对平台能力建设有新的推动和要求。
从近几年行业的发展看，为了应对稳定性挑战，通用技术平台也在保持快速的发展，并形成了一些建设方向，下图我作了一些简要汇总。
1.监控平台
随着技术复杂性与行业对系统故障容忍度下降，监控平台的功能已经从异常发现和统一告警，逐步扩展至监控发现到故障识别、辅助排障与应急恢复的能力发展。所以，首先，监控平台需要能够进行可观测数据采集和控制，确保系统运行的透明度和可控性。同时，监控平台还需从传统的基础设施、技术平台、应用可用等层面的监控，向业务层面的监控能力提升，需要融合系统的个性化监控，提供SRE左移到系统设计阶段的平台能力支撑。另外，针对云上环境，在能力上重点需要增加对复杂、弹性、动态的云资源、服务和应用的监控能力。最后，监控平台还需要建立事件驱动的平台能力，提供通用的基于异常发现后的故障自愈的自动化操作能力。
2.服务管理
运维的服务管理是通过服务化管理模式去管理运维，以确保运维管理行为能够高质量、高效率地满足公司业务需求，优化IT资源的效能。在平台层面，除了传统的流程管理和IT服务台功能外，当前的服务管理已经扩展到流程自动化，通过自动化工具和技术减少人工干预，提高服务交付效率。同时，无代码平台的引入，使得无软件开发能力的运维专家也能参与到服务管理的持续迭代，推动了服务管理的民主化。另外，构建一站式的服务平台目录为服务消费者提供了清晰的服务目录和说明，便于他们快速找到所需的服务。最后，在管理协同中充分提升连接能力也是服务管理的一个措施，比如平台引入ChatOps，通过聊天工具进行团队协作，提高了服务管理过程中的沟通效率和响应速度。
3.操作管控
以往操作平台重点强调生产环境操作的自动化，主要聚焦在效率的提升。当前，传统的脚本平台和RPA（机器人流程自动化）工具已经不能满足现代运维的需求。因此，操作管控已经扩展至变更风险控制和持续集成/持续部署（CI/CD）等领域。同时，变更风险控制通过自动化和智能化的手段，对变更进行风险评估和预测，对操作风险的事中建立事件驱动的控制行为，对变更对象进行变化感知等变更风险管控，确保变更的安全性和稳定性。另外，将运维组织能力扩展到软件交付价值流中，推动CI/CD则实现了代码的持续集成、构建、测试和部署，以加快了软件开发和交付的速度，也是操作管控的重点方向。
4.运维分析
运维分析是通过对系统数据的采集、存储、计算、管理和使用，以及对指标异常检测和日志模式识别等技术的运用，来洞察系统运行状态和性能瓶颈的重要手段。当前，运维数据分析从原来建平台、试点AIOps等平台建设外，正在更加务实的推动运维数据场景的落地。比如在运维分析领域的风险预测、容量评估、性能管理以及LLMOps（日志、监控、度量、操作）等领域。其中，风险预测通过引入算法，对历史数据的分析和挖掘，预测未来可能出现的问题和风险；容量评估则帮助运维团队合理规划系统资源，确保系统在高负载下仍能稳定运行；性能管理则通过实时监控和调优，确保系统始终运行在最佳状态；LLMOps则是充分利用大模型带来识别语言、推理、分析决策等能力，将日志、监控、度量和操作等各个环节紧密结合起来，形成一种全新的运维模式的探索。
5.配置管理
CMDB的配置管理作为运维的基础工作之一，也在不断发展和完善。以往，运维组织主要将配置管理主要作为生产设备台帐和平台间互联互通的作用发展。下一步，配置管理需要从运维领域进行扩展，发展到IT运营数字化的主数据管理，通过对各类数据的集中管理、整合和治理，为IT的项目建设提供准确、全面的数据支持。同时，随着云计算和大数据技术的广泛应用，FinOps也逐渐成为配置管理的重要组成部分。FinOps通过引入财务视角来审视和优化IT资源的投入和产出，帮助企业实现IT资源的最大化利用和成本优化。
三、决定解决方案的因素
在金融企业中，结合产品和定制服务的解决方案相对受欢迎。SRE组织会根据不同的项目需求、发展阶段和行业特点，对四类解决方案——纯产品、产品为主+少量定制、产品打底+大量定制、纯客户导向的定制——表现出不同的偏好。
以项目需求为例，企业的项目可划分为痛点驱动型和发展驱动型两大类。对于追求快速成效的发展驱动型项目，以产品为核心的解决方案更受青睐，因为它们能够迅速部署并产生创新或验证假设的效益。相比之下，痛点驱动型项目则与企业的具体工作场景紧密相关，这要求技术平台必须能够与现有场景相融合，因此在这类项目中，定制服务的比重会更大。
以LLMOps为例，许多企业已将LLM作为IT战略的一部分，积极探索大模型与实际业务场景的结合，以促进业务模式创新和运营效率的提升。在大模型还未开发出爆点场景阶段，以及企业大模型的技术战略的驱动下，企业内各部门可能都会思考如何挖掘大模型在自身条线下的场景研发。在大模型技术尚未完全成熟，但企业已开始基于技术战略推动场景开发的阶段，LLMOps项目更多地被视为发展驱动型。此时，领先企业的SRE组织可能会抓住时机，快速落地至少能在某些方面提供赋能的以产品为主的解决方案。鉴于大模型技术的快速发展和行业的大规模投入，这一发展驱动型的机遇窗口可能不会持续太久。一旦过了这个阶段，对于LLMOps项目成效的期望值将提高，届时将更加注重解决核心价值创造的痛点，对定制服务的需求也会随之增加。
此外，还有一些其他因素可能影响解决方案类型的选择。例如，在大型企业中，如果场景建设已经较为成熟，那么新引入的平台解决方案能否与现有体系相融合就成为关键，这时定制服务的重要性凸显；如果管理决策者希望快速出成效，快速引入技术平台以改善现有短板，那么即插即用的标准化产品解决方案将更受优先考虑；对于仅在特定局部使用的工具类解决方案，产品化的解决方案可能更为合适。
总的来说，在组织内部，那些与企业现有工作场景和人员交互密切相关的解决方案，通过定制化服务来更好地融入现有平台体系，往往更有市场；而对于底层技术平台或局部按需使用的工具等解决方案，标准化的产品解决方案则更具优势。当然，改变上述倾向性也可有可能，比如管理决策者推动新的工作机制。
四、场景是平台解决方案的方向
鉴于很多SRE组织通用运维平台已经比较成熟，且在当前以“价值驱动”、“降本增效”等为导向的思维下，组织选择新技术平台时，更加注重平台能否针对性地解决具体问题。因此，以往以技术驱动的平台建设的需求将大幅减少，取而代之的是以实际工作场景为基础的平台化建设，场景化更符合价值驱动的底层逻辑。此时，如何将SER组织原有技术平台能力与新的平台解决方案融合，为企业打造一个敏捷的技术平台将是一个发展方向。为了实现这一目标，运维平台供应商需要关注能力、效率、成本方面的差异化能力，比如：
- 具备以数据采控、自动化操作、流程引擎、可视化等通用平台能力；
- 能够提供几个高粘性的场景工具（相比上一条，场景面向人，上一条面向机器）；
- 交付团队提供产品设计能力，能够根据用户反馈和市场需求，快速迭代和优化产品功能；
- 提供能够降低定制化成本的相关技术方案，比如低代码或无代码解决方案；
- 具备良好项目管理机制与项目经理，落实进度、成本控制、需求分析等，提升研发效率。
五.总结
运维平台作为数字化运维体系的支撑能力，其选型工作显得尤为重要。作为解决方案供应商，通过对运维平台解决方案类型的分析，可以看到“产品+定制服务”的结合型解决方案在当前市场环境下更受欢迎，既能够让运维组织获得行业先进的平台能力，还能通过定制化服务深度融入企业的实际工作场景。作为SRE，在运维平台方案选型时，需在聚焦于平台的“监、管、控、析、配”核心功能的同时，还要注重平台是否遵循主流的技术发展方向，其扩展性、开放性和对特定场景的定制支持程度。同时，在当前LLM快速发展的背景下，有条件的SRE组织保持在LLMOps上的投入相信会有意想不到的收获。另外，推动由通用平台向场景建设扩展，预期会是行业运维平台的建设方向，需要平台建设者能够灵活适应不同稳定性保障场景，提供高效落地场景的能力。
