限制开发人员访问 UAT 和生产环境但仍能完成任务的最佳实践

Question

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

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

现在还处于早期阶段，但到目前为止这种方法似乎站不住脚。最终结果是，每次出现生产问题，或者甚至只是在 UAT 中输入错误通知单...都需要召开“全体人员”会议，其中一半人参加该部门挤进某人的办公室或挤在某人的显示器周围。

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

注意：在写这篇文章之前，我确实发现了一些模糊相似的问题。然而，它们要么太窄（并且此处），或处理萨班斯-奥克斯利法案问题此处不存在问题，或简单地问“这些限制正常吗？”而不是问如何应对它们。

Answer 1

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

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

我们的用户也接受过良好的培训，可以提供屏幕截图。令人惊奇的是，通过查看屏幕截图可以解决很多问题。有时修复很容易（用户正在查看错误的屏幕），有时您可以看到记录包含您认为不应该包含的数据或缺少应有的数据。 （谁将该字段从不可为空更改为可空？难怪代码被破坏了。）

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

如果数据受到限制（我们的开发人员位于另一个国家，他们根本看不到产品），则由技术负责人进行研究以找出导致问题的原因，然后在向开发人员提供修复后将修复程序分配给开发人员以及他的研究的详细信息。这使得只有一个人负责研究，而不是整个团队和开发人员，直到初步研究完成后才参与其中。

从文化上来说，这并不是一个容易的改变。人们一开始表示抵制，并不愿意失去自己的刺激权。但过了一段时间，人们开始庆幸他们不必直接在产品上进行更改（如果出现问题，就会受到打击！哎呀，忘记突出显示 where 子句并删除了整个用户表。）我们很感激我们拥有进行代码审查和 QA 测试的机会（当开发人员拥有产品权利时我们也没有机会）。我们亲眼目睹，由于在压力下对产品的不良推动或直接在产品上做某事而忘记对开发人员进行操作（或放入源代码控制）而造成的危机较少，所以那些时候，开发人员后来的推动覆盖了产品的更改消失了。我们很高兴没有人再意外删除整个用户表（感谢上帝的审计表）。

Answer 2

好吧，这里有一些想法

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

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

此外，展示风险成本与收益之间的关系也没什么坏处。如果对日志、数据库等的临时授权让您在生产中“启动”，那么您的内部和外部客户所感受到的满意度也许会超过这种风险。

无论如何，只是一些需要思考的想法。我不确定这里有对还是错。这只是每个公司都必须自己做出的事情，然后接受他们的选择。但值得赞扬的是你让这次谈话顺利进行。