AI 基础
什么是 IT 运维 (ITOps)？
将 Unite.AI 添加到您在 Google 上的首选来源
IT 运维 (ITOps) 是组织运行其依赖的技术服务的工作。它涵盖计算、网络、身份、终端、云平台、数据库、存储、备份以及保持这些组件可用、安全和可支持的运维流程。
现代 IT 运维并不局限于监控仪表盘的网络运维中心。团队日益管理软件定义的基础设施、平台服务、自动化和分布式所有权，同时仍对事件、容量、连续性和服务水平负责。
关键要点
- IT 运维管理跨本地、云端和边缘环境的服务及其依赖关系。
- 可观测性、配置和资产清单提供解释故障所需的上下文。
- 事件管理恢复服务；问题管理处理重复或系统性原因。
- IT 运维与 ITSM、SRE、DevOps、SecOps 和 AIOps 有交叉，但并不等同于其中任何一种。
服务、资产和配置
运维首先要了解存在哪些服务、谁拥有这些服务、哪些用户依赖它们以及哪些基础设施支撑它们。资产清单记录组件；配置管理记录相关关系和受控状态。
从未对齐的清单会产生误导。应在有价值的地方自动化发现，确定权威来源，并记录可信度或新鲜度，而不是假装每个依赖图都是完整的。
可观测性和服务目标
指标量化行为，日志记录事件，追踪跨服务的工作流。合成检查可以测试用户旅程。有效的可观测性始于问题和服务目标，然后收集回答这些问题所需的信号。
告警应识别需要及时行动的情况。没有用户影响的阈值会产生噪音，而缺少依赖上下文会拖慢诊断。AIOps 可以帮助关联，但它需要可信的遥测数据和运维反馈。
事件、问题和变更管理
事件管理协调检测、分诊、缓解、沟通和恢复。明确的角色可以在压力下减少混乱。临时变通方案可以在后续问题调查解决更深层原因之前恢复服务。
变更管理在评估和记录风险时不必把每一次变更都排入队列。标准化、自动化且低风险的变更可以走预批准路径；高影响的变更则需要更充分的证据、计划安排和回滚准备。
容量、弹性和连续性
团队预测资源需求，消除瓶颈，并在负载下测试行为。只有在恢复得到验证时，备份才有价值。冗余只有在故障模式相互独立且故障转移真正可行时才有意义。
业务连续性定义优先级、恢复时间和可接受的数据丢失。应在演练中纳入对身份、DNS、云控制平面和供应商的依赖，而不是假设它们始终可用。
ITOps、ITSM、SRE 与 DevOps
IT 服务管理提供将服务与组织需求对齐的流程。站点可靠性工程将软件工程方法应用于运维，并使用服务水平目标和错误预算。DevOps 将开发与运维反馈相结合。
SecOps 专注于威胁与响应，而 ITOps 维护更广泛的服务健康。组织结构图各有不同；重要的是在这些学科之间保持明确的所有权和共享的证据。
ITOps 运营模型
IT 运维确保组织的技术服务可用、高性能、安全且可恢复。范围通常包括终端、身份、网络、服务器、云、存储、协作、数据库、监控、服务台、备份以及供应商服务。现代 ITOps 跨越自有基础设施和托管平台，因此即使外包运营，也必须明确责任。配置或服务清单将技术组件与所有者、用户、依赖关系、数据分类和业务关键性关联起来。
服务管理组织事件、请求、问题、变更、资产、知识和服务水平。事件管理恢复服务；问题管理调查重复原因；变更使能评估并协调风险。把每一次变更都视为慢速审批会导致规避，而无治理的自动化会产生失控的故障。标准的低风险变更可以预授权并自动化；高风险变更则需要证据、沟通、回滚和基于影响的计划安排。
可靠性、容量和连续性
监控应关注面向用户的服务及其依赖关系，而不仅仅是设备数量。与业务所有者一起定义可用性、延迟、容量、新鲜度和支持目标。对可操作的症状和错误预算消耗进行告警；用所有权和最近的变更丰富事件信息。容量规划模型包括需求、饱和度、许可证和交付时间。云弹性可以缩短供给延迟，但并不能消除配额、区域限制或成本控制。
业务连续性需要经过测试的备份、恢复、身份恢复、网络备选、供应商联系和手工流程。为每项服务定义恢复时间目标和恢复点目标。备份只有在恢复并验证后才算是恢复的证据。演练勒索软件、区域失效、证书过期、身份中断和供应商故障。尽可能将配置和基础设施作为代码进行跟踪，以实现可重复的恢复。
安全、自动化和度量
使用最小特权、补丁和漏洞管理、终端控制、网络分段、日志记录以及事件响应。通过幂等性、限制、审批和审计自动化重复工作。衡量服务可用性、事件复发、请求履行、变更失败、恢复、补丁暴露、容量、成本和用户满意度——而不仅仅是工单关闭数量。IT 运维的成功在于技术能够可预测地支持工作并从故障中恢复，而不是仪表盘看起来繁忙或绿色指示灯过多。
实战示例：恢复协作服务
某公司为协作平台设定了四小时的恢复时间目标和一小时的恢复点目标。它清点了身份、DNS、网络、数据、密钥、配置、集成和供应商依赖。恢复演练假设主区域和管理员账户不可用。操作员激活独立受保护的紧急身份，将服务配置和数据恢复到隔离的区域，并验证权限、消息、集成和客户端访问。业务所有者通过真实的用户旅程验证恢复的服务，而不是仅依赖基础设施健康检查。
演练记录了实际的数据丢失、耗时、手动步骤、失效联系以及隐藏的依赖。仅能恢复文件但无法恢复加密密钥或身份策略的备份被标记为不完整。纠正措施附带所有者和日期，运行手册随之更新并重新测试。监控和沟通模板被纳入其中。组织衡量的是恢复证据而非备份作业成功，因为可靠的 ITOps 必须在真实的故障条件下恢复用户真正需要的服务。
实施证据和运营准备度
生产决策需要的不仅是一次成功的演示。必须定义预期用户、运行环境、输入、输出、依赖、所有者以及每项关键故障的后果。建立可重复的基线和版本化的评估集，然后再进行调优。测试普通情况、边界条件、错误或缺失的输入、分布漂移、依赖中断、误用以及最可能被服务不足的群体或环境。将任务质量与校准或不确定性、延迟、吞吐量、资源成本、可访问性、隐私和安全一起度量。记录每一次转换和阈值，以便独立审查者能够复现结果并区分证据与吸引人的原型。
上线前，分配发布、例外、变更、回滚和退役的授权。使用分阶段发布，保留安全回退，并通过人为注入的故障验证监控。运营遥测应揭示输入质量、输出行为、模型或规则版本、依赖健康、人为覆盖以及确认的结果，而不收集不必要的敏感数据。定义告警阈值和响应所有者，然后在部署后审查真实世界的证据，而不是假设离线性能会持续。每当数据源、用户、模型、供应商、策略、硬件或目标发生变化时都要重新评估。维护中的系统同样需要文档化的恢复、事件学习、删除和保留流程，以及明确的停用或替换时点。
常见问题解答
ITOps 的主要目标是什么？
在约定的安全、性能、连续性和成本约束内，交付并恢复可靠的技术服务。
云基础设施是否完全由云提供商运营？
不是。供应商运营底层平台的部分组件，而客户仍需负责配置、身份、数据、工作负载、监控以及许多服务级别的决策。
主要参考文献
