企业官网建设流程全解析

• 教程
• 文档
• DevOps

AWS Systems Manager（SSM）是 AWS 提供的统一运维管理服务，它把 Run Command、State Manager、Automation、Parameter Store、Patch Manager 等一组常用运维工具整合在一起，帮助 DevOps 工程师以"无跳板机、无 SSH"的方式集中管理云上与本地服务器。本文以 interview-questions/systems-manager.md 中的 20 道面试题为骨架，逐题展开讲解，并结合本仓库 aws-devops-zero-to-hero 中 CodeBuild、CloudFormation/Terraform 与 Lambda 等实际代码，印证 Parameter Store、Automation 等能力在真实 CI/CD 与运维场景中的用法。读完本文，你将能系统回答 Systems Manager 相关面试题，并理解如何把 SSM 接入既有交付流水线。

1. 什么是 AWS Systems Manager？

面试题：What is AWS Systems Manager？

AWS Systems Manager 是一项为 AWS 资源提供集中化管理的服务，核心价值在于：自动化运维任务、统一管理实例配置、提升整体运营效率。它不是一个单一工具，而是一个"运维工具箱"：

• 免去逐台 SSH 登录的繁琐流程；
• 以文档（Document）驱动的标准化方式执行命令与流程；
• 在同一控制台内完成补丁、配置、库存、合规、运维工单的全链路管理。

在 DevOps 语境下，SSM 让"基础设施的可重复、可审计运维"成为可能：同样的操作以同一份文档定义，在任何一台托管实例上执行结果一致，天然契合"以代码和配置驱动运维"的工程实践。

2. Systems Manager 的核心组件全景

面试题：What are some key components of AWS Systems Manager？

SSM 的主要组件包括：

理解这张组件表，是回答后续所有 SSM 问题的前提：面试官往往会从组件清单出发，逐个追问"用途 + 适用场景 + 与相邻服务的关系"。

3. Parameter Store：安全的配置数据存储

面试题：What is the purpose of AWS Systems Manager Parameter Store？

Parameter Store 是 SSM 提供的安全存储服务，用于存放密码、数据库连接字符串、API Key 等配置数据。它支持标准参数（String / StringList / SecureString）与分层命名（如/myapp/docker-credentials/username），并可通过 IAM 策略精确控制谁能读写某个参数。

本仓库 day-14/simple-python-app/buildspec.yml 就是一个非常典型的 Parameter Store 落地场景——CodeBuild 构建阶段通过parameter-store声明直接注入三个敏感参数：

version: 0.2 env: parameter-store: DOCKER_REGISTRY_USERNAME: /myapp/docker-credentials/username DOCKER_REGISTRY_PASSWORD: /myapp/docker-credentials/password DOCKER_REGISTRY_URL: /myapp/docker-registry/url

随后在 build 阶段，构建命令无需再硬编码任何凭据，直接使用注入的环境变量登录并推送镜像：

echo "$DOCKER_REGISTRY_PASSWORD" | docker login -u "$DOCKER_REGISTRY_USERNAME" --password-stdin "$DOCKER_REGISTRY_URL" docker build -t "$DOCKER_REGISTRY_URL/$DOCKER_REGISTRY_USERNAME/simple-python-flask-app:latest" . docker push "$DOCKER_REGISTRY_URL/$DOCKER_REGISTRY_USERNAME/simple-python-flask-app:latest"

这正是 Parameter Store 在 CI/CD 中的核心价值：敏感信息从代码仓库中剥离，集中托管在参数库中，由 IAM 控制访问，构建时按需注入。本仓库还配套了完整的 Flask 应用与部署脚本（见 day-14/simple-python-app/Dockerfile、scripts/start_container.sh），可作为端到端演示的参照。

4. Run Command：无需直连的远程命令执行

面试题：How can you use Run Command in AWS Systems Manager？

Run Command 允许你远程管理实例——在不建立 SSH/RDP 直接连接的前提下批量执行命令，典型场景包括软件安装与更新、批量文件操作、服务启停等。它依赖安装在目标机器上的 SSM Agent，配合实例的 IAM 角色（AmazonSSMManagedInstanceCore托管策略）即可工作。

Run Command 的特点：

• 通过SSM Documents（如AWS-RunShellScript）定义要执行的命令内容；
• 可指定单台或多台目标实例（Tag、实例 ID、资源组均可）；
• 支持执行结果收集与输出日志（可落 S3 / CloudWatch Logs）；
• 比传统批量工具更安全——无需开放 22 端口到公网。

在面试回答中，可以强调"无需 direct access"与"任务自动化"两个关键词，并补充 SSM Agent + IAM 角色这一前置条件。

5. State Manager：长期维护实例的期望状态

面试题：What is State Manager in AWS Systems Manager？What is the difference between Run Command and State Manager？

State Manager 帮助你定义并长期维护实例的一致性配置，确保实例持续符合你设定的"期望状态"（desired state）。典型用法：

• 确保某软件包始终安装/保持特定版本；
• 确保某配置文件始终存在且内容正确；
• 定期执行某个维护脚本（本质上是"带调度、按状态收敛的 Run Command"）。

与 Run Command 的区别在于：Run Command 是"一次性、即触即发"的；State Manager 是"持续、可重复、带状态校验"的。面试时可用"fire-and-forget vs. continuously enforce"来概括二者的差异。

6. Automation：文档驱动的工作流编排

面试题：How does Automation work in AWS Systems Manager？

Automation 用于创建常见运维与部署任务的自动化工作流，它通过**文档（Documents）**定义达成特定结果所需的步骤序列。每个 Automation 文档由若干步骤（step）组成，步骤可调用 AWS API（如重启实例、创建 AMI、修改安全组），支持输入参数、条件分支与异常处理。

例如在 DevOps 场景中，Automation 常被用来编排：

• 补丁管理流程；
• 应用部署与配置变更；
• 故障自动恢复（配合 CloudWatch 事件触发）。

本仓库 interview-questions/01-ADVANCED.md 也印证了这一点：Automation 通过自动化补丁管理、应用部署和配置变更，"减少人工干预与错误"，从而提升 DevOps 实践中的可重复性与一致性——这正是面试答题时可以引用的进阶视角。

Automation 还常与CloudWatch 事件 / EventBridge联动：当监控指标触发告警时，自动执行某个 Automation 文档完成自愈，形成"监控 → 告警 → 自动运维"的闭环。

7. Patch Manager：自动化补丁管理

面试题：What is Patch Manager in AWS Systems Manager？

Patch Manager 帮助你将打补丁（安装最新安全更新）的过程自动化，让实例持续保持最新、安全状态。它允许：

• 定义补丁基线（Patch Baseline），指定哪些补丁被批准/拒绝；
• 按需或按调度（配合 Maintenance Window）批量打补丁；
• 记录合规结果，输出已打/未打补丁的报告；
• 适用于 Windows 与 Linux 实例（包括 EC2 与本地服务器）。

在运维合规视角下，Patch Manager + Compliance 的组合可以回答"我们如何证明补丁已安装"这一审计问题。

8. Inventory：实例与应用元数据采集

面试题：How can you manage inventory using AWS Systems Manager？

Systems ManagerInventory收集实例与应用层面的元数据，帮助你跟踪变更、执行审计、维持合规。采集内容包括：

• 操作系统版本、CPU/内存等硬件信息；
• 已安装软件及应用列表；
• 网络配置、文件信息、Windows 补丁/服务状态等。

Inventory 数据可定期采集并存储，用于回答"某实例当前运行哪些应用、版本如何、配置是否漂移"这类审计问题，也是变更管理的基础数据来源。

9. Parameter Store 与 Secrets Manager 的区别

面试题：What is the difference between Systems Manager Parameter Store and Secrets Manager？

一句话记忆："配置用 Parameter Store，机密用 Secrets Manager"。但需注意二者并不互斥——低成本场景下 SecureString 参数也能承担机密存储，而需要自动轮换、跨账号共享的机密应优先选择 Secrets Manager。本仓库 README.md 的 Day 23 专题即围绕 Secrets Manager 展开（存储/检索秘密、集成应用、实现轮换策略），与本题形成对照学习素材。

10. 用 Systems Manager 自动化实例配置

面试题：How can you use AWS Systems Manager to automate instance configuration？

自动化实例配置的核心手段是State Manager + SSM Documents：

1. 编写 SSM Document（如AWS-ApplyAnsiblePlaybooks、AWS-RunShellScript或自定义文档）；
2. 用 State Manager 将文档绑定到目标实例，并设定调度；
3. 实例上的 SSM Agent 按调度执行文档，持续收敛到期望状态（安装软件、写入配置、保持合规）。

这与本仓库 day-24/userdata.sh 的**启动引导（UserData）**形成对比：UserData 是"实例首次启动时一次性执行的 shell 脚本"，而 State Manager 是"持续、可重复的配置收敛"。两者都可用于自动化实例配置，但生命周期不同——面试中区分"一次性引导 vs. 持续状态管理"是加分点。

11. Systems Manager Documents：自动化与命令的执行脚本

面试题：What are AWS Systems Manager documents？

Documents是预定义或自定义的脚本/步骤集，用于在 Systems Manager 中执行任务，可被Automation、Run Command 和 State Manager共同复用：

• Command 文档：如AWS-RunShellScript、AWS-RunPowerShellScript，定义在实例上执行的具体命令；
• Automation 文档：如AWS-UpdateLinuxAmi，定义跨服务编排步骤；
• Policy 文档：用于 State Manager 的状态收敛策略。

文档是 SSM 的"标准化单元"：把运维动作固化为文档后，任何人、任何时间执行，结果一致且可审计——这正是 SSM 强调工程化运维的根基。

12. Maintenance Windows：批量任务调度

面试题：How can you schedule automated tasks with AWS Systems Manager？

Maintenance Windows允许你定义在整批实例上执行任务的调度，比如：

• 每周日凌晨 2:00 为生产实例打补丁；
• 每月初批量重启实例或执行维护脚本；
• 与 Patch Manager、Run Command、Automation 组合使用。

它的价值在于把批量运维收敛到约定的低峰窗口，避免补丁/维护操作打乱业务。回答时建议补充：Maintenance Window 由"调度 + 目标实例 + 注册任务（Task）"三要素构成。

13. Distributor：软件包的打包与分发

面试题：What is the purpose of Distributor in AWS Systems Manager？

Distributor允许你将软件包打包并分发到实例上，简化软件部署管理：

• 以 ZIP 包 + JSON 清单（Manifest）定义软件包（安装脚本、校验、版本）；
• 通过 Distributor 发布到 Systems Manager 包目录；
• 配合 State Manager / Run Command 在目标实例上安装或更新；
• 支持版本管理与增量更新。

适合统一管理 Agent、运行时或内部工具链的版本分发。

14. Compliance：实例合规监控

面试题：How can you use AWS Systems Manager to manage compliance？

SSM 提供合规评估与监控能力：针对预定义或自定义策略，持续评估实例状态并输出合规结果。典型用法：

• 配合Patch Manager：报告实例补丁合规率；
• 配合State Manager：报告实例是否偏离期望状态；
• 配合Inventory：核对软件清单与审计要求。

合规结果可按实例、按基线查看，为"安全审计 + 变更追踪"提供证据链。

15. OpsCenter：运维事件集中处置

面试题：What is the OpsCenter feature in AWS Systems Manager？

OpsCenter提供一个集中平台来管理并解决运营问题：把来自 CloudWatch 告警、EventBridge 事件、配置变更等来源的运维任务与事件汇聚成OpsItem，支持：

• 集中查看与调查（关联上下文、资源、相关事件）；
• 执行自动化修复（绑定 Automation 文档一键处置）；
• 追踪处置状态与负责人，形成工单闭环。

它解决的是"告警散落在多个服务、缺乏统一处置入口"的痛点，是 SSM 面向事件驱动运维的一站式门户。

16. 与其他 AWS 服务的集成

面试题：How can you integrate AWS Systems Manager with other AWS services？

SSM 可与CloudWatch、Lambda、Step Functions等服务集成，实现更高级的自动化与编排：

• CloudWatch：指标告警触发 Automation 文档，实现自愈；
• EventBridge / CloudWatch Events：实例状态变化、定时事件触发 SSM 任务；
• Lambda：作为 Automation 步骤或事件目标，扩展自定义逻辑；
• Step Functions：编排跨多服务的长流程，SSM 文档可作为其中的执行步骤；
• CodeBuild / CodePipeline：通过 Parameter Store 注入构建凭据（见本仓库 day-14/simple-python-app/buildspec.yml），或在部署阶段调用 Automation 完成金丝雀/蓝绿验证；
• IAM：SSM 的所有访问最终由 IAM 策略裁决（详见 interview-questions/iam.md 中的策略评估逻辑）。

17. 管理本地（on-premises）资源

面试题：Can AWS Systems Manager be used with on-premises resources？

可以。只要在服务器上安装SSM Agent并完成注册（Activation），本地服务器即可与 EC2 一样被 Systems Manager 统一管理。这意味着：

• 一套工具、一套文档、一套审计，同时覆盖云端与本地；
• 本地实例同样可使用 Run Command、Patch Manager、Inventory 等能力；
• 通过 IAM 角色或临时 Activation 凭证建立身份信任。

这是"混合云统一运维"的常见答案要点。

18. 故障排查能力

面试题：How does AWS Systems Manager help with troubleshooting？

SSM 提供Run Command、Session Manager、Automation等远程手段，用于故障排查与维护：

• Run Command：批量收集日志、查询状态，无需逐个登录；
• Session Manager：交互式登录实例进行实时排查（详见下一题）；
• Automation：按预定义流程执行诊断/恢复步骤，如收集诊断包、重启服务。

配合 CloudWatch Logs 输出命令结果，可形成"远程执行 → 日志集中 → 分析定位"的排查闭环。

19. Session Manager：免 SSH 的交互式会话

面试题：What is the Session Manager feature in AWS Systems Manager？

Session Manager允许你与实例建立交互式会话，无需 SSH 或 RDP 开放端口，从而提升安全性与可控性：

• 通过 SSM Agent 与 AWS 控制面建立加密会话通道；
• 不要求实例暴露 22/3389 端口，减少攻击面；
• 会话操作可被审计（记录到 CloudTrail / S3 / CloudWatch Logs）；
• 支持 IAM 级权限控制"谁能登录哪台实例"；
• 可与堡垒机策略结合，替代传统跳板机。

在现代运维中，Session Manager 几乎已成为"无 SSH 运维"的最佳实践，也是面试高频考点。

20. 保护 Parameter Store 中的数据

面试题：How can you secure data stored in AWS Systems Manager Parameter Store？

保护 Parameter Store 中的数据主要靠两道防线：

1. IAM 策略控制访问：用 IAM 精细定义"谁可以读取/写入/列出哪些参数路径"。例如只给构建服务ssm:GetParameter权限且限定路径前缀/myapp/，即遵循最小权限原则（IAM 的显式 Deny 覆盖逻辑参见 interview-questions/iam.md）；
2. KMS 加密落盘：SecureString 类型参数使用KMS 密钥进行静态加密，可选择 AWS 托管密钥或自建 CMK，并对解密操作做 CloudTrail 审计。

进阶提示：Parameter Store 还支持跨账号/跨区域参数引用与参数策略（Parameter Policies）限制有效期，可根据面试深度选用。

仓库实战印证：SSM 在 aws-devops-zero-to-hero 中的落点

除上述 buildspec.yml 的 Parameter Store 集成外，本仓库还有几处与 SSM 相关的佐证，可加深理解：

• 部署钩子与自动化流程：day-14/simple-python-app/appspec.yml 中定义的应用生命周期钩子（ApplicationStop、AfterInstall）本质上与 SSM Automation / Run Command 的"标准化执行步骤"思路一致——把部署动作拆解为可审计、可复用的步骤序列；
• 实例元数据与引导脚本：day-24/userdata.sh 和 day-24/userdata1.sh 展示了实例如何通过169.254.169.254元数据服务获取自身信息——SSM Agent 同样依赖实例元数据/IMDS 获取角色凭据，理解这条链路有助于理解 SSM 的实例身份模型；
• 合规与审计上下文：day-25/lambda_function.py 展示了自定义合规评估的写法（put_evaluations上报COMPLIANT/NON_COMPLIANT），与 SSM Compliance 的评估模型同源，可作为"如何程序化上报合规状态"的参考实现；
• 面试题库体系：本仓库 interview-questions 目录下按服务组织了大量面试题（如 cloudwatch.md、cloudformation.md、code-deploy.md），Systems Manager 常与这些服务联动出题，建议配套复习。

面试应答要点速记

• 定位：SSM = AWS 资源集中管理 + 自动化 + 配置管理 + 运营效率提升；
• 组件九宫格：Run Command（即时命令）、State Manager（期望状态）、Automation（工作流）、Parameter Store（配置存储）、Patch Manager（补丁）、OpsCenter（事件处置）、Distributor（软件分发）、Inventory（元数据采集）、Compliance（合规评估）；
• 高频对比题：Parameter Store vs Secrets Manager（配置 vs 机密 / 轮换 / 成本）；Run Command vs State Manager（一次性 vs 持续）；SSM 文档 vs CloudFormation（运维执行 vs 资源编排）；
• 安全要点：IAM 最小权限 + KMS 加密 + Session Manager 免端口 + CloudTrail 审计；
• 落地场景：CI/CD 凭据注入（见本仓库 buildspec）、补丁/合规批量管理、混合云统一运维、事件驱动自愈。

这套"20 问"覆盖了 SSM 的组件、用法、对比、安全与集成五个维度，配合本仓库的代码实例理解后，无论是面试应答还是实际工程选型，都能给出有依据、可落地的答案。

• 教程
• 文档
• DevOps