22、云平台部署与运维全解析

云平台部署与运维全解析

1. 容器镜像下载与构建替换

在构建过程中，可使用如下代码下载并验证 img 工具：

# Download and check the sha256sum.
RUN curl -fSL "https://github.com/genuinetools/img/releases/download/v0.4.7/img-linux-amd64" -o "/usr/local/bin/img" \
    && echo "${IMG_SHA256}  /usr/local/bin/img" | sha256sum -c  - \
    && chmod a+x "/usr/local/bin/img"
RUN echo "img installed!"

之后，构建过程中原本的 docker build 和 docker push 可替换为 img build 和 img push ，这样能在集群内以隔离方式构建镜像。

2. 构建组件的流转

平台的环境结构包含集成环境、用户验收环境、预发布环境和生产环境。当集成测试完成后，容器会被标记为准备进入流水线，更新后的容器会部署到相应环境，随着测试推进和审批通过，更改会无缝流转到最终环境。

3. 持续交付的选择

Gamecorp 的工程管理团队倾向于有控制的发布，更关注成功发布而非每日多次可能不稳定的发布。Azure DevOps Services Release Management 提供了预部署和后部署审批以及发布门控等功能。

4. 发布门控的使用

Azure DevOps Services 的发布门控可在每个环境的预部署或后部署阶段进行程序化评估，有以下四种类型：
| 类型 | 说明 |
| ---- | ---- |
| Azure Functions | 可直接调用 Azure 函数 |
| REST API call | 可直接调用 REST API |
| Azure Monitor | 可监控应用服务、虚拟机、存储账户或应用程序洞察 |
| Work item query | 可使用工作项查询确定是否有与部署相关的未解决问题 |

每个发布门控都需定义成功判定条件，可设置运行间隔和超时时间，还可在不同阶段获取审批。一般策略是在成功通过门控后要求审批，以打造更注重质量的流水线。

5. 审批的利用

部署审批可在部署前后插入到发布定义中。预部署审批可让团队或个人知晓发布已在队列中，后部署审批可作为审计记录，表明更改按计划进行，发布可进入下一环境。为便于使用组进行审批，创建了以下四个组：
- Cardstock Integration Approvers
- Cardstock UAT Approvers
- Cardstock Staging Approvers
- Cardstock Production Approvers

跨职能团队成员可加入这些组，并在发布定义的每个环境中分配审批插槽。

6. 保持定义简洁

Azure DevOps Services 的 UI 配置灵活，但为避免定义过于复杂，对于平台的容器部署，使用通用任务进行变量替换和 Kubernetes 部署，由工件和变量驱动这些任务更合适。

7. 发布流水线的创建

以下是创建发布流水线的具体步骤：
1. 选择工件类型 ：选择 Azure Container Registry 作为工件类型，为应用的每个部分添加指向 gamecorp ACR 实例的工件源，最终得到五个工件源：Cardstock 仓库（Git）、交易、消息传递、库存和前端（UI）。
2. 添加环境 ：使用“+ Add”选项在环境部分添加新环境，将第一个环境命名为“Integration”。
3. 定义任务 ：点击环境名称下方的链接打开环境编辑器，创建新的代理阶段，添加 Replace Tokens 任务（将“.config”扩展名改为“.yaml”）和 Kubernetes 任务（使用 kubectl apply 命令更新目标集群中的部署）。
4. 配置集群和文件 ：填写目标集群和配置文件的详细信息，勾选“Use configuration files”框，浏览 Cardstock 仓库的工件源选择部署配置文件。
5. 克隆环境 ：通过克隆“Integration”环境创建“UAT”、“Staging”和“Production”环境。
6. 设置审批 ：点击环境右侧的人员图标添加审批者，为每个环境选择相应的审批组。
7. 调整集群设置 ：点击每个阶段/任务链接，调整 Kubernetes 集群设置以指向相应环境的集群。
8. 创建变量组 ：使用 Key Vault 存储非生产和生产密钥，创建“Dev Secrets”和“Prod Secrets”变量组，并将其链接到发布定义，为不同环境分配不同的变量组。

graph LR
    A[选择工件类型] --> B[添加环境]
    B --> C[定义任务]
    C --> D[配置集群和文件]
    D --> E[克隆环境]
    E --> F[设置审批]
    F --> G[调整集群设置]
    G --> H[创建变量组]

最后，完成设置并保存定义，通知团队进行审查和测试。

8. 运维与站点可靠性

在完成流水线搭建和测试后，需关注生产阶段的运维和站点可靠性。

9. 运维模型修订

回顾早期的运维模型初稿，发现存在显著差距需要填补。明确角色和职责对于流程顺利运行至关重要，将新云平台的功能与这些角色进行映射，有助于缩小影响范围。之后要建立并自动化运营流程，站点可靠性团队的关注点与运营人员有所不同。

10. 角色与职责

组织内的核心技术和安全角色及属性如下：
| 角色 | 属性 |
| ---- | ---- |
| Engineer | 使用自动化构建和发布机制；在代码中使用 APM/遥测捕获；理解网络；具备不同级别技能；理解容错与故障处理及相关设计模式；了解基本安全要求 |
| Architect | 理解不同云技术对应用性能的影响；掌握不同数据持久化技术和用例；了解不同消息传递模式和用例；熟悉一般云设计模式和用例；具备中级到高级安全要求知识 |
| Manager | 理解不同云技术对交付时间表的影响；了解产品/平台的业务、技术和安全要求 |
| Compliance Officer | 了解监管和合规要求及在云环境中实施控制的方法；了解云环境中的认证和相关控制 |
| Analyst | 了解业务、技术或安全要求及其对已实施平台设计的适用性 |
| Operator | 了解业务、技术或安全程序及相关实施流程 |

11. 能力评估与角色映射

按领域详细列出与云优先工程相关的能力，从业务领域开始。业务领域的重要能力、关键角色和关键功能如下：
| 能力 | 关键角色 | 关键功能 |
| ---- | ---- | ---- |
| 风险管理与补救 | 工程管理、业务运营管理、IT 运营管理、站点可靠性工程师、DevOps 工程师、数据库管理员 | 使用最佳实践和标准构建解决方案以确保合规；监控平台内的所有操作；确保内部用户遵守最高诚信和合规标准 |
| 采购 | 应付账款、企业采购、财务、云项目管理 | 执行合同或采购订单以确保技术和服务的优惠定价；确保使用供应商管理规定的批准供应商 |
| 平台许可与治理 | 云项目管理、企业采购、企业 IT 运营 | 协商优惠折扣和服务费率；确保所有技术、软件和服务的许可合规 |
| 供应商管理 | 云项目管理、企业 IT 运营 | 与首选服务供应商建立关系；维护联系和协商以确保最佳使用；确保供应商提供的服务对公司持续有重大益处 |

graph LR
    A[业务领域] --> B[风险管理与补救]
    A --> C[采购]
    A --> D[平台许可与治理]
    A --> E[供应商管理]

通过明确这些角色和能力，能更好地应对平台变化、合规问题或故障，确保平台的稳定运行。

云平台部署与运维全解析

12. 运营流程的自动化

在明确了角色、职责以及能力与角色的映射后，接下来的关键步骤是将运营流程自动化。自动化不仅能提高效率，还能减少人为错误，确保流程的一致性和可靠性。

对于不同的业务能力，可采取以下自动化策略：
- 风险管理与补救 ：可以利用 Azure Monitor 等工具，设置自动化的监控规则，当平台出现潜在风险时，自动触发相应的 Azure Functions 进行风险评估和初步处理。例如，当某个应用服务的性能指标超过阈值时，自动调用 Azure Function 发送警报并尝试进行优化。
- 采购 ：通过编写脚本或使用自动化工具，实现采购流程的自动化。例如，当库存低于某个阈值时，自动生成采购订单并发送给供应商。
- 平台许可与治理 ：使用自动化脚本定期检查所有技术、软件和服务的许可合规情况，当发现违规时，自动通知相关人员进行处理。
- 供应商管理 ：可以建立自动化的供应商评估系统，定期收集供应商的服务数据，自动生成评估报告，为供应商的选择和管理提供依据。

13. 站点可靠性团队的关注点

站点可靠性团队的主要目标是确保平台的高可用性和稳定性。他们的关注点与运营人员有所不同，主要集中在以下几个方面：
- 性能监控 ：使用 Azure Monitor 等工具，实时监控平台的性能指标，如响应时间、吞吐量、错误率等。当发现性能问题时，及时进行排查和优化。
- 故障处理 ：建立完善的故障处理流程，当平台出现故障时，能够快速响应并解决问题。例如，设置故障自动恢复机制，当某个服务出现故障时，自动切换到备用服务。
- 容量规划 ：根据平台的历史数据和业务发展趋势，进行容量规划，确保平台能够满足未来的业务需求。例如，预测未来一段时间内的用户数量和流量，提前调整服务器资源。
- 安全审计 ：定期进行安全审计，检查平台的安全漏洞和合规情况。例如，使用漏洞扫描工具定期扫描平台，发现漏洞及时修复。

14. 持续改进

云平台的部署和运维是一个持续改进的过程。为了不断提高平台的性能和可靠性，需要建立持续改进的机制。具体可以从以下几个方面入手：
- 收集反馈 ：定期收集用户、运营人员和站点可靠性团队的反馈，了解他们对平台的满意度和改进建议。
- 数据分析 ：对平台的运行数据进行分析，找出存在的问题和潜在的风险。例如，分析用户的行为数据，了解用户的需求和痛点。
- 制定改进计划 ：根据反馈和数据分析的结果，制定改进计划，并明确责任人和时间节点。
- 实施改进措施 ：按照改进计划，实施相应的改进措施，并对改进效果进行评估。

以下是持续改进的流程图：

graph LR
    A[收集反馈] --> B[数据分析]
    B --> C[制定改进计划]
    C --> D[实施改进措施]
    D --> E[评估改进效果]
    E --> A

15. 总结

通过以上的步骤和策略，我们可以建立一个高效、稳定的云平台部署和运维体系。从容器镜像的下载与构建，到发布流水线的创建，再到运维模型的修订和持续改进，每个环节都相互关联，共同确保平台的顺利运行。

在这个过程中，我们需要明确各个角色的职责，充分利用 Azure DevOps Services 等工具提供的功能，如发布门控、审批机制等，来保证发布的质量和安全性。同时，要注重运营流程的自动化和持续改进，不断提高平台的性能和可靠性。

以下是整个云平台部署与运维的关键步骤总结：
| 步骤 | 内容 |
| ---- | ---- |
| 容器镜像处理 | 下载并验证 img 工具，替换 docker 命令进行镜像构建 |
| 构建组件流转 | 明确平台环境结构，完成容器在不同环境的流转 |
| 持续交付选择 | 选择合适的交付方式，利用 Azure DevOps Services 功能 |
| 发布门控设置 | 使用四种类型的发布门控进行程序化评估 |
| 审批利用 | 在部署前后插入审批机制，创建审批组 |
| 定义简洁化 | 使用通用任务进行容器部署 |
| 发布流水线创建 | 按步骤创建发布流水线，包括选择工件、添加环境、定义任务等 |
| 运维模型修订 | 明确角色和职责，映射能力与角色 |
| 能力评估与映射 | 按领域评估能力并进行角色映射 |
| 运营流程自动化 | 对不同业务能力实现自动化 |
| 站点可靠性关注 | 关注性能监控、故障处理、容量规划和安全审计 |
| 持续改进 | 建立持续改进机制，不断优化平台 |

通过遵循这些步骤和策略，我们可以更好地应对云平台部署和运维过程中的各种挑战，为业务的发展提供有力支持。