Портал №1 по управлению цифровыми
и информационными технологиями

Управление мощностями, как оно есть

На днях опять вспомнилась тема управления мощностями. Столько всего понакручено вокруг нее. Решил немного про это порассуждать.

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

1. Откуда взяться требованиям к мониторингу? 
2. Откуда взяться пороговым значениям?
3. Как реагировать? Что значит для нас превышение того или иного порога?

Бывает, что на эти вопросы отвечают так (конечно утрирую): "собираем все важное, пороги поставили разумные, если жахнет, то разберемся".

При таком подходе, есть риски:

1. За грудой данных не увидеть опасной тенденции или значений характеристик ресурсов.
2. Вообще не следить за теми параметрами, которые важны, т.к. про них не подумали.
3. Не понять, что собираемые данные иллюстрируют поведение не совместимое с требованиями к ресурсам.

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

С ресурсами такая же история, если мы не знаем, что завтра бизнес запускает новый продукт на рынок, то есть шанс утром разглядывать в нашей чудесной системе мониторинга зашкаливающие графики загрузки. Но ни нам, ни бизнесу это уже не поможет, т.к. мы уже "уткнулись лбом в лобовое стекло". В итоге вывод — как-то надо заранее знать о том, что собирается делать бизнес и заблаговременно "сгруппироваться". Вот тут и начинается самое интересное.

Про цепочку из теории BCM — SCM — RCM (business — service — resource capacity management) все слышали и знают. Но вот на практике эта цепочка выстраивается с бооольшим трудом. Построить сервисно-ресурсную модель связей между сервисами и ресурсами типа "Сервер используется для предоставления сервиса" конечно можно и многие вполне успешно это делают. Но для мощностей этого мало, необходимо понять, как изменение характеристик ИТ-сервиса (например, количество пользователей, или объем оформляемых документов) влияет на загрузку ресурсов. Очень редко можно с уверенностью сказать, что каждая 1000 пользователей, это 100мб места на жестком диске в неделю и 10% средней загрузки процессора. Часто на помощь приходит наблюдение на трендами по характеристикам ИТ-сервиса и ИТ-ресурсов, для выявления корреляции. Иногда выручают производители ПО, которые предоставляют Sizing модели, которые позволяют по нескольким входным параметрам определить требования к ресурсам. Ну и последнее, даже определив взаимосвязь характеристик остается еще наладить отношения с бизнесом, для того чтобы они заблаговременно предоставляли данные о своих планах, да еще и в терминах характеристик ИТ-сервисов.

Зато если цепочка будет выстроена и каждое звено будет работать, то есть шансы получить те самые преимущества, которые описываются в ITIL

Никто не говорит, что это будет просто, зато если усилия будут приложены в нужном направлении, то есть шанс не просто "мониторить" и потом иметь почву для размышлений на тему почему все упало/замерло/тормозит, но и в большинстве случаев избежать подобных ситуаций, как и ненужных трат на лишние мощности, нервов по поводу срочной поставки оборудования и т.д.

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 3

  • Жень, завидую тебе безмерно.

    Я ведь совсем чуть-чуть поучаствовал в том проекте про управление мощностями, а ты прошёл его от начала до счастливого конца.

    По себе знаю как много нового и неожиданного узнаёшь когда выстраиваешь процесс, а не просто читаешь/рассуждаешь о нём.

    Ты бы ещё поделился бы какими-нибудь соображениями или наблюдениями по управлению мощностями, жутко интересно.

  • Да я бы рад, вот только со своими мощностями разберусь 🙂

  • Катерина

    Евгений, доброе утро! Пишите еще, ждем продолжения!


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT