我正在与一家小公司合作，这种公司正在经历从初创企业文化向更成熟的企业文化过渡的日益增长的痛苦。 在过去，开发人员可以或多或少地自由地访问UAT环境，甚至可以在很大程度上访问生产环境。
但是，根据新方法，开发人员只能访问Dev和初始QA环境......并且无法访问UAT和生产环境。 对这些环境的所有访问，从部署代码（在本例中为Java WAR）到管理Java应用服务器，甚至查看日志和数据库，都必须通过系统管理员进行管道传输。
它还处于早期阶段，但到目前为止，这种方法似乎并不成立。 最终结果是，每次出现生产问题， 或者甚至只是在UAT中输入错误票时 ......它需要一个“全手”会议，一半的部门挤进某人的办公室或挤在一个人的监视器周围。
我想提出一些更可行的方法，同时仍然满足限制访问敏感用户数据等的需要。想到的一个想法是为日志文件目录创建一个只读安装，在开发人员可能的其他位置至少查看应用程序级日志。 但是，除此之外，我对如何限制开发人员访问的最佳实践感兴趣，同时尽可能降低生产力。
注意：在我写这篇文章之前，我确实找到了一些模糊的类似问题。 然而，它们要么太狭窄 （和这里 ），要么处理萨班斯 - 奥克斯利法案中没有问题的问题，或者只是问“这些限制是否正常？” 而不是问如何应对它们。
我们在过去几年里做了这个改变。 但是，我们允许大多数开发人员访问生产日志和读取数据库访问权限。 我们根本不允许他们直接在生产上改变任何东西。 必须对所有更改进行代码审查，然后将代码首先推送到QA进行测试，然后由配置管理或技术主管推送。
我们还经常用prod数据刷新我们的开发环境。 由于对数据库和数据库数据（如查找表）的所有dev更改都是脚本化并存储在源代码控制中，因此从prod刷新并快速加载所有dev更改并不困难。 由于报告的大量问题与针对一个或多个特定记录的数据有关，这有助于我们查看更准确的prod数据视图。 拥有一个用于项目开发的独立开发服务器和一个用于支持现有产品问题的服务器也可以工作。 这样，您就不会通过刷新数据库来处理项目工作中的人员，从而处理从prod报告的错误。 与一群人坐在一个房间看一个屏幕试图解决问题的成本相比，硬件便宜。 可能只需要避免两次或三次会议来证明服务器的成本是合理的，这可以使用prod数据轻松刷新。
我们的用户也训练有素，可以提供屏幕截图。 通过观看屏幕截图可以修复多少事情。 有时修复很容易（用户正在查看错误的屏幕），有时您可以看到记录包含您认为不具备的数据或缺少应有的数据。 （谁将该字段从不可空变为可空？难怪代码被破坏了。）
我们还广泛使用我们的审计表来查找问题所在。 我们存储了哪些应用程序使数据发生了变化以及更改，因为我们有许多可能的应用程序访问同一个数据库。 能够准确地看到谁或什么改变了数据到目前的错误状态是有帮助的。 这有助于我们找到从哪里开始快速解决问题。
如果数据受到限制（我们在其他国家/地区的开发人员根本看不到产品），那么由技术主管负责进行研究以查找导致问题的原因，然后在向他提供修复后将其分配给开发人员他的研究细节。 这使得一个人负责研究，而不是整个团队，开发人员直到初步研究完成后才开始参与。
这在文化上并不容易改变。 人们一开始就讨厌，并且讨厌失去他们的产品权利。 但过了一段时间后，人们开始感激他们不必直接在prod上进行更改（如果出现问题就会受到打击！哎呀忘了突出where子句并删除了整个用户表。）我们很感激我们有代码审查和QA测试的机会（当开发人员拥有产品权利时我们也没有这样做）。 我们亲眼目睹了由于在压力下做出不好的推动或通过直接做生产并且忘记做到开发（或进行源代码管理）而产生的更少的危机，所以那些时候后来推出的开发覆盖了刺激的变化消失了。 而且我们很高兴没有人意外删除整个用户表（感谢上帝审计表）。
好吧，这里有一些想法
最终，所有这些或其他事情都是贵公司和您的IS / IT部门需要决定的事情。 也许这是与你的CIO讨论的事情？ 还是你的经理？ （当然这取决于他们接受反馈和评论的程度。我工作的地方，我很幸运，他们很欣赏我们的那些想法。）或许，现在是时候开始讨论这些事情。
同样，提出风险与收益的成本并没有什么坏处。 如果对日志，数据库等的临时授权使您“生产”，或许这种风险，则会被您的客户（内部和外部）感到满意。
无论如何，只是想一想。 我不确定这里是对还是错。 这只是每家公司都必须自己创造，然后与他们的选择一起生活的东西。 但是对于你在这次谈话中获得成功而感到荣幸。