限制开发人员访问UAT和生产环境的最佳实践，但仍然可以完成任何工作

Question

我正在与一家小公司合作，这种公司正在经历从初创企业文化向更成熟的企业文化过渡的日益增长的痛苦。在过去，开发人员可以或多或少地自由地访问UAT环境，甚至可以在很大程度上访问生产环境。

然而，根据新方法，开发人员只能访问Dev和初始QA环境......并且无法访问UAT和生产环境。对这些环境的所有访问，从部署代码（在本例中为Java WAR），到管理Java应用服务器，甚至查看日志和数据库，都必须通过系统管理员进行管理。

它还处于早期阶段，但到目前为止，这种方法似乎并不成立。最终的结果是，每次出现生产问题时， 甚至只是在UAT中输入的错误提单 ......它需要一个“全手”会议，一半部门塞进某人的办公室，或挤在一个人的监视器周围。

我想提出一些更可行的方法，同时仍然满足限制访问敏感用户数据等的需要。想到的一个想法是为日志文件目录创建一个readonly-mount，在其他位置开发人员至少可以查看应用程序级别的日志。但是，除此之外，我对如何限制开发人员访问的最佳实践感兴趣，同时尽可能降低生产力。

注意：在我写这篇文章之前，我确实发现了一些含糊不清的问题。但是，它们要么too narrow（和here），要么dealt with Sarbanes-Oxley matters没有问题，要么simply asked "are these restrictions normal?"而不是询问如何处理它们。

Answer 1

我们在过去几年里做出了这一改变。但是，我们允许大多数开发人员访问生产日志和读取数据库访问权限。我们根本不允许他们直接在生产上改变任何东西。必须对所有更改进行代码审查，然后将代码首先推送到QA进行测试，然后由配置管理或技术主管推送。

我们还经常使用prod数据刷新我们的开发环境。由于对数据库和数据库数据（如查找表）的所有dev更改都是脚本化并存储在源代码控制中，因此从prod刷新并快速加载所有dev更改并不困难。由于报告的大量问题与针对一个或多个特定记录的数据有关，这有助于我们查看更准确的prod数据视图。拥有一个用于项目开发的独立开发服务器和一个用于支持现有产品问题的服务器也可以工作。这样，您就不会通过刷新数据库来处理项目工作中的人员，从而处理从prod报告的错误。与一群人坐在一个房间看一个屏幕试图解决问题的成本相比，硬件便宜。可能只需要避免两次或三次会议来证明服务器的成本是合理的，这可以使用prod数据轻松刷新。

我们的用户也训练有素，可以提供屏幕截图。通过观看屏幕截图可以修复多少事情。有时修复很容易（用户正在查看错误的屏幕），有时您可以看到记录包含您认为不具备的数据或缺少应有的数据。 （谁将该字段从不可空变为可空？难怪代码被破坏了。）

我们还广泛使用我们的审计表来查找问题所在。我们存储了哪些应用程序使数据发生了变化以及更改，因为我们有许多可能的应用程序访问同一个数据库。能够准确地看到谁或什么改变了数据到目前的错误状态是有帮助的。这有助于我们找到从哪里开始快速解决问题。

如果数据受到限制（我们在其他国家/地区的开发人员根本无法看到产品），则由技术主管负责进行研究以查找导致问题的原因，然后将修复程序分配给开发人员在向他提供他的研究细节之后。这使得一个人负责研究，而不是整个团队，开发人员直到初步研究完成后才开始参与。

在文化上这不容易改变。人们一开始就讨厌，并且讨厌失去他们的产品权利。但过了一段时间后，人们开始感激他们不必直接在prod上进行更改（如果出现问题就会受到打击！哎呀忘了突出where子句并删除了整个用户表。）我们很感激我们有代码审查和QA测试的机会（当开发人员拥有产品权利时我们也没有这样做）。我们亲眼目睹了由于在压力下做出不好的推动或通过直接做生产并且忘记做到开发（或进行源代码管理）而产生的更少的危机，所以那些时候后来推出的开发覆盖了刺激的变化消失了。我们很高兴没有人意外删除整个用户表（感谢上帝审计表）。

Answer 2

嗯，这里有一些想法

• 将日志文件公开为只读。让它们可用 请求，或通过HTTP将其提供给页面，以便开发人员可以使用 他们需要的时候。如果您确定不记录客户 信息到日志，这使得更容易达成一致 时。
• 我个人认为让开发人员阅读并不是一件坏事 只访问应用程序服务器控制台屏幕（例如a WebSphere Application Server）。这样，您就可以查看设置。 密码和事物无论如何都应该被隐藏，所以它不像你 可以窃取秘密。另外，仅通过查看，您可以看到是否有某些内容 amiss，并且总是要求更高级别的系统管理员进行更改 需要的。
• 如果贵公司有时间做，那就值得分类 你的数据。什么是以客户为基础？什么是数据可能是 对于贵公司与其他竞争对手的业务关系的“秘密”。 如果您对数据进行分类，现在可以更好地定义谁可以拥有 什么访问什么。即使在制作中，DBA也可以设置一些 开发人员用户ID，允许您选择（读取）访问权限 可以查看的数据分类。任何需要的东西 通关，你可能要去DBA，但是......你至少可以 在不需要整个“战争室”的情况下查询某些事情。
• 如果您有能力建造和维护它，请制作一面镜子 某处。此镜像配置与生产完全相同。 它具有最近部署的应用程序版本。 如果您需要生产数据，则需要备份数据 生产，如果需要，通过“洗涤器”或“搅拌器”运行 所以满足你的高管，并将其上传到这个镜像。瞧！您 现在尽可能接近生产，但你被允许 在此环境中拥有更多权限进行故障排除。这将 除了确切的生产数据之外，它可以为您提供所有数据 炒）。如果这个bug变成了类似的东西 具体数据，然后你回去查询生产和/或工作 与DBA就可以了。
• 此外，也许值得一些配置文件 支持？也许你的系统管理员可以给你一些临时的 当局的事情？这可以被认为是好的或坏的两种方式 并且最终是公司政策。
• 同时拥有良好的变更管理系统还有很长的路要走 确定出错的候选人。如果你的 应用程序突然崩溃，知道这将是有帮助的 系统管理员刚刚将OS补丁应用于生产和此操作系统补丁 实际上可能会影响您的申请。或者也许是其他人 将修复程序移到生产中并没有完全测试它。但至少你 知道什么可能成为破坏事物的潜在候选人。

最终，所有这些或其他事情都是贵公司和您的IS / IT部门需要决定的事情。也许这是与你的CIO讨论的事情？还是你的经理？ （当然这取决于他们接受反馈和评论的程度。我工作的地方，我很幸运，他们很欣赏我们的那些想法。）或许，现在是时候开始讨论这些事情。

提出风险与收益的成本也没有什么坏处。如果对日志，数据库等临时授予权限让您“投入”生产，或许这种风险，则会被您的客户（内部和外部）感到满意。

无论如何，只是想一想。我不确定这里是对还是错。这只是每家公司都必须自己创造，然后与他们的选择一起生活的东西。但是，对于你们在这次谈话中获得成功的声音，我感到很荣幸。