Прежде чем вы сможете реализовать стратегию аварийного восстановления для своей ИТ-инфраструктуры, вы должны создать официальный план. В этом критически важном документе должны быть подробно описаны все возможные непредвиденные обстоятельства, которые могут возникнуть в вашей организации, определить критически важные приложения и системы и подписаться всеми ключевыми фигурами в вашей организации, в том числе руководителями, сотрудниками и лицами, ответственными за управление объектами. Эта статья даст вам план для создания этого плана.
После того, как вы встретились с ключевыми заинтересованными сторонами и определили возможные сценарии стихийного бедствия, такие как потеря критически важных приложений и данных, которые могут привести организацию в тупик (и возможный упадок), ваш план все равно должен быть задокументирован. Важно составить конкретный план в кратком письменном формате для распространения среди персонала, чтобы никто не остался в неведении, когда речь заходит о том, что делать в случае бедствия. Чтобы составить план, ознакомьтесь с контрольным списком того, что должен содержать эффективный план.
Контрольный список
• Определение критически важных приложений, систем и платформ.
Вам нужно отрезать мясо от жира при определении того, какие компоненты инфраструктуры обязательно должны быть доступны во время бедствия. Это подчеркивает важность современной инвентаризации оборудования и программного обеспечения. Знайте все части программного или аппаратного обеспечения, работающие в инфраструктуре, включая все, что виртуализировано. Это выгодно не только инвестировать в хорошее решение для управления активами, но и вести журнал всех программ и обновлений. Таким образом, вы не только узнаете, что представляет собой весь ИТ-инвентарь в случае потери в результате аварии, но вы также можете составить список и проверить, какие системы обязательно должны оставаться работоспособными во время кризиса, а какие вы можете временно обходиться без них.
Обдумайте, чем можно пожертвовать в случае бедствия. Например, база данных, которая используется для отслеживания потенциальных клиентов, может не иметь решающего значения в случае бедствия, но для медицинского учреждения база данных, в которой перечислены все текущие пациенты, такова. Электронная почта может быть необходима для связи с обновлениями статуса персонала и процедурами, особенно если сотрудники вынуждены оставаться за пределами площадки. Какие компоненты важны, зависит от характера бизнеса, но, какими бы они ни были, они должны быть перечислены и включены в план.
• Оценка и внедрение
Это где вы должны начать думать о реализации. Какие данные могут быть доступны вне сайта без ущерба для безопасности или корпоративного соответствия? Если организация никогда не переводила какие-либо бизнес-процессы на модель облачных вычислений, возможно, сейчас самое время подумать об этом. В то время как бизнес-приложения могут требовать более тщательного планирования или сложного переноса в облако, электронная почта и хранилище являются хорошими кандидатами для перехода в облако.
Облачная почта и хранилище
Доступны облачные почтовые сервисы, которые могут не только отражать существующие почтовые системы, но и при необходимости соответствовать HIPAA и другим правилам электронной почты. Многие из этих провайдеров электронной почты могут также осуществлять управление данными через сообщения электронной почты для бизнеса, такого как юридическая фирма, которой может потребоваться пометить определенные сообщения как конфиденциальные или высокочувствительные, или может потребоваться, чтобы только определенные сотрудники получали определенные сообщения электронной почты.
Облачное хранилище является быстрорастущей тенденцией среди потребителей, и компании также могут использовать преимущества облачного хранилища в рамках плана действий в случае бедствия. Подавляющее число организаций по-прежнему используют локальные решения для резервного копирования с резервным копированием данных на магнитную ленту или носитель RDX. Резервные данные часто отправляются за пределы площадки и регулярно меняются, поэтому последняя копия данных организации легко доступна в случае сбоев системы или аварии.
Однако репликация этих данных поставщику облачного хранилища может сэкономить время, которое в противном случае было бы потрачено на извлечение этих данных из физического местоположения за пределами площадки и последующее ручное восстановление их на серверах. Облачное решение позволяет получать доступ к критически важным данным практически в режиме реального времени, если у сотрудников есть подключение к Интернету. Существуют также поставщики облачных хранилищ, которые могут гарантировать соответствие хранимых данных корпоративным стандартам, например Sarbanes-Oxley (SOX).
Приложения, серверы и виртуализация
Излагая план аварийного восстановления, стоит задуматься не только о переносе данных в облако, но и о любых приложениях, которые можно перенести. С такими провайдерами, как Amazon, Rackspace и Google, компания может переносить приложения и базы данных в облако, чтобы в чрезвычайной ситуации доступ был доступен.
Существуют случаи, когда предприятие не может полностью выполнить резервное копирование данных в облако или, по крайней мере, может реализовать только гибридное решение - резервное копирование некоторых данных и сохранение локальных других данных. Причины могут включать проблемы безопасности или стоимость запретов. При создании плана DP самое время определить, как можно оптимизировать инфраструктуру.
В чрезвычайной ситуации, чем более разнородное программное обеспечение развернуто на большем количестве оборудования, тем больше вероятность того, что повсеместный ущерб и время, затрачиваемое на восстановление систем. Виртуализация может быть мощным решением для такого рода проблем. Консолидация физических серверов в виртуальных машинах означает, что ИТ-специалисты могут создавать регулярные снимки экземпляров серверов и легко восстанавливать эти серверы после аварии. Решения для виртуализации, предлагающие такие функции, как живая миграция, не требуют длительного периода простоя для восстановления критически важных систем инфраструктуры.
Для организаций, которым все еще необходимо разместить большинство систем и данных на месте, можно также спланировать подвижный мобильный центр обработки данных в месте, определенном как безопасное в чрезвычайной ситуации. Серверы резервного копирования, которые могут реплицировать данные с основного сайта на сайт резервного копирования, могут, по крайней мере, обеспечить доступность критически важных систем.
Сила
Помимо данных и серверов, есть и другие основные соображения, которые необходимо учитывать при подготовке к аварийному восстановлению. Одним из наиболее распространенных сценариев бедствия является отключение электроэнергии - бедствие, которое должен иметь каждый бизнес, поскольку электрическая инфраструктура страны, как правило, не успевает за ростом. Разумеется, все критически важные аппаратные средства должны работать на неограниченных источниках питания (ИБП). Решения ИБП могут обеспечить период безотказной работы в случае сбоя питания достаточно долго, чтобы, по крайней мере, заставить организацию перейти на альтернативные аварийные процедуры. Регулярные проверки и испытания устройств ИБП имеют решающее значение.
При более длительных перебоях в подаче электроэнергии некоторым организациям также может потребоваться работа с отделом оборудования для установки альтернативных источников питания, таких как генераторы, предназначенные для ИТ-оборудования.
Телекоммуникации и удаленный доступ
Интернет-провайдеры и операторы мобильной связи часто испытывают длительные простои в случае стихийных бедствий. Несмотря на то, что в случае серьезной катастрофы, которая может повлиять на телекоммуникации в ближайших и близлежащих районах, мало что может сделать бизнес, стоит иметь избыточные подключения к Интернету от разных интернет-провайдеров. Таким образом, если сеть одного интернет-провайдера не работает, второй интернет-провайдер может оставаться в сети. Хороший план аварийного восстановления документирует, как инфраструктура будет переключаться с одного интернет-соединения на другое, избыточное соединение. План должен наметить регулярное тестирование этого аварийного соединения.
План также должен учитывать, как конечные пользователи будут получать доступ к системам в чрезвычайной ситуации. Многие конечные пользователи имеют выпущенные компанией или персональные мобильные устройства, которые можно настроить для удаленного доступа к корпоративной сети. В большинстве организаций уже есть какое-то решение для виртуальной частной сети (VPN), позволяющее осуществлять удаленный доступ в бизнес-сеть. Работает ли эта система VPN на самом деле, и обучены ли нетехнические сотрудники ее использованию без интенсивной ИТ-поддержки, которая может быть недоступна во время аварии? Может ли это решение VPN или удаленного доступа противостоять катастрофе? Резервное копирование в VPN также следует рассмотреть. Это может быть сервер VPN на другом сайте или доступ к данным и системам через облачного провайдера вместо обычной системы VPN.
Некоторые организации могут иметь решение для удаленного доступа, которое будет предоставлять удаленному устройству доступ к корпоративной сети только после сканирования на предмет определенных требуемых соответствий. Например, клиентскому устройству Windows, в котором отсутствует необходимый пакет обновления или файл определения антивируса, может быть отказано в доступе к корпоративной сети. Вы не хотите сюрпризов, как это в чрезвычайной ситуации. В рамках готовности к бедствиям подробно опишите, как и какие клиентские устройства будут получать доступ к сети в чрезвычайной ситуации. Регулярно проверяйте эти устройства, чтобы убедиться, что они имеют доступ к сети. Именно здесь организация может захотеть рассмотреть решение для управления мобильными устройствами (MDM), которое позволяет централизованно управлять мобильными устройствами, обращающимися к корпоративной сети.
Компания, возможно, выпустила смартфоны для сотрудников. Если компания использует один конкретный оператор связи для телефонов сотрудников, рассмотрите возможность приобретения телефонов другого оператора для передачи ключевым сотрудникам в чрезвычайной ситуации. Если сеть одного оператора не работает, может быть доступна сеть другого оператора. Не полагайтесь на одного и того же оператора для Интернета и телекоммуникаций в случае бедствия.
• документ
После того, как план аварийного восстановления был задокументирован, убедитесь, что все ключевые руководители, руководство и любой другой персонал, участвующий в принятии решений по обеспечению готовности к бедствиям, рассмотрели и подписали документ. Это делает документ официальной политикой и должно быть включено в политику организации.
План аварийного восстановления - это живой документ, который должен регулярно обновляться. Если процедуры тестирования являются частью этого документа, дата и результаты тестирования должны быть задокументированы и связаны с планом аварийного восстановления.
В следующей части этой серии мы рассмотрим выполнение планов аварийного восстановления и решения, которые могут помочь вам подготовить вашу стратегию аварийного восстановления.
