DBA，不再是圣职

已发表: 2017-03-07

注意：这篇工程文章由我们的 DBA Silvia Botros 撰写，最初于 2016 年 12 月出现在 Sysadvent 博客上。

公司多年来一直拥有并需要数据库管理员。数据是企业最重要的资产之一。这意味着许多企业一旦发展到必须能够快速扩展的地步，就需要有人来确保资产得到妥善管理、性能满足产品需求，并且可以在发生灾难时进行恢复。

在传统意义上，DBA 的工作意味着她是唯一有权访问托管数据的服务器的人，是为新特性创建新数据库集群的人，是设计新模式的人，也是唯一在生产环境中发生与数据库相关的任何问题时联系的人。

由于 DBA 传统上具有如此独特的角色，因此他们的时间非常宝贵，因此当日常任务不堪重负时，就很难从全局考虑。在 DBA 领域，通常会使用 bash 之类的脆弱工具来执行各种操作任务。需要从干净的操作系统安装中进行新的数据库设置？获取、验证或恢复备份？轮换分区或陈旧数据？当您最常用的工具是 bash 脚本时，一切看起来都像钉子。我相信很多读者都在准备推文来告诉我 bash 有多么强大，但请在评估我的推理之后再发表评论。

这一切听起来像你作为 DBA 的工作描述吗？职位描述是否详细讨论了升级服务器、创建和测试备份以及监控？大多数典型的 DBA 职位发布都会确保您必须配置和设置“多个”数据库服务器（因为期望 DBA 手工制作它们），并使用（手工制作的）脚本自动执行数据库管理任务。

对于成长中、快节奏的组织中通常由一个人组成的团队来说，这真的是一种可扩展的方法吗？

我在这里争辩说，您的工作不是执行和管理备份、创建和管理数据库或优化查询。您将在您的工作范围内完成所有这些事情，但主要目标是使您的业务数据可访问和可扩展。这不仅是为了让企业运行当前的产品，而且是为了构建新功能并为客户提供价值。

为什么

你可能想问，我为什么要这样做？传统上继续执行 DBA 角色有一个论点：工作安全，对吗？如今，许多技术组织都在执行以下一项或多项操作：

他们由许多较小的团队组成
它们通过创建许多微服务来代替一个或几个更大的服务来提供功能
他们采用敏捷方法来加速功能的交付
他们将运营和工程结合在一个领导下
他们在设计过程中尽早将运营工程师与开发人员一起嵌入
运营中的 DBA 孤岛意味着运营团队在自己的堆栈中帮助调试生产问题的能力较低，有时在没有帮助的情况下无法响应和修复问题，而且坦率地说，如果他们需要与工程团队进行更密切和更早的合作，则更不可信不要实践他们在 Tech Ops 中宣扬的内容。

那么可以做些什么来打破这个孤岛，让其他人更容易调试，帮助扩展数据库层，让工程师能够设计可扩展的服务呢？大多数崭露头角的商店最多只有一名内部 DBA。一个 DBA 能否“出席”所有设计会议，批准每一次架构更改，并随时待命应对庞大且不断增长的数据库足迹？

DBA 不再是守门人或魔术师。 DBA 可以而且应该成为组织中工程师的知识和专业知识的来源。她不仅应该帮助交付团队交付功能，还应该交付可扩展的产品，让他们不必担心数据库。但是，DBA 如何在管理数据层的日常工作中实现这一目标呢？作为 DBA，您可以通过多种方式让自己变得卓越。

配置管理

这是一个非常重要的。 DBA 倾向于使用 bash 等老式工具来设置数据库。我之前提到过这一点，我并不反对使用 bash 本身。实际上，我经常使用它。但它不是集群设置的正确工具。特别是如果其余的操作不使用 Bash 来管理架构的其余部分。确实，运维工程师也知道 Bash，但是如果他们使用 Chef 或 Puppet 之类的工具来管理基础架构的其余部分，并且数据库主要由 DBA 编写的手工脚本来管理，那么你就是在给他们提供一个障碍在需要紧急更改时提供帮助。

更重要的是，帮助工程团队自助服务并拥有他们为新功能“foo”所需的新集群的创建变得更加困难。你成为完成工作的“阻碍者”。熟悉贵公司的配置管理也是一个双向的好处。随着您熟悉基础架构的管理方式，您将了解团队的标准，更加熟悉堆栈，并能够就最终影响产品规模的变更进行协作。

将工程组织的产品和基础设施作为一个整体进行调整的 DBA 是非常宝贵的。

操作手册

从技术上讲，这是您必须编写的文档的一个子集，但根据我的经验，这证明它更有用，我觉得必须单独指出它。当我说运行手册时，我特别指的是为非 DBA 的受众编写的文档。作为 DBA，我们可能会遇到很多生产 DB 问题，这些问题对我们来说很容易调试和解决。我们往往低估了肌肉记忆，我们陷入了“只给我发送页面”的模式，我们“照顾好事情”。

如果您的运营团队像我的一样，您是唯一的 DBA，则可能意味着团队中的其他人是 DB 相关事件页面时的第一道防线。一些关于如何进行初始调试和数据收集的简单文档可以大大帮助运营团队的其他成员熟悉数据库层并更熟悉我们如何监控和调试它。即使该事件仍然导致分页 DBA，缓慢但肯定地，运行手册成为每个人添加所学知识的地方。

此外，我将指向相关 Runbook 部分的链接（使用锚点！）添加到转到寻呼机的页面描述中。这对于凌晨 3 点被数据库主机寻呼以找到开始的地方的人非常有帮助。这些东西可能看起来很小，但根据我的经验，它们在为我的运营团队在必要时在数据库层工作时打破了心理障碍方面已经走了很长一段路。

作为个人喜好，我将这些作为降价文档写在我的厨师食谱存储库中。这无缝地融入了拉取请求、审查和合并模式，并成为数据库食谱模式不可或缺的一部分。随着工程团队开始创建自己的，运行手册成为一个熟悉的模板，因为新的数据库集群在各地涌现。

能见度

我们喜欢我们的终端屏幕。我们爱他们。 MySQL 领域最流行的工具仍然是直接存在于 db 主机上的终端工具，需要事先了解它们以及如何使用它们。我说的是innotop 和MySQL shell 之类的东西。这些很好并且仍然有用，但它们是为 DBA 创建的。如果您不想成为诸如“现在是否存在复制延迟？”之类的问题的看门人。您需要有更好的工具来让所有团队成员现在和历史上的任何集群运行状况都可用且易于消化。我在这个领域有几个例子：

编排器

我们使用只读副本将负载从主服务器分散开，这意味着一旦延迟达到某个阈值，它就会成为客户支持事件。让公司中的任何人在任何给定时间更容易了解是否有任何集群出现延迟、该集群中的服务器是什么以及是否有任何主机出现故障，这一点很重要。在这方面，Orchestrator 是一个很棒的工具，因为它使集群及其运行状况可视化只需一个浏览器窗口即可。

格拉法纳/石墨

数据库层的指标需要与基础设施其余部分的指标位于同一位置。对于团队来说，能够将这些指标并列并列是很重要的。有一种简单的方法可以查看任何数据库集群的历史指标，这一点很重要。虽然您可能对 cacti 或 munin 或您多年来编写的手工模板有个人偏好，但如果您用于调查问题的指标与其他基础设施指标不在同一个位置，则它会设置障碍其他忙碌的工程师——他们将不太愿意使用您的工具而不是其他地方正在使用的工具。 Graphite 在现代基础设施团队中被广泛用于获取指标，而 Grafana 是一个广泛使用的用于指标和分析的仪表板前端。

查询性能

我们使用 VividCortex 来跟踪我们在关键集群上的查询，虽然本文不打算成为付费服务的广告，但我会说您需要能够检查部署和代码更改对运行查询的影响和查询性能不需要特殊访问日志并手动处理它们的东西。如果 VividCortex 不可能（尽管说真的，它们太棒了！），还有其他产品和开源工具甚至可以捕获缓慢的日志并将其放在易于阅读的网页中供非 DBA 检查并查看他们的代码的效果。这里重要的一点是，如果您提供查看数据的方法，工程师将使用这些数据并尽最大努力保持工作效率。但让访问可用而不是特殊的 DBA 技巧是您工作的一部分。

对抗寻呼机疲劳

许多组织没有将数据库层扩展作为其堆栈设计中的一项非常早期的必要条件——而且他们不应该这样做。在公司的早期，如果还没有人使用 API，您不应该担心如何限制 API 调用。但考虑几年后的情况是合适的，当产品获得关注时，少数客户访问几千行表的 API 调用现在是数百万行表，以及几个客户已经构建了 cron 作业，每天早上 6 点在您的时区淹没该 API。

更改任何产品的应用程序层以保护基础设施都需要做大量工作，在此期间，允许虚假的数据库活动导致寻呼机疲劳对您和运营组织的其他成员都是一个很大的危险。熟悉诸如 pt-kill 之类的工具，这些工具可以轻松使用，以防止数据库主机因计划外卷而出现重大停机。使该工具的使用为人所知，并将操作及其效果传达给持股工程团队，但尝试从您无法直接改变的事情中吸收痛苦是不健康的，并且最终对帮助工程团队无益' 学习如何应对成长的痛苦。

与运营团队的其他成员相比，DBA 的工作有很多独特之处，但这并不意味着它必须是一个没有人可以接近的神奇神职人员。这些步骤在使您的工作透明化方面大有帮助，但最重要的是，您的工作不是作为数据库主机黄金花园的守门人，而是作为可以提供建议并帮助您合作的工程师成长并提供更多服务的主题专家对业务的价值比备份和查询调优（但这些也很有趣！）。

特别感谢 Sendgrid 出色的运营团队，他们继续教给我很多东西，也感谢 Charity Majors 创造了这篇文章的标题。并在此处查看有关 DBA 的更多帖子。