18.02.2019
Восстановление после сбоя сети не так просто к мгновенному исполнению, учитывая современные сложные механизмы гибридных облачных вычислений и виртуальных серверов.
Восстановление после сбоя сети не так просто к мгновенному исполнению, учитывая современные сложные механизмы гибридных облачных вычислений и виртуальных серверов.
Системный администратор, который хочет быть в топе, должен принять во внимание самые последние рекомендации по восстановлению сети от Тодда Мэттерса, соучредителя и главного архитектора RackWare, и Скотта Сандерса, главного архитектора решений для восстановления в Sungard Availability Services.
Наличие плана восстановления для вашей сети на самом деле является лишь частью комплексного плана аварийного восстановления. Всегда полезно иметь встроенную систему по отказоустойчивости. Конечно, есть компромисс между затратами и выгодой. Все чаще становится очень экономичным выполнять аварийное восстановление в облаке.
Даже если ваша компания не использует какие-либо другие сервисы облачных вычислений (что маловероятно в 2019 году), преимущество облачных сервисов для восстановления заключается в том, что они гибкие, быстро конфигурируемые и легко доступные. Это не похоже на старые времена, когда администраторам приходилось иметь кучу дублированного оборудования, большую часть времени сидящего без дела. Но, как и в случае с настоящим железом, вы хотите выяснить, какие части вашей сети должны быть предварительно подготовлены, а какие - динамически. Внешние DNS, маршрутизаторы и все, что критически важно, могут относиться к первой категории, а внутренние DNS и контроллеры домена - к последней.
Это звучит как легкая задача, но многие не следуют этим рекомендациям. Вам необходимо тренироваться по аварийному восстановлению и постоянно обновлять Runbook точно, как и в каком порядке вызывать каждую систему и приложение после крупного сбоя.
Безопасность должна быть одной из первых вещей, которую нужно восстановить. Подумайте о старом Западе - если ваш форт был разрушен, первое, что вы должны сделать, это окружить себя новыми стенами, прежде чем восстанавливать. Но одна вещь, которая не должна быть автоматизирована, это ваша глобальная сеть, потому что это займет больше времени, чем ее перестройка вручну.
Слишком многими компаниями не уделяется достаточного внимания вопросу восстановлению сети, лучший способ проводить ежегодные тесты - использовать людей, отличных от тех, кто их разрабатывал. В конце концов, что, если катастрофа помешала вашим штатным ИТ-специалистам приступить к работе - или того хуже? Многие люди не могут определить, когда их окружение ухудшается, что их ключевые люди не смогут помочь.
Ежегодные тесты с полным восстановлением должны дополняться ежемесячными или ежеквартальными инкрементными тестами, такими как восстановление определенных приложений. Только потому, что вы проводите тестирование один раз в год, вы могли бы внести множество дополнительных изменений в свою среду ... Если у вас есть среднесрочный вариант бедствия, вы не будете готовы. Лучшее действие в том, что касается аварийного восстановления.
Десять лет назад компании измеряли восстановление в днях и часах - сегодня это часы и минуты, и, возможно, в другое десятилетие это будут минуты и секунды.
Киберстрахование также является фактором. Аудит плана аварийного восстановления компании в настоящее время не является основанием для предоставления страхового покрытия или отказа в иске, специалист по киберстрахованию. Тем не менее, очень часто заявка на страхование будет спрашивать, есть ли у компании план аварийного восстановления ИТ.
Системный администратор, который хочет быть в топе, должен принять во внимание самые последние рекомендации по восстановлению сети от Тодда Мэттерса, соучредителя и главного архитектора RackWare, и Скотта Сандерса, главного архитектора решений для восстановления в Sungard Availability Services.
Наличие плана восстановления для вашей сети на самом деле является лишь частью комплексного плана аварийного восстановления. Всегда полезно иметь встроенную систему по отказоустойчивости. Конечно, есть компромисс между затратами и выгодой. Все чаще становится очень экономичным выполнять аварийное восстановление в облаке.
Даже если ваша компания не использует какие-либо другие сервисы облачных вычислений (что маловероятно в 2019 году), преимущество облачных сервисов для восстановления заключается в том, что они гибкие, быстро конфигурируемые и легко доступные. Это не похоже на старые времена, когда администраторам приходилось иметь кучу дублированного оборудования, большую часть времени сидящего без дела. Но, как и в случае с настоящим железом, вы хотите выяснить, какие части вашей сети должны быть предварительно подготовлены, а какие - динамически. Внешние DNS, маршрутизаторы и все, что критически важно, могут относиться к первой категории, а внутренние DNS и контроллеры домена - к последней.
Это звучит как легкая задача, но многие не следуют этим рекомендациям. Вам необходимо тренироваться по аварийному восстановлению и постоянно обновлять Runbook точно, как и в каком порядке вызывать каждую систему и приложение после крупного сбоя.
Безопасность должна быть одной из первых вещей, которую нужно восстановить. Подумайте о старом Западе - если ваш форт был разрушен, первое, что вы должны сделать, это окружить себя новыми стенами, прежде чем восстанавливать. Но одна вещь, которая не должна быть автоматизирована, это ваша глобальная сеть, потому что это займет больше времени, чем ее перестройка вручну.
Слишком многими компаниями не уделяется достаточного внимания вопросу восстановлению сети, лучший способ проводить ежегодные тесты - использовать людей, отличных от тех, кто их разрабатывал. В конце концов, что, если катастрофа помешала вашим штатным ИТ-специалистам приступить к работе - или того хуже? Многие люди не могут определить, когда их окружение ухудшается, что их ключевые люди не смогут помочь.
Ежегодные тесты с полным восстановлением должны дополняться ежемесячными или ежеквартальными инкрементными тестами, такими как восстановление определенных приложений. Только потому, что вы проводите тестирование один раз в год, вы могли бы внести множество дополнительных изменений в свою среду ... Если у вас есть среднесрочный вариант бедствия, вы не будете готовы. Лучшее действие в том, что касается аварийного восстановления.
Десять лет назад компании измеряли восстановление в днях и часах - сегодня это часы и минуты, и, возможно, в другое десятилетие это будут минуты и секунды.
Киберстрахование также является фактором. Аудит плана аварийного восстановления компании в настоящее время не является основанием для предоставления страхового покрытия или отказа в иске, специалист по киберстрахованию. Тем не менее, очень часто заявка на страхование будет спрашивать, есть ли у компании план аварийного восстановления ИТ.
