大多数产品团队都认为，负责基础设施的管理只是软件开发过程中的一个环节而已。我们当初也是这么想的。直到我们统计出究竟有多少工程时间被浪费在了运维工作上，才意识到这种观念其实代价是多么高昂。
在一次季度规划会议上，我们的一位工程师提出了一个之前没有人直接问过的问题：“我们实际花费在基础设施管理上的时间，与用于开发用户真正需要的功能的时间相比，各占多少？”
这并不是一个 rhetorical question（纯粹为了引发讨论的问题）。我们查阅了之前的工作记录、故障日志以及日程安排，试图诚实地回答这个问题。
我们是一个由7人组成的内部工具开发团队，隶属于一家规模更大的企业。我们的职责很明确：通过工作流程自动化、内部数据看板以及各系统之间的集成，帮助公司内的其他团队提高工作效率。
我们的亚马逊网络服务基础设施环境本身并没有什么问题。按照大多数标准来看，它都属于成熟的基础设施体系。ECS上的容器化服务、通过GitHub Actions实现的自动化部署、CloudWatch提供的监控功能，以及各环境中合理配置的IAM权限设置——这些都没有在任何架构审查中引发疑虑。
但这些因素所造成的代价，并不会体现在发票上。而是体现在我们的日程安排中，体现在我们频繁地切换工作内容，以及“基础设施维护工作”如何逐渐取代了我们真正应该负责的任务上。
最终，这次讨论促使我们开始评估并迁移至Sevalla这一平台作为服务提供的基础设施管理工具，以此来简化运维流程。整个迁移过程耗时三周，而其效果在一个月内就显现了出来。
在这篇文章中，我们将详细介绍迁移之前的AWS环境配置情况、迁移的具体步骤、迁移后各项指标的变化，以及我们在这一过程中所做出的权衡。
我们将会讨论的内容：
迁移之前
我们的AWS配置相当完善。我们并没有使用那些过于繁琐、依赖人工操作的系统。我们所拥有的包括：
-
用于容器编排的ECS
-
用于存储数据库的RDS
-
用于监控日志和各项指标的CloudWatch
-
通过GitHub Actions实现的CI/CD流程
-
在各个环境中统一管理的IAM角色
-
由一位资深工程师负责维护的CloudFormation模板
这样的配置运行效果良好，部署过程都是自动化的，系统也非常稳定。
问题并不在于这些系统出现了故障，而在于维持它们的正常运转所耗费的成本。
引发讨论的那个数字
在一次季度规划会议上，我们试图如实评估工程团队所花费的时间究竟都用在了哪里。
我们估计，整个团队每周大约有12到15个小时被用于那些与基础设施相关的工作，但这些工作并没有直接为内部用户创造价值。这些工作包括：
-
部署流程的维护和故障排查（约4小时/周）
-
对CloudWatch日志的分析以及警报设置的调整（约3小时/周）
-
IAM权限的管理与访问审核工作（约2小时/周）
-
基础设施组件的依赖关系更新及安全补丁应用（约2小时/周）
-
处理各种突发问题、环境状态的变化以及成本异常情况（约3到4小时/周）
以一名工程师的全职工作时间来计算，每周花费12到15个小时仅仅是为了维持系统的正常运行，而不是用于开发新的功能或项目。
对于一个已经积压了大量工作、根本无法在短时间内完成所有任务的团队来说，这样的成本投入确实难以被合理解释。
部署流程：所谓“合理自动化”究竟意味着什么
按照大多数标准来看，我们的部署流程已经相当完善了。当代码被推送到main分支后，GitHub Actions会自动触发构建过程，然后将生成的镜像上传到ECR，并更新ECS服务的相关配置。在理想情况下，从代码合并到最终部署完成，整个过程只需要大约12分钟的时间。
然而，“合理自动化”这个概念也有一些局限性。
只有其中一位工程师完全了解整个部署流程的细节。如果在部署过程中出现任何问题，比如任务定义不匹配、IAM权限错误，或者CloudFormation模板存在冲突，大多数团队成员要么需要等待这位工程师来解决问题，要么就要花费大量时间去阅读AWS的相关文档自行排查故障。
回滚操作也是手动进行的，并没有简单的一键回滚功能。要进行回滚，就必须先确定之前使用的镜像标签是什么，然后重新触发部署流程，再等待大约12分钟才能完成整个过程。在遇到紧急情况时，这12分钟的时间就显得格外重要了。
我们的测试环境与生产环境之间的配置一致性也很容易受到影响。要保持两者之间的同步，就需要定期进行检查和调整。实际上，配置出现偏差的情况比我们愿意承认的要多，而这种差异有时会导致生产环境中的系统行为与测试环境中的表现有所不同。
<新加入的团队成员无法自信地执行部署操作。让一名新工程师熟悉部署流程竟然花费了将近一整天的时间，而大多数新员工在数周内仍然不敢独立进行部署操作。虽然部署流程已经实现了自动化，但相关知识并没有同步得到普及。
迁移实际上涉及哪些内容
<我们花了大约三周的时间来完成迁移工作，采取的是逐步迁移的方式，而非一次性全部完成转换。
其中耗时最多的是将我们的环境变量配置及密钥管理机制从AWS Parameter Store迁移到Sevalla的系统中，这一过程大概花费了半天的时间。
CI/CD流程的迁移工作进行得相当顺利。我们用Sevalla提供的与Git集成在一起的部署系统替换了原有的ECS部署方案，GitHub也能直接访问我们的代码仓库。
数据库迁移是整个过程中最为谨慎的部分。我们在两周内同时运行旧版和新版的数据库，确认数据一致性后才更改DNS配置。最终没有出现数据丢失或系统停机的情况。
<整个团队在三周内总共花费了大约40个小时来完成这次迁移工作，其中大部分工作时间是由两名工程师完成的。
迁移之后发生了哪些变化
部署时间从约12分钟缩短到了约3分钟
<这一变化虽然不是最重要的，但却是最显而易见的。更快的部署速度意味着反馈周期也会变短：修复代码可以在几分钟内就应用到生产环境中并得到验证，而无需等待完整的构建流程完成。
<以一个典型的一周为例，如果每周需要进行8到10次部署操作，那么这样就能节省大约90分钟的等待时间。
任何工程师在第一天就可以自信地执行部署操作
<这一变化在实际运营中意义最为重大。部署流程变得清晰明了，而且有相应的界面进行指导，因此无需具备专业知识就能操作。新加入团队的工程师可以在第一天就独立完成自己的首次部署任务。
><过去由我们经验最丰富的AWS专家担任的“部署监管者”角色，如今已经不再存在了。
回滚操作从原本需要12分钟的手动流程缩短到了只需30秒
<在Sevalla系统中，每次部署都可以通过一键操作快速恢复到之前的版本。在迁移后的第一个月里，我们两次使用了这个功能：一次是为了处理一个很快被发现的错误，另一次则是为了在数据库迁移失败后立即进行恢复。
<这两次情况原本都需要花费数小时的手动干预，但现在却都在不到一分钟的时间内得到了解决。
基础设施维护时间减少到了每周大约2到3小时
我们不再维护IAM角色、CloudWatch警报、CloudFormation模板或ECS任务定义了。我们所负责的基础设施规模已经大幅缩减。
我们原本预计每周需要花费12到15个小时来维护基础设施，但现在这个时间减少到了大约2到3小时。目前的主要工作是监控应用程序的运行情况并审查构建日志。这样一来，每周原本用于维护基础设施的时间中约有10个小时被重新用来处理那些积压的工作。
在一个季度的时间里，这些被重新安排出来的时间总共约为130小时，相当于三个完整的工作周，最终都被用在了产品开发上。
回顾整个过程，我们不知不觉中已经变成了一支专注于平台建设的团队。这并非我们的初衷，而是因为每一个与基础设施相关的决策都会导致我们需要管理更多的基础设施资源。
无需使用任何额外工具，日志可见性得到了提升
有一个结果是我们没有预料到的：尽管我们在维护生产环境的日志系统上投入的资源较少，但其可见性却得到了改善。
在AWS平台上，要进行有意义的日志分析，就需要使用CloudWatch Insights进行查询、正确配置日志组，并且要知道该去哪里查找相关数据。这些操作原本都需要花费一定的精力来进行设置。
而在Sevalla平台上，构建日志、运行时日志以及部署历史记录都可以直接从控制面板中查看，无需进行任何额外的配置。当生产环境中出现问题的时候，从发现问题到查明原因所需的时间，从之前需要通过多个工具进行搜索才能找到答案，现在在大多数情况下已经缩短到了不到2分钟。
我们放弃了什么
出于诚实考虑，我们必须列出这些权衡因素。
首先，我们的基础设施管理灵活性降低了。如果我们需要定制网络拓扑结构、使用专门的计算资源或进行精细的存储配置，Sevalla平台是无法满足这些需求的。对于一支专注于内部工具开发的团队来说，这些需求目前并没有出现；不过，如果需要的话，这些功能也是可以实现的。
此外，一些与AWS原生系统集成的部分也需要重新进行开发。我们之前使用了一些Lambda函数，后来发现这些函数需要被重构为服务形式，这增加了一定的迁移难度，而这是我们事先没有预料到的。
真正的经验教训
这次迁移过程让我们意识到一个很容易被忽视的事实：对于一个产品开发团队来说，维护基础设施所付出的代价并不主要体现在云服务的使用费用上，而是体现在工程师们需要投入的时间和精力上。
对我们这个7人的团队来说，每周节省下来的10个小时意味着我们可以将更多时间投入到那些真正用户关心的工作中去。这种改进的效果是非常显著的，它显著提升了我们团队实际能够交付的产品质量。
这种效果并不是Sevalla平台所特有的。任何能够真正减轻运营负担的基础设施简化措施，都会产生类似的效果。
值得思考的问题不是你的团队“是否”有能力管理基础设施，而是管理基础设施是否真的是对你手中现有工程资源的最佳利用方式。
对于这样一个内部开发团队来说，其价值完全取决于他们最终交付出来的成果，而不是他们的部署方式；因此，对我们来说，答案显然是否定的。因此，