问题描述
最近，亚马逊S3在us-east-1地区发生了一次重大故障。看起来这很可能是由于在运行Ansible或类似工具的维护playbook时出现了拼写错误。有人提出了一个解决方案，可以在ansible-playbook周围添加一个shell脚本包装器，如下所示：
#!/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 "$@"
但是，你还知道有哪些其他方法可以提高安全性，减少错误导致公司发生重大故障的机会？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
使用CI/CD工具触发部署
使用CI/CD工具来触发部署是一个不错的方法，它可以确保无论谁执行部署，运行的ansible命令都是相同的。一个很好的附加优势是构建日志记录了部署的触发时间、触发者以及部署过程中发生的情况。虽然这并不是绝对可靠的，但相比手动运行ansible playbooks，这是一个很好的改进。
对于更大、更有风险的更改，最好将其与某种形式的变更管理结合使用，以便在另一个人/团队审查变更和变更方法之后才进行更改，以帮助及早发现和解决潜在问题。
此外，对于重大更改，最好有一个了解你正在进行的更改的团队成员在场并观察，以便他们可以在执行更改过程中观察并帮助防止错误。
使用Ansible Tower
除了直接调用ansible脚本外，你还可以将类似Ansible Tower的工具添加到你的流程中。Ansible Tower可以更轻松地跟踪已运行的更改，并为你的流程提供额外的安全性。
添加测试
在你的流水线中添加测试，可以在你的staging环境（或新创建的环境）上对部署脚本进行测试，以便更早地发现错误。
其他建议
- 使用“四眼原则”：在财务领域，所有业务决策和交易都需要首席执行官和首席财务官的批准。通过增加备份系统或多次检查（双重、三重或更多），可以增加流程正确进行的概率。
- 使危险明显：如果能够让危险明显或无法触及，人们就不会犯错误。例如，使用颜色编码可以使错误更加明显。或者，想想各种计算机插座，只能插入一种方式而不能插入另一种方式等等。
相关书籍推荐
- 《The Field Guide to Understanding ‘Human Error’》 by Sidney Dekker
- 《Site Reliability Engineering: How Google Runs Production Systems》
- 《Zero Quality Control: Source Inspection and the Poka-Yoke System》 by Shigeo Shingo
以上是一些提高安全性、减少错误的方法和建议，希望对你有所帮助。
参考资料：
– Ansible Tower
– Etsy Code as Craft blog post
– More about blameless post-mortems
– The Four-Eyes Principle
请注意，这些建议并不能完全保证防止意外部署，但它们可以帮助你提高安全性并减少错误的风险。