devops 数据库_DevOps世界中与数据库管理员合作的6种方法

devops 数据库

DevOps的定义是“统一运营和工程团队”，以培养跨团队协作的文化，整理基础架构的构建方式，并成为数据驱动型组织。 但是似乎数据库和照顾他们的团队被视为这种环境的例外。 在大多数公司中，数据库仍然像围墙花园一样对待，数据库主机往往喜欢精美的花朵，而数据库管理员（DBA）则保护着对它们的任何访问。

这种围墙式的态度总是会影响整个组织的其他部门，从技术操作到交付工程，再到产品规划，因为每个人都在努力处理数据存储。 最终，这会降低采用敏捷方法进行软件开发的好处，这对于已经运营了几年并且在忠实的付费客户中拥有坚实财务基础的公司来说是个问题，但是很难摆脱创业公司的皮肤（靠裤子座位飞行的人），并感受到在现有产品和未来产品中获得稳定感的压力。

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

在一家典型的商店中，新功能的开发周期如下所示：

1. 产品要求新的闪亮功能。
2. 开发人员可能会承诺新的闪亮功能的发布日期。
3. 开发人员对其进行编码。
4. 一些功能测试是在看起来像生产环境的环境中进行的（或者可能不完全是）。
5. 已部署。
6. 利润？？

太好了 但是，如果您的产品经理对这个闪亮的新功能的市场需求正确，该怎么办？

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

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

DBA也不是无可厚非的。 许多DBA可能会停留在原来的方式上，直到在生产中才看到更改，并且当生产中断时，通过对他们的数据库提供更多保护以防止那些“讨厌的开发人员”做出React。

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

1.维护组织技术目录。

工程是一项团队运动。 整个团队都需要朝同一个方向划船。 这意味着，无论您了解多少新技术似乎都非常适合您要构建的新事物，您都需要了解将新技术添加到现有且庞大的产品/技术堆栈中的组织成本。

这并不意味着您不能在需要时将新技术添加到该目录中。 但是，随着业务的增长，重要的是要认识到添加到堆栈中的每种新技术所带来的成本和风险。 尤其是当这项新技术将存储任何形式的应用程序状态时。 工程组织，运营团队和DBA中的更多高级成员都需要参与有意识地审查潜在的新数据存储区并定义新数据存储区技术有望解决的特定业务需求。 对于任何交付团队采用新数据存储的情况，多数据中心复制，可用性保证，完整性保证和操作需求等详细信息都应作为清单的一部分。

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

工程是一项团队运动。 整个团队都需要朝同一个方向划船。

在着手创建有史以来的最佳产品之前，请写下该新事物将如何构建以及它的许多组件将如何相互作用。 在微服务和分布式系统的新世界中，watercooler和传闻的设计可能会损害任何产品的成功。 确保记录您的设计并将其保存在活动文档中，以便从产品经理寻求功能到负责这些新部署的数据库团队的每个人都可以在同一页面上找到每个细节。

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

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

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

3.开始架构审查过程。

如果您的组织中有多个工程师在同一个房间内从事相同的工作，那么您必须接受的是，并非每个人都总是知道正在构建的所有新事物。 如果您已经获得了可观的收入，并且拥有一个两层或三层的工程组织，每个季度都要对新产品进行计划，但是仍然没有一个流程来审查那些计划中的新产品的体系结构，那么您将陷入困境。

正如编写新事物的体系结构对于使每个人都处于循环中非常重要一样，在编写一行代码之前 ，要有一个建设性的对话场所并征求有关计划的反馈，这一点同样重要。 这是一种很好的方法，可以利用那些已经建立了相似的东西或看到相似的体系结构并用于更大的客户群并可以分享重要经验教训的人们的专业知识。

4.利用队友的经验。

将设计新产品成功的团队运动方面内化之后，您可能会发现DBA团队不仅擅长解决生产中的问题，而且还非常擅长在问题仍然存在时就确定问题，而设计仍然是审查中的文件。 随着体系结构蓝图和审核流程成为您组织中的标准，您将不再觉得有一个独立的团队来保持进度。 您可以不断利用DBA团队的知识来告知您如何使用技术堆栈中的数据存储，如何扩展以及如何拥有新产品的可用性和性能。 对于您的团队来说，这就像一个超级大国。

5.消防演习不仅适用于行动。

即使在完成体系结构审查中的所有规划和设计之后，一旦事物构建完成，但在业务收入依赖于此之前，测试所有假设仍然有很多价值。 当产品的成功与数据存储的性能，可用性或扩展能力直接相关时，这一点尤为重要。 在向客户发布新功能之前，请确保安排可控环境中导致故障的防火演习，并按照预期的方案进行恢复以证明其准确性或调整期望。 是的，确保您的数据库团队参与了防火练习和实际练习的计划。 通过拥有“游戏日”并确保故障排除和恢复计划能够按预期执行，在工程组织中可以建立很多有用的力量。

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

最后，随着您公司的不断发展，您不可避免地会发现几年前效果良好的产品部分现在正在显示其年龄。 当需要重写时，请不要假装这仅是工程方面的工作。 就像新功能一样，重写和重构是一个完整的组织工作。 他们需要产品经理的支持，运营和DBA团队的建议以及完整的蓝图和体系结构审查过程。

在想要实践DevOps的组织中，工程团队在将产品从构思到生产过程中具有很大的力量。 有了这种能力，就不仅可以使用设计堆栈或编写代码的能力，而且还可以开发功能，稳定性和可伸缩性的功能。 整个技术组织之间越来越多的协作为您的企业和客户提供了长期价值。

请参见将于10月29日至11月3日在加利福尼亚州旧金山举行的LISA17上 Silvia的演讲“ 在DevOps World中与DBA一起工作”，了解更多信息。

翻译自: https://opensource.com/article/17/10/working-dbas-devops-world

devops 数据库