あなたが参加した主な停止は何ですか？
停止は私たちが避けようとしていることの一部ですが、避けられません。停止は発生し（非常にまれですが、私たちは望んでいます）、それらに対処する方法を知る必要があります（そしてそれらから学ぶ必要があります）。
それで、あなたが参加した主な停止は何ですか？あなたとあなたのチームはどのように問題に対処しましたか？将来のために何を学びましたか？あなたの考えを共有してください:)
私はほぼ毎日停止の「一部」です（モニターWAN 44サイトのリンク）。「小さなもの」は5分未満で、ほとんどの場合に発生します。 「気づかれていません」（NOCは何らかの理由で5分を超える停止のみを監視します）。サイトと通信して内部の問題かどうかを確認し、問題が「不明」の場合は常にルーターログを確認します。
停止に対処するときは、通信が重要であることがわかります（これは控えめな表現です！）。トラブルシューティングを行っているとき、または正確に何が起こっているのかを調べようとしているときに、呼び出されるのを待たないでください。彼らがダウンしていることを知っていて、それに取り組んでいることを伝えてください。状況（ETR）の最新情報を提供するために、いつ連絡するかについての時間枠を提供します。あなたが彼らのことを忘れていると思わせないでください。誰かが彼らの問題を見ていることを彼らが知っていることを確認してください。あなたは彼らに電話するので、彼らはあなたに電話する必要はありません。
ありがたいことに、私の監視下でサイトがダウンしている最長の時間は7時間でした（これは1日の午前10時から午後5時までです）。関係するすべての関係者間の良好なコミュニケーションの欠如がなければ、それは数時間短縮されるべきでした。ほとんどの場合、問題は適切にエスカレーションされておらず、「誰かがそれに取り組んでいる」という仮定のために、問題は（サイトにとって比較的）解決するのに永遠にかかりました。
データセンターの破裂を通過する加熱蒸気パイプがありました。非常に高温で、結露とアスベストの断熱材がいたるところにあります。クリーンアップ中の数週間の停電。
OK、myグループのものはBGPペアであり、複数のデータセンター間で負荷分散されていました。現在のトランザクションが転送される前に、ユーザーの一部に30秒のフリーズが発生しました。他のプロジェクトの多くでは、最大数日間の停止が見られ、全員が他の全員を助けるために多くの残業をしていました。
学んだ教訓：最初に継続性計画を行い、次に結論をサポートするシステムを構築します。
- 1週間のダウンタイムに耐えられない場合は、転送を計画して練習してください。プライマリ/フェイルオーバーサイトの代わりに、ブルー/ゴールドを使用し、2週間ごとにローテーションして、すべてが更新されて利用可能であることを確認します。
- 30分から1日程度に耐えられない場合は、アクティブなサイト間の負荷分散を行ってください。時間との戦いで回復を試みるというプレッシャーの下で費やすよりも、セットアップに費やす時間と労力が少なくて済みます。
- 数分間のダウンタイムに耐えられない場合は、実際の高可用性を実現するために多大な労力を費やす必要があります。最善の策は、専門のコンサルタントを雇うことです。
- 階層を完成させるために、数秒のダウンタイムを許容できない場合は、特殊なハードウェアと特殊な設計が必要です。あなたの方がいいbe専門家
私は、50以上のユーザーオフィスで現在ネットワーク全体の停止に直面している会社での就職の面接に出席していました。私は数分以内にそれを解決し、彼がそれを解決できなかったので彼らが呼んだ彼らの現在のシステム管理者と彼らのITサポート会社に会うことができました-彼らは何が悪いのかを解明するために朝中過ごしました。
前の男は、ブリッジモードで2つのワイヤレスルーターをインストールし、両方を有線ネットワークに接続していました。それらは互いにほとんど範囲内になかったので、受信が変化するにつれて行き来するネットワークにループがありました。
言うまでもなく、私は仕事を得て、開始するとすぐに変更管理ログを実装しました。
おそらく最大のものは、大規模なネットワークのアップグレードによって引き起こされた4日間の全本社ネットワークの停止でした。
私が持っている最大のヒントは、確立された堅牢なインシデント管理プロセスを持つことです。緊急要員が使用する一般的なインシデントコマンドシステム（ http://en.wikipedia.org/wiki/Incident_Command_System ）をITタイプのインシデントに適応させることについて私が見たVelocity2008カンファレンスからの素晴らしいプレゼンテーションがあります。よく： http://en.oreilly.com/velocity2008/public/schedule/detail/1525
独自の内部「Sev1」インシデントプロセスを開発する際に、これから広範囲に渡りました。それは、コミュニケーション、指揮の統一、責任の明確な引き継ぎ、および他の素晴らしいものを強調します。
また、Transparent Uptimeブログのプラグインも挿入します： http://www.transparentuptime.com/ -オンラインサービスに重点を置いていますが、停止時に通信する方法/内容に関する彼の一般的なルールが適用されます内部のIT-eyのものにも。 http://www.transparentuptime.com/2010/03/guideline-for-postmortem-communication.html 具体的には-そこからマネージャーのベビーベッドがあり、その形式で通信を送信し始めました。肯定的な反応を信じていない。
サーバーネットワーク全体が1週間にわたって停止しました。将来同じ問題が発生しないように、冗長ネットワークを作成して対処しましたが、停止が発生している間は、離れた場所に設置した古いサーバーを使用しました。私たちは常にバックアップ計画を立てることを学びました。
どのくらいタイミングが良いか。私は、私たちがサポートしているサイトの1つへの緊急旅行から戻ったところです。
ユーザーへの影響に関しては、大きな影響ではありませんでしたが、大きな影響を与える可能性がありました。一部のサイトをサポートから移行するための進行中のプロジェクトの一環として、新しい信頼できるドメインを作成しました。徹底的なテストの後、私たちは最初のサイトがまだ管理している新しいドメインに移行する準備をしました。そのため、移行の夜がやって来て、2つのDCのうちの1つを新しいドメインに移行することから始めます。それはうまくいきます。セキュリティグループとユーザーアカウントを移行します。それもうまくいき、グループメンバーシップは適切に更新されます。ファイルサーバーを移行し、セキュリティ変換を実行してACLを更新します。繰り返しますが、すべてうまくいきます。アプリサーバーを移行し、VPN用にIASを更新します。問題はありません。次に、テストユーザーのPCを移行すると、ユーザーはプロファイル設定を保持し、すべてのネットワークリソースに完全にアクセスできます。次に、他のDCを移行します。次に、残りのコンピューターを移行しますが、半分は失敗します。ローカルのXPファイアウォールがオンになっていることがわかりました。すぐにGPOをサイトにプッシュしてオフにしますが、コンピューターが更新されるのを待つ必要があります。これ十分な速度で発生せず、ユーザーが到着し始めます。両方のDCが新しいドメインにあるため、元のドメインにログインできません。
次に、1つを再度追加してみてくださいDC元のドメインに戻すファイアウォールルールを更新して、元のドメインの他のリモートDCへのアクセスを許可し、サイトまで車で3時間かかります。
少し眠りにつく：ローカルファイアウォールを無効にするGPOがプッシュされました。考えずに、すべてのコンピューターオブジェクトを取得して移行をプッシュします。これにより、コンピューターオブジェクトがリセットされることを忘れました。正常に移行されたすべてのPCがドメインから削除されます。
さらに悪いことに、画像を使用してロールアウトするローカル管理者パスは、それらをリセットする長年のオンサイト技術のために機能しません。
ブートディスクを使用してローカル管理者パスをワイプした後、週末にすべてのPCを新しいドメインに手動で追加しました。
学んだ教訓：
- 予期しないことを予期し、すべての潜在的な問題を予測してみてください。
- ローカル管理者パスワードやファイアウォール設定などの管理を一元化します
- GPOとグループポリシーの設定
- クリックする前に、もう1分待って、正しく実行していることを確認してください。
すみません、それは長蛇の列でした。