开发人员应该有权访问什么？
我工作的地方是构建处理和存储敏感数据的应用程序。 我们有3个环境。 开发、UAT/QA（用户接受测试）和生产，
我工作中的开发人员无法访问 UAT 或生产，并且对开发的访问也有限。 我们在开发中所能做的就是连接到开发数据库服务器。 我们无法访问开发服务器本身。 所以我们不被允许在开发中使用诸如 Web 服务器（iis）之类的东西。 如果我们想要更改，我们必须通过向网络管理员提交工作请求的正式流程（这可能需要几天时间才能完成）。 如果开发人员请求在 UAT 或 PROd 数据库中检查某些内容，情况也是如此。 当试图支持我们的应用程序时，这种严格的访问限制确实令人沮丧。
我可以理解为什么我们有这些政策，因为它减少了事情搞砸的风险。 但这使得解决问题变得非常耗时且痛苦。 一些可能需要 5 分钟才能修复的问题（如果开发人员有权访问）可能需要几天的时间才能解决。
这种严格的访问权限正常吗？
i work at a place where we build applications that process and store sensitive data.
we have 3 environments. Dev, UAT / QA (user acceptant testing) and Production
the developers at my work have no access to UAT or Production and have limited access to Dev. All we can do in dev is connect to a dev DB server . we have no access to the dev server itself. so we arent allowed to play with things like the web server (iis) on dev. if we want changes we must go though a formal process of submitting work requests to our network administrators (which could takes days to complete).
the same goes if a developer were to request for something to be checked in a UAT or PRod database.
this strict access restriction is really frustrating when trying to support our applications.
i can understand why we have these policies, as it reduces the risk of things getting screwed up. but this makes solving issues really time consuming and painful. something that could take 5 mins to fix (if a developer had access) could take days to resolve.
is this sort of strict access rights normal?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
即使在小公司中，工程师也不需要过多访问代码之外的开发环境。 核心环境应该保持相当静态。 您希望快速更改 Web 服务器上的哪些类型的内容？
Even in a small company, engineers shouldn't need much access to the dev environment beyond code. The core environment should remain fairly static. What types of things on the web server would you like to change at a rapid pace?
查看 Stackify。 我们刚刚发布了一项新服务，使开发人员可以更好地了解他们的应用程序和生产服务器。 我们可以为他们提供对日志文件、配置文件、Windows 事件查看器等内容的简单只读访问权限。我们可以解决您所描述的问题。 我们基本上发明了 DevOps 支持：http://www.stackify.com
Check out Stackify. We just released a new service that gives developers more visibility to their applications and the production servers. We can give them simple read only access to things like log files, config files, windows event viewer, etc. We can solve the problem you describe. We have basically invented DevOps support: http://www.stackify.com
很难说是否正常。 例如，我曾在投资银行工作过，他们的程序比你描述的更为严厉。 我还曾在一家完全没有任何程序的IB工作过。 然而，值得注意的是，前者仍在营业，而后者最近刚刚破产！
Difficult to say if it's normal. For example, I've worked for investment banks where they have even more draconian procedures than the ones you describe. I've also worked for one IB that had no procedures at all. However, it's noticeable that the former are still in business, whereas the latter went bust famously just recently!
如果开发人员无权访问，那么它就不是“开发服务器”。 现在，拥有 4 个环境并非闻所未闻：生产、预生产、测试和开发。 （按增加开发人员的访问权限排序）。 如果我忽略名称，则似乎您具有相同的结构，只是缺少开发服务器。
It's not a "dev server" if developers have no access. Now it's not unheard of to have 4 environments: production, pre-production, test and dev. (sorted by increasing access for devs). If I ignore names, it seems that you have the same structure except that you're missing the dev server.
对我来说听起来有点紧。 通常，我希望完全控制开发服务器，我很高兴看到测试服务器上的只读访问权限，而且说实话，我对查看生产服务器不感兴趣（从开发的角度来看）。
当然，这里做了以下假设；
在我们的过程中，我们不允许开发人员部署来测试 -在我们将其交给部署到产品的第三方之前，这取决于测试人员。
这与其他任何事情一样验证了我们的发布程序。
所以; 只要发布的所有内容都已记录下来，您就不需要访问除开发之外的任何内容，但对开发环境有适当程度的控制会很好。
Sounds a bit tight to me. Normallly I would expect full control over the Dev server, I'd be happy to see readonly access onthe test server and to be perfectly honest, I'm not interested in looking at the production server (from a development point of view).
Of course, the following assumtpions are made here;
In our procedure here we don't allow the developer to deploy to test - this is up to the tester before we hand over to a 3rd party who deploys to prod.
This validates our release procedure as much as anything else.
So; as long as everythiong is documented for the release, you shouldn't need access to anything other than Dev, but it would be nice to have a decent level of control over the dev environment.
这是一个你想要什么的问题。
工作中有两个相互竞争的要求：
您的公司（有意识或无意识）决定，降低敏感数据泄露的风险比拥有快速解决问题和开发新代码的能力更好。 我的公司也倾向于同样的方向，但还没有真正了解到你所描述的极端情况。
这是一个商业决定。
这样做是因为（可能是无意识地）您的公司对下行风险（泄露数据）的重视程度高于对上行风险（使软件正常运行）的重视。 这是一种常见的偏见——它被称为规避风险（我相信有比这更好的术语——有人吗？），对于我们这些试图完成工作、必须克服风险的人来说，这非常烦人。一堆障碍是由那些对这些障碍的影响没有很好了解的人设置的。
总结
It's a question of what you want
There are 2 competing requirements at work:
Your company has decided (consciously or unconsciously) that it is better to reduce the risk of leaking sensitive data than to have the ability to fix problems and develop new code quickly. My company leans in the same direction, but is not really clued-up enough to take it to the extremes you are describing.
This is a business decision.
It is made because (probably unconsciously) your company puts a higher value on the downside risk (leaking data) than on the upside risk (making the software work). This is a common bias - it's known as being risk-averse (I'm sure there's a better term than that - anybody?), and it is very annoying for those of us who, trying to get our jobs done, have to overcome a bunch of obstacles put there by people who don't have a good understanding of the impact of those obstacles.
To Summarise
这是关于变革管理的； 确保对系统的所有更改都进行跟踪并将其纳入发行说明，并且系统某一部分的更改不会导致另一部分出现问题。
如果由我决定，我会给每个开发人员一台足够强大的 PC，可以根据需要运行尽可能多的虚拟机来模拟生产环境，并完全控制这些机器。 然后确保对官方开发环境的每项更改都进行记录，以便可以生成完整的发行说明。
It's about change management; making sure all changes to the system are tracked and make it into release notes, and also that a change in one part of the system doesn't cause problems in another part.
If it was up to me, I'd give each developer a PC powerful enough to run as many virtual machines as needed to emulate the production environment, with total control over those machines. And then make sure every change to the official dev environment is documented so that full release notes can be produced.