平台团队的 Schema 变更管理
平台团队的 Schema 变更管理
翻译自 Schema change management for platform teams
什么是平台工程
几个月前，The New Stack 上的一篇文章在我们的行业中引起了很大的波澜，声称“DevOps已死”，将被平台工程所取代。我有幸与阿里加（Ariga）顾问委员会成员之一、HashiCorp联合创始人兼首席技术官 Armon Dadgar 讨论了这个话题。
Armon 回忆说， DevOps 运动向软件行业提出了一个大胆的愿景：“如果我们能够将 Dev 和 Ops 功能融合到同一个人身上，形成一个超级工程师，早餐写后端应用程序，午餐配置构建系统和 CI 管道，晚餐解决数据库生产问题，则最终实现全面拥有权和责任。”
然而，在实践中事情更为复杂： “除了少数几家能够雇佣并留住他们的公司外，这些人实际上并不存在。” 这种认识催生了平台工程。 “我们需要开发人员能够自助式地负责其应用程序, 但是现代云原生架构的复杂性过于庞大。为了高效运作, 组织需要抽象化这些东西。”
我们看到随着对此复杂性反应不断增强, 平台团队正在各地创建。这些团队的任务是维护内部开发平台，作为管理云原生架构中应用程序复杂性的灵活抽象化。
平台团队的 Schema 变更管理
一个优秀的平台团队会将其开发者平台视为一种产品，并不断寻找可衡量的方法来提高所服务的工程组织的效率。
通常可以通过以下方式之一实现：
- 解决技术瓶颈或自动化手动工作，使缓慢的事情变得快速。
- 提供更简单的检索信息或提供声明性工作流程，使难做的事情变得容易。
- 防止CI期间人为错误，从而使风险较大的事情更加安全。
平台团队可以创造严格的技术杠杆的一个被忽视的领域是提供强大的 Schema 变更管理方案。 Schema 变更管理指支持应用程序数据模型和存储在数据库中方式演变的工具和流程集合。
过去，大多数应用程序由单个企业数据库组成，通常由企业供应商支持，服务于整体后端。这些是采用瀑布方法开发并由专业训练有素的 DBA 进行管理。今天，应用程序以微服务爆炸为特征。每个微服务都由自己的数据库（有时是多个数据库）支持，并由多个自治团队开发和维护，在处理其数据库时具有不同（甚至非常少）操作知识。
换句话说，尽管作为任何架构关键组件之一，但备份数据库运营方面在许多情况下都是事后考虑。组织可以轻易地花费数十万美元来确保开发人员能够访问可观测性数据，但当涉及到管理 schema 变更时，则期望开发人员了解他们所使用团队所使用数据库的所有复杂性。
不支持 schema 变更管理有什么影响？
经过对数十家公司的工程师进行采访，我们发现，在没有深思熟虑的 schema 变更管理策略的组织中，一些严重问题会反复出现：
- 数据库 schema 不兼容变更会打破数据库和应用程序后端之间的契约，导致停机时间。
- 数据库 schema 下游使用者（例如消费 CDC 日志的数据工程团队）经常感到惊讶。
- 表意外地被锁定以进行写入操作，导致应用程序停机 - 有时长达几个小时或几天。
- 开发人员使用根凭据连接到数据库以应用变更或解决问题。
- 部署因在生产数据上才发现的约束违规而失败了一半。
- 发生事故和停机是由于许多工程师不知道数据库行为。
- 简单重构成为需要高级工程领导计划和仔细执行的复杂项目，使其频率降低，并增加技术债务。
- 对数据库架构更改的挫败感（和恐惧）促进了反模式，例如将架构管理推向应用程序层有效地使用 SQL 数据库作为 NoSQL 存储等。
- 还有很多其他问题。
超越 schema 迁移工具
大多数现有的 schema 管理工具（通常称为 schema 迁移工具）是在一个非常不同的时代创建的。在 DevOps 运动开始之初，将所有 schema 变更描述为提交到源代码控制并由已知哪些已应用了这些变更的工具自动应用文件的想法是革命性的。
然而，正如我们上面提到过的，与这些工具构思时相比，今天软件构建方式发生了很大变化：
- 我们的开发方式 - 微服务带来了数据库数量和组织使用存储技术多样性方面爆炸般增长，使得许多组织无法拥有专业 DBA 编写或审查数据库 schema 变更。团队需要能够自主和自给自足以便持续取得进展。
- 我们的运作方式 - 过去可以接受将应用程序停机进行维护-您银行公司最后一名员工离开办公室和第二天第一位员工进入之间 DBA 有几个小时时间可以关闭系统、升级它并重新启动它。管理 24/7 提供流量的始终在线系统是不同寻常的。
- 谁来操作 - 在大多数情况下，团队会操作他们自己的数据库，在这种情况下负责该系统值班人员对于数据库运营方面通常只有非常基本的知识。
平台团队可以通过什么方式提高 schema 变更管理的开发效率？
因此，现代化的 schema 变更管理解决方案可以解决以下问题：
- 计划更改 - 当今的工具期望所有技术背景和专业水平的开发人员能够规划正确、安全和高效的数据库变更。鉴于开发人员必须处理各种技术范畴，这可能并不总是可行。因此，平台可以为开发人员提供自动化、声明性工作流程来规划变更（“用于数据库的 terraform plan ”）。理想情况下，该工作流应支持任何 ORM 或框架开发人员用于构建应用程序。
- 验证安全性 - 一旦变更离开了开发者的工作站并提交为 merge request ，则成为团队审查和批准变更正确性和安全性负责。现有工具在这个领域没有提供任何支持，完全依靠手动审核。平台可以为团队提供自动验证变更（“ schema 变更 CI ”），以在它们到达生产之前检测到风险变化。
- 部署修改 - 现有工具主要集中在描述和应用目标数据库上所需机制上。这是一个很好的开始，但部署机制很少单独使用了。平台需要找出如何以本地方式将这些工具集成到其持续交付管道中。此外，交付管道负责验证目标环境是否安全可部署，然后推出变更（“ schema 变更 CD ”）。
- 此外，在微服务架构中，管理和协调单个部署单元内各种微服务的 schema 迁移对于确保安全发布或从故障中恢复至关重要。
- 故障排除 - 不幸的是，schema 变更并不总是成功的。现有工具在帮助开发人员摆脱困境方面几乎没有提供任何支持。这通常需要工程师连接到数据库来诊断问题，并执行风险操作，例如手动编辑元数据表。当计划的变更失败或导致停机时，平台团队应考虑他们可以做什么来支持工程师。
- 漂移检测和 schema 监控 - 一旦变更成功推出，则对于团队能够检测系统预期状态与实际状态之间的差异非常有价值。由于技术问题或允许手动访问数据库等情况可能会导致 schema 漂移，并且可能会引起操作和合规性问题。平台团队应考虑如何为其团队提供信心，即其应用程序中没有模式漂移。