The DBA Code of Ethics – SQLServerCentral
我最近在Slashdot上讨论了一个关于一个系统管理员在他前雇主的系统中植入逻辑炸弹并试图从中获利的讨论。虽然对故事本身感到震惊，但 Slashdot 内部的讨论将我引向了SAGE 站点（系统管理员协会）的系统管理员道德准则。我发现这个有趣的阅读并鼓励大家在那里花几分钟。
我还认为应该有类似的 DBA 道德规范。由于我喜欢写作并且有几分钟的时间，所以我开始写一篇，欢迎您的评论。这是一个草稿，（希望）会演变成一个代码，我们可以在这个网站上发布，供每个人使用和适应他们的组织。
数据库管理员
Canon 1 - DBA 必须保护数据的完整性
这是最基本的。我们是需要保护数据的人，其中很大一部分是确保数据的完整性。我知道我们无法控制应用程序，当然也无法控制用户输入数据，但我们可以有所作为。通过严格的变更控制和审查，我们可以确保将优质代码放置在我们的服务器上。特别是对于插入/更新/删除代码，我们可以尝试通过确保数据在事务上的一致性来防止完整性。我们可以确保正确的版本或至少知道服务器上的代码版本。
通过使用强引用完整性，我们可以防止孤儿和其他数据不匹配的发生。通过定期维护，我们可以防止索引和表损坏。
通过教育，我们可以帮助开发人员和最终用户了解拥有“好”数据、完整数据的重要性。我们可以帮助他们了解强制执行良好的源数据对于确保数据库能够完成其工作至关重要。
Canon 2 - DBA 必须确保授权用户正确访问系统
在某种程度上，你可能会争辩说这应该是佳能 1 的一部分，但我认为把它叫出来有帮助是很重要的。我们必须从两个意义上确保安全，以确保我们能够完成这个项目。
我们需要做的第一件事是显而易见的。我们必须确保未经授权的用户不会访问我们的系统。这是通过修补服务器、使用强密码、保护这些密码并定期更改它们来实现的。确保外部暴露的服务器得到强化，等等。每个人似乎都在争取的基本安全内容。
然而，这个经典的第二部分是更难满足的。我看到的每个人都抱怨并产生最多问题的那个。我们必须确保访问是正确的. 一个有趣的词，但我的意思是，我们需要确保人们只能访问他们有权查看的数据。这（通常）等同于对象类型权限，但如果您有某种类型的系统，它可能是基于行的。这也意味着读取和更改权限。允许某人阅读他们不应该阅读的信息对您的公司来说可能比允许他们更改访问权限更危险。在这里，我们不应该允许使用“as”来访问数据库，甚至可能不允许使用 DBO。同样，这是一场教育之战，我与供应商进行了多次斗争，试图向他们展示他们的应用程序不需要“as”或类似的访问权限。
Canon 3 - DBA 应尽一切可能确保数据库在需要时可用。
我在这个问题上挣扎了很多。我最初在这里对正常运行时间有所了解，但我意识到正常运行时间并不是一个好数字。我的数据库可能已经启动了，但是如果用户由于某种原因（安全、网络等）无法访问它，那么它真的启动了吗？尽管这些项目可能不在我的域中，但它们通常是我可以影响或至少促进为用户更改它们的过程。
我也纠结于时机。我们应该争取 99% 的正常运行时间吗？99.99%？有这样的目标似乎不太正确，至少对我来说是这样。相反，我认为我们应该努力让数据库在需要时可用，而在不需要时，对我来说，这些是我们应该采取的停机时间来主动处理系统。在 JD Edwards，我们几乎每周都会安排周五晚上的停机时间。我们并不总是把盒子拿下来，但那是在数据库上工作的好时机，比如重建索引，因为此时数据库不需要可用（感谢上帝，我们为 v7 盒子提供了这个) 如果性能达不到标准，那也没什么大不了的。
佳能 4 - DBA 应该不断改进他们的数据库。
这是另一个延伸。我从声明中的“性能”一词开始，但认为它应该过于局限。我们的工作是改进数据库，虽然性能很重要，但这只是一方面。存储使用、模式设计以及其他一些可能很重要的事情，作为专业的 DBA，我们应该随着时间的推移改进系统。某种程度上来说。
这不是最终版本，而是我认为行政 DBA 应该遵守的初稿。请花几分钟时间并在下面提交一些反馈，以便我可以将其修改为我们都可以自豪地支持的内容。