本专栏的读者有时会问我有关数据库和数据库管理的问题，我很欢迎。有时我会借此机会以书面形式回答特别有趣的问题。我不止一次被问到的一个有趣的问题是：“哪些指标和度量对管理您的 DBA 团队的效率有用？”
这不是一个很容易回答的问题，因为好的 DBA 必须是“万事通”。我的意思是，DBA 需要胜任许多不同的任务（或行业）才能发挥最大的作用——而且这些“行业”中的每一个都可以有多个衡量成功的指标。例如，一位读者建议的指标是衡量成功处理的 SQL 语句的数量。但“成功”是什么意思？它是仅仅意味着该语句返回了正确的结果，还是意味着它在合理的时间内返回了正确的结果？
什么是“合理”时间？两秒？等一下？半个小时？除非您已建立服务级别协议，否则以响应时间衡量 DBA 是不公平的。而 DBA 必须参与建立和管理合理的服务水平协议（在成本和响应时间方面），以免他们被交给一项无法完成的任务。（在本专栏的 2022 年 9 月版中，我谈到了服务水平管理的重要性。）
衡量事件报告的数量是建议的另一个指标。好吧，如果它仅限于可能受 DBA 影响的真实问题，那很好。DBA 不应对 DBMS 中的错误（由 DBMS 供应商引起）负责，也不应对管理层或过度热心的开发团队不合理的时间表强加给他或她的设计元素负责。
我喜欢使用可用性指标的想法，但它应该根据环境和您组织的正常运行时间需求进行调整。换句话说，所需的可用性是多少？再次回到服务水平协议。如果 DBMS 没有提供实现所需可用性级别的技术基础设施，或者组织没有从第三方供应商购买数据库可用性解决方案，那么 DBA 不应该因为没有实现可用性而受到严厉的评判。当然，如果 DBA 决定购买正在使用的 DBMS，那么他可能要承担责任，但通常情况并非如此。许多 DBA 是在选择 DBMS 之后才加入的。
基于对问题的反应的指标怎么样？该指标不一定意味着问题已解决，但 DBA 已对“投诉”实体做出回应并正在制定解决方案。这样的指标倾向于将数据库管理视为一种服务或服务台类型的功能。但我认为这个衡量 DBA 的标准太窄了；毕竟，他们所做的不仅仅是对问题做出反应。
必须在了解 DBA 工作环境的情况下制定任何 DBA 评估指标。这需要深入分析诸如：
- 必须支持的应用程序数量；
- 数据库的数量和这些数据库的大小；
- 本地与云数据库支持；
- 数据库的使用（OLTP、OLAP、基于网络的、分析、AI、临时等）；
- 不同 DBMS 和供应商（即 Oracle、Db2、SQL Server 等）的数量；
- 支持的操作系统平台数量（Windows、UNIX、Linux、z/OS 等）；
- 由于非标准 DBMS 使用，对 ERP 应用程序的特殊考虑；
- 用户数和并发用户数；
- 有效或计划中的服务级别协议的类型；
- 参与 DevOps 敏捷开发环境的要求；
- 需要可用性（24/7 或更少）；
- 数据库停机对业务的影响（$$$）；
- 性能要求（亚秒或更长——回到 SLA 问题）；
- 应用程序类型（关键任务与非关键任务）；和
- 变更请求的频率。
这可能是一个不完整的列表，但它准确地显示了 DBA 每天面临的复杂性和挑战。
当然，衡量 DBA 效率的最佳方法是判断 DBA 执行的所有任务的质量。但是这种衡量的许多方面都是主观的。请记住，DBA 执行许多任务以确保组织的数据和数据库有用、可用、可用且正确。这些任务包括数据建模、逻辑和物理数据库设计、性能监控和调整、确保可用性、授权安全性、备份和恢复、确保数据完整性，以及与公司数据库接口的所有内容。开发以非主观方式衡量这些任务的一致指标具有挑战性。
你可能需要想出一个包含以上所有内容的复杂公式——甚至更多——才能正确地完成工作，这可能就是为什么我从未见过一个公平的、非主观的、基于指标的测量程序放在一起的原因对于 DBA。
如果您实施这样的程序，我很想听听详细信息以及 DBA 组、他们的管理层和他们的客户/用户如何接受它。
原文标题：How to Measure Your DBAs
原文作者： Craig S. Mullins
原文链接：https://www.dbta.com/Columns/DBA-Corner/How-to-Measure-Your-DBAs-156273.aspx
