DRP の準備 - 隕石を考慮することを忘れないでください

災害時でも、お茶を飲む時間は必ずあります。

DRP （災害復旧計画）は、理想的には決して必要とされないものです。 しかし、発情期に移動してきたビーバーが突然幹線光ファイバーをかじったり、下級管理者が生産基盤を落としたりした場合、この不名誉な事態にどう対処するかについて事前に計画を立てておく必要があります。

パニックに陥った顧客がテクニカル サポートに電話をかけ始める中、後輩がシアン化物を探している中、あなたは賢明にも赤い封筒を開け、すべてを整理し始めます。

この投稿では、DRP の作成方法とそれに含まれるものについての推奨事項を共有したいと思います。 以下についても見ていきます。

1. 悪役のように考えることを学びましょう。
2. 黙示録における一杯のお茶の利点を分析してみましょう。
3. 便利なDRP構造を考える
4. テスト方法を見てみましょう

この恩恵を受ける可能性があるのはどの企業でしょうか?

IT 部門がこれらのものを必要とし始めると、線を引くのは非常に困難です。 次の場合には、確実に DRP が必要になると言えます。

• サーバーやアプリケーションを停止したり、データベースの一部を失ったりすると、ビジネス全体に重大な損失が生じます。
• 本格的な IT 部門があります。 つまり、ネットワークを敷設したり、ウイルスを駆除したり、プリンターを補充したりする数人の疲れた従業員だけではなく、独自の予算を持つ会社の本格的な単位としての部門です。
• 緊急時に少なくとも部分的な冗長性を確保するための現実的な予算を用意しておきます。

IT 部門が何か月もの間、古いサーバーのバックアップ用に少なくとも XNUMX 台の HDD を懇願してきた場合、空き容量を確保するために障害が発生したサービスの本格的な再配置を計画できる可能性は低いでしょう。 ただし、ここでもドキュメントは不必要ではありません。

文書化は重要です

まずはドキュメントから始めます。 あなたのサービスが、管理者の XNUMX 世代前に書かれた Perl スクリプトで実行されており、それがどのように機能するのか誰も知らないとします。 蓄積された技術的負債と文書の欠如により、膝だけでなく他の手足にも悪影響を与えることは避けられず、それは時間の問題です。

サービス コンポーネントについて十分な説明を用意したら、クラッシュ統計を上げます。 ほぼ間違いなく、それらは完全に典型的なものとなるでしょう。 たとえば、ディスクが時々いっぱいになると、手動でクリーンアップするまでノードに障害が発生します。 または、誰かが再び証明書の更新を忘れたが、Let's Encrypt をセットアップできなかった、またはセットアップしたくなかったために、クライアント サービスが利用できなくなります。

破壊工作員のような考え

最も難しいのは、これまでに発生したことはないものの、サービスを完全に台無しにする可能性がある事故を予測することです。 ここでは通常、同僚と一緒に悪役を演じます。 コーヒーとおいしいものをたくさん飲んで、会議室に閉じこもります。 同じ会議で、対象のサービスを開発したり、定期的に使用したりするエンジニアをロックするようにしてください。 次に、ボードまたは紙に、サービスに起こり得るすべての恐怖を描き始めます。 特定の清掃員やケーブルの引き出しまで詳細に説明する必要はありません。「ローカル ネットワークの整合性の侵害」というシナリオを考慮するだけで十分です。

通常、最も典型的な緊急事態は次のタイプに当てはまります。

• ネットワーク障害
• OSサービス障害
• アプリケーションの失敗
• 鉄の故障
• 仮想化の失敗

各ビューを確認して、サービスに何が当てはまるかを確認してください。 たとえば、Nginx デーモンが停止し、起動しない場合があります。これは OS 側の障害です。 まれに、ソフトウェア障害によって Web アプリケーションが動作しなくなることがあります。 この段階の開発では、問題の診断を行うことが重要です。 たとえば、仮想化でハングしたインターフェイスを、シスコの障害やネットワーク クラッシュと区別する方法。 これは、責任者を迅速に見つけて、事故が解決されるまで尻尾を引っ張り始めることが重要です。

典型的な問題を書き留めた後、さらにコーヒーを注ぎ、いくつかのパラメーターが標準を超え始めたときに、最も奇妙なシナリオを検討し始めます。 例えば：

• アクティブ ノードの時間がクラスター内の他のノードと比較して XNUMX 分戻るとどうなりますか?
• そして、時間が進んで10年後だとどうでしょうか？
• 同期中にクラスター ノードが突然ネットワークを失った場合はどうなりますか?
• また、ネットワーク上で相互に一時的に分離されているために XNUMX つのノードがリーダーシップを共有していない場合はどうなるのでしょうか?

この段階では、逆のアプローチが非常に役立ちます。 チームの中で最も頑固で想像力の乏しいメンバーを連れて、可能な限り短い時間で陽動を手配する任務を与えてください。そうすればサービスが停止します。 診断が難しい場合は、さらに良いでしょう。 エンジニアが何かを壊すというアイデアを与えられたときに思いつく、奇妙でクールなアイデアは信じられないでしょう。 そして、これをテストするスタンドを提供すると約束すれば、それは非常に良いことです。

あなたのこの DRP は何ですか?!

これで脅威モデルが定義されました。 また、銅を求めて光ファイバーケーブルを切断する地元住民や、金曜日の16時46分に厳密に無線中継線を投下する軍用レーダーも考慮に入れられた。 次に、これらすべてをどうするかを考えなければなりません。

あなたの仕事は、緊急時に開封されるのと同じ赤い封筒に書くことです。 すべてが台無しになったとき（そうではない！）、最も経験の浅い訓練生だけが近くにいて、何が起こっているのかという恐怖で手が激しく震えることをすぐに予想してください。 医療オフィスで緊急標識がどのように導入されているかをご覧ください。 例えば、アナフィラキシーショックをどうするか。 医療スタッフはすべての手順を暗記していますが、近くにいる人が死に始めると、多くの場合、誰もが何もできずに何もかもをつかみます。 そのためには、「これこれのパッケージを開けてください」「これだけの単位の薬を静脈内に注射してください」などの明確な説明書が壁に貼られています。

緊急時に考えるのは大変です！ 脊椎解析のための簡単な指示があるはずです。

優れた DRP は、いくつかの単純なブロックで構成されます。

1. 事故の始まりを誰に通知するか。 これは、削除プロセスを可能な限り並列化するために重要です。
2. 正しく診断する方法 - トレースし、systemctl ステータスのサービス名などを調べます。
3. 各ステージに費やすことができる時間。 SLA 時間内に手動で修正する時間がない場合、仮想マシンは強制終了され、昨日のバックアップからロールされます。
4. クラッシュが終わったことを確認する方法。

DRP はサービスが完全に失敗したときに開始され、効率が低下したとしても回復によって完了することに注意してください。 単に予約を失っただけでは、DRP はアクティブ化されません。 DRP でお茶を処方することもできます。 真剣に。 統計によると、多くの事故は、パニックに陥ったスタッフが何かを修復しようと急いで、同時にデータを持つ唯一の生きているノードを停止させたり、最終的にクラスターを終了させたりするという事実により、不快な事故から壊滅的な事故にまで発展します。 原則として、お茶を一杯飲むのに5分間あれば、落ち着いて何が起こっているのかを分析する時間が得られます。

DRP とシステムパスポートを混同しないでください。 不必要なデータで過負荷にしないでください。 ハイパーリンクを介してドキュメントの必要なセクションにすばやく簡単に移動し、サービス アーキテクチャの必要なセクションについて展開された形式で読む機会を与えるだけです。 また、DRP 自体には、コピー＆ペーストのための特定のコマンドをどこにどのように接続するかについての直接的な指示しかありません。

正しくテストする方法

責任ある従業員がすべての項目を完了できることを確認してください。 最も重要な瞬間に、エンジニアが必要なシステムへのアクセス権を持っていない、必要なアカウントのパスワードがない、または「サービス管理コンソールにプロキシを介して接続する」ということが何であるかわからないことが判明する可能性があります。本社」という意味です。 各項目はできるだけシンプルにする必要があります。

間違った - 「仮想化に移動し、デッドノードを再起動します」
正しく - 「Web インターフェイス経由で virt.example.com に接続し、ノード セクションでエラーの原因となっているノードをリロードします。」

曖昧さを避けてください。 怯えたインターンを思い出してください。

必ず DRP をテストしてください。 これは単なる見せかけの計画ではなく、あなたとあなたのクライアントが危機的な状況から素早く抜け出すことができるようにするものです。 これを数回行うのが最善です。

• XNUMX 人の専門家と数人のインターンが、実際のサービスを可能な限り模倣したテストベンチで作業します。 専門家はさまざまな方法でサービスを破壊し、研修生が DRP に従ってサービスを復元できるようにします。 すべての問題、ドキュメント内の曖昧さ、およびエラーが記録されます。 研修生のトレーニング後、DRP は補完され、目立たない場所で簡素化されます。
• 実際のサービスでのテスト。 実際、実際のサービスの完全なコピーを作成することはできません。 したがって、回復順序を評価するために、年に数回、計画的にサーバーの一部を停止し、接続を切断し、脅威のリストからその他の事故を整理する必要があります。 ピーク負荷時に突然障害が発生してデータが損失する数時間よりも、真夜中に 10 分間の計画停止が発生する方が良いでしょう。
• 本当の意味での事故撲滅。 はい、これもテストの一部です。 脅威リストに記載されていない事故が発生した場合には、調査結果に基づいて DRP を補完し、最終的に策定する必要があります。

キーポイント

1. もしデタラメが起こり得るとしたら、それはただ起こるだけではなく、最も壊滅的なシナリオで起こるでしょう。
2. フェイルオーバー用のリソースがあることを確認してください。
3. バックアップがあることを確認してください。バックアップは自動的に作成され、定期的に整合性がチェックされます。
4. 典型的な脅威のシナリオを考えてみましょう。
5. エンジニアに、サービスを導入するための非標準的なオプションを考え出す機会を与えます。
6. DRP はシンプルで愚かな命令でなければなりません。 すべての複雑な診断は、お客様がサービスを復元した後にのみ実行されます。 スタンバイ中でも。
7. DRP に主要な電話番号と連絡先をリストします。
8. 従業員の DRP 理解度を定期的にテストします。
9. 製品に関する計画的な事故を手配します。 スタンドがすべてを置き換えることはできません。

出所： habr.com