云计算-ITSM-云上确定性运维实践

柑木
33 阅读15分钟

博主最近在调研一些IT运维的方案，恰巧之前在云厂商工作时与相关云服务做过类似解决方案，在这里想重新梳理一下，分享一些在云服务视角下的企业级IT运维方案。

ITSM

IT 服务管理（ITSM）是一套以 “用户需求” 为导向，通过标准化流程、工具和最佳实践，管理 IT 服务全生命周期的方法论。它不只是工具或流程的堆砌，而是一种 “以服务为中心” 的管理思维。

其核心要素有：

  1. 服务全生命周期：覆盖服务战略、设计、转换、运营、持续改进 5 个阶段。
  2. 标准化流程：核心流程包括事件管理、问题管理、变更管理、发布管理、服务请求管理等。
  3. 价值导向：最终目标是为业务创造价值，而非单纯保障 IT 系统运行。
  4. 角色与责任：明确划分服务台、二线支持、三线支持、流程负责人等角色。

典型应用场景：

  • 员工电脑蓝屏，通过服务台提交故障工单（事件管理）。
  • 业务部门需要新增办公软件账号，提交申请单（服务请求管理）。
  • 系统升级前评估风险、制定方案（变更管理 + 发布管理）。
  • 频繁出现的网络卡顿，深挖根本原因并解决（问题管理）。

ITSM的演进

ITSM 的演进源于 IT 运维的痛点升级，从 “技术导向” 逐步转向 “服务导向”，可分为 4 个关键阶段：

初始阶段：被动运维时代

IT 基础设施刚起步，规模小、功能单一，主要用于核心业务数据存储（如财务、库存）。无标准化流程，IT 团队扮演 “消防员” 角色，仅在系统故障后被动抢修。响应慢、责任不清，用户满意度低，IT 与业务脱节。

萌芽阶段：流程化探索时代

IT 系统逐渐普及，服务器、网络设备增多，故障和需求激增，单纯被动抢修无法满足需求。ITIL（IT Infrastructure Library）1.0 版本诞生，由英国政府计算机与电信局（CCTA）发布，首次提出 IT 运维的标准化流程框架。开始梳理核心流程（如事件管理、变更管理），尝试用 “流程” 规范运维行为，减少人为失误。

成熟阶段：框架标准化与工具落地时代

企业数字化加速，IT 成为业务核心支撑，对服务稳定性、规范性要求大幅提升。ITIL 迭代至 2.0、3.0 版本，完善服务全生命周期理念，成为全球主流 ITSM 框架。商业化工具兴起，如 ServiceNow、BMC Remedy 等，将 ITIL 流程固化为系统功能，实现流程自动化。ITSM 从 “方法论” 落地为 “可执行的系统”，IT 团队从 “技术支持” 转向 “服务提供者”。

智能化阶段：数字化与智能化升级时代

云计算、大数据、AI 普及，IT 环境变得复杂（混合云、分布式架构），用户对服务效率要求更高。ITIL 4 发布，融入敏捷、DevOps 理念，强调 “服务价值系统”，打通 IT 与业务的协同。智能化功能落地，如通过 AI 自动分类工单、预测故障（如服务器负载过高预警）、机器人流程自动化（RPA）处理重复请求。ITSM 与业务深度融合，从 “规范交付” 向 “高效创新” 升级，支持快速响应业务变化。

ITSM的核心流程

以下是 ITSM 最核心的 5 大流程，包含流程定义、核心目标、标准步骤、角色职责和典型应用示例，覆盖日常 IT 运维的核心场景。

事件管理（Incident Management）

事件是指导致 IT 服务中断或质量下降的未计划内情况（如系统故障、软件报错、硬件损坏等），事件管理的核心是快速恢复服务，最小化对业务的影响。

核心目标

  • 快速响应用户上报的故障，缩短服务中断时间。
  • 记录事件全生命周期信息，便于追溯和分析。
  • 确保用户需求得到及时反馈，提升满意度。

标准步骤

  1. 事件记录：用户通过服务台（电话、工单系统）上报，记录故障现象、影响范围、紧急程度。
  2. 事件分类与优先级：按故障类型（如硬件、软件、网络）分类，按影响范围（单人 / 部门 / 全公司）和紧急程度（P1-P4）定优先级。
  3. 初步诊断与处理：服务台尝试快速解决（如密码重置、简单设置调整），无法解决则升级至二线 / 三线支持。
  4. 问题解决与验证：支持团队排查并修复问题，通知用户验证服务是否恢复。
  5. 事件关闭：用户确认恢复后，关闭工单并记录解决方案。

问题管理（Problem Management）

问题是导致多个事件重复发生的 “根本原因”（如频繁卡顿、反复报错的底层问题），问题管理的核心是找到并消除根本原因，预防同类事件再次发生。

核心目标

  • 挖掘事件背后的根本原因，减少重复故障。
  • 建立问题知识库，沉淀解决方案。
  • 优化 IT 环境，提升系统稳定性。

标准步骤

  1. 问题识别：通过分析重复事件（如一周内 5 人上报同一软件崩溃）或重大事件，触发问题记录。
  2. 问题分类与优先级：按问题类型（如系统漏洞、配置缺陷）分类，按影响范围定优先级。
  3. 根本原因分析：通过日志分析、故障复现、专家评审等方式，找到问题根源（如软件版本兼容性问题）。
  4. 制定解决方案：如升级软件版本、调整系统配置、修复漏洞等。
  5. 方案实施与验证：执行解决方案后，监控是否还有同类事件发生。
  6. 问题关闭：确认根本原因已消除，更新知识库。

变更管理（Change Management）

变更是指对 IT 基础设施、系统、服务等进行的调整（如系统升级、硬件更换、配置修改），变更管理的核心是控制变更风险，确保变更不会导致服务中断。

核心目标

  • 标准化变更流程，避免无序变更带来的故障。
  • 评估变更风险，制定应对预案。
  • 确保变更实施后，IT 服务正常运行。

标准步骤

  1. 变更申请：相关人员提交变更请求（CR），说明变更目的、范围、影响、实施时间。
  2. 变更评估：变更评审委员会（CAB）评估变更的必要性、风险（如是否影响核心业务）、资源需求。
  3. 变更审批：根据评估结果，审批变更（批准、驳回、延期），高风险变更需高层审批。
  4. 变更规划：制定实施计划、回滚预案（如变更失败如何恢复）、测试方案。
  5. 变更实施：在非业务高峰时段（如夜间、周末）执行变更，同步监控状态。
  6. 变更验证：检查变更是否达到预期效果，系统是否正常运行。
  7. 变更关闭：确认无异常后，关闭变更记录，更新相关文档。

发布管理（Release Management）

发布是指将经过测试的变更（如软件新版本、系统补丁、配置更新）部署到生产环境的过程，发布管理的核心是确保发布过程平稳，实现变更的有序交付。但在许多场景上，发布和变更不会存在太大差异（发布可以视为是一类变更）。

核心目标

  • 标准化发布流程，减少发布失败概率。
  • 协调各方资源，确保发布按时完成。
  • 快速回滚失败发布，降低业务影响。

标准步骤

  1. 发布规划：明确发布内容（如软件 V2.0 版本）、发布范围（全量 / 灰度）、时间窗口、资源需求。
  2. 发布构建：整合变更内容，构建发布包（如安装文件、配置脚本）。
  3. 发布测试：在测试环境验证发布包的功能、兼容性、性能，确保无问题。
  4. 发布审批：提交发布计划，经相关负责人审批通过。
  5. 发布实施：按计划部署发布包（如先灰度发布给 10% 用户，无异常再全量），实时监控。
  6. 发布验证：检查生产环境运行状态，收集用户反馈，确认发布成功。
  7. 发布关闭：记录发布结果，更新知识库和系统文档，归档发布包。

服务请求管理（Service Request Management）

服务请求是用户主动提出的、非故障类的 IT 需求（如账号开通、权限申请、软件安装等），服务请求管理的核心是高效满足用户常规需求，提供标准化服务。

核心目标

  • 简化请求流程，缩短处理周期。
  • 标准化服务内容，提升用户体验。
  • 减少重复沟通，提高处理效率。

标准步骤

  1. 请求提交：用户通过服务台（自助门户、工单系统）提交请求，选择需求类型（如账号开通）。
  2. 请求审核：服务台验证请求的合理性（如是否符合公司权限规范）。
  3. 任务分配：将请求分配给对应处理人员（如 IT 管理员）。
  4. 需求满足：处理人员按标准化流程完成请求（如创建账号、安装软件）。
  5. 结果反馈：通知用户需求已完成，确认满意度。
  6. 请求关闭：用户确认后，关闭工单并归档。

华为云确定性运维

image.png

流程体系涵盖了产品全生命周期运维活动，它驱动了不同分工团队在业务和体系上的融合和发展。确定性运维流程是强调运维活动标准化、规范化，且不断迭代提升运维能力的流程体系。通过对各环节进行规范化和自动化管理，来避免人为因素对整体稳定性和效率的影响，提升管理体系能力。

组织转型是企业人力资源再分配与再布局，是效率、成本、竞争力和可持续化发展的集中体现。上述示意图中的实践，其运维组织架构是一种阶梯式的分工和协作架构。

运维工具是管理体系和组织效能的催化剂，在效率、可靠性、安全性、可用性和管理水平等多个方面都发挥着重要作用。运维工具是实现高效、稳定、安全的运维管理和提高业务运营效率和质量的重要手段。

云运维中心 COC

云运维中心（Cloud Operations Center，简称COC）为用户提供安全、高效的一站式智能运维平台，满足客户集中运维诉求。承载华为云确定性运维业务场景，提供变更管理、批量运维等核心特性，实现在安全合规的前提下，提升用户运维能力成熟度和云上运维效率。

image.png

变更管理

变更管理作为保障运维作业安全有序开展的核心模块，其核心功能在于构建覆盖运维作业全生命周期的安全生产能力。从变更需求的初步提出，到方案设计、实施执行，再到事后复盘与效果评估，该模块通过系统化的流程设计与多层级的风险管控机制，精准识别潜在风险点并提前制定应对策略，从而有效降低变更操作过程中的各类风险，为运维体系的稳定运转提供坚实保障。

该模块主要承载变更流程管理的核心业务，整合了变更日历、变更中心、变更配置、变更管控等关键能力，各能力模块协同联动，形成一套从计划到执行、从配置到监控的闭环变更管理体系。

变更日历：变更日历主要是根据日历视图展示变更单的数据，并根据不同状态（染色、时间窗等）查看变更分布。

变更中心：变更中心主要承载变更流程管理业务，以变更工单模式，从变更的申请、审批、执行三个大环节管控变更业务，为变更人员、变更管理人员提供统一管理平台。

变更配置：承载变更中心相关配置的业务，支持审批配置等变更基础配置的能力。支持用户根据自身业务需求，自定义变更单审批流程、审批人员。

变更管控：是对资源进行变更操作时，通过工单提权的方式，才能执行脚本、作业或查询账号密码等操作，确保人和所操作的对象和实际资源保持一致，防止权限过大，降低安全风险。

image.png

image.png

AWS Systems Manager

AWS Systems Manager（简称 SSM）是亚马逊云科技（AWS）提供的一个统一的运营中心，旨在帮助客户在混合云和多云环境中大规模地可视化、控制和自动化 IT 基础设施。

image.png

Systems Manager的优势包括以下几点：

  • 增强对整个基础设施的可见性：提供跨组织账户和区域的节点集中视图。快速访问实例信息，如 ID、名称、操作系统详细信息以及安装的agent。
  • 通过Automation提升运营效率：自动化常见的运维任务，减少维护系统所需的时间和精力。Systems Manager 可大规模安全地远程管理节点，无需登录服务器。您不再需要使用堡垒主机、SSH 或远程 PowerShell。Systems Manager 还提供了一种简单的方法，用于跨节点组自动化常见的管理任务，如注册表编辑、用户管理以及软件和补丁安装。
  • 在任何环境中简化大规模节点管理：Systems Manager 帮助管理 AWS、本地和多云环境中的节点。安排自动诊断以识别 SSM Agent 问题，并使用一键运行簿进行修复。在客户的节点配置为受管节点后，客户可以执行关键运维任务，如应用安全补丁、启动记录会话以及远程运行命令。

image.png

AWS Systems Manager 由多个组件构成，每个组件解决特定的运维需求(主要组件）：

  • Run Command (运行命令) ：安全地在成百上千个实例上远程执行 Shell 脚本或 PowerShell 命令，例如安装软件或更新配置，无需直接访问服务器。
  • State Manager (状态管理器) ：定义并强制实例保持所需配置状态（如特定的防火墙设置、软件版本），确保环境始终符合安全和合规标准。
  • Inventory (清单) ：自动收集和查询实例的配置信息，包括已安装的应用程序、软件补丁、网络配置等，帮助您进行资产管理和审计。
  • Session Manager (会话管理器) ：在需要进行交互式排查时，通过安全的浏览器或 CLI 连接到实例，替代不安全的 SSH/RDP 访问。
  • OpsCenter (运维中心) ：集中查看、调查和解决来自 Amazon CloudWatch、CloudTrail 等多个 AWS 服务的运营问题，帮助缩短平均解决时间 (MTTR)。
  • Fleet Manager (资产管理员) ：简化对云端和本地实例集群的远程管理，提供文件浏览、日志管理和快速 Shell 访问等功能，无需逐一登录。
  • Patch Manager (补丁管理器) ：自动扫描和安装操作系统补丁，保持系统的安全性。

基于SSM Agent的多云管理

SSM Agent（Amazon Systems Manager Agent）是 AWS Systems Manager服务的核心组件，它是一个轻量级的软件代理，必须运行在目标主机上（如 EC2 实例、本地服务器、Azure/GCP 虚拟机等），才能使该主机被 SSM 服务管理和控制。

SSM Agent 充当  “目标主机”与“AWS SSM 服务”之间的通信桥梁，主要职责包括：

  1. 监听来自 SSM 服务的指令（如 Run Command、Session 请求）。
  2. 在本地执行命令或脚本（如 Bash、PowerShell、Python 等）。
  3. 收集执行结果、日志和系统状态，并回传给 SSM 服务。
  4. 定期上报主机清单信息（Inventory）。
  5. 应用配置变更（通过 State Manager 关联的文档）。
  6. 建立安全会话通道（用于 Session Manager）。

SSM Agent 采用 出站连接（Outbound-only）模型，安全性高：

  1. Agent 主动连接 AWS SSM 服务端点（通过 HTTPS/443）。

    • 不需要在主机上开放入站端口（如 SSH 的 22 端口）。
    • 防火墙只需允许出站到 ssm.{region}.amazonaws.com 和相关服务端点。

  2. 使用 IAM 角色或激活凭证进行身份认证：

    • EC2 实例：通过附加的 IAM Instance Profile（角色）自动获取临时凭证。
    • 非 AWS 主机：通过激活码（Activation）注册后，使用临时 IAM 用户凭证（注册后可轮换或撤销）。

  3. 基于长轮询（Long Polling）或 WebSocket 接收指令：

    • Agent 定期向 SSM 服务查询是否有待处理的任务。
    • 一旦有任务（如用户发起 Run Command），SSM 服务立即下发指令。

  4. 执行结果异步回传：

    • 执行输出、退出码、错误信息等通过 HTTPS 回传至 SSM 服务。
    • 用户可在 AWS 控制台、CLI 或 API 中查看实时或历史结果。
通信场景使用协议原因
常规任务拉取（如 Run Command、State Manager）长轮询（Long Polling）轻量、可靠，适合低频指令下发
交互式会话（Session Manager）WebSocket需要低延迟、双向实时通信
sequenceDiagram
    participant Agent
    participant SSM Service

    Agent->>SSM Service: GET /tasks (长轮询)
    Note right of SSM Service: 无任务，保持连接
    SSM Service-->>Agent: (30秒后超时，空响应)
    
    Agent->>SSM Service: GET /tasks (再次轮询)
    Note right of SSM Service: 此时有新命令
    SSM Service-->>Agent: 返回任务详情
    Agent->>SSM Service: POST /results (上报结果)

sequenceDiagram
    participant User
    participant SSM Service
    participant Agent

    User->>SSM Service: StartSession API
    SSM Service->>Agent: 通过长轮询通知“有会话请求”
    Agent->>SSM Service: 建立 WebSocket (wss://...)
    User->>SSM Service: 建立 WebSocket (wss://...)
    SSM Service->>SSM Service: 中继 stdin/stdout 数据
avatar
文章
阅读
粉丝