谁应该编写Docker文件？

公司争论再次引起了谁应该编写Docker文件的争论（包括撰写，可互换的这篇文章）。
这种情况在我的工作（开发人员和顾问）中很常见，我想知道是否有严格的规定用于创建和管理Docker文件。我在以下三种情况下进行过操作：
1.）Dev-ops编写和管理Docker文件
优点：它们对生产没有什么意外，并最终控制了最终实例
缺点：开发人员对Docker /服务器的了解较少，必须等待某些更改或征求许可，或者需要操作团队人员进行诸如添加环境变量之类的操作
2。）开发人员编写和维护Docker文件
优点：开发人员可以继续工作，在团队内部可以解决冲突和冲突
缺点：开发人员操作通常会遇到不良或困扰的Docker文件进行生产。开发运营还花费时间解决Docker文件上的开发人员问题。开发人员通常不关注实例的安全性。
3.）混合方法：开发人员编写Docker文件以结合dev-ops策略或需求使用。 Dev-ops在工作Docker文件的开发人员基础上建立了一个不同的生产docker文件，但增加了秘密处理，Terraform / IaC / CI + CD的需求，并负责实例上运行的Docker文件。
在这种情况下，dev-ops团队观看了我们的（开发人员）文件，并使用差异来提出问题或深入了解更改。
-
我一遍又一遍地遇到的问题（关于Docker文件）：

由于各种原因（场景1），开发人员无法进行简单更改
开发人员进行的更改会使开发人员不满意（所有情况）
开发人员需要“ 2周通知任何更改”或类似内容令人无法接受的延迟（方案1）
开发人员花费太多时间来学习如何与基础架构兼容并降低生产力（方案1）
Dev-ops获取垃圾文件（方案2）
安全责任和其他与操作有关的任务在部门之间分担（发生问题时会发生内in）（在所有情况下都存在问题）

遇到的问题列表很长，但是我希望这是足够的信息在负责Docker最多并负责正常运行时间的专业人员之间建立一个关于此主题的对话。
7月23日，对@MLu的回复：
Dev ops是“ Developer Operations”，如部署和基础架构中所述东西的。 “一起工作”总是会发生，但这是两条截然不同的职业道路和专业领域（开发人员和运营人员）。正如Wikipedia条目强调我的观点一样，有一些关于上下文对范例的依赖的说明。 Dev写代码，Ops编写实例，中间是协作。因此，我完全不同意“ DevOps模型完全是这两个角色的融合。”，而不是在我17年的许多团队中。
其中一个团队被视为“ SRE”，而另一个团队则喜欢“ Devops” ”和另一个“ Infra（甚至不回答使用devop的人）”。每个团队都有他们自己的想法，但最终在为项目的开发方面服务时会遇到相同的问题。
CI和CD中的开发和“操作”需要一起工作，但出于某种原因，只有这些“操作”团队才能参与其中。所有情况都是公认的痛点。为什么如此常见？
如果DevOps是基于开发人员实践（敏捷，依赖SCM，DRY等）而诞生的，并且通常由大量的前开发人员组成，那么为什么在构建/运输/管道方面的人员配置却是分散的通常反应或响应速度慢，需要较长的交付时间，并且通常是项目中最常见的障碍。我质疑这些行动小组的象牙城堡宣言。当一个团队超负荷工作，表现欠佳，与既定准则背道而驰时，“ X需要做Y”的（教条）可能是解决方案，也可能是吸管？我确实同意@MLu关于通过PR和其他概述方法管理Docker文件的评论。我将响应理解为我更喜欢的一种混合方法。
挫败根源于我曾经是“开发”的几个项目，而我们拥有基于云的产品，具有复杂的CI / CD和其他操作。但是我们从未遇到过发展问题。只要有专职团队处理这些要素，事情就会变慢，正常运行时间会受到影响，并且产品发布周期会变得压力更大。我们的一个干部正在讨论当前范式的替代方案，因为我们在组织中以及在不同的工作中一遍又一遍地重复着相同的问题。