На днях опять вспомнилась тема управления мощностями. Столько всего понакручено вокруг нее. Решил немного про это порассуждать.
Например, выяснилось, что иногда под управлением мощностями понимают мониторинг ИТ-ресурсов ("всякие железяки"). В лучшем случае, с определением пороговых значений и правил реагирования на их нарушение. И тут появляются вопросы и типичные ошибки:
1. Откуда взяться требованиям к мониторингу?
2. Откуда взяться пороговым значениям?
3. Как реагировать? Что значит для нас превышение того или иного порога?
Бывает, что на эти вопросы отвечают так (конечно утрирую): "собираем все важное, пороги поставили разумные, если жахнет, то разберемся".
При таком подходе, есть риски:
1. За грудой данных не увидеть опасной тенденции или значений характеристик ресурсов.
2. Вообще не следить за теми параметрами, которые важны, т.к. про них не подумали.
3. Не понять, что собираемые данные иллюстрируют поведение не совместимое с требованиями к ресурсам.
Кроме того, есть риски, того что если мы сосредотачиваемся на мониторинге ресурсов, то мы теряем связь с внешним миром, который на эти ресурсы влияет. Представьте, что вы пассажир в машине. Водитель резко тормозит, вы невольно наклоняетесь вперед, т.к. законы физики, инерция и все такое, водитель при этом остается в своем прежнем положении, т.к. он был к этому готов, уперся руками в руль.
С ресурсами такая же история, если мы не знаем, что завтра бизнес запускает новый продукт на рынок, то есть шанс утром разглядывать в нашей чудесной системе мониторинга зашкаливающие графики загрузки. Но ни нам, ни бизнесу это уже не поможет, т.к. мы уже "уткнулись лбом в лобовое стекло". В итоге вывод – как-то надо заранее знать о том, что собирается делать бизнес и заблаговременно "сгруппироваться". Вот тут и начинается самое интересное.
Про цепочку из теории BCM – SCM – RCM (business – service – resource capacity management) все слышали и знают. Но вот на практике эта цепочка выстраивается с бооольшим трудом. Построить сервисно-ресурсную модель связей между сервисами и ресурсами типа "Сервер используется для предоставления сервиса" конечно можно и многие вполне успешно это делают. Но для мощностей этого мало, необходимо понять, как изменение характеристик ИТ-сервиса (например, количество пользователей, или объем оформляемых документов) влияет на загрузку ресурсов. Очень редко можно с уверенностью сказать, что каждая 1000 пользователей, это 100мб места на жестком диске в неделю и 10% средней загрузки процессора. Часто на помощь приходит наблюдение на трендами по характеристикам ИТ-сервиса и ИТ-ресурсов, для выявления корреляции. Иногда выручают производители ПО, которые предоставляют Sizing модели, которые позволяют по нескольким входным параметрам определить требования к ресурсам. Ну и последнее, даже определив взаимосвязь характеристик остается еще наладить отношения с бизнесом, для того чтобы они заблаговременно предоставляли данные о своих планах, да еще и в терминах характеристик ИТ-сервисов.
Зато если цепочка будет выстроена и каждое звено будет работать, то есть шансы получить те самые преимущества, которые описываются в ITIL.
Никто не говорит, что это будет просто, зато если усилия будут приложены в нужном направлении, то есть шанс не просто "мониторить" и потом иметь почву для размышлений на тему почему все упало/замерло/тормозит, но и в большинстве случаев избежать подобных ситуаций, как и ненужных трат на лишние мощности, нервов по поводу срочной поставки оборудования и т.д.
Жень, завидую тебе безмерно.
Я ведь совсем чуть-чуть поучаствовал в том проекте про управление мощностями, а ты прошёл его от начала до счастливого конца.
По себе знаю как много нового и неожиданного узнаёшь когда выстраиваешь процесс, а не просто читаешь/рассуждаешь о нём.
Ты бы ещё поделился бы какими-нибудь соображениями или наблюдениями по управлению мощностями, жутко интересно.