在 DevOps 世界中与数据库管理员协作的 6 种方法

DevOps 的定义是“统一运维和工程团队”，以培养跨团队协作的文化，编纂基础设施的构建方式，并成为更数据驱动的组织。 但似乎数据库和负责维护它们的团队在这种环境中被视为例外。 在大多数公司中，数据库仍然像围墙花园一样被对待，数据库主机像娇嫩的花朵一样被照料，数据库管理员 (DBA) 守卫着对它们的任何和所有访问。

这种围墙花园的态度不可避免地影响到组织的其余部分，从技术运维到交付工程，一直到产品规划，因为每个人都试图绕过数据存储。 最终，这降低了敏捷软件开发方法的好处，这对于已经运营几年并通过忠实的付费客户获得了坚实的财务基础，但很难摆脱初创公司外壳（那种随心所欲的外壳），并且感到有压力在现有和未来的产品中实现稳定性的公司来说，是一个问题。

在我们深入探讨如何使 DBA 及其传统的围墙花园成为 DevOps 文化的一部分之前，让我们先检查一下当前的状况。

在一个典型的公司中，新功能的开发周期如下所示：

1. 产品部门要求新的炫酷功能。
2. 也许开发人员承诺了新炫酷功能的交付日期。
3. 开发人员编写代码。
4. 在可能看起来像生产环境（或者……也许不完全是）的环境中完成一些功能测试。
5. 已部署。
6. 盈利？？

这一切都很棒。 但是，如果您的产品经理对这个炫酷新功能的市场需求是正确的呢？

• 当您为此编写代码时，您是否使用 100 个虚假用户进行了测试？
• 您是否使用 100,000 个用户进行了测试？
• 100 万以上的用户呢？
• 您是否考虑了长期需求？ 增长率？ 数据保留？ 安全需求？
• 当数据库主机/存储发生故障时，您是否为故障转移场景进行了设计？
• 您是否实践了这些假设？

这就是将 DevOps 限制在运维和工程方面的不足之处。 如果在规划阶段没有获得 DBA 的观点，那么如果您构建的东西成功了，您可能会遇到麻烦。 谁会害怕成功呢？

DBA 也并非没有责任。 许多 DBA 可能仍然坚持旧的方式，直到更改在生产环境中才看到，并且当生产环境中出现问题时，他们的反应是更加保护他们的数据库，以防那些“讨厌的开发人员”。

尝试以下六种策略，将 DBA 纳入 DevOps 文化，以解决这些问题，并使您交付的产品更加成功。

1. 维护组织技术目录。

工程是一项团队运动。 整个团队需要朝着同一个方向划船。 这意味着，无论您读到的这项新技术看起来多么适合您正在构建的新事物，您都需要意识到将新技术添加到现有且庞大的产品/技术堆栈中的组织成本。

这并不意味着当需要时您不能将新技术添加到该目录中。 但是，作为一家成长中的企业，重要的是要认识到您添加到堆栈中的每项新技术所带来的成本和风险。 尤其是当新技术将存储任何形式的应用程序状态时。 工程组织、运维团队和 DBA 中更资深的成员都需要参与有意识地审查潜在的新数据存储，并定义预期新数据存储技术要解决的特定业务需求。 诸如多数据中心复制、可用性保证、完整性保证和运维需求等细节都应成为任何交付团队为采用新数据存储提出理由的清单的一部分。

2. 编写设计蓝图。 保持更新。

在您着手创建有史以来最好的新产品之前，请写下这个新事物将如何构建，以及它的许多组件将如何相互交互。 在这个微服务和分布式系统的新世界中，靠饮水机旁的闲聊和传闻进行设计可能对任何产品的成功都是不利的。 确保您记录您的设计并将其保存在一份活文档中，以便从要求产品功能的产品经理到将负责这些新部署的数据库团队，每个人都可以了解每个小细节。

在这些文档中跟踪可以帮助您的产品获得成功的事项包括：

• 数据保留需求
• 预期可用性目标
• 预期数据一致性
• 预期增长率
• 预期延迟需求
• 新数据库的上游和下游依赖项

您会惊讶地发现，在同一个项目上工作的工程师和产品经理有多少次拥有完全不同的期望和设计计划。 这是一个大问题。 工程团队通常负责向业务部门和客户承诺交付日期，必须确保所有利益相关者都了解这些承诺的细节。 这些利益相关者不仅包括管理层，还包括任何将帮助您部署系统所有层的人。

3. 启动架构评审流程。

如果您的组织有超过少数工程师在同一个房间里为同一个事物工作，您必须接受并非每个人都始终了解所有正在构建的新事物。 如果您已经获得了可观的收入，并且拥有一个两到三级的工程组织，为新产品进行季度规划，但仍然没有审查这些计划中的新产品的架构的流程，那么您将面临糟糕的境地。

正如编写新事物的架构对于让每个人都了解情况非常重要一样，拥有一个进行建设性对话并征求对计划在编写单行代码之前的反馈的场所也很重要。 这是利用那些构建过类似事物或见过类似架构用于更大客户群的人的专业知识，并分享关键经验教训的好方法。

4. 利用您团队成员的经验。

一旦您将团队运动的方面内化到设计成功的新产品中，您可能会发现您的 DBA 团队不仅擅长解决生产环境中的问题，而且还非常擅长在问题发生之前识别问题，即当设计仍然是审查中的文档时。 随着架构蓝图和审查流程在您的组织中变得标准，您将不再感觉一个脱节的团队在把守您的进度。 您可以不断利用 DBA 团队的知识来了解如何在您的技术堆栈中使用数据存储、如何扩展以及如何拥有您的新产品的可用性和性能。 这就像您团队的超能力。

5. 消防演习不仅适用于运维。

即使在您在架构审查中完成了所有规划和设计之后，在业务收入依赖于它之前，在构建完成后测试所有假设仍然有很多价值。 当产品的成功与数据存储的性能、可用性或扩展能力直接相关时，这一点甚至更加关键。 在向您的客户发布新功能之前，请务必安排一次消防演习，在受控环境中导致故障，并演练预期的恢复场景，以证明其准确性或调整预期。 是的，确保您的数据库团队参与消防演习的计划和实际演习。 通过进行“演练日”并确保故障排除和恢复计划按预期进行，可以在工程组织中建立很多有用的能力。

6. 不要将此限制为新功能。

最后，随着您的公司不断发展，您将不可避免地发现几年前运行良好的产品部分现在已经显现出老态。 当需要重写时，不要假装这只是工程部门的努力。 重写和重构是一项全组织范围的活动，就像新功能一样。 它们需要产品经理的认可、运维和 DBA 团队的建议以及完整的蓝图和架构审查流程。

在想要实践 DevOps 的组织中，工程团队在将产品从概念到生产的整个过程中拥有很大的权力。 随着这种权力而来的是，不仅可以利用设计堆栈或编写代码的能力，还可以开发不仅面向功能，还面向稳定性和可扩展性的能力。 加强整个技术组织内的协作，为您的业务和客户提供长期价值。

在 Silvia 的演讲中了解更多信息，在 DevOps 世界中与 DBA 协作，在 LISA17，将于 10 月 29 日至 11 月 3 日在加利福尼亚州旧金山举行。