転倒に備える
これは、災害復旧計画に関する一連の出版物の続きです。 前の記事で 、計画ゾーンの定義と、ユーザーサービスの中断につながる可能性のある障害ポイントの発見について説明しました。 次のステップでは、障害点に関する情報に基づいて、必要なリソースがすべて揃っている場合に技術スペシャリストが提供できるインシデントを排除するための最小限のタイムラインを決定します。
実際、必要なリソースは会社の経営陣とさらに交渉され、情報技術への投資、ダウンタイム、障害発生時のデータ損失のバランスを見出すのに役立ちます。 しかし、これは後でありますが、今のところ、原則として、障害が発生した場合にITインフラストラクチャから絞り出すことができる回復時間の種類を決定する必要があります。 行こう：
1.不良要素をすばやく検出する準備-ローカライズ手順を作成します
最大のダウンタイムは、テクニカルサポートのスペシャリストが連絡先のユーザーのコンピューター上のメールクライアントを頑固に修正しようとするときに発生しますが、メールサーバー自体は修復する必要があります。 この段階でのタスクは、重大な障害に関する情報が、何も邪魔することなくサービスを復元するための作業を実行できる適切な専門家を迅速に見つけることです。 これを行うには、次のことを行います。
- ユーザーサービスの動作と障害点をチェックする手順を作成します。 依存性スキーム（ 第1条 ）のフレームワーク内で、テクニカルサポートの専門家は、ユーザーサービスとその作業が依存する障害点の両方の動作を診断できる必要があります。
- 障害点監視を構成します。 状況によっては、ユーザーの前に問題を報告できます。 その他では、容疑者のリストからいくつかの障害点を除外することができます。
- エスカレーションのルールを決定します。 ビジネスに影響する問題が特定された場合は、すぐにシステム管理者に連絡してください。 ユニットへの影響-障害の原因を突き止めることができなかった場合は、ローカライズ（5分以内）して、復旧のために適切な専門家を連れてくるか、当直のシステム管理者に連絡する
- テクニカルサポートスペシャリストを提供することで、ユーザーサービスの作業におけるさまざまなインフラストラクチャ要素の役割を理解し、障害点を診断するための共通のスキルを持ち、また彼らの目標と目的を理解し、何かが起こったとしても先輩を再び悩ませることを恐れません。
その後、各障害点に関して障害の場所を特定する時間を見積もることができ、これらの値の最大値が「場所特定時間」になります。これは、今後の計算に役立ちます。
2.復旧に必要なリソースと条件を決定します
災害復旧のプロセスでは、4つの段階を区別できます。
- ユーザーサービスが機能しません。
- ユーザーサービスは制限付きで機能します（品質の低下または回避策）。
- ユーザーサービスは完全に復元されましたが、1つ以上のITシステムが劣化したり、必要な予備が不足したりしています。
- すべてのITシステムが復元され、必要な予備が補充されます。
災害復旧を計画する場合、エンドユーザーサービスを完全に復元するための必要十分条件として、第3段階を達成するために必要なリソースと条件に主に関心があります。 これは通常次のとおりです。
- 同様の機能と電力を備えた機器のユニットを予約します。
- 事故発生時のデータ/構成のバックアップコピーおよびそれらへのアクセス。
- ソフトウェア配布。
- ハードウェアとアプリケーションへのアクセス（物理情報とパスワード情報の両方）。
- 関連資格のスペシャリスト。
障害のポイントに応じて、特異性が導入される場合があります：電源の場合、システムを起動するためのディーゼルエンジンまたはバックアッププラットフォームのいずれかが必要であり、UPSの障害の場合、外部DNSホスティング障害の場合、主電源への切り替えが必要です。ドメインを新しいホスティングなどに移管する
必要なすべてのリソースを書き留めて、それらを障害ポイントに結び付けて、すでに所有しているリソースと取得する必要があるリソースをマークします。
3.ユーザーサービスの最小保証復旧時間を決定します
一般に、ユーザーサービスの回復手順は次のとおりです。
この段階での最大の困難は、障害ポイントの保証された回復時間の決定です。 回復手順では、予測可能な期間のルートは1つだけです。障害の原因について小規模ながら十分な調査を行った後、障害ポイントの完全な復元が実行されます。 はい、ほとんどの場合、間違いの修正は完全なリカバリを実行するよりも高速ですが、2番目のシナリオでのみいつでも保証できます。そのため、私たちはそれだけに集中できます。
ただし、単一障害点の復元は、ユーザーサービスの復元を常に意味するわけではありません。依存障害点にも障害がある可能性があるためです（ 最初の記事の依存関係図を参照 ）。 このスキームに基づいて、可能な限り最長のシナリオを決定すると、ユーザーサービスの「最小回復時間」が得られ、ITサービスがビジネスを保証できます。 あなたの意見でさえ、この期間がすべての合理的な制限を超えている場合、これはその最適化について考える機会です：
- 回復を早めるために事前収穫を行います。
- インシデントの調査に費やす時間を削減します（データ損失の可能性を高めます）。
- 障害点のアーキテクチャを変更して、復旧速度を向上させます。
実際、修復の条件とその削減方法に関する結論は文書化する必要があります。これらの結論は、後にリーダーシップとの対話の際に役立ちます。 まだ考慮に入れていないいくつかの驚きがなければ、これでこの段階は終了した可能性があります。
4.災害復旧手順のリスク要因を特定し、それらを制御するための対策を計画します
事故時に、発電機にガソリンが入っていないか、バッテリーが切れていること、緊急復旧指示（パスワードは言うまでもありません）がクラッシュした同じサーバーに保存されていること、建物のセキュリティサービスが夜間にサーバールームに誰も入らせなかったことを知るのはどれほど不快ですか時間、または非常に必要なバックアップが数か月連続で作成されていないもの。
これを防ぐには、適切なタイミング、適切な場所、適切な品質で必要なリソースを取得できない理由を事前に判断する必要があります。 その後、リスク要因を制御できるタスク（またはイベント全体）を計画し、完全に除外しない場合は、少なくとも災害復旧への影響を減らします。 そのようなタスクの例は次のとおりです。
- バックアップの正確性を確認し、
- バックアップ通信チャネルの品質管理、
- 必要な備品の可用性の監視、
- 無停電電源装置と発電機の状態を監視し、
- 現状の完全な回復のための計画の適合性の分析
- など
そして、もちろん、障害点の完全な回復のための手順の直接的なテストを忘れないでください。
リスク要因の重要度、その発生の可能性、およびそれを制御するタスクの複雑さに基づいて、独自の裁量でルーチンタスクを実行する頻度を選択することをお勧めします。 日常的なタスクを実行し、その結果、リスク要因を制御するには、追加のリソースが必要になる場合があることを思い出してください。
5.計画を超える状況を定義する
ビジネスへの最も大きなマイナスの影響は、技術者がある程度準備している単一の（または連続した）障害ではなく、複数の同一システムの並行崩壊につながる不可抗力の状況を強制します。 火災、深刻な電力サージ、ウイルス攻撃、さらには第三者による違法行為は、深刻な損害を引き起こすだけでなく、ビジネスにとって致命的となる可能性があります。 このような状況では、「運用回復」という用語を使用することは困難ですが、打撃を軽減できるいくつかの手段があります。
- 不可抗力の場合のデータバックアップの問題を解決する。 バックアップメディアの保存場所は、会社のオフィスだけでなく、たとえば銀行のセルにする必要があります。 会社に複数の場所がある場合-クロスバックアップを提供できます。
- ユーザーサービスの復元に優先順位を付けます。 ビジネスがなければ存続できないことは常に1つあります。他のすべては待機します。
- 不可抗力要因の影響から準備金を確保します。 予備が完全に装備されている場合、少なくとも1つのサービスを開始します。
- 展開用のバックアップサイトを準備します（または少なくとも概要を示します）。 ゼネラルディレクターのアパートで-戦争ではすべての手段は良いです。
一般に、不可抗力計画の問題は別の大きなトピックです。 災害復旧計画の一部として、この用語は、復旧期間でカバーされない状況を指す可能性が高いです。 通常、このような状況は「同じクラスの機器またはソフトウェアの2つ以上の同時故障」のように聞こえます。 誰もが2つ以上の同一のシステムで並行作業を行うことができる二重の引当金と専門スタッフを持っていることはめったにありません。 それにもかかわらず、状況は異なり、おそらく、あなたの場合、管理者はそのような追加の信頼性を求めます。
すべての結論を要約することにより、必要なリソースと規制タスクのセットを決定して、既存のITインフラストラクチャ内のユーザーサービスの復旧時間を最小限に抑え、時間枠を保証できない状況のリストを強調表示できます。 概略的には、計画は次のようになります。
それをビジネスの現実とニーズと相関させるだけであり、リーダーシップとともに、すべての人に合ったソリューションを見つけますが、それについては次の記事で詳しく説明します。
パート1： habrahabr.ru/post/225719
パート3： habrahabr.ru/post/228115
頑張って！
イワン・コルマチェフ
IT部門会社
www.depit.ru