4

我在一个我们构建处理和存储敏感数据的应用程序的地方工作。我们有 3 个环境。开发、UAT / QA（用户验收测试）和生产

我工作的开发人员无法访问 UAT 或 Production，并且对 Dev 的访问权限有限。我们在 dev 中所能做的就是连接到 dev 数据库服务器。我们无法访问开发服务器本身。所以我们不允许在 dev 上玩 Web 服务器 (iis) 之类的东西。如果我们想要更改，我们必须通过向我们的网络管理员提交工作请求的正式流程（这可能需要几天才能完成）。如果开发人员请求在 UAT 或 PROd 数据库中检查某些内容，情况也是如此。在尝试支持我们的应用程序时，这种严格的访问限制确实令人沮丧。

我能理解为什么我们有这些政策，因为它降低了事情被搞砸的风险。但这使得解决问题非常耗时且痛苦。可能需要 5 分钟才能解决的问题（如果开发人员有权访问）可能需要数天才能解决。

这种严格的访问权限正常吗？

4

7 回答 7

3

是否正常很难说。例如，我曾在投资银行工作过，他们的程序比你描述的更严格。我还为一个完全没有程序的 IB 工作过。但是，值得注意的是，前者仍在营业，而后者最近才声名狼藉！

于 2009-07-17T08:34:51.000 回答
3

如果开发人员无权访问，它就不是“开发服务器”。现在有 4 个环境并非闻所未闻：生产、预生产、测试​​和开发。（按增加开发人员的访问权限排序）。如果我忽略名称，那么您似乎具有相同的结构，只是缺少开发服务器。

于 2009-07-17T08:58:04.807 回答
2

对我来说听起来有点紧。通常我希望完全控制开发服务器，我很高兴看到测试服务器上的只读访问权限，老实说，我对查看生产服务器不感兴趣（从开发的角度来看）。

当然，这里做以下假设；

  • 3 个环境开始时完全相同
  • 对 prod 所做的更改通过 test 级联回 dev
  • Dev 中的任何配置更改都由部署者进行测试和生产

在我们的程序中，我们不允许开发人员部署进行测试 - 这取决于测试人员，然后我们将其移交给部署到 prod 的第 3 方。

这与其他任何事情一样验证了我们的发布程序。

所以; 只要为发布记录了所有内容，您就不需要访问除 Dev 之外的任何东西，但是对开发环境有适当的控制水平会很好。

于 2009-07-17T08:42:00.750 回答
2

这是你想要什么的问题

工作中有两个相互竞争的要求：

  • 快速解决问题/开发新代码。
  • 确保不泄露敏感数据。

贵公司已决定（有意或无意地）降低泄露敏感数据的风险，而不是拥有快速解决问题和开发新代码的能力。我的公司朝着同一个方向倾斜，但还没有真正掌握到足以将其推向您所描述的极端。

这是一个商业决策。

这是因为（可能是无意识地）您的公司对下行风险（泄露数据）的重视高于对上行风险（使软件工作）的重视。这是一种常见的偏见——它被称为规避风险（我敢肯定有比这更好的术语——有人吗？），对于我们这些试图完成工作却不得不克服的人来说，这很烦人那些对这些障碍的影响没有很好理解的人设置的一堆障碍。

总结

  • 这是一个商业决策。
  • 这是一个如何感知不同风险的问题。
  • 它反映了风险厌恶的立场。
  • 这个位置大概是公司完全不知不觉就走到了这一步。
于 2009-07-17T09:13:24.057 回答
1

这是关于变更管理；确保跟踪对系统的所有更改并将其写入发行说明，并且确保系统某一部分的更改不会导致另一部分出现问题。

如果由我决定，我会为每个开发人员提供一台足够强大的 PC，以根据需要运行尽可能多的虚拟机来模拟生产环境，并完全控制这些机器。然后确保记录对官方开发环境的每一次更改，以便生成完整的发行说明。

于 2009-07-17T11:05:13.520 回答
0

即使在一家小公司，工程师也不应该需要太多访问代码之外的开发环境。核心环境应该保持相当静态。您希望快速更改 Web 服务器上的哪些类型的内容？

于 2009-07-17T09:19:17.120 回答
0

查看 Stackify。我们刚刚发布了一项新服务，让开发人员可以更好地了解他们的应用程序和生产服务器。我们可以为他们提供对日志文件、配置文件、Windows 事件查看器等内容的简单只读访问权限。我们可以解决您描述的问题。我们基本上发明了 DevOps 支持： http: //www.stackify.com

于 2012-08-30T01:24:11.183 回答