Kubernetes让部署变得简单，但没人提醒你数据库的问题。
内容提要
在Kubernetes环境中，“你构建，你运行”的DevOps模式对数据库运维不现实。开发者擅长构建软件，但数据库操作需专业运维。平台工程应通过集中控制平面自动化处理数据库的配置、补丁、备份和治理，减少开发者负担，避免因升级或故障导致停机。开发者应专注应用开发，而非数据库运维。
延伸解读
“你构建，你运行”在数据库上的局限
文章指出，DevOps的“你构建，你运行”原则在Kubernetes环境中对数据库运维并不现实。开发者擅长构建软件，但数据库运维需要专业知识和经验，如处理集群故障、升级和备份恢复。将数据库运维完全交给开发者，会导致他们偏离核心工作，降低效率。因此，该原则需要调整，通过自动化平台来承担复杂的运维任务，让开发者专注于应用开发。
数据库集群的隐性风险
文章强调，为了高可用性，数据库常以集群方式部署，如三节点Postgres集群。但集群升级和故障切换可能引发新问题，例如领导者选举失败导致双主，进而造成数据不一致甚至损坏。这类故障可能导致长时间停机，影响业务。因此，数据库运维需要专业知识和自动化工具来管理集群生命周期，降低风险。
专业数据库运维人才稀缺
文章提到，依赖招聘专业数据库运维人员来解决问题并不可行。美国劳工统计局预测，2024至2034年数据库管理员和架构师的岗位增长率仅为4%，且多数空缺来自人员更替。此外，不同数据库需要不同专家，且需建立多个值班表，随着业务增长，管理难度加大。因此，通过集中化平台自动化运维是更可持续的解决方案。
Q&A
为什么在Kubernetes环境中“你构建，你运行”的DevOps模式对数据库运维不现实？
因为开发者虽然擅长构建软件，但数据库运维需要专业的操作技能，如处理升级、故障恢复、备份等，这些与软件开发完全不同。在Kubernetes环境中，如果要求应用团队同时运维数据库，会给他们带来沉重负担，且容易导致停机或数据损坏。
在Kubernetes中部署Postgres、Redis等数据库后，常见的挑战有哪些？
挑战包括：需要持续进行补丁更新、监控、备份和恢复；升级数据库时可能遇到安全漏洞，需要仔细评估和准备；运行集群时，节点故障可能导致故障转移问题，甚至数据损坏；这些运维工作对开发者来说并非专长，容易导致应用开发受阻。
为什么说数据库升级是生命周期管理的一部分，而不是一次性设置？
因为数据库需要持续维护，例如发现安全漏洞后必须及时升级。升级过程可能涉及阅读变更日志、评估风险、执行多步骤操作，且集群升级需逐个节点进行，处理不当可能导致故障转移失败和数据不一致。因此，升级是持续的过程，需要自动化支持。
在Kubernetes中运行Postgres集群时，可能出现哪些故障转移问题？
当集群中的一个节点故障时，其他节点需要接管，但如果选举新主节点的过程失败，可能导致两个节点都认为自己是主节点，从而产生不一致的写入，甚至数据损坏。有时重启集群可以解决，但严重时可能导致数小时的停机。
为什么说通过招聘数据库专家来解决运维问题不可行？
因为数据库运维专家稀缺，美国劳工统计局预测2024至2034年数据库管理员和架构师仅增长4%，且多数为替代性岗位。此外，专家无法覆盖所有数据库类型，且需要轮班应对夜间问题，依赖个人专家存在风险，如生病、休假或离职。
平台工程如何帮助减轻开发者的数据库运维负担？
平台工程通过提供内部开发者平台，如a9s Hub，使开发者可以通过Kubernetes原生工作流请求数据库，而由集中控制平面处理配置、备份、补丁和治理。这样开发者无需深入数据库运维，只需在需要时请求服务，其余由自动化处理。
在数据库生命周期中，开发者真正需要参与的环节有哪些？
开发者只需在需要新数据库、获取凭据或在进行高风险发布前触发备份时参与。其他所有运维工作，如安全补丁、定期备份和恢复，都应由平台自动化处理。
集中控制平面在数据库治理方面有哪些优势？
集中控制平面可以统一管理多个数据库，清晰显示哪些需要补丁、哪些合规、哪些需要立即处理，避免团队手动协调。它支持本地环境和跨不同技术栈（如Kubernetes、VM、AWS服务），确保治理可见且可控。
