38、现代DevOps管道的安全、测试与性能指标实践

最新推荐文章于 2026-07-18 09:14:00 发布

原创最新推荐文章于 2026-07-18 09:14:00 发布 · 117 阅读

0 GEO检测

现代DevOps实践：从理论到实战专栏收录该内容

44 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

现代DevOps管道的安全、测试与性能指标实践

1. 代码合并与生产部署

当在GitHub仓库中进行代码操作时，会触发GitHub Actions工作流。GitHub会生成一个拉取请求（Pull Request），将代码合并到生产（prod）分支，同时开发持续部署（Dev CD）工作流会按预期运行。以下是具体操作步骤：
1. 访问 https://github.com/<your_github_user>/mdo-environments/pulls 找到拉取请求。
2. 点击拉取请求，确认其准备好合并后，点击“Merge pull request”，此时更改将反映在prod分支上。
3. 访问 https://github.com/<your_user>/mdo-environments/actions ，会发现生产持续部署（Prod CD）工作流已被触发。该工作流会构建生产环境、部署应用程序并进行测试，且此集群启用了二进制授权。

为确认二进制授权正常工作，可进行如下检查：
1. 使用以下命令建立与生产集群的连接：

$ gcloud container clusters get-credentials \
mdo-cluster-prod --zone us-central1-a --project ${PROJECT_ID}

尝试使用nginx镜像部署一个Pod：

$ kubectl run nginx --image=nginx

此操作会失败，原因是指定了标签而不是sha256摘要。
3. 获取镜像摘要并设置为变量 DIGEST ：

$ DIGEST=$(docker pull nginx | grep Digest | awk {'print $2'})

使用摘要重新部署镜像：

$ kubectl run nginx --image=nginx@$DIGEST

这次部署仍会被拒绝，因为没有找到有效的签名证明，这证实了二进制授权正常工作，可防止部署未经认证的镜像，保障Kubernetes集群的安全。

2. 现代DevOps管道的安全和测试最佳实践

2.1 采用DevSecOps文化

在现代DevOps中，采用DevSecOps方法至关重要。要将安全融入组织文化，需促进开发、运营和安全团队之间的有效沟通与协作。员工应跨技能和提升技能，安全团队要学习编写代码和使用API，开发人员要理解安全并运用自动化。

2.2 建立访问控制

遵循最小权限原则（PoLP），只授予人员完成工作所需的权限。简化访问授予流程，减少不必要的权限申请。

2.3 实施左移策略

在软件开发的早期阶段就嵌入安全，安全专家要与开发人员密切合作，共同开发安全强化的设计和代码。

2.4 一致管理安全风险

接受不可避免的风险，制定标准操作程序（SOP）以应对攻击。在软件开发和基础设施管理的各个方面，如配置管理、访问控制、漏洞测试、代码审查和防火墙等，制定清晰易懂的安全策略和实践。

2.5 实施漏洞扫描

开源软件的使用日益广泛，但存在安全漏洞。漏洞扫描可发现第三方依赖中的漏洞，并在早期发出警报。

2.6 自动化安全

将安全嵌入CI/CD流程，通过代码分析、漏洞扫描、配置管理和基础设施扫描等自动化手段，只允许测试通过且安全的软件部署，降低软件开发和返工成本。

3. 现代测试方法的最佳实践

3.1 CI/CD管道内的测试自动化

全面自动化测试，涵盖单元测试、集成测试、功能测试、安全测试和性能测试等。创建隔离和可重现的测试环境，可使用容器化和虚拟化等方法。

3.2 有效管理测试数据

有效处理测试数据，确保其一致性和数据隐私。可利用数据生成工具创建相关数据集，处理敏感信息时考虑数据匿名化。

3.3 测试应用程序的各个方面

持续集成（CI） ：频繁合并代码并自动运行测试，确保代码库的稳定性。测试失败时及时处理。
端到端测试 ：使用自动化框架模拟真实用户交互，确保整个应用程序工作流按预期运行。
负载测试 ：评估应用程序在不同负载下的性能，了解其健壮性和容量。
可扩展性测试 ：确保系统能够处理增长，保障应用程序的长期健康。

3.4 实施混沌工程

通过受控实验引入混乱，评估系统的弹性，发现并解决潜在的系统弱点，使系统更可靠。

3.5 测试时监控和观察应用程序

设置强大的监控和可观测性工具，收集关键指标、日志和跟踪信息，全面了解应用程序的健康和性能。

3.6 生产环境中的有效测试

采用功能标志和金丝雀发布策略，在生产环境中安全地测试新功能。功能标志可在运行时启用或禁用特定功能，金丝雀发布将新功能逐步推送给小部分用户，同时进行持续监控，出现问题可及时回滚。

3.7 文档和知识共享

记录测试程序、测试用例和最佳实践，为团队成员提供参考，促进知识共享，提高团队的集体专业知识和问题解决能力。

4. 理解生产服务的关键性能指标（KPIs）

4.1 理解可靠性的重要性

软件开发和在生产环境中运行软件存在差异，许多在开发环境中未发现的问题会在生产环境中暴露。以零售银行应用程序为例，软件可靠性的重要性体现在以下几个方面：
| 重要性方面 | 具体描述 |
| ---- | ---- |
| 用户满意度 | 可靠的软件确保积极的用户体验，避免用户因软件故障而感到沮丧和失去信任。 |
| 商业声誉 | 软件故障会损害公司的声誉和品牌形象，导致客户流失。 |
| 财务影响 | 软件故障可能导致销售损失、客户支持费用增加，甚至法律责任。 |
| 竞争优势 | 可靠的软件能提供竞争优势，吸引和留住用户。 |
| 生产力和效率 | 可靠的软件有助于维持组织的生产力，减少资源浪费。 |
| 安全 | 可靠的软件通常更安全，可防止攻击者利用漏洞。 |
| 合规性 | 某些行业对软件可靠性有监管要求，不满足要求可能导致法律和财务处罚。 |
| 客户信任 | 软件可靠性是建立和维护客户信任的关键因素。 |
| 可维护性 | 可靠的软件更容易维护，减少因软件不可靠带来的修复和更新困难。 |
| 扩展和增长 | 随着软件使用量的增长，可靠性变得更加重要。 |

4.2 DevOps和SRE的转变

传统上，软件在生产环境中的运行和管理由运维（Ops）团队负责，开发（Dev）和Ops团队目标和优先级不同，常产生冲突。DevOps的出现改变了这种局面，谷歌提出的站点可靠性工程（SRE）体现了DevOps原则，鼓励共享所有权、使用共同工具和实践，从失败中学习以防止问题复发。理想的SRE团队成员应具备两个关键特征：对手动任务不感兴趣，寻求自动化机会；具备开发软件解决方案的技能，即使面对复杂挑战也能应对。SRE工作由具有强大软件专业知识的工程师承担，可减少对人工劳动的依赖。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(代码合并):::process --> B(触发GitHub Actions工作流):::process
    B --> C(生成拉取请求):::process
    C --> D(Dev CD工作流运行):::process
    D --> E(审查并合并代码到prod分支):::process
    E --> F(触发Prod CD工作流):::process
    F --> G(构建生产环境、部署应用、测试):::process
    G --> H(启用二进制授权):::process
    H --> I(确认二进制授权正常工作):::process

5. SLOs、SLAs和SLIs

在生产服务中，SLOs（服务级别目标）、SLAs（服务级别协议）和SLIs（服务级别指标）是衡量和管理服务可靠性的重要概念。
- SLIs ：是对服务性能的具体量化指标，例如响应时间、错误率等。比如，一个Web应用的SLI可以是平均响应时间小于1秒。
- SLOs ：基于SLIs设定的目标值，是服务提供商承诺要达到的服务水平。例如，规定Web应用的平均响应时间在95%的情况下小于1秒。
- SLAs ：是服务提供商与客户之间的正式协议，明确了服务的质量和可靠性标准，以及未达到标准时的赔偿措施。如果服务未达到SLOs，可能触发SLAs中的赔偿条款。

三者的关系可以用以下流程图表示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(SLIs):::process --> B(SLOs):::process
    B --> C(SLAs):::process

6. 错误预算

错误预算是指在一定时间内允许的服务故障或未达到SLOs的程度。它是一种平衡创新和可靠性的机制。当错误预算用完时，需要暂停新功能的开发和部署，优先解决可靠性问题。例如，设定一个月内服务的错误率不能超过5%，这5%就是错误预算。如果在半个月内错误率已经达到5%，则需要停止新功能开发，专注于修复问题。

错误预算的管理步骤如下：
1. 定义SLOs和对应的错误预算。
2. 实时监控SLIs，计算已使用的错误预算。
3. 根据错误预算的使用情况，调整开发和部署计划。

7. 恢复时间目标（RPO）和恢复点目标（RTO）

RPO ：是指在发生灾难或故障后，允许丢失的数据的最大时间范围。例如，RPO为1小时，表示在故障发生后，最多允许丢失1小时内的数据。
RTO ：是指从发生灾难或故障到系统恢复正常运行的最大时间。例如，RTO为2小时，表示系统必须在故障发生后的2小时内恢复正常。

RPO和RTO的设定取决于业务对数据丢失和系统停机的容忍度。不同的业务场景可能有不同的RPO和RTO要求，如下表所示：
| 业务场景 | RPO | RTO |
| ---- | ---- | ---- |
| 在线支付系统 | 几分钟 | 几十分钟 |
| 电子邮件服务 | 几小时 | 几小时 |
| 企业内部文档管理系统 | 一天 | 一天 |

8. 运行分布式应用程序在生产环境

分布式应用程序在生产环境中的运行面临着诸多挑战，如网络延迟、节点故障等。为了确保分布式应用程序的可靠性和性能，需要采取以下措施：
- 负载均衡 ：将请求均匀地分配到多个节点上，避免单个节点过载。
- 容错机制 ：当某个节点出现故障时，能够自动切换到其他正常节点，保证服务的连续性。
- 监控和日志记录 ：实时监控应用程序的性能和状态，记录详细的日志信息，以便及时发现和解决问题。
- 自动化部署和扩展 ：能够根据负载情况自动部署新的节点或扩展现有节点的资源。

以下是一个简单的分布式应用程序运行架构图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(客户端请求):::process --> B(负载均衡器):::process
    B --> C(节点1):::process
    B --> D(节点2):::process
    B --> E(节点3):::process
    C --> F(数据库):::process
    D --> F
    E --> F
    G(监控系统):::process --> C
    G --> D
    G --> E

通过理解和应用这些关键性能指标和策略，可以更好地管理生产环境中的应用程序，提高软件的可靠性和性能，为用户提供更优质的服务。同时，遵循现代DevOps管道的安全和测试最佳实践，能够确保整个开发和部署过程的安全性和高效性。