如何保护Ansible部署以减轻事故？

最近，Amazon S3 在us-east-1地区发生了重大故障。在Ansible或类似工具中运行维护手册时，可能是由于拼写错误引起的。您可以将shell脚本包装器包裹在ansible-playbook周围，如下所示：

#!/bin/bash
/usr/bin/ansible-playbook "$@" --list-hosts --list-tasks
read -p "Are you sure? (y/n) " answer
test "$answer" = "y" || exit 0
exec /usr/bin/ansible-playbook "$@"

但是，您还可以使用其他一些方法来提高安全性并减少出错的可能性，这会给您的公司造成严重的故障。

ansible process

— 吉里·克鲁达（Jiri Klouda）
source

我投票结束这个问题是因为离题，因为它更适合unix.stackexchange.com或superuser.com

— Romeo Ninov

基础架构即代码是每天进行数百次部署的关键组件之一。在我看来，能够保护能够提供这种速度的工具而不会在运营中造成重大停机的问题似乎是一个相关主题。我当然是错的。我非常感谢您的观点。您是否想加入有关Meta中有关主题话题的讨论？

— 吉里·克鲁达

例如这个问题似乎被接受为话题：devops.stackexchange.com/questions/98/...

— 吉日Klouda

吉里（Jiri），您是否提到其他问题？

— 罗密欧·尼诺夫

如果这类问题适合于超级用户，则不需要devops.se。这绝对是这里的话题。操作和缓解人为错误是DevOps的核心。

— Evgeny

我们正在使用詹金斯中的作业来触发部署。它确保无论由谁进行部署，运行的ansible命令都将相同。一个不错的好处是，构建日志记录可以记录何时触发部署，谁触发了部署以及部署期间发生了什么。

这当然不是万无一失的，但是相对于手动运行Ansible剧本来说，这是一个不错的改进。

对于较大/风险较大的更改，理想情况下，应将其与某种形式的更改管理结合使用，以便仅在另一个人/团队检查更改和更改方法以帮助及早识别和解决潜在问题之后进行更改。

此外，拥有一个团队成员了解您正在进行的更改并在进行重大更改时观察并从此无济于事，这样他们就可以观察并帮助防止更改执行中的错误。

— 布雷迪
source

错误类别

有两种方法可以查看导致问题和事故的人为因素：

您可以将人为错误视为事故的原因。在这种情况下，调查的结论是“人为错误”，无论情况如何，包括情境意识的丧失，程序违规，监管不足，管理缺陷。
您可以将人为错误视为更深层麻烦的征兆。在这种情况下，人为错误是您调查的起点。您将探讨人为错误如何与人们的工具，任务和运营/组织环境的特征系统地联系在一起。

第一种称为人工方法，第二种称为系统方法。

要使用人为方法解释失败，您将寻求失败并发现人们的评估不准确，错误的决定或错误的判断。

为了使用系统方法来解释失败，您并没有试图找出人们哪里出错了。取而代之的是，根据周围的环境，找出当时人们的评估和行动是如何有意义的。

例如，医疗保健改善研究所（IHI）的唐纳德·伯威克（Donald Berwick）认为，提高患者安全性需要对系统设计进行更改：

...我们是人类，人类是错误的。尽管有愤怒，有悲伤，有经验，尽管我们尽了最大的努力，尽管我们有最深切的愿望，但我们天生容易犯错，并将继续保持下去。谨慎会有所帮助，但这并不能带给我们完美的解决方法。补救措施是在设计中。目标应该是极端安全。我相信我们在医院中应该像在家中一样安全。但是，我们不能通过劝告，谴责，暴行和耻辱达到这一目标。我们只有通过做出改变的承诺才能实现这一目标，这样才能使正常的人为错误与结果无关，不断发现并巧妙地加以缓解。

唐纳德·贝里克（Donald M Berwick）。再没有！英国医学杂志2001

消除系统中的错误

查找（并纠正）事实发生后失败的各种方式的一种好方法是寻找根本原因，而不会怪罪于人们。这通常被称为“无罪的验尸”，Etsy Code作为Craft博客文章扩展了这一概念。Etsy的人们在其他论坛和博客上发表并撰写了更多有关它的文章。

首先，为了防止错误，必须具备一些文化特质。系统中创建的过程和各种工件必须测试人员使用它们的过程是非常清晰且不言自明的。通常，创造者不是消费者，从而导致脱节和缺乏明确性。这样，该系统就不安全运行，因为唯一知道所有假设的人就是创建它的人（没有其他人）。

有效的控制措施

采取有效的控制措施以在发生错误时停止该过程。这是防错的。有效的控制措施是设计变更，当发生错误时，通过引入过程故障来防止或阻止过程继续进行

例：

1896年，丰田章吉（Sakichi Toyoda）发明了日本第一台动力织机，称为“丰田蒸汽织机”。这种发展使生产力提高了20倍，纺织品的质量得到了改善，并引起了日本纺织业的一场革命。但是，这是微妙但非常重要的发现和原理：

断针时机器停止

丰田章男（Sakichi Toyoda）为织布机创造了一项创新，后来成为丰田生产系统（精益）的支柱之一。我们现在将该支柱称为Jidoka，有时也称为“人性化的智能自动化”或“自动化”。

在很大程度上，安东（首先出现缺陷时停止）和波卡-轭（防错）是后来的发展，它们从织机中找到了影响。

消除单点缺陷

单点弱点一词是指在系统中创建冗余，以提高系统可靠性。通过增加过程中涉及的系统或个人的数量来创建冗余。具有更多的备份系统或更多的检查（两次，三次或更多次）会增加该过程正确进行的可能性。

一个很好的例子是“四眼原则”，这意味着“所有业务决策和交易都需要获得首席执行官和首席财务官的批准。由于首席财务官没有向首席执行官汇报，因此存在独立的控制机制” 。

^{来源：https : //en.wikipedia.org/wiki/Two-man_rule}

消除危害

如果危险变得明显或无法达到，则人类将不会犯错。例如，颜色编码是使错误更明显的常用方法。或者，如果您想到只能以一种方式插入而不能以另一种方式插入的各种计算机插座，等等。

一些很棒的书都在谈论这个主题，如果不提及它们，那将不是一个好的答案：

— 叶夫根尼
source

您没有提到的一个非常重要的方法是在金融中使用的“四眼原则” –作为监管义务或作为安全保障。在软件行业中，它以多种方式实现，例如代码审查，但也可用于验证影响实时系统的命令。

— Michael Le BarbierGrünewald17年

我将其添加到SPW原理中。

— Evgeny

关于错误的精彩讨论，但并未说明如何防止意外部署。

— 亚历山大

这个问题专门问Ansible。这个答案是非常彻底的和经过深入研究的，但它距现实世界的问题仅一步之遥。

— Woodland Hunter

@Evgeny当我回答您的AWS Lambda性能问题时，起初我没有说如何运行测试，您却指出了这一点。你说得对，我调整了答案。我了解有人在这里拒绝您的回答。对于“如何处理和减少工作场所中的错误？”的问题，您的答案将是有益的。在这里，OP有一个关于Ansible的问题，您甚至没有提到它。更糟糕的是，OP指出了他正在寻找的解决方案类型，而您却选择了另一种方法。您的回答很好（真的），但不是这个问题。

— 亚历山大

正如@bradim所说，使用CI / CD工具来启动部署而不是基于手工的命令通常是向前迈出的好一步，在管道中添加测试以实际测试登台（或新创建）环境中的部署脚本的测试也是如此。您可以更早地发现错误。

我还要补充一点，您可以直接在流中添加Ansible Tower之类的工具，而不是直接调用您的ansible脚本，这将使您可以更轻松地跟踪已运行的更改，并可以为您提供额外的安全性流。

— z
source