Опубликован: 12.11.2012 | Доступ: свободный | Студентов: 1817 / 306 | Длительность: 18:27:00
Лекция 10:

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

< Лекция 9 || Лекция 10: 123 || Лекция 11 >

Практическое задание

Постановка задачи: Компания является поставщиком услуг электронной почты. В 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 представлена информация, необходимая для процесса и ее источники.

Таблица 10.5.
Источник Входящая информация
PO 2 Принятые классификации данных
PO 9 Оценка рисков
AI 2 Спецификации по доступности, непрерывности и восстановлению
AI 4 Пользовательские, эксплуатационные, обслуживающие, технические и руководства для администраторов
DS 1 Соглашения об уровне обслуживания и соглашения операционного уровня

В таблице 10.6 приведены результаты процесса и то, куда они должны поступить.

Таблица 10.6.
Результаты В процессы
Результаты тестирования отказоустойчивости PO 9
Критичность объектов конфигурации ИТ DS 9
План резервного хранения и защиты DS 11 DS 13
Пороговый уровень инцидентов/аварийных ситуаций DS 8
Требования аварийного обслуживания, в том числе перечень должностных лиц и их обязанности DS 1 DS 2
Отчеты об эффективности процессов ME 1

Таблица 10.7 содержит таблицу ОУКИ для процесса, а таблица 10.8 – цели и показатели.

Таблица 10.7.
Действия\Функции Президент Финансовый директор Высшее руководство Директор по ИТ Владелец бизнес-процесса Руководитель эксплуатации системы Главный архитектор ИТ-системы Руководитель разработок Руководитель администрации ИТ Руководитель проектного офиса Аудит, риски, безопасность
Разработать методологию непрерывности обслуживания К К У К О О О К К О
Оценить риски и проанализировать последствия рисков для бизнеса К К К К У/О К К К К К
Разработать и поддерживать планы непрерывности ИТ-обслуживания И К К К И У/О К К К К
Определить категории ИТ-ресурсов на основе задач восстановления К У/О К К К И
Определить и внедрить процедуры управления изменениями для поддержки плана непрерывности ИТ в обновленном виде И У/О О О О И
Периодически тестировать план непрерывности ИТ-обслуживания И И У/О К К И И
Разработать последовательный план действий на основе результатов тестирования К И У/О К О О О И
Планировать и проводить обучение по проблеме непрерывности ИТ-обслуживания И О У/О К О И И
Планировать восстановление ИТ-услуг И И К К У/О К О О О К
Планировать и внедрить систему резервного хранения и защиты И У/О К К И И
Установить процедуры проведения анализа по результатам восстановления К И У/О К К К
Таблица 10.8.
Цели Показатели
ИТ:
  • убедиться в доступности ИТ –услуг в соответствии с требованиями
  • убедиться в минимальности последствий сбоя или изменения в ИТ-услугах для бизнеса
  • убедиться в том, что ИТ-услуги и инфраструктура устойчивы к сбоям вследствие ошибок, преднамеренной атаки или аварийной ситуации
  • число часов из расчета на пользователя в месяц, потерянных по причине незапланированных отключений или перебоев в работе
Процесса:
  • разработать план непрерывности ИТ обслуживания, который будет поддерживать план непрерывности бизнеса
  • разработать планы непрерывности ИТ обслуживания, которые могут быть реализованы на практике, протестированы и которых можно придерживаться
  • минимизировать вероятность перебоя в оказании услуг
  • доля соответствия соглашениям об уровне обслуживания по критерию доступности
  • число критичных бизнес-процессов, зависящих от ИТ, но не охваченных планом непрерывности обслуживания
  • доля тестов, достигших контрольных показателей по восстановлению
  • регулярность перебоев в обслуживании критических систем
Действия:
  • разработка, поддержка и улучшение непрерывности обслуживания
  • подготовка персонала и тестирование планов непрерывности обслуживания ИТ
  • хранение копий планов непрерывности обслуживания и данных в сторонних хранилищах
  • время между тестами отдельных компонентов плана непрерывности ИТ-обслуживания
  • число часов, затраченных на обучение вопросам непрерывности ИТ-обслуживания из расчета на одного сотрудника ИТ в год
  • доля критических компонентов инфраструктуры, охваченных автоматизированным мониторингом
  • регулярность обновления планов непрерывности ИТ-обслуживания
< Лекция 9 || Лекция 10: 123 || Лекция 11 >
Максим Цапко
Максим Цапко

Я наконец закончил курс "Управление ИТ-проектами". Как получить документ об окончании курса.

Дмитрий Лобанов
Дмитрий Лобанов

Управление ИТ на основе COBIT 4.1

: в перечне литературы, п.15 - отсутствует документ по ссылке https://www.rusonyx.ru/support/agreements/

Алексей Янов
Алексей Янов
Россия, Москва, МГТУ им Н.Э.Баумана, 2002
Сергей Уткин
Сергей Уткин
Россия