事故を軽減するためにAnsibleデプロイメントを保護する方法は？

最近、Amazon S3はus-east-1リージョンで大規模な停止がありました。Ansibleまたは同様のツールでメンテナンスプレイブックを実行しているときに、スペルミスが原因であると思われます。次のように、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コマンドは同じになります。良いボーナスは、デプロイメントがいつトリガーされたか、誰がトリガーしたか、そしてデプロイメント中に正確に何が起こったか、ビルドログレコードです。

それは確かに絶対確実というわけではありませんが、ansibleプレイブックを手動で実行するよりも優れた改善点です。

より大きな/よりリスクのある変更の場合、これは何らかの形の変更管理と組み合わせるのが理想的です。変更は、別の人/チームが変更と変更へのアプローチを検討して初めて、潜在的な問題を早期に特定して解決するのに役立ちます。

さらに、大きな変更を加えている間、あなたが行っている変更を理解しているチームメイトがいて、見守っていて、変更の実行を間違えないようにすることができます。

エラーのカテゴリー

問題や事故につながる人的要因を見る方法は2つあります。

1. ヒューマンエラーは事故の原因として見ることができます。この場合、どのようなラベルの下でも、「人的ミス」、つまり状況認識の喪失、手続き違反、規制の不足、経営上の不備が調査の結論です。
2. ヒューマンエラーは、より深いトラブルの兆候と見ることができます。この場合、ヒューマンエラーが調査の開始点です。ヒューマンエラーが、人々のツール、タスク、運用/組織環境の機能に体系的にどのように関連付けられているかを調査します。

1つ目はヒューマンアプローチと呼ばれ、2つ目はシステムアプローチと呼ばれます。

人間のアプローチを使用して失敗を説明するには、失敗を求め、人々の不正確な評価、間違った決定、または誤った判断を見つけるでしょう。

システムアプローチを使用して失敗を説明するために、あなたは人々がどこで間違ったのかを見つけようとしているのではありません。代わりに、人々を取り巻く状況を考慮して、当時の人々の評価と行動がどのように理にかなっているかを見つけてください。

たとえば、ヘルスケア改善研究所（IHI）のドナルドバーウィックは、患者の安全を改善するにはシステムの設計を変更する必要があると主張しています。

...私たちは人間であり、人間は間違っています。怒りにもかかわらず、悲しみにもかかわらず、経験にもかかわらず、私たちの最善の努力にもかかわらず、私たちの深い願いにもかかわらず、私たちは過ちを犯して生まれ、そのままです。注意することは役立ちますが、完璧に近づくことはできません...救済策は、仕事のシステムを変えることです。救済策は設計中です。目標は、極度の安全であるべきです。私達は私達が私達の家にいるのと同じように私達の病院にも安全でなければならないことを信じています。しかし、私たちは、勧め、非難、怒り、そして恥によってその目標に到達することはできません。変化へのコミットメントによってのみ到達することができるため、通常の人為的エラーを結果に関係なく作成し、継続的に発見し、巧みに緩和することができます。

ドナルドMバーウィック。二度とない！BMJ 2001

システムからミスを取り除く

事後に障害が発生するさまざまな方法を見つけて修正するための優れた方法は、人々を責めることなく根本原因を探すことです。これは「非難の死後」と呼ばれることが多く、Craftブログの投稿としてのEtsyコードはその概念を拡張しています。Etsyの人々は、他のフォーラムやブログでそれについてより多くのことを発表し、書きました。

そもそも間違いを防ぐために、いくつかの文化的特性は必須です。システムで作成されたプロシージャとさまざまなアーティファクトは、人間によるそれらの使用が非常に明確で自明であることをテストする必要があります。多くの場合、作成するのは消費するのではなく、接続が切断され、明快さが欠如します。その場合、すべての仮定を知っているのはそれを作成した人だけであり、他の誰もいないため、システムは安全に動作しません。

効果的な管理策

エラーが発生したときにプロセスを停止するための効果的な管理手段を導入します。これは間違い防止です。効果的な制御手段は、プロセス障害を導入することにより、エラーが発生したときにプロセスの続行を防止または停止する設計変更です

例：

1896年、豊田佐吉は日本で最初に「豊田蒸気力織機」と呼ばれる動力織機を発明しました。この開発により生産性が20倍になり、テキスタイルの品質が向上し、日本の繊維産業に革命をもたらしました。しかし、ここに、微妙ですが非常に重要な発見と原則があります。

針が折れたとき、マシンが停止しました

豊田佐吉が織機に革新をもたらし、後にトヨタ生産システム（リーン）の柱の1つになります。私たちが現在ジドカと呼んでいるその柱は、「ヒ​​ューマンタッチによるスマートオートメーション」または「オートノメーション」と呼ばれることもあります。

主に、Andon（最初の欠陥で停止）とPoka-Yoke（間違いの防止）は、Loomからの影響を発見した後の開発です。

シングルポイントの弱点を取り除く

シングルポイントの弱点という用語は、システムの信頼性を向上させるためのアプローチとして、システムに冗長性を作成することを指します。冗長性は、プロセスに関与するシステムまたは個人の数を増やすことによって作成されます。より多くのバックアップシステムまたはより多くのチェック（ダブル、トリプル、またはそれ以上）を使用すると、プロセスが正しく進行する可能性が高くなります。

これの1つの優れた例が「4つの目」の原則です。つまり、「すべてのビジネス上の決定と取引には、CEOとCFOの承認が必要です。CFOはCEOに報告しないため、独立した制御メカニズムが導入されています」 。

^{ソース：https : //en.wikipedia.org/wiki/Two-man_rule}

ハザードを明らかにする

危険が明らかになったり、到達が不可能になったりした場合、人間は間違いを犯すことができません。たとえば、色分けは間違いをより明白にする一般的なアプローチです。あるいは、一方向にしか挿入できず、他の方法では挿入できないさまざまなコンピュータソケットを考えた場合などです。

いくつかの優れた本はその主題について話しているので、それらに言及しないとそれは良い答えにはなりません：

• シドニー・デッカーによる「ヒューマンエラー」を理解するためのフィールドガイド
• サイト信頼性エンジニアリング：Googleによる本番システムの実行方法
• ゼロ品質管理：ソース検査とシンゴシゲオによるポカヨークシステム

@bradimが言ったように、ステージング（または新しく作成された）環境で実際にデプロイメントスクリプトをテストするパイプラインにテストを追加するのと同様に、手作業のコマンドの代わりにCI / CDツールを使用してデプロイメントを開始します。早くバグを拾うことができます。

ansibleスクリプトを直接呼び出す代わりに、Ansible Towerなどのツールをフローに追加することもできます。これにより、実行された変更をより簡単に追跡でき、セキュリティを強化できます。フロー。