#1 楼
我们正在使用詹金斯中的作业来触发部署。它确保无论由谁进行部署，运行的ansible命令都将相同。一个不错的好处是，在部署触发时，谁触发了部署以及部署过程中到底发生了什么的构建日志记录。当然不是万无一失的，但是与手动运行可玩剧本相比，这是一个不错的改进。
对于较大/风险较大的更改，理想情况下，应将其与某种形式的更改管理结合使用，以便仅在另一个人/团队检查更改和更改方法以帮助识别和解决潜在问题之后进行更改
另外，拥有一个团队成员了解您正在进行的更改并在进行重大更改时注视它，这对他们没有伤害，因此他们可以监视并帮助防止执行更改中的错误。
#2 楼
错误类别有两种方法可以查看导致问题和事故的人为因素：
您可以将人为错误视为导致错误的原因。不幸在这种情况下，
“人为失误”在任何情况下都属于调查的结论，无论情况是什么，都应注意情势意识缺失，程序违规，监管不足，管理缺陷。
您可以将人为失误视为症状的征兆。更深的麻烦。在这种情况下，人为错误是您调查的起点。您
将探讨人为错误如何与人们的工具，任务以及运营/组织环境的特征系统地联系起来。
第一个被称为人为方法，第二个被称为人为方法作为系统方法。
要使用人为方法来解释失败，您将寻求失败并发现人们的错误评估，错误决策或错误判断。系统方法中，您不是要查找人们出问题的地方。取而代之的是，根据周围的环境，找出当时人们的评估和行动是如何有意义的。在系统设计中：
...我们是人类，人类是错误的。尽管有愤怒，有悲伤，有经验，尽管我们尽了最大的努力，尽管我们有最深切的愿望，但我们天生会犯错误，并且会一直如此。细心的帮助会给您带来帮助，但这并不能带给我们完美的解决方法。补救措施是在设计中。目标应该是极端安全。我相信我们在医院中应该像在家中一样安全。但是，我们不能通过劝告，谴责，暴行和耻辱达到这一目标。我们只有通过做出改变的承诺才能实现这一目标，这样才能使正常的人为错误与结果无关，不断发现并巧妙地加以缓解。再没有！ BMJ 2001
从系统中消除错误
查找（并纠正）事实发生后各种故障的一种好方法是寻找根本原因而不责怪人民。这通常被称为“无罪的验尸”，Etsy Code作为Craft博客发布了这一概念的扩展。 Etsy的人们在其他论坛和博客上发表了有关它的文章，并对此进行了更多介绍。系统中创建的过程和各种工件必须测试人员使用它们的过程是非常清晰且不言自明的。通常，创造者不是消费者，从而导致脱节和缺乏明确性。这样，该系统就不安全运行，因为唯一知道所有假设的人就是创建该假设的人（而没有其他人）。采取有效的控制措施以在发生错误时停止该过程。这是防错的。有效的控制措施是设计变更，通过引入过程故障来防止或阻止发生错误的过程继续进行。
示例：
1896年，丰田章吉（Sakichi Toyoda）发明了日本第一台动力织机，称为“丰田蒸汽织机”。这种发展使生产力提高了20倍，纺织品的质量提高了，并引起了日本纺织业的一场革命。但是，这是一个微妙但非常重要的发现和原理：
断针时，机器停止运转
Sakichi Toyoda对织机后来成为丰田生产系统（精益）的支柱之一。我们现在称其为Jidoka的支柱，有时也称为“人性化的智能自动化”或“自动化”。
在很大程度上，Andon（首先出现缺陷时停止）和Poka-Yoke（防错）是
消除单点弱点
单点弱点一词是指在系统中创建冗余以作为解决方法提高系统可靠性。通过增加过程中涉及的系统或个人的数量来创建冗余。具有更多备份系统或更多检查（两次，三次或更多次检查）会增加该过程正确进行的可能性。
一个很好的例子是“四眼原则”，这意味着“所有业务决策和交易都需要获得CEO和CFO的批准。由于CFO不会向CEO汇报，因此存在独立的控制机制。” wikipedia.org/wiki/Two-man_rule
使危险变得明显
如果危险变得明显或不可能达到，则人类将不会犯错。例如，颜色编码是使错误更明显的常用方法。或者，如果您想到只能以一种方式插入而不能以另一种方式插入的各种计算机插槽，等等。
一些好书都在谈论这个主题，那不是一个好方法。答案不提：
Sidney Dekker理解“人为错误”的现场指南
站点可靠性工程：Google如何运行生产系统
零质量控制：源检验和Shikao Shingo的Poka-Yoke系统
评论
您没有提到的一个非常重要的方法是在金融中使用的“四眼原则” –作为监管义务或作为安全保障。在软件行业中，它以各种方式实现，例如代码审查，但也可用于验证影响实时系统的命令。
–MichaëlLe Barbier
17 Mar 4 '17 at 11:27
我将其添加到SPW原理中。
– Evgeny Zislis
17 Mar 4 '17 at 11:29
关于错误的精彩讨论，但并未说明如何防止意外部署。
–亚历山大
17 Mar 4 '17 at 13:03
问题专门询问Ansible。这个答案是非常彻底的和经过深入研究的，但它距现实世界的问题仅一步之遥。
–林地猎人
17 Mar 5 '17 at 0:13
@Evgeny当我回答您的AWS Lambda性能问题时，起初我没有说如何运行测试，您却指出了这一点。你说得对，我调整了答案。我了解有人在这里拒绝您的回答。对于“如何处理和减少工作场所中的错误？”的问题，您的答案将是有益的。在这里，OP有一个关于Ansible的问题，您甚至没有提及。更糟糕的是，OP指出了他正在寻找的解决方案类型，而您却选择了另一种方法。您的回答很好（真的），但不是这个问题。
–亚历山大
17 Mar 5 '17 at 6:39
#3 楼
正如@bradim所说，使用CI / CD工具来启动部署而不是基于手工的命令通常是向前迈出的好一步，在管道中添加测试以实际测试您的登台（或新创建）环境中的部署脚本的测试也是如此。您可以更早地发现错误。我还想补充一点，您可以直接在流中添加Ansible Tower之类的工具，而不是直接调用您的ansible脚本，这将使您跟踪已进行的更改。运行起来更轻松，并且可以为您的流程提供额外的安全保护。
评论
我投票结束这个问题是因为离题，因为它更适合unix.stackexchange.com或superuser.com基础架构即代码是每天进行数百次部署的关键组件之一。在我看来，能够保护能够提供这种速度的工具而不会在运营中造成重大停机的问题似乎是一个相关主题。我当然是错的。我非常感谢您的观点。您是否想加入有关Meta中有关主题话题的讨论？
例如，这个问题似乎被接受为话题：devops.stackexchange.com/questions/98/…
吉里，您是否提到其他问题？
如果这些问题适合于超级用户，则不需要devops.se。这绝对是这里的话题。操作和缓解人为错误是DevOps的核心。