Домен "Эксплуатация и сопровождение ": процессы, отвечающие за управление мощностями, производительностью и непрерывностью

Цели контроля

• DS 4.1. Методология непрерывности обслуживания ИТ Разработать методологию непрерывности обслуживания ИТ, которая будет поддерживать управление непрерывностью бизнеса в масштабах организации на постоянной основе. Цель методологии должна заключаться в определении требуемого уровня надежности (устойчивости) инфраструктуры, направлении разработок по вопросам восстановления после аварийных ситуаций и планов по непрерывности обслуживания. Данная методология должна рассматривать организационную структуру для обеспечения непрерывного управления, включать в себя перечень должностных лиц внутренних и внешних поставщиков услуг и их обязанностей, их руководство и клиентов, процессы планирования, в рамках которых вырабатываются правила и форматы документирования, тестирования и выполнения мер по восстановлению после аварийных ситуаций, а также планы по непрерывности обслуживания ИТ. План также должен включать в себя такие аспекты как определение критических ресурсов, выявление основных взаимозависимостей, мониторинг и отчетность по доступности критических ресурсов, методы альтернативной обработки данных, а также принципы резервного хранения и восстановления.
• DS 4.2. Планы непрерывности обслуживания ИТ Разработать планы непрерывности обслуживания ИТ, на основе методологии и с целью минимизации возможных последствий крупных прерываний для бизнес функций и процессов. Планы должны быть основаны на понимании рисков потенциальных последствий для бизнеса и учитывать требования по надежности, альтернативной обработке данных и возможностям восстановления всех критических ИТ услуг. Они также должны охватывать использование руководств пользователей, перечень должностных лиц и их обязанностей, процессы взаимодействия и подходы к тестированию.
• DS 4.3. Критические ИТ-ресурсы Обратить внимание на наиболее критические аспекты плана обеспечения непрерывности обслуживания ИТ, от которых зависят надежность и приоритеты в ситуациях восстановления после сбоев. Избегать отвлечения на восстановление менее критичных ресурсов и убедитесь, что время отклика и время на восстановление соответствуют приоритетным потребностям бизнеса, а также, что затраты остаются на приемлемом уровне и соответствуют регулирующим требованиям и условиям контрактов. Изучить аспекты, связанные с устойчивостью к сбоям, различные требования к времени отклика и времени на восстановление (например, от одного до четырех часов, от четырех до двадцати четырех часов, более 24 часов) и критические периоды операционной активности бизнеса.
• DS 4.4. Поддержка плана непрерывности обслуживания ИТ Следует убедить руководство ИТ в необходимости определять и исполнять контрольные процедуры по изменениям, чтобы план непрерывности обслуживания ИТ поддерживался в актуализированном виде и всегда отражал актуальные бизнес требования. Донести информацию об изменениях в процедурах и ответственностях четко и своевременно.
• DS 4.5. Тестирование плана непрерывности обслуживания ИТ Проводить регулярное тестирование плана непрерывности обслуживания ИТ, чтобы удостовериться в возможности эффективного восстановления ИТ-систем, выявить недостатки и убедиться в адекватности плана. Это требует тщательного анализа, документирования, отчетности о результатах тестирования и внедрению мер, основанных на этих результатах. Изучить степень способности к восстановлению отдельных приложений, связанную со сценариями комплексного тестирования и интеграционного тестирования со вороны поставщиков.
• DS 4.6. Обучение по плану непрерывности обслуживания ИТ Обеспечить все заинтересованные стороны возможностью регулярного обучения соответствующим процедурам, их ролям и обязанностям в случае инцидента или аварийной ситуации. Следует проверять и совершенствовать обучение в соответствии с результатами тестирования планов обеспечения непрерывности.
• DS 4.7. Распространение плана непрерывности обслуживания ИТ Следует убедиться в том, что существует определенная и управляемая стратегия по распространению плана, согласно которой уполномоченные заинтересованные стороны могут ознакомиться с планом. Особое внимание следует уделить доступности плана при возникновении аварийных ситуаций.
• DS 4.8. Восстановление ИТ-услуг после сбоя Распланировать действия, которые следует предпринять в период восстановления ИТ- услуг. К этим действиям относятся активация резервных площадок, переход на альтернативную обработку данных, общение с клиентами и заинтересованными сторонами, процедуры восстановления. Следует убедиться в том, что организация осознает сроки, необходимые для восстановления, а также масштабы требуемых технологических инвестиций для поддержки процессов восстановления.
• DS 4.9. Сторонние хранилища резервных данных Использовать сторонние хранилища для резервного хранения носителей данных, документации и других ИТ-ресурсов, требуемых для восстановления ИТ и обеспечения планов непрерывности обслуживания. Определить содержание резервного хранилища совместно с владельцами бизнес процессов и ИТ-персоналом. Руководство сторонним хранилищем должно следовать политике классификации данных и корпоративной практике хранения данных. Руководство ИТ должно убедиться в том, что сторонние хранилища проходят проверку не реже раза в год в отношении хранимых ресурсов, защиты от воздействий окружающей среды и безопасности. Следует убедиться в совместимости аппаратного и программного обеспечения для восстановления архивных данных, периодически тестировать и обновлять архивные данные.
• DS 4.10. Анализ по результатам восстановления Определить, предприняло ли руководство ИТ меры по оценке адекватности плана по успешному восстановлению работы ИТ службы после аварийной ситуации, после чего осуществлять обновление плана.

Допустим, Вы – CIO в большой торговой компании с сайтом e-commerce. Что если Ваш дата-центр или даже центральный офис будут разрушены пожаром или землетрясением? Тогда сайт, как и многие другие бизнес-процессы, перестанет работать и компания будет терять возможно миллионы рублей в день. Конечно, Вы захотите восстановить критичные ИТ-услуги максимально быстро. Именно для таких ситуаций и предназначен План восстановления (или План обеспечения непрерывности). Сначала нужно предусмотреть процедуру начала реализации Плана. Например:

• в случае возникновения катастрофы, которая привела к значительным разрушениям, сотрудники должны незамедлительно сообщить об этом CIO;
• CIO инициирует План восстановления. Он уведомит об этом CEO и других участвующих лиц;
• операционный менеджер ответственен за восстановление ИТ-услуг. Он проинформирует членов своей команды о необходимости начать действия в соответствии с Планом восстановления. Он также проинформирует бизнес-менеджеров, которые в свою очередь известят ключевых клиентов.
• Телефонные номера:
• CEO …
• CIO …
• …

Требования к восстановлению чаще всего устанавливает бизнес. Например, это может выглядеть так:

• бизнес-клиент (например, CEO) может потребовать, чтобы внешний интерфейс (каталог продуктов и система принятия заказов) сайта e-commerce были восстановлены через 2 часа и заказы не должны быть потеряны (кроме тех, которые были сделаны за минуту до катастрофы);
• для "теневой части" сайта (доставка товаров, статус заказа и т.п.) восстановление услуг три дня, а восстановление данных – два дня;
• для услуги внутреннего документооборота (Lotus Notes) на восстановление услуг и данных – 1 неделя;
• … (требования для других услуг). Резервное копирование данных и репликация
• для поддержки требований по восстановлению данных для внешнего интерфейса Вы используете поставщика услуг – облачного хостинг-провайдера. Все изменения данных о продуктах и заказах в асинхронном режиме реплицируются в удаленное хранилище данных каждую минуту. Для поддержки такой репликации пропускная способность сети должна быть 10 Mб;
• для поддержки требований по восстановлению услуг внешнего интерфейса, виртуальные машины для веб-сервера и базы данных реплицируются облачному хост-провайдеру. Для экономии пропускной способности они реплицируются раз в неделю. Виртуальные машины на стороне облачного хост-провайдера могут быть не запущены;
• для "теневой части" сайта можно предусмотреть репликацию изменений каждые два дня;
• для внутреннего документооборота в целях экономии Вы будете делать резервную копию базы данных на внешние носители ежедневно и раз в неделю отправлять их в удаленное от офиса место (какой-то третьей стороне). В SLA с поставщиком Вы оговорите, что носители будут доставлены Вам в течение трех дней в случае возникновения необходимости. То есть у Вас будет еще четыре для восстановления данных.

Восстановление:

• Команда 1 (список членов) запустит виртуальные машины для базы данных продуктов и заказов, а затем для веб-сервера;
• Команда 1 (список членов) получит публичный IP-адрес для веб-сервера (описывается процедура);
• Команда 1 изменить осуществить настройку в соответствии с новыми параметрами (описывается процедура);
• Команда 1 изменит DNS-запись для веб-сайта в соответствии с новым IP. Если компьютеры клиентов кэшируют записи DNS, уменьшить TTL;
• Команда 1 разместит на сайте информацию о происшествии, о том, что процесс восстановления начат и доставка товаров может задержаться на три дня;
• Команда 2 (список членов) будет работать над восстановлением услуги документооборота. Команда 2 свяжется с третьей стороной, которая хранит носители с резервными копиями базы данных и т.п.
• …

После того, как детальный План восстановления в случае сбоев составлен, необходимо убедиться в том, что он действительно работает. Помимо этого необходимо донести План до персонала и обучить его действиям, описанным в Плане.

Еще одним важным моментом, о котором можно легко забыть, является само хранение Плана восстановления. Если Вы будете хранить его локально (в пределах офиса), то после катастрофы Плана не будет. Поэтому Вы можете хранить его в телефонах ключевых сотрудников, во внешних хранилищах, в электронной почте в Интернете, на каких-то файловых ресурсах - в общем, там, где он не будет разрушен непредвиденным событием.

Процесс также включает регулярный пересмотр и обновление плана на предмет изменения контактов, ответственных лиц и даже действий по восстановлению.

Ключевые термины:

Производительность (Performance) - мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой.

Мощность(Capacity) - максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги.

Непрерывность (Continuity) – предотвращение, нивелирование последствий и восстановление после прерывания или сбоя. Понятия "планирование восстановления бизнеса", "планирование восстановления после сбоя" и "планирование непредвиденных обстоятельств" также могут употребляться в данном контексте, все эти термины обращаются к аспектам восстановления.

Постепенное восстановление (Gradual Recovery) - способ восстановления, также известный как "холодное резервирование". Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем. Эта опция восстановления рекомендована для некритичных услуг, предоставление которых может быть задержано на дни и недели без значительного влияния на бизнес.

Промежуточное восстановление (Intermediate Recovery) - способ восстановления, также известный как "теплое резервирование". Предусматривается восстановление услуги в течение 24 - 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг. Данная опция восстановления обычно предлагается третьими сторонами, которые имеют для этого все необходимое оборудование и квалифицированный персонал.

Быстрое восстановление (Fast Recovery) - способ восстановления. Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг.

Немедленное восстановление (Immediate recovery) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Этот способ чаще всего предусматривает "двойную локацию" компонентов системы, то есть полное дублирование.