Серия «ITIL-процессы на салфетке».
Capacity Management (Управление вместимостью)

Изучение использования процессного подхода через практические примеры так же полезно, как и чтение книг ITIL.
В этой статье Владимир Бахметьев рассказывает о процессах в популярной и доступной форме, опираясь на собственный опыт их внедрения.

Задачи процесса:

  • Обеспечить запас мощностей для поддержки работы компании в течении ближайших Х месяцев
    Или:
  • Определить, на сколько хватит имеющихся мощностей

    Основания для прогнозирования:

  • данные маркетинга
  • данные по текущей «нагруженности» информационных систем и история их изменений (сколько есть)
  • метод оценки загрузки – экспертная оценка («метод научного тыка»)

    Вопрос:

  • Как реально («на пальцах») построить процесс?
  • Что из этого может получиться на практике?

    Часть 1. Capacity Management Essentials.

    1. People. Назначаем сотрудника на роль Capacity Manager. Желательно — из уже работающих в компании, знающих инфраструктуру и понимающих архитектуру бизнес-приложений и сам бизнес компании хотя бы в крупную клетку. Уровень знаний — технический специалист с базовой подготовкой по основным ОС, СУБД, сетям и приложениям. Знание основных бизнес-процессов компании и их отображение на ИТ-архитектуру также очень пригодится. Английский — свободное чтение документации, русский — грамотная устная речь и письмо. Это может быть начинающий менеджер — вчерашний системный администратор или грамотный программист со знанием инфраструктурной проблематики.
    2. Knowledge. Учим на ITIL/ITSM/MOF Essentials. По возможности — на practitioner.
    3. Quick Wins. Берем (или составляем, если еще нет SLM) перечень информационных систем, выбираем критически важные для компании, из них выбираем «жертву» для пилотного проекта (Итерация 1). Система не должна быть ни слишком сложной, ни слишком простой, должна иметь хорошую видимость и ценность внутри компании. Цель — обеспечить quick wins. Провал в работе с такой системой может означать дискредитацию идеи и отказ руководства от продолжения работ.
    4. Reporting. Естественно, нужны регулярные отчеты. Используя (не)штатные системы мониторинга, получаем текущую нагрузку на уровне отдельных ресурсов. Выставляем пороги загрузки конкретных подсистем (CPU, Диски, Память и пр.) Налаживаем дисциплину выпуска регулярных отчетов по загрузке ресурсов (HW, OS, DBMS и пр.). Пример: ежедневно в 8:00 утра по почте приходит отчет о загрузке ресурсов за прошедшие сутки, каждый понедельник — отчет за неделю, 1-го числа каждого месяца — за прошедший месяц и т.п. Логично делать это вместе с Availability Manager-ом, но это уже другая история…
    5. KPI (Key Performance Indicators). Изучаем показатели работы компании (или зовем того, кто в этом разбирается), относим их к тем или иным бизнес-процессам, определяем с помощью каких приложений исполняются бизнес процессы. Понимаем нагрузку на информационные системы в терминах бизнеса как в абсолютных цифрах (кол-во заказчиков, объем выпуска продукции и пр.), так и в терминах «скорости» и пропускной способности (кол-во транзакций в единицу времени, кол-во обращений в час и т.п.). Звучит просто, реализация может быть сложной.
    6. Top Secret. По согласованию на «верхнем» уровне, получаем в маркетинге (или где-либо еще) прогнозы роста на 3-6-12 месяцев.
    7. Data analysis. Получаем тренды за 4-8 недель. Пытаемся методом научного тыка («экспертной оценки») соотнести рост бизнес-показателей компании с ростом загрузки индивидуальных ресурсов и нарисовать «усредненный» показатель загрузки прикладной системы и пороги. Таким же способом «прикидываем» прогноз на несколько месяцев. Результат в первом приближении получен. Про погрешность можно пока скромно умолчать.
    8. Success factor. Теперь надо «продать» результаты. Ежедневно Capacity Manager анализирует полученные данные (графики). Он готовит еженедельный, ежемесячный и пр. отчеты, включая тренды на х месяцев вперед. Стоит максимально их упростить (3-5 графиков), сделать максимально наглядными (пригласите профессионального дизайнера!) и четко и явно соответствующими бизнес-показателям компании. Главное на первом этапе — регулярность и дисциплинированность. Эти отчеты при регулярном предоставлении их руководству через некоторое время становятся обоснованием для запросов на закупку дополнительной Capacity

    Кроме этого:

  • Работа по событиям. Capacity Manager также входит в CAB и его ответственность — оценивать потенциальное влияние предлагаемых изменений на запасы Capacity информационных систем.
  • Эти данные также используются для более точного бюджетирования и планирования закупок. Деньги не бесплатны, помните?

    В общем, особо сложного ничего нет — надо просто делать. На первом этапе достаточно сделать хотя бы описанное выше, и уже такой результат послужит базой И ОБОСНОВАНИЕМ для последующего внедрения более точных средств моделирования и анализа систем.

    При успехе итерации 1, итерация 1а может содержать внедрение инструментов моделирования, итерация 2 — охват других критических для компании систем (выделяются при составлении перечня систем), итерация 3 — прочие системы.

    Часть 2. Пример практического применения в крупной Hi-Tech российской компании (несколько тысяч компьютеров, несколько сотен(!) серверов и информационных систем).

    1. Выделили человека на роль Capacity Manager-а (размеры организации позволяли). Хороший технарь c хорошими пробивными способностями и начальными менеджерскими навыками (договариваться нужно со многими).
    2. Изучил раздел Capacity Management в ITIL Service Delivery (вводный курс по ITIL к тому времени он уже прослушал).
    3. Выбрали сервис из класса Mission-Critical.
    4. ИТ-директор договорился с маркетингом на регулярное предоставление Capacity-менеджеру прогнозов развития компании.
    5. Поняли, какие метрики бизнес-уровня мы хотим «вынимать» из прикладной системы.
    6. Получили от людей, обслуживающих систему, информацию о ее архитектуре (мини-CMDB). «Большой и правильной» CMDB не было.
    7. Прорисовали метрики компонент и метрики интерфейсов (метрики «сервисного» уровня). Можно сказать, что часть этой информации немного в другом виде идет в отчеты по Availability и в SLM.
    8. Проставили пороги. Постановка задачи: «Обеспечить Capacity на шесть месяцев вперед». Методы решения: «на глазок», «экспертная оценка» или «научного тыка». Кому как нравится
    9. Пришли к человеку, который занимается системой мониторинга и «заказали» подсистему, собирающую эти метрики.
    10. Через п.п. 5-9 прошли еще несколько раз, пока не получили что-то вразумительное.
    11. Начали получать данные из системы мониторинга.
    12. Составили Capacity Plan по этой системе. Взяли лучший инструмент Capacity Manager-а — Microsoft Word, составили отчет на один лист с метриками бизнес, сервис и ресурсного уровня. На графиках показали историю и тренды. Внизу — выводы. Все просто.
    13. Прокатали эту систему в течении несколько недель, наладили выпуск еженедельных отчетов.
    14. Получили от директора задание: «Составить план охвата ВСЕХ Mission- и Business-critical систем» и совместно «продали» этот план и результаты пилота (по самому важному сервису, замечу) на «самый верхний» уровень руководства.
    15. За полгода «окучили» около двух десятков Mission-critical, еще за полгода — примерно столько же других систем
    16. Средства моделирования не использовались. Было одно относительно дешевое — до ума не довели, CapMan сказал, что оно к нашим задачам не подходит. «Настоящие» системы такого класса для крупных распределенных систем вместе с обучением персонала обходятся в миллионы долларов. Пока не купили

    Владимир Бахметьев,
    Специалист по системной архитектуре,
    Microsoft Russia & CIS

  • Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

    Комментарии закрыты.