只有一人知道如何发布
流程只存在于一名工程师的脑中。该员工一旦休假，全部发布工作都会停滞。
DevOps服务
发布软件而无需特意选择用户低峰时段
HiTechCloud 构建 CI/CD pipeline、基础设施即代码和监控系统，使开发团队能够实现每日多次部署 — 并在需要时于数分钟内快速回滚。我们的 DevOps 能力已获得 AWS DevOps Competency 认证认可。
- 已获认可的能力
- AWS DevOps Competency
- 范围
- CI/CD · IaC · Container · 监控
- 合作模式
- 搭建平台、协同配合或全托管运维
- Platform
- HiTechCloud · AWS · 本地基础设施
总览
DevOps 旨在减少手动操作，而非采购更多工具
在我们接触的大多数企业中，发布流程仍有至少一个手动步骤：将文件复制到服务器、运行数据库更新命令、修改一行配置。正是这些步骤导致发布必须等到深夜，并且让任何人都未敢在周五改动系统。
我们的工作是将这些手动步骤逐一转化为代码：基础设施可从代码仓库中重建，发布流程通过 pipeline 自动化运行，且每一次变更都会完整记录操作人、操作时间及具体变更内容。
结果必须可衡量。我们跟踪四项常用指标——发布频率、从 commit 到生产环境的前置时间、发布错误率以及恢复时间——并进行前后对比，而非凭主观感受得出结论。
常见问题
发布流程正在阻碍开发团队的迹象
测试环境与生产环境存在差异
代码在测试环境中运行良好但在生产环境中出现错误，因为这两个环境是在不同时间手动搭建的。
回滚耗时数小时
当发布版本出现错误时，恢复工作必须手动执行，有时甚至需要从备份副本中恢复。
无法定位系统故障点
缺乏集中式日志与监控指标，导致每次发生故障都要逐台登录服务器排查原因。
服务
部署范围
Pipeline CI/CD
从 commit 到生产环境的自动化：构建、运行测试、安全扫描、审批及按环境逐步部署。
基础设施即代码
使用 Terraform 或同类工具定义全部基础设施，以便在短时间内从代码仓库重新构建新环境。
container 与编排
使用 Docker 打包应用，部署在 Kubernetes 或托管 container 服务上，并配置资源策略与自动扩缩容。
监控与集中日志
统一收集指标、log 和请求追踪，构建监控看板，并根据业务实际意义设置阈值告警。
流程内置安全
依赖项与 container 镜像扫描、集中式机密管理、基于角色的权限控制，并对所有部署操作进行日志记录。
交付内部团队
培训并指导企业的技术团队，以便在项目结束后自主运维该平台。
如何开始
选择一项服务，切实做好，再行推广
我们不会从一开始就为整个系统搭建平台。我们会选择一个服务作为样本，完整运行新流程，随后再将该模式推广至其余部分。
- 选择一项变更频率高但风险适中的服务。
- 为该特定服务构建 pipeline 和基础设施即代码。
- 衡量应用前后的四项发布指标。
- 标准化为可复用模板，供下一步服务使用。
流程
DevOps 项目的运作流程
-
01
现状评估
审查发布流程、环境及在用工具，并测算当前指标作为对比基准。
-
02
平台设计
选择适配现有团队与基础设施的工具，设计环境模型、权限及审批流程。
-
03
试点部署
为单个服务构建 pipeline 和基础设施即代码，实际运行并微调直至稳定。
-
04
规模化推广
将模板应用于其余服务，并为各部分补充监控和文档。
-
05
知识转移
培训内部团队，交接运维文档，并统一项目后期的支持模式。
部署方式
逐步实现自动化，每一步均可回滚
不一次性变更全部流程。每个自动化步骤均与原有模式并行运行，直至团队建立信任。
- 在 pipeline 稳定运行之前，原有的发布方式保持不变。
- 所有基础设施变更均保存在代码仓库中，历史记录可追溯。
- 生产环境部署权限与修改pipeline的权限相互分离。
技术
常用工具
工具链根据企业团队现有的基础设施与技能进行选择，不强加固定的技术栈。
CI/CD
- GitLab CI
- GitHub Actions
- Jenkins
- Argo CD
基础设施即代码
- Terraform
- Ansible
- CloudFormation
- Packer
Container
- Docker
- Kubernetes
- Helm
- Harbor
监控与日志
- Prometheus
- Grafana
- Loki
- Elastic Stack
- CloudWatch
客户
本服务适用对象
开发团队手动发布
- 发布新版本需要依赖单人凭记忆操作。
- 每次发布都必须选择用户较少的时段。
- 出现错误时回滚耗时数小时且存在不确定性。
拥有多个异构环境的企业
- 测试环境与实际环境在不同时间节点通过手动搭建。
- 为新项目搭建环境需要耗费数天。
- 配置分散各处，未保存在代码仓库中。
运维团队希望自主开展工作但缺乏带头人
- 拥有工程师，但从未搭建过完整的 pipeline。
- 需要可复用的模板，而非为每个服务从零开始重新构建。
- 希望在项目结束后完成交接以实现自主运维。
常见问题
常见问题
我们团队只有几位开发者，DevOps 会不会负担过重？
并非必须。对于小型团队，合理的范围通常是自动化 pipeline 和基础设施即代码，尚不需要 Kubernetes。我们根据实际规模推荐契合的方案，而非盲目套用全套架构。
必须使用 Kubernetes 吗？
否。仅当服务数量和伸缩需求足够大时，Kubernetes 才值得采用。许多系统在虚拟机和托管 container 服务上运行表现更佳，且运维成本要低得多。
HiTechCloud是实施后交接还是长期运维？
两种模式均支持。部分企业希望由我们搭建平台并培训内部团队接管；另一些企业则通过长期服务合同将运维完全交付给我们。
正在运行的系统是否需要停机部署？
不会。pipeline和基础设施即代码在独立环境中并行构建，仅在稳定运行并通过验收后才正式切换使用。
评估您当前的发布流程
联系 HiTechCloud 审查发布流程，指出仍需人工操作的环节，并根据团队规模提供适宜的自动化范围建议。
