10.1. DS 3. Управление производительностью и мощностями
Мы уже рассматривали в предыдущей лекции понятия производительности и мощности. Повторим:
Производительность (Performance) - мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой.
Мощность(Capacity) - максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги.
Производительность и мощность являются важнейшими характеристиками ИТ-ресурсов. Процесс "Управление производительностью и мощностями" отвечает за регулярное изучение текущего состояния производительности и мощностей ИТ-ресурсов, а также прогнозирование будущих потребностей на основе данных о рабочей нагрузке и требований по емкостям хранения и непрерывности. Данный процесс призван обеспечить уверенность в том, что информационные ресурсы, поддерживающие исполнение бизнес требований, будут доступны на постоянной основе (рис.10.1).
Выделяют реактивные и проактивные мероприятия в рамках процесса Управления мощностями и производительностью. К проактивным мероприятиям относятся:
"предугадывание" появления вопросов, связанных с нехваткой ресурсов;
выделение тенденций использования ресурсов в настоящее время и оценка будущих требований к ресурсам. Последнее выражается в обновлении и улучшении планов в терминах пороговых величин и направлений использования ресурсов;
моделирование и анализ тенденций изменений в ИТ-услугах, в том числе определение изменений в ресурсах, которые должны быть предприняты в будущем;
обеспечение того, что обновления будут профинансированы, запланированы и проведены до того, как будет нарушен SLA или появятся какие-то проблемы с производительностью:
активный поиск возможностей для улучшения производительности услуг там, где это экономически оправдано;
настройка и оптимизация производительности услуг и их компонентов.
К реактивным мероприятиям относятся:
мониторинг, измерение и ведение отчетности по текущей производительности (мощностям) услуг и их компонентов;
реагирование на все события, связанные с пороговыми величинами производительности (мощности) и дальнейшая инициализация коррективных мер;
реагирование на все проблемы, связанные с производительностью (мощностью) и помощь в их разрешении [5].
(рис 10.1) Процесс "Управление производительностью и мощностями"
Управление производительностью и мощностями.
удовлетворяет следующим бизнес требованиям к ИТ
оптимизация эффективности ИТ-инфраструктуры, ресурсов и возможностей в соответствии с бизнес требованиями.
сосредоточено на
достижении соответствия требованиям по срокам, указанным в соглашениях об уровне обслуживания, минимизации простоев, а также проведении постоянного совершенствования производительности и мощности ИТ посредством мониторинга и измерений.
достигается с помощью
Планирования и обеспечения мощностей и доступности систем.
Мониторинга и отчетности о производительности систем.
Моделирования и прогнозирования производительности систем.
результаты оцениваются с помощью следующих показателей
Число часов, из расчета на пользователя в месяц, потерянных по причине не эффективного планирования мощностей.
Доля пиков, при которых превышалась плановая нагрузка.
Доля показателей времени реакции системы, не соответствующих соглашениям об уровне обслуживания.
В таблице 10.1 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| AI 2 | Спецификации по доступности, непрерывности и восстановлению |
| AI 3 | Требования мониторинга систем |
| DS 1 | Соглашения об уровне обслуживания |
В таблице 10.2 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| Данные по производительности и мощностям | PO 2 | PO 3 | | |
| Требования к плану по производительности и мощностям | PO 5 | AI 1 | AI 3 | ME 1 |
| Требуемые изменения | AI 6 | | | |
| Отчеты об эффективности процесса | ME 1 | | | |
Таблица 10.3 содержит таблицу ОУКИ для процесса, а таблица 10.4 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Вести планирование производительности и мощности ИТ-ресурсов | | | | У | | О | К | К | К | К | |
| Изучать текущую производительность и мощность ИТ-ресурсов | | | | К | И | У/О | | К | К | К | |
| Прогнозировать производительность и мощности ИТ-ресурсов | | | | К | К | У/О | К | К | К | К | |
| Проводить анализ проблем для выявления нехватки ИТ-ресурсов | | | | К | И | У/О | | О | К | К | И |
| Вести планирование непрерывности для избежания случаев недоступности ИТ-ресурсов | | | | К | И | У/О | | К | К | И | К |
| Вести постоянный мониторинг доступности, производительности, мощностей ИТ-ресурсов | | | | И | И | У/О | | И | И | И | И |
| Цели | Показатели |
|---|
ИТ:
обеспечить соответствие бизнес-требованиям в соответствии с корпоративной стратегией
обеспечить требуемую доступность ИТ-ресурсов
осуществить оптимизацию ИТ инфраструктуры, ресурсов и возможностей |
число часов из расчета на пользователя в месяц, потерянных по причине неэффективного планирования мощностей
число критичных бизнес-процессов, не охваченных определенным планом доступности обслуживания |
Процесса:
осуществлять мониторинг и измерение пиковой нагрузки и времени отклика при транзакциях
обеспечить соответствие времени отклика, предусмотренного соглашениями об уровне обслуживания
минимизировать сбои при транзакциях
оптимизировать использование ИТ-ресурсов |
Пиковая нагрузка и общий уровень эксплуатационной нагрузки
доля пиков, при которых превышалась плановая нагрузка
доля показателей времени реакции системы, не соответствующих соглашениям об уровне обслуживания
доля ошибок при транзакциях |
Действия:
планирование и обеспечение мощности и доступности системы
мониторинг и отчетность о производительности систем
моделирование и прогнозирование производительности систем |
регулярность прогнозов по производительности и мощностям
доля активов, включенных в отчетность по мощностям
доля активов, по которым ведется автоматизированный мониторинг |
Цели контроля
DS 3.1. Планирование производительности и мощностей
Осуществлять планирование для анализа производительности и мощностей ИТ- ресурсов, чтобы быть уверенным в том, что производительность и мощности оправданы с точки зрения затрат и соответствуют уровням нагрузки, предусмотренным в соглашениях об уровне обслуживания. Планирование по мощностям и производительности должно с помощью методик моделирования создать модель производительности, мощностей и объема ИТ-ресурсов в настоящем и будущем.
DS 3.2. Текущее состояние производительности и мощностей
Оценить текущую производительность и мощности ИТ-ресурсов для того, чтобы определить, достаточны ли их текущие показатели для соответствия согласованным уровням обслуживания.
DS 3.3. Прогноз производительности и мощностей
Вести регулярное прогнозирование производительности и мощностей ИТ-ресурсов, чтобы минимизировать риск сбоев в предоставлении услуг по причине недостаточных мощностей или снижения производительности и выделить резервные мощности на случай возможного перераспределения ресурсов. Выявить тенденции в распределении эксплуатационной нагрузки и учесть данные прогнозов при составлении планов производительности и мощностей.
DS 3.4. Доступность ИТ-ресурсов
Обеспечить требуемые производительность и мощности, принимая во внимание такие аспекты как нормальный уровень эксплуатационной нагрузки, резервы, требования к системам хранения и продолжительность жизненного цикла ИТ-ресурсов. Также должны быть учтены приоритетные задачи, механизмы устойчивости к отказам и расположение ресурсов. Руководство должно убедиться в том, что планы по обеспечению непрерывности должным образом учитывают все вопросы, связанные с доступностью, мощностями и производительностью отдельных ИТ-ресурсов.
DS 3.5. Мониторинг и отчетность
Осуществлять постоянный мониторинг производительности и мощностей ИТ -ресурсов. Полученные в ходе мониторинга данные должны служить двум целям:
Обеспечению и настройке текущей производительности ИТ и учитывать такие вопросы как устойчивость, вероятность инцидентов, текущая и проектная эксплуатационная нагрузка, планы хранения и приобретение ресурсов.
Отчетности по вопросу доступности оказываемых услуг для бизнеса, в соответствии с соглашениями об уровне обслуживания.
Сопровождать все отчеты об отклонениях рекомендациями по их устранению.
Практическое задание
Постановка задачи: Компания является поставщиком услуг электронной почты. В SLA оговорено следующее:
Входящее письмо (размером < 2K) должно быть доставлено в почтовый ящик получателя в течение 1 минуты после получения его почтовым сервером с учетом того, что в день поступает более 10 000 тысяч писем (требование к производительности).
Электронная почта сможет обрабатывать до 12 000 писем (входящих и исходящих) в день в течение 10 лет (требование к мощности).
Электронная почта будет пересылать письма до 10 Мб (требование к мощности).
Как определить оборудование и программное обеспечение, которые обеспечат требуемые уровни мощности и производительности?
Решение задачи:
Необходимо разобраться с двумя требованиями – к производительности и мощности:
1. Производительность. Производительность закладывается при проектировании услуги. Как убедиться в том, что она будет достигнута? Мы уже отмечали ранее, что производительность в данном случае зависит от многих компонентов – почтового приложения, операционной системы, оборудования и т.п. В первую очередь нужно обратиться к вендорам и поискать в Интернете какие-то примеры для сравнения. Например, Вы нашли такое сообщение:
"I have a dual-Athlon XP 1200, 1GB RAM, Maxtor 60GB drive, running Postfix, checking about 5 RBLs, and running Vexira antivirus. It is the primary MX for about 150 domains. It receives (that is, permits) about 150,000 messages per day, rejects another 70,000."
Вы понимаете, что имеющееся у Вас оборудование обладает лучшими характеристиками и доставка письма в течение одной минуты не будет проблемой.
2. Мощность. Посчитать и спроектировать мощность легче, чем посчитать производительность. Вы можете примерно посчитать средний размер письма, скажем, 100 К. 12000 в день в течение 10 лет: 100*12000*365*10=4380 Гб или 4,4 Тб. Таким образом, Вы можете посчитать необходимое пространство на дисках, может быть с запасом, например, на резервное хранение.
Задание для самостоятельной работы:
Рассчитайте необходимое дисковое пространство для хранения писем, если требуется, чтобы электронная почта пересылала письма до 5 Мб в течение 5 лет по 10 000 писем в день.
Помимо этого процесс занимается планированием мощностей. Например, при проектировании электронной почты Вы можете предположить, что количество писем в день может измениться и заранее "заложить" в услугу запасную мощность. В рамках планирования также необходимо учитывать ситуации, выходящие за рамки нормальной работы. Например, организация будет рассылать сотни тысяч писем в дни накануне Нового года с поздравлениями и уведомлениями об акциях. Нужно предусмотреть механизм, который позволит задействовать дополнительные ресурсы (например, если используются виртуальные машины, можно добавить RAM или перенести VM на более мощный сервер).
В рамках процесса нужно также учитывать, что ИТ-ресурсы имеют свой жизненный цикл и не могут служить вечно. Например, Ваш сервер может выйти из строя в течение 10 лет, так что планировать смену оборудования нужно сразу.
После того, как услуга электронной почты запущена в эксплуатацию, необходимо осуществлять мониторинг выполнения требований SLA по производительности и мощности. Все эти задачи решаются в рамках процесса "Управление производительностью и мощностями". Многие процессы зависят от Управления мощностями и будут менее эффективны без использования его информации. Например, Управление внесением изменений должно получить информацию от Управления мощностями и производительностью перед внесением каких-то изменений, так как они могут повлиять на доступность мощностей и текущую производительность. Правильно организованное Управление мощностями и производительностью дает возможность предсказывать различные события в бизнесе до того, как они фактически случаются. Это помогает избежать неприятных сюрпризов в отношении услуг и их компонентов.
DS 4. Обеспечение непрерывности ИТ-сервисов
Непрерывность (Continuity) – предотвращение, нивелирование последствий и восстановление после прерывания или сбоя. Понятия "планирование восстановления бизнеса" планирование восстановления после сбоя и планирование непредвиденных обстоятельств также могут употребляться в данном контексте, все эти термины обращаются к аспектам восстановления. Потребность в обеспечении непрерывности ИТ- сервисов предполагает разработку, поддержку и тестирование планов по непрерывности обслуживания, использование сторонних резервных хранилищ данных и периодическое обучение по плану непрерывности обслуживания. Обеспечение непрерывности ИТ-сервисов является частью обеспечения непрерывности бизнеса. Эффективные процессы обслуживания минимизируют вероятность и последствия существенных перебоев в предоставлении ИТ-услуг для корпоративных функций и процессов.
Большое внимание в рамках обеспечения непрерывности необходимо уделить восстановлению после прерывания или сбоя. Возможные опции восстановления, принятые в области управления услугами:
переход на ручную работу для некоторых типов услуг может стать хорошей альтернативой на короткий период до восстановления услуги. Например, Сервис-деск может работать какое-то время с бумажными заявками и журналами;
взаимные соглашения являются еще одной опцией для восстановления. Предполагают заключение соглашений между организациями, использующими похожие технологии. В настоящее время являются неприемлемыми для большинства ИТ-систем, но могут использоваться в отдельных случаях - например, для внешнего резервного копирования или использования принтеров;
постепенное восстановление (Gradual Recovery) - способ восстановления, также известный как "холодное резервирование". Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем. Эта опция восстановления рекомендована для некритичных услуг, предоставление которых может быть задержано на дни и недели без значительного влияния на бизнес;
промежуточное восстановление (Intermediate Recovery) - способ восстановления, также известный как "теплое резервирование". Предусматривается восстановление услуги в течение 24 - 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг. Данная опция восстановления обычно предлагается третьими сторонами, которые имеют для этого все необходимое оборудование и квалифицированный персонал. Стоимость этой опции восстановления зависит от ресурсов третьей стороны, которые должны быть задействованы для восстановления, а также от времени, в течение которого требуется восстановить услугу. Преимуществом данного метода является его прозрачность для пользователей. Недостатком - то, что информация (в том числе конфиденциальная) будет храниться у сторонней организации. Последнее делает неприемлемым данный способ восстановления для многих организаций.
быстрое восстановление (Fast Recovery) - способ восстановления. Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования.
немедленное восстановление (Immediate recovery) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Этот способ чаще всего предусматривает "двойную локацию" компонентов системы, то есть полное дублирование. Он является самым дорогим и применяется только для критичных бизнес-процессов, простой которых может оказать значительное негативное влияние на бизнес. Копии должны быть расположены на максимальном удалении от оригиналов, чтобы не быть задетыми разрушающим событием [5].
Различные услуги, используемые организацией, требуют различных подходов к восстановлению и уменьшению рисков сбоя. Какая бы опция ни выбиралась, она должна быть экономически эффективной. Главное правило - чем дольше бизнес может обходиться без услуги, тем дешевле должно быть решение по обеспечению ее непрерывности.
(рис 10.2) Процесс "Обеспечение непрерывности ИТ-сервисов"
Обеспечение непрерывности ИТ-сервисов.
удовлетворяет следующим бизнес требованиям к
минимизация последствий для организации в случае прерываний в оказании ИТ-услуг. сосредоточено на
выработка способности к быстрому восстановлению автоматизированных решений, а также разработка, поддержка и тестирование планов непрерывности обслуживания. достигается с помощью
Разработки и поддержки (улучшения) непрерывности обслуживания.
Подготовки персонала и тестированию планов непрерывности обслуживания ИТ.
Хранения копий планов непрерывности обслуживания и данных в сторонних хранилищах.
результаты оцениваются с помощью следующих показателей
Число часов, из расчета на пользователя в месяц, потерянных по причине незапланированных отключений/перебоев в работе.
Число критичных корпоративных процессов, возложенных на службу ИТ, но не охваченных планом непрерывности обслуживания.
В таблице 10.5 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| PO 2 | Принятые классификации данных |
| PO 9 | Оценка рисков |
| AI 2 | Спецификации по доступности, непрерывности и восстановлению |
| AI 4 | Пользовательские, эксплуатационные, обслуживающие, технические и руководства для администраторов |
| DS 1 | Соглашения об уровне обслуживания и соглашения операционного уровня |
В таблице 10.6 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| Результаты тестирования отказоустойчивости | PO 9 | |
| Критичность объектов конфигурации ИТ | DS 9 | |
| План резервного хранения и защиты | DS 11 | DS 13 |
| Пороговый уровень инцидентов/аварийных ситуаций | DS 8 | |
| Требования аварийного обслуживания, в том числе перечень должностных лиц и их обязанности | DS 1 | DS 2 |
| Отчеты об эффективности процессов | ME 1 | |
Таблица 10.7 содержит таблицу ОУКИ для процесса, а таблица 10.8 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Разработать методологию непрерывности обслуживания | | К | К | У | К | О | О | О | К | К | О |
| Оценить риски и проанализировать последствия рисков для бизнеса | | К | К | К | К | У/О | К | К | К | К | К |
| Разработать и поддерживать планы непрерывности ИТ-обслуживания | И | К | К | К | И | У/О | | К | К | К | К |
| Определить категории ИТ-ресурсов на основе задач восстановления | | | | К | | У/О | | К | К | К | И |
| Определить и внедрить процедуры управления изменениями для поддержки плана непрерывности ИТ в обновленном виде | | | | И | | У/О | | О | О | О | И |
| Периодически тестировать план непрерывности ИТ-обслуживания | | | | И | И | У/О | | К | К | И | И |
| Разработать последовательный план действий на основе результатов тестирования | | | | К | И | У/О | К | О | О | О | И |
| Планировать и проводить обучение по проблеме непрерывности ИТ-обслуживания | | | | И | О | У/О | | К | О | И | И |
| Планировать восстановление ИТ-услуг | | И | И | К | К | У/О | К | О | О | О | К |
| Планировать и внедрить систему резервного хранения и защиты | | | | И | | У/О | | К | К | И | И |
| Установить процедуры проведения анализа по результатам восстановления | | | | К | И | У/О | | К | К | | К |
| Цели | Показатели |
|---|
ИТ:
убедиться в доступности ИТ –услуг в соответствии с требованиями
убедиться в минимальности последствий сбоя или изменения в ИТ-услугах для бизнеса
убедиться в том, что ИТ-услуги и инфраструктура устойчивы к сбоям вследствие ошибок, преднамеренной атаки или аварийной ситуации |
число часов из расчета на пользователя в месяц, потерянных по причине незапланированных отключений или перебоев в работе |
Процесса:
разработать план непрерывности ИТ обслуживания, который будет поддерживать план непрерывности бизнеса
разработать планы непрерывности ИТ обслуживания, которые могут быть реализованы на практике, протестированы и которых можно придерживаться
минимизировать вероятность перебоя в оказании услуг |
доля соответствия соглашениям об уровне обслуживания по критерию доступности
число критичных бизнес-процессов, зависящих от ИТ, но не охваченных планом непрерывности обслуживания
доля тестов, достигших контрольных показателей по восстановлению
регулярность перебоев в обслуживании критических систем |
Действия:
разработка, поддержка и улучшение непрерывности обслуживания
подготовка персонала и тестирование планов непрерывности обслуживания ИТ
хранение копий планов непрерывности обслуживания и данных в сторонних хранилищах |
время между тестами отдельных компонентов плана непрерывности ИТ-обслуживания
число часов, затраченных на обучение вопросам непрерывности ИТ-обслуживания из расчета на одного сотрудника ИТ в год
доля критических компонентов инфраструктуры, охваченных автоматизированным мониторингом
регулярность обновления планов непрерывности ИТ-обслуживания |
Цели контроля
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) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Этот способ чаще всего предусматривает "двойную локацию" компонентов системы, то есть полное дублирование.
10.1. DS 3. Управление производительностью и мощностями
Мы уже рассматривали в предыдущей лекции понятия производительности и мощности. Повторим:
Производительность (Performance) - мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой.
Мощность(Capacity) - максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги.
Производительность и мощность являются важнейшими характеристиками ИТ-ресурсов. Процесс "Управление производительностью и мощностями" отвечает за регулярное изучение текущего состояния производительности и мощностей ИТ-ресурсов, а также прогнозирование будущих потребностей на основе данных о рабочей нагрузке и требований по емкостям хранения и непрерывности. Данный процесс призван обеспечить уверенность в том, что информационные ресурсы, поддерживающие исполнение бизнес требований, будут доступны на постоянной основе (рис.10.1).
Выделяют реактивные и проактивные мероприятия в рамках процесса Управления мощностями и производительностью. К проактивным мероприятиям относятся:
"предугадывание" появления вопросов, связанных с нехваткой ресурсов;
выделение тенденций использования ресурсов в настоящее время и оценка будущих требований к ресурсам. Последнее выражается в обновлении и улучшении планов в терминах пороговых величин и направлений использования ресурсов;
моделирование и анализ тенденций изменений в ИТ-услугах, в том числе определение изменений в ресурсах, которые должны быть предприняты в будущем;
обеспечение того, что обновления будут профинансированы, запланированы и проведены до того, как будет нарушен SLA или появятся какие-то проблемы с производительностью:
активный поиск возможностей для улучшения производительности услуг там, где это экономически оправдано;
настройка и оптимизация производительности услуг и их компонентов.
К реактивным мероприятиям относятся:
мониторинг, измерение и ведение отчетности по текущей производительности (мощностям) услуг и их компонентов;
реагирование на все события, связанные с пороговыми величинами производительности (мощности) и дальнейшая инициализация коррективных мер;
реагирование на все проблемы, связанные с производительностью (мощностью) и помощь в их разрешении [5].
(рис 10.1) Процесс "Управление производительностью и мощностями"
Управление производительностью и мощностями.
удовлетворяет следующим бизнес требованиям к ИТ
оптимизация эффективности ИТ-инфраструктуры, ресурсов и возможностей в соответствии с бизнес требованиями.
сосредоточено на
достижении соответствия требованиям по срокам, указанным в соглашениях об уровне обслуживания, минимизации простоев, а также проведении постоянного совершенствования производительности и мощности ИТ посредством мониторинга и измерений.
достигается с помощью
Планирования и обеспечения мощностей и доступности систем.
Мониторинга и отчетности о производительности систем.
Моделирования и прогнозирования производительности систем.
результаты оцениваются с помощью следующих показателей
Число часов, из расчета на пользователя в месяц, потерянных по причине не эффективного планирования мощностей.
Доля пиков, при которых превышалась плановая нагрузка.
Доля показателей времени реакции системы, не соответствующих соглашениям об уровне обслуживания.
В таблице 10.1 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| AI 2 | Спецификации по доступности, непрерывности и восстановлению |
| AI 3 | Требования мониторинга систем |
| DS 1 | Соглашения об уровне обслуживания |
В таблице 10.2 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| Данные по производительности и мощностям | PO 2 | PO 3 | | |
| Требования к плану по производительности и мощностям | PO 5 | AI 1 | AI 3 | ME 1 |
| Требуемые изменения | AI 6 | | | |
| Отчеты об эффективности процесса | ME 1 | | | |
Таблица 10.3 содержит таблицу ОУКИ для процесса, а таблица 10.4 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Вести планирование производительности и мощности ИТ-ресурсов | | | | У | | О | К | К | К | К | |
| Изучать текущую производительность и мощность ИТ-ресурсов | | | | К | И | У/О | | К | К | К | |
| Прогнозировать производительность и мощности ИТ-ресурсов | | | | К | К | У/О | К | К | К | К | |
| Проводить анализ проблем для выявления нехватки ИТ-ресурсов | | | | К | И | У/О | | О | К | К | И |
| Вести планирование непрерывности для избежания случаев недоступности ИТ-ресурсов | | | | К | И | У/О | | К | К | И | К |
| Вести постоянный мониторинг доступности, производительности, мощностей ИТ-ресурсов | | | | И | И | У/О | | И | И | И | И |
| Цели | Показатели |
|---|
ИТ:
обеспечить соответствие бизнес-требованиям в соответствии с корпоративной стратегией
обеспечить требуемую доступность ИТ-ресурсов
осуществить оптимизацию ИТ инфраструктуры, ресурсов и возможностей |
число часов из расчета на пользователя в месяц, потерянных по причине неэффективного планирования мощностей
число критичных бизнес-процессов, не охваченных определенным планом доступности обслуживания |
Процесса:
осуществлять мониторинг и измерение пиковой нагрузки и времени отклика при транзакциях
обеспечить соответствие времени отклика, предусмотренного соглашениями об уровне обслуживания
минимизировать сбои при транзакциях
оптимизировать использование ИТ-ресурсов |
Пиковая нагрузка и общий уровень эксплуатационной нагрузки
доля пиков, при которых превышалась плановая нагрузка
доля показателей времени реакции системы, не соответствующих соглашениям об уровне обслуживания
доля ошибок при транзакциях |
Действия:
планирование и обеспечение мощности и доступности системы
мониторинг и отчетность о производительности систем
моделирование и прогнозирование производительности систем |
регулярность прогнозов по производительности и мощностям
доля активов, включенных в отчетность по мощностям
доля активов, по которым ведется автоматизированный мониторинг |
Цели контроля
DS 3.1. Планирование производительности и мощностей
Осуществлять планирование для анализа производительности и мощностей ИТ- ресурсов, чтобы быть уверенным в том, что производительность и мощности оправданы с точки зрения затрат и соответствуют уровням нагрузки, предусмотренным в соглашениях об уровне обслуживания. Планирование по мощностям и производительности должно с помощью методик моделирования создать модель производительности, мощностей и объема ИТ-ресурсов в настоящем и будущем.
DS 3.2. Текущее состояние производительности и мощностей
Оценить текущую производительность и мощности ИТ-ресурсов для того, чтобы определить, достаточны ли их текущие показатели для соответствия согласованным уровням обслуживания.
DS 3.3. Прогноз производительности и мощностей
Вести регулярное прогнозирование производительности и мощностей ИТ-ресурсов, чтобы минимизировать риск сбоев в предоставлении услуг по причине недостаточных мощностей или снижения производительности и выделить резервные мощности на случай возможного перераспределения ресурсов. Выявить тенденции в распределении эксплуатационной нагрузки и учесть данные прогнозов при составлении планов производительности и мощностей.
DS 3.4. Доступность ИТ-ресурсов
Обеспечить требуемые производительность и мощности, принимая во внимание такие аспекты как нормальный уровень эксплуатационной нагрузки, резервы, требования к системам хранения и продолжительность жизненного цикла ИТ-ресурсов. Также должны быть учтены приоритетные задачи, механизмы устойчивости к отказам и расположение ресурсов. Руководство должно убедиться в том, что планы по обеспечению непрерывности должным образом учитывают все вопросы, связанные с доступностью, мощностями и производительностью отдельных ИТ-ресурсов.
DS 3.5. Мониторинг и отчетность
Осуществлять постоянный мониторинг производительности и мощностей ИТ -ресурсов. Полученные в ходе мониторинга данные должны служить двум целям:
Обеспечению и настройке текущей производительности ИТ и учитывать такие вопросы как устойчивость, вероятность инцидентов, текущая и проектная эксплуатационная нагрузка, планы хранения и приобретение ресурсов.
Отчетности по вопросу доступности оказываемых услуг для бизнеса, в соответствии с соглашениями об уровне обслуживания.
Сопровождать все отчеты об отклонениях рекомендациями по их устранению.
Практическое задание
Постановка задачи: Компания является поставщиком услуг электронной почты. В SLA оговорено следующее:
Входящее письмо (размером < 2K) должно быть доставлено в почтовый ящик получателя в течение 1 минуты после получения его почтовым сервером с учетом того, что в день поступает более 10 000 тысяч писем (требование к производительности).
Электронная почта сможет обрабатывать до 12 000 писем (входящих и исходящих) в день в течение 10 лет (требование к мощности).
Электронная почта будет пересылать письма до 10 Мб (требование к мощности).
Как определить оборудование и программное обеспечение, которые обеспечат требуемые уровни мощности и производительности?
Решение задачи:
Необходимо разобраться с двумя требованиями – к производительности и мощности:
1. Производительность. Производительность закладывается при проектировании услуги. Как убедиться в том, что она будет достигнута? Мы уже отмечали ранее, что производительность в данном случае зависит от многих компонентов – почтового приложения, операционной системы, оборудования и т.п. В первую очередь нужно обратиться к вендорам и поискать в Интернете какие-то примеры для сравнения. Например, Вы нашли такое сообщение:
"I have a dual-Athlon XP 1200, 1GB RAM, Maxtor 60GB drive, running Postfix, checking about 5 RBLs, and running Vexira antivirus. It is the primary MX for about 150 domains. It receives (that is, permits) about 150,000 messages per day, rejects another 70,000."
Вы понимаете, что имеющееся у Вас оборудование обладает лучшими характеристиками и доставка письма в течение одной минуты не будет проблемой.
2. Мощность. Посчитать и спроектировать мощность легче, чем посчитать производительность. Вы можете примерно посчитать средний размер письма, скажем, 100 К. 12000 в день в течение 10 лет: 100*12000*365*10=4380 Гб или 4,4 Тб. Таким образом, Вы можете посчитать необходимое пространство на дисках, может быть с запасом, например, на резервное хранение.
Задание для самостоятельной работы:
Рассчитайте необходимое дисковое пространство для хранения писем, если требуется, чтобы электронная почта пересылала письма до 5 Мб в течение 5 лет по 10 000 писем в день.
Помимо этого процесс занимается планированием мощностей. Например, при проектировании электронной почты Вы можете предположить, что количество писем в день может измениться и заранее "заложить" в услугу запасную мощность. В рамках планирования также необходимо учитывать ситуации, выходящие за рамки нормальной работы. Например, организация будет рассылать сотни тысяч писем в дни накануне Нового года с поздравлениями и уведомлениями об акциях. Нужно предусмотреть механизм, который позволит задействовать дополнительные ресурсы (например, если используются виртуальные машины, можно добавить RAM или перенести VM на более мощный сервер).
В рамках процесса нужно также учитывать, что ИТ-ресурсы имеют свой жизненный цикл и не могут служить вечно. Например, Ваш сервер может выйти из строя в течение 10 лет, так что планировать смену оборудования нужно сразу.
После того, как услуга электронной почты запущена в эксплуатацию, необходимо осуществлять мониторинг выполнения требований SLA по производительности и мощности. Все эти задачи решаются в рамках процесса "Управление производительностью и мощностями". Многие процессы зависят от Управления мощностями и будут менее эффективны без использования его информации. Например, Управление внесением изменений должно получить информацию от Управления мощностями и производительностью перед внесением каких-то изменений, так как они могут повлиять на доступность мощностей и текущую производительность. Правильно организованное Управление мощностями и производительностью дает возможность предсказывать различные события в бизнесе до того, как они фактически случаются. Это помогает избежать неприятных сюрпризов в отношении услуг и их компонентов.
DS 4. Обеспечение непрерывности ИТ-сервисов
Непрерывность (Continuity) – предотвращение, нивелирование последствий и восстановление после прерывания или сбоя. Понятия "планирование восстановления бизнеса" планирование восстановления после сбоя и планирование непредвиденных обстоятельств также могут употребляться в данном контексте, все эти термины обращаются к аспектам восстановления. Потребность в обеспечении непрерывности ИТ- сервисов предполагает разработку, поддержку и тестирование планов по непрерывности обслуживания, использование сторонних резервных хранилищ данных и периодическое обучение по плану непрерывности обслуживания. Обеспечение непрерывности ИТ-сервисов является частью обеспечения непрерывности бизнеса. Эффективные процессы обслуживания минимизируют вероятность и последствия существенных перебоев в предоставлении ИТ-услуг для корпоративных функций и процессов.
Большое внимание в рамках обеспечения непрерывности необходимо уделить восстановлению после прерывания или сбоя. Возможные опции восстановления, принятые в области управления услугами:
переход на ручную работу для некоторых типов услуг может стать хорошей альтернативой на короткий период до восстановления услуги. Например, Сервис-деск может работать какое-то время с бумажными заявками и журналами;
взаимные соглашения являются еще одной опцией для восстановления. Предполагают заключение соглашений между организациями, использующими похожие технологии. В настоящее время являются неприемлемыми для большинства ИТ-систем, но могут использоваться в отдельных случаях - например, для внешнего резервного копирования или использования принтеров;
постепенное восстановление (Gradual Recovery) - способ восстановления, также известный как "холодное резервирование". Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем. Эта опция восстановления рекомендована для некритичных услуг, предоставление которых может быть задержано на дни и недели без значительного влияния на бизнес;
промежуточное восстановление (Intermediate Recovery) - способ восстановления, также известный как "теплое резервирование". Предусматривается восстановление услуги в течение 24 - 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг. Данная опция восстановления обычно предлагается третьими сторонами, которые имеют для этого все необходимое оборудование и квалифицированный персонал. Стоимость этой опции восстановления зависит от ресурсов третьей стороны, которые должны быть задействованы для восстановления, а также от времени, в течение которого требуется восстановить услугу. Преимуществом данного метода является его прозрачность для пользователей. Недостатком - то, что информация (в том числе конфиденциальная) будет храниться у сторонней организации. Последнее делает неприемлемым данный способ восстановления для многих организаций.
быстрое восстановление (Fast Recovery) - способ восстановления. Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования.
немедленное восстановление (Immediate recovery) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Этот способ чаще всего предусматривает "двойную локацию" компонентов системы, то есть полное дублирование. Он является самым дорогим и применяется только для критичных бизнес-процессов, простой которых может оказать значительное негативное влияние на бизнес. Копии должны быть расположены на максимальном удалении от оригиналов, чтобы не быть задетыми разрушающим событием [5].
Различные услуги, используемые организацией, требуют различных подходов к восстановлению и уменьшению рисков сбоя. Какая бы опция ни выбиралась, она должна быть экономически эффективной. Главное правило - чем дольше бизнес может обходиться без услуги, тем дешевле должно быть решение по обеспечению ее непрерывности.
(рис 10.2) Процесс "Обеспечение непрерывности ИТ-сервисов"
Обеспечение непрерывности ИТ-сервисов.
удовлетворяет следующим бизнес требованиям к
минимизация последствий для организации в случае прерываний в оказании ИТ-услуг. сосредоточено на
выработка способности к быстрому восстановлению автоматизированных решений, а также разработка, поддержка и тестирование планов непрерывности обслуживания. достигается с помощью
Разработки и поддержки (улучшения) непрерывности обслуживания.
Подготовки персонала и тестированию планов непрерывности обслуживания ИТ.
Хранения копий планов непрерывности обслуживания и данных в сторонних хранилищах.
результаты оцениваются с помощью следующих показателей
Число часов, из расчета на пользователя в месяц, потерянных по причине незапланированных отключений/перебоев в работе.
Число критичных корпоративных процессов, возложенных на службу ИТ, но не охваченных планом непрерывности обслуживания.
В таблице 10.5 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| PO 2 | Принятые классификации данных |
| PO 9 | Оценка рисков |
| AI 2 | Спецификации по доступности, непрерывности и восстановлению |
| AI 4 | Пользовательские, эксплуатационные, обслуживающие, технические и руководства для администраторов |
| DS 1 | Соглашения об уровне обслуживания и соглашения операционного уровня |
В таблице 10.6 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| Результаты тестирования отказоустойчивости | PO 9 | |
| Критичность объектов конфигурации ИТ | DS 9 | |
| План резервного хранения и защиты | DS 11 | DS 13 |
| Пороговый уровень инцидентов/аварийных ситуаций | DS 8 | |
| Требования аварийного обслуживания, в том числе перечень должностных лиц и их обязанности | DS 1 | DS 2 |
| Отчеты об эффективности процессов | ME 1 | |
Таблица 10.7 содержит таблицу ОУКИ для процесса, а таблица 10.8 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Разработать методологию непрерывности обслуживания | | К | К | У | К | О | О | О | К | К | О |
| Оценить риски и проанализировать последствия рисков для бизнеса | | К | К | К | К | У/О | К | К | К | К | К |
| Разработать и поддерживать планы непрерывности ИТ-обслуживания | И | К | К | К | И | У/О | | К | К | К | К |
| Определить категории ИТ-ресурсов на основе задач восстановления | | | | К | | У/О | | К | К | К | И |
| Определить и внедрить процедуры управления изменениями для поддержки плана непрерывности ИТ в обновленном виде | | | | И | | У/О | | О | О | О | И |
| Периодически тестировать план непрерывности ИТ-обслуживания | | | | И | И | У/О | | К | К | И | И |
| Разработать последовательный план действий на основе результатов тестирования | | | | К | И | У/О | К | О | О | О | И |
| Планировать и проводить обучение по проблеме непрерывности ИТ-обслуживания | | | | И | О | У/О | | К | О | И | И |
| Планировать восстановление ИТ-услуг | | И | И | К | К | У/О | К | О | О | О | К |
| Планировать и внедрить систему резервного хранения и защиты | | | | И | | У/О | | К | К | И | И |
| Установить процедуры проведения анализа по результатам восстановления | | | | К | И | У/О | | К | К | | К |
| Цели | Показатели |
|---|
ИТ:
убедиться в доступности ИТ –услуг в соответствии с требованиями
убедиться в минимальности последствий сбоя или изменения в ИТ-услугах для бизнеса
убедиться в том, что ИТ-услуги и инфраструктура устойчивы к сбоям вследствие ошибок, преднамеренной атаки или аварийной ситуации |
число часов из расчета на пользователя в месяц, потерянных по причине незапланированных отключений или перебоев в работе |
Процесса:
разработать план непрерывности ИТ обслуживания, который будет поддерживать план непрерывности бизнеса
разработать планы непрерывности ИТ обслуживания, которые могут быть реализованы на практике, протестированы и которых можно придерживаться
минимизировать вероятность перебоя в оказании услуг |
доля соответствия соглашениям об уровне обслуживания по критерию доступности
число критичных бизнес-процессов, зависящих от ИТ, но не охваченных планом непрерывности обслуживания
доля тестов, достигших контрольных показателей по восстановлению
регулярность перебоев в обслуживании критических систем |
Действия:
разработка, поддержка и улучшение непрерывности обслуживания
подготовка персонала и тестирование планов непрерывности обслуживания ИТ
хранение копий планов непрерывности обслуживания и данных в сторонних хранилищах |
время между тестами отдельных компонентов плана непрерывности ИТ-обслуживания
число часов, затраченных на обучение вопросам непрерывности ИТ-обслуживания из расчета на одного сотрудника ИТ в год
доля критических компонентов инфраструктуры, охваченных автоматизированным мониторингом
регулярность обновления планов непрерывности ИТ-обслуживания |
Цели контроля
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) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Этот способ чаще всего предусматривает "двойную локацию" компонентов системы, то есть полное дублирование.
