1. 课程导入与自动化运维全景

在数据中心规模持续扩张的今天，一台服务器从开箱到投入生产，往往要经历固件升级、BIOS 参数设置、RAID 配置、操作系统部署、驱动安装、带外管理配置等一系列动作。如果这些动作全部依靠人工逐台完成，不仅耗时，而且极易因为"手抖"造成配置漂移——同一批 50 台机器里，可能有三五台的启动模式、网卡绑定或固件版本与基线不一致，后续排查故障时会被这些差异反复拖累。Lenovo ThinkSystem 自动化运维要解决的核心问题，正是把这类"重复、标准、可描述"的操作从人工执行转变为可复现、可审计、可批量下发的工程流程。

自动化运维的价值定位

ThinkSystem 服务器本身提供了丰富的可编程接口，这是自动化得以落地的基础。带外层面有 XClarity Controller（XCC）提供的 REST API 与 Redfish 接口，可以在不开机、不依赖操作系统的情况下完成电源控制、固件更新、BIOS/UEFI 设置、虚拟介质挂载和硬件清单采集；带内层面则有 XClarity Administrator（LXCA）作为集中管理平台，配合 XClarity Integrator 与 XClarity Provisioning Manager（LXPM）完成批量部署与配置。把这些能力串起来，运维团队就能实现"一次定义、多次复用、批量执行"。

从收益角度看，自动化带来的价值可以拆成三层：第一层是效率，原本需要数小时的人工装机流程可以压缩到几十分钟甚至更短；第二层是一致性，所有机器严格按同一份配置基线生成，消除了人为差异；第三层是可追溯，每一次配置变更都有日志、有版本、有回滚路径，审计和故障复盘时不再靠回忆。对于动辄管理数百上千台服务器的团队，这三层价值叠加起来，直接决定了运维是"救火"还是"可控"。

典型场景与工具链概览

ThinkSystem 自动化运维的典型场景大致可以归为四类：新机批量上线、固件与驱动合规、配置基线与漂移修复、日常巡检与告警联动。不同场景对应的工具组合并不相同，理解它们之间的分工，是规划学习路径的前提。

下面这张图展示了从"待交付服务器"到"纳入生产运维"的完整工具链与数据流关系，可以帮助建立整体认知：

图中左侧是物理对象层，包括服务器本体、XCC 控制器、LXPM 引导引擎以及存储网络资源，它们是被操作的目标；中间是集中管理平台层，LXCA 负责纳管与策略下发，XClarity Integrator 负责与虚拟化平台和 Ansible 对接，XClarity Orchestrator 面向多站点编排，配置基线库则保存了标准化的 Server Profile 模板；右侧是自动化执行层，Ansible 剧本、Python+Redfish 脚本、LXCA CLI 以及 CI/CD 流水线是实际"动手"的工具；最右侧是结果与反馈，包括合规报告、固件清单、资产台账和告警事件，其中漂移修复会触发反馈回路，把不合规的机器重新拉回基线。

学习路径规划

面对这样一套工具链，初学者容易陷入"工具太多、不知从哪下手"的困境。建议按"先带外、后带内，先单机、后批量，先手动、后脚本"的顺序推进。

第一阶段聚焦 XCC 与 Redfish 基础。目标是能用 curl 或 Python 直接对单台服务器的 XCC 发起请求，完成登录鉴权、查询硬件清单、读取当前 BIOS 属性、控制电源状态。这个阶段的关键是理解 Redfish 的资源树结构——比如 /redfish/v1/Systems/1 代表系统资源，/redfish/v1/Systems/1/Bios 代表 BIOS 属性集合，/redfish/v1/Managers/1 代表管理控制器。下面是一段示例代码，展示如何用 Python 读取一台 ThinkSystem 服务器的 BIOS 启动模式（示例参数，实际使用时需替换 IP、用户名和密码）：

import requests

XCC_IP = "192.168.10.101"   # 示例地址
AUTH = ("USERID", "PASSW0RD")  # 示例凭据

# 关闭证书告警（实验环境示例，生产环境应启用校验）
requests.packages.urllib3.disable_warnings()

# 读取 BIOS 属性
resp = requests.get(
    f"https://{XCC_IP}/redfish/v1/Systems/1/Bios",
    auth=AUTH, verify=False, timeout=10
)
bios = resp.json()
print("当前启动模式:", bios["Attributes"].get("BootMode"))
print("超线程状态:", bios["Attributes"].get("HyperThreading"))

执行后如果返回 BootMode: UEFI、HyperThreading: Enabled，说明读取链路已经打通。这一步看似简单，却是后续所有批量操作的基础——只有单台能稳定读写，批量才有意义。

第二阶段进入 LXCA 集中管理。把若干台 XCC 纳管到 LXCA 后，可以练习批量固件合规检查、批量应用 Server Profile、批量重启与电源策略下发。这个阶段要重点理解"配置基线"的概念：基线不是某一台机器的当前状态，而是经过验证的标准配置集合，所有机器都应向它对齐。

第三阶段是脚本化与流水线化。把前两阶段验证过的操作封装成 Ansible Role 或 Python 模块，接入 Git 做版本管理，再通过 Jenkins 或 GitLab CI 触发执行。到这一步，运维动作就变成了"提交代码—自动执行—生成报告"的闭环。