我是一个由五人组成的团队的首席开发人员。只有三个是编码员。并且只有编码人员真正具备足够的技术才能将我们的应用程序推广到生产服务器。
我们的应用程序非常成功，我们已经获得了一些知名客户。这些客户通常会让我们通过相当残酷的安全审计。在大多数情况下，我们通过了这些审核。但让我们绊倒的一个领域是职责分离。例如，他们希望一个人/团队处理开发环境，而一个人/团队处理生产环境。此外，有时他们甚至希望从事工作（如推动生产）和监督/监督/批准工作的人也成为单独的角色。
只有三个技术人员的问题是，我们不能在保持某些客户要求的职责分离的同时保持我们的巴士系数很高。
想法？解决方案？您是否遇到过类似的资源问题？
ps 试图标记这个 devops 和总线因素，但我没有足够的代表来创建新标签。
我个人不必做出这个决定，尽管我确实在实施这种职责分离的环境中工作。
您是该企业的所有者还是为其他人工作？
我问的原因是因为实际上这归结为商业决策。（除非有明显的信息安全观点——“把所有的东西分开！”）
要找到答案，您需要问自己/所有者/首席财务官这个问题：
为实施职责分离而增加更多员工的成本是否低于需要这样做的客户损失的业务量，或者您是否可以提高销售软件的成本以支付更多员工的工资而不会失去额外的业务涨价？
如果是这样，那么您可以增加更多员工，而不会让自己陷入财务困境。
欢迎来到企业 IT 安全的世界。正如您所发现的，安全部门很容易提出含糊其辞的“最佳实践”建议。在实地实施这一点要困难得多。但是你可以解决这个问题，你会得到一些好处。
一键式部署- 应打包新版本，以便轻松安装。您可以将其与使用 Puppet 之类的自动部署相结合。此时，部署应该足够简单，您可以将其留给技术水平较低的同事。这种方法的一个好处是它避免了部署错误。开发人员可以在预生产中测试完整部署。
日志关联- 让您的服务器使用 Splunk 之类的工具登录到中央日志关联服务器。您可以在不违反职责分离的情况下授予您的开发团队对此的只读访问权限。您还可以对 CPU、内存、磁盘等进行集中监控。理想情况下，您将对日志进行足够的自动分析，以便技术水平较低的同事可以判断事情是否正常。
尽可能自动化。例行维护应该有脚本和计划。您可能还想编写对问题的某些响应的脚本，例如重新启动应用服务器。
紧急访问- 有时您的应用程序会中断，您需要开发人员登录才能进行修复。即使在职责分离的情况下，这也是可以接受的。您可能想要一个看起来像这样的流程：“操作人员识别故障，请求帮助”“经理批准紧急访问”“操作人员向开发人员发出临时密码”。
如果您做到了所有这些，您可以使用您的两个技术含量较低的同事作为您的运营人员。您的总线因素（BTW 的好词）没有受到严重影响，因为您已经取消了操作角色的技能。
您是在本地还是在云端运行您的应用程序？使用平台即服务云，您可以更轻松地满足此要求。