災害時でも、
DRP（災害復旧計画）ティーを飲む時間は常にあります。これは理想的には必要のないものです。しかし、交配期に突然移動するビーバーがバックボーンの光ファイバをかじったり、後輩の管理者が生産的な基盤を落としたりした場合は、このすべての混乱をどうするかについて事前に計画を立てておく必要があります。
パニックに陥っている顧客がテクニカルサポートの電話を切り始めている間、ジュニアはシアン化物を探しています。あなたは賢明に赤い封筒を開けて、すべてを整え始めます。
この投稿では、DRPの作成方法とその内容に関する推奨事項を共有したいと思います。また、次のことも見ていきます。
- 悪人のように考えることを学びましょう。
- 黙示録の間に一杯のお茶の利点を見てみましょう。
- 便利なDRP構造を考えます
- それをテストする方法を見てみましょう。
どの会社にとってそれは役に立つことができます
IT部門がこれらのものを必要とし始めたときに線を引くことは非常に困難です。次の場合、DRPが必要になることが保証されています。
- サーバー、アプリケーションの停止、または一部の基盤の喪失は、ビジネス全体の重大な損失につながります。
- 本格的なIT部門があります。会社の本格的なユニットの形をした部門という意味で、独自の予算があり、ネットワークを構築し、ウイルスをクリーニングし、プリンターに燃料を補給する疲れた従業員が数人いるだけではありません。
- 緊急時に少なくとも部分的な冗長性を確保するための現実的な予算があります。
IT部門が数か月間、バックアップ用の古いサーバー用に少なくとも2台のHDDを要求した場合、容量を予約するために、落ちたサービスの本格的な転送を計画することはできません。ここのドキュメントは不必要ではありませんが。
ドキュメントは重要です
ドキュメントから始めます。あなたのサービスが3世代前の管理者によって書かれたPerlスクリプトに基づいており、それがどのように機能するか誰も知らないとしましょう。蓄積された技術的負債と文書の欠如は、必然的に膝だけでなく他の手足でもあなたを撃ちます、それはむしろ時間の問題です。
手元にあるサービスコンポーネントの適切な説明ができたら、クラッシュ統計を表示します。それらはほぼ確実に完全に典型的です。たとえば、ディスクがいっぱいになることがあり、手動でクリーニングする前にノードに障害が発生します。または、誰かが証明書の更新を再度忘れたためにクライアントサービスが利用できなくなり、Let's Encryptが証明書を構成できなかったか、構成したくなかった。
妨害者のような考え
最も難しいのは、これまでに発生したことのない事故を予測することですが、それによってサービスが完全に停止する可能性があります。ここでは通常、同僚と悪役を演じます。たくさんのコーヒーとおいしいものを取り、会議室に閉じ込めてください。同じ会議室で、自分でターゲットサービスを上げたり、定期的に使用したりするエンジニアをロックしていることを確認してください。次に、ボード上または紙上で、サービスに発生する可能性のあるすべての恐怖を描き始めます。特定のクリーナーに詳細を記述してケーブルを引き出す必要はありません。「ローカルネットワークの整合性の違反」のシナリオを検討するだけで十分です。
通常、最も一般的な緊急事態は次のタイプに当てはまります。
- ネットワーク障害
- OSサービスの失敗
- アプリケーションの失敗
- 鉄の故障
- 仮想化の失敗
各ビューを確認して、サービスに何が適用されるかを確認してください。たとえば、Nginxデーモンがクラッシュして起動しない場合があります。これは、OS側の障害です。Webアプリケーションが機能しない状態になるまれな状況は、ソフトウェアの障害です。この段階を経て作業している間、問題の診断を行うことが重要です。たとえば、仮想化でハングしたインターフェイスを、tsiskaの落下やネットワーククラッシュと区別する方法。責任者をすばやく見つけて、事故が解決するまで彼らの尻尾を引っ張り始めることが重要です。
典型的な問題が書き留められた後、私たちはより多くのコーヒーを注ぎ、いくつかのパラメーターが標準を超え始めたときに最も奇妙なシナリオを検討し始めます。例えば：
- アクティブノードの時間がクラスター内の他のノードと比較して1分戻るとどうなりますか？
- そして、時間が進むと、10年までに？
- 同期中にクラスターノードが突然ネットワークを失った場合はどうなりますか？
- また、ネットワーク上で一時的に相互に分離されているために2つのノードがリーダーシップを共有しない場合はどうなりますか？
逆のアプローチは、この段階で大いに役立ちます。あなたは病気の想像力を持った最も頑固なチームメンバーを連れて行き、彼にできるだけ早く妨害を手配する任務を与えます。それはサービスを停止させます。それを診断するのが難しい場合は、さらに良いです。何かを壊すアイデアをエンジニアに与えた場合、エンジニアが思いついた奇妙でクールなアイデアを信じることはできません。そしてすでにあなたが彼らにこれのためのテストベンチを約束するなら、それはとても良いです。
あなたのこのDRPは何ですか？！
これで、脅威モデルを定義しました。銅を求めて光ファイバーケーブルを切断した地元の人々や、金曜日の午後4時46分に無線中継線を厳密に落とす軍用レーダーも考慮されました。今、私たちはこれらすべてをどうするかを理解する必要があります。
あなたの仕事は、緊急時に開かれる非常に赤い封筒を書くことです。すべてがうまくいき始めたら、最も経験の浅い研修生だけが近くにいて、起こっていることの恐怖から手を激しく揺らしていることをすぐに期待してください。緊急標識が診療所でどのように実施されているかをご覧ください。たとえば、アナフィラキシーショックの場合の対処法。医療スタッフはすべてのプロトコルを心から知っていますが、彼の隣の人が死に始めたとき、非常に多くの場合、誰もが無力にすべてをつかみます。これを行うために、「これのパッケージを開ける」および「非常に多くの単位の薬剤を静脈内に注射する」などの項目を含む明確な指示が壁にあります。
緊急時に考えるのは難しいです！脊髄による解析のための簡単な指示があるはずです。
優れたDRPは、いくつかの単純なブロックで構成されています。
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
DRPは、サービスが完全に失敗したときに開始され、効率が低下しても再構築されることに注意してください。予約を失っただけでは、DRPはアクティブになりません。 DRPにお茶を追加することもできます。真剣に。統計によると、パニック状態のスタッフが急いで何かを修正し、同時にデータのある唯一のライブノードを強制終了するか、最終的にクラスターを終了するという事実により、不快な事故の多くは壊滅的なものになります。通常、お茶を5分間飲むと、落ち着いて何が起こっているのかを分析する時間が与えられます。
DRPとシステムパスポートを混同しないでください！不要なデータで過負荷にしないでください。ハイパーリンクをすばやく便利に使用して、ドキュメントの必要なセクションに移動し、サービスアーキテクチャの必要なセクションについて拡張形式で読むことができるようにするだけです。また、DRP自体には、コピーアンドペーストの特定のコマンドに接続する場所と方法に関する直接的な指示しかありません。
正しくテストする方法
責任者がすべてのポイントを完了できることを確認してください。最も重要な瞬間に、エンジニアが必要なシステムへのアクセス権を持っていない、必要なアカウントのパスワードがない、または「本社のプロキシを介してサービス管理コンソールに接続する」とはどういう意味かわからないことが判明する場合があります。各ポイントは非常に単純である必要があります。
間違った-「仮想化に移動してデッドノードを再起動する」
正しい-「Webインターフェイスを介してvirt.example.comに接続し、ノードセクションでエラーの原因となったノードを再起動します。」
あいまいさを避けてください。おびえた訓練生を覚えておいてください。
必ずDRPをテストしてください。これは単にチェックする計画ではありません-それはあなたとあなたの顧客が危機的な状況から素早く抜け出すことを可能にするものです。これを数回行うのが最適です。
- 1人の専門家と数人の研修生が、実際のサービスを可能な限りシミュレートするテストベンチで作業します。専門家はさまざまな方法でサービスを中断し、研修生がDRPに従ってサービスを復元できるようにします。すべての問題、ドキュメントのあいまいさ、エラーが記録されます。研修生を訓練した後、DRPはあいまいな場所で補足され、簡素化されます。
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
