Подписаться
Читать в телеграм
Что сайзинг дает бизнесу?
С чего начать и как избежать типовых проблем?
Советы от «Инфосистемы Джет».
Сайзинг — это процесс планирования ИТ-инфраструктуры под текущие бизнес-процессы компании и с учетом их предполагаемого роста. Бизнес должен всегда получать необходимые ИТ-ресурсы в штатном режиме, даже в периоды пиковой нагрузки, а для этого необходим разумный запас мощностей.
На российском рынке сайзинговые проекты — достаточно распространенное явление. Подобные запросы идут от крупных компаний, в основном они привлекают для решения задачи партнера-аутсорсера. Одним нужно разово просчитать расширение инфраструктуры, другим регулярно (например, раз в полгода) проводить аудиты, на основании которых бизнес принимает решения о приобретении новых мощностей.
Сейчас интерес к сайзингу активно растет. Раньше бизнес мог свободно докупать железо в любых объемах, а в нынешних условиях на первый план вышли анализ, консолидация и грамотное перераспределение имеющихся мощностей.
Немного о ПО
Существует отдельный класс систем — Capacity Management System (CMS), — которые помогают проводить сайзинг. Подобные решения аккумулируют статистику по утилизации инфраструктурных объектов и собирают всевозможные технические и бизнес-метрики. На основе этих данных CMS может спрогнозировать поведение ИТ-инфраструктуры на ближайшие несколько месяцев и выдать ресурсный план развития.
До февраля этого года львиную долю российского рынка занимали западные CMS. Когда зарубежные вендоры ушли, свободную нишу заняли отечественные решения. Например, ISGNEURO — разработчик универсальной аналитической платформы с Big Data движком, с которым мы недавно подписали партнерское соглашение.
Стратегии сайзинга, метрики и кейсы
Ключевой и самый сложный момент подобных проектов — оцифровка бизнес-показателей в ИТ-инфраструктуру. Исходя из этого и формируются стратегии сайзинга. Первый возможный вариант — сайзинг по количеству пользователей. Например, на проекте для интернет-магазина мы эмулировали работу клиентов и смотрели метрики производительности сервисов. А затем с учетом ожидаемого количества покупателей выстраивали требования к ИТ-инфраструктуре.
Вторая стратегия сайзинга опирается наожидаемую производительность ИС. Это так называемый Capacity Planning. Как правило, такие проекты реализуются в рамках сервисных контрактов. Мы смотрим на текущую утилизацию инфраструктуры, анализируем ретроспективные требования и прогнозируем развитие. Здесь важно плотно общаться с заказчиком, т. к. в целевом сайзинге необходимо учитывать планы по развитию бизнеса компании, что напрямую влияет на требования к ИТ-инфраструктуре. Соответственно, Capacity Planning — это в большинстве случаев постоянная, а не проектная стратегия.
Третий вариант связан с бизнес-метриками. Для его реализации нужно понимать количество транзакций и операций, которое должны поддерживать ИС. К примеру, один из заказчиков планировал масштабную маркетинговую акцию и, опираясь на предыдущий опыт, выразил опасения по поводу готовности инфраструктуры к повышенной нагрузке. Мы совместно с техническими специалистами заказчика провели нагрузочное тестирование, проверили работу систем и подготовили ИТ-инфраструктуру к ожидаемой нагрузке.
Также в последнее время заказчики часто просят спрогнозировать нагрузку на ИТ-инфраструктуру, чтобы обосновать наращивание мощностей. Для этого требуется много статистических данных, в том числе из систем мониторинга. Мы оцениваем, как системы вели себя в течение последних месяцев, а затем с помощью математических моделей оцениваем, какие нагрузки ожидаются в ближайшее время и когда системы не смогут выполнять свои функции без наращивания мощностей.
Кейс
В рамках аутсорс-договора с российской торговой сетью по продаже бытовой техники и электроники мы проводим сайзинг раз в полгода. В процессе анализируем более 30 ландшафтов SAP (в каждом — по 3–4 ИС) и сегмент e-commerce и, если это необходимо, рекомендуем докупить оборудование и расширить сегменты ИС.
Две ошибки: недобор и перебор
Первый кейс — ошибка в большую сторону: компания закупает оборудование, которое ей не потребуется. В этом случае она просто переплачивает, причем и в момент закупки, и при дальнейшей эксплуатации железа. Это достаточно распространенная проблема: заказчики особенно любят «перестраховаться» в части инфраструктуры. Как правило, эту ошибку допускают компании, в которых сайзинг почти не развит или отсутствует совсем.
Кейс номер два — недобор, или ошибка в меньшую сторону. Либо бизнес неправильно сформулировал требования к ИС, либо кто-то неправильно перенес их на ИТ-инфраструктуру. В итоге компанию ждет нехватка производительности или низкая производительность и, как следствие, ограниченная доступность сервисов, что может повлечь прямые убытки.
Приведем пример из практики. Заказчик показал нам результаты сайзинга инфраструктуры под его ИС. После внедрения новых мощностей выяснилось, что он был сделан некорректно, причем сильно в меньшую сторону. Вариантов, почему это случилось, было несколько, в том числе огромные опросники от функциональщиков, которые представители бизнеса заполняли неохотно. В итоге система совсем не отвечала заявленным требованиям — пришлось быстро докупать железо и наращивать производительность, иначе бизнес бы просто встал.
Еще одна встречающаяся проблема — отсутствие ресурсов для пилотирования новых технологий. Например, компания хочет внедрить новую фичу, но из-за нехватки свободных мощностей приходится делать все на железе, поддерживающем критичные бизнес-системы. В случае неудачи бизнес может остановиться, поэтому на такое пойдут далеко не все.
Практика: с чего начать и как не облажаться
Сначала необходимо проанализировать имеющиеся в компании инструменты мониторинга и понять, какую информацию они собирают. Если данных недостаточно или нужны другие метрики, в первую очередь нужно будет развивать это направление и только потом приступать к разработке требований для ИС. Причем наш опыт показывает, что у большинства заказчиков нет нужной для сайзинга информации или они не умеют ее собирать. Поэтому будьте готовы к модернизации инструментов по мониторингу и планированию ресурсов до начала сайзинга.
Затем нужно выстроить диалог между ИТ и бизнесом, чтобы последний на регулярной основе формировал требования к ИТ-инфраструктуре компании. Это позволит избежать уже упомянутых выше проблем. Опять же, курировать сайзинг-проекты должна команда, включающая представителей и ИТ, и бизнеса.
Следующий момент: отдавать сайзинг на аутсорс или делать самостоятельно? Предположим, большая часть ИТ-инфраструктуры компании уже обслуживается аутсорсером. В этом случае провести сайзинг самостоятельно будет сложно. В нашей практике был кейс, когда мы организовали для заказчика мониторинг 20 информационных систем. 70% из них обслуживались сторонними подрядчиками, поэтому сотрудники компании просто не понимали, как работают и взаимодействуют эти решения. В таких условиях лучше, конечно, привлечь стороннюю компанию, которая возьмет на себя все коммуникации и анализ.
И напоследок — несколько советов, как провести сайзинг максимально эффективно. Во-первых, подобные проекты всегда упираются в человеческий фактор. Важно назначить правильных людей и поставить им четкие задачи. Если в компании не будет ответственных исполнителей, вместо эффективной работы вы получите зависший проект. Во-вторых, проанализируйте, как компоненты вашей ИТ-инфраструктуры влияют на те или иные бизнес-процессы, и все ли эти компоненты отдают информацию по утилизации на постоянной основе в системы мониторинга. Если это не так, то нужно срочно это исправлять.
Чек-лист «Что нужно учитывать при первом, "ручном", сайзинге»
Прежде чем внедрять Capacity Management System (CMS) или набор других систем, автоматизирующих сбор и обработку статистических данных, рекомендуем сделать первый пробный сайзинг «руками» с привлечением бизнеса, разработчиков и администраторов прикладных систем и ИТ, чтобы выработать подходы и проверить все гипотезы на практике. На что следует обратить внимание:
- Можем ли мы установить точную связь между бизнес-показателями (например, число выданных кредитов) и показателями загруженности платформы (утилизация процессоров, памяти, IOPS, используемое дисковое пространство)? Очень часто выясняется, что нет. Взаимосвязи могут быть очень сложными и неочевидными, на практике часто нет прямой зависимости только от одного показателя, а действует комбинация нескольких одновременно. Ресурсами сервера может пользоваться не одна, а несколько систем, что еще более усложняет поиск зависимостей (например, база данных АБС используется рядом других систем, которые создают на нее дополнительную нагрузку). В случаях, когда действует много разных факторов и зависимости установить сложно, единственным более-менее точным инструментом для прогнозирования роста нагрузки становятся стенды нагрузочного тестирования. Чем точнее они будут повторять продуктивную нагрузку, тем точнее будут данные, полученные в ходе тестов. Со стороны ИТ в таких сложных случаях можно отслеживать только историческое изменение нагрузки на серверы/массивы и пробовать строить тренды, основываясь на этих данных без какой-либо привязки к бизнес-показателям. Конечно же, нужно иметь в виду и подсвечивать бизнесу, что такие прогнозы никак не будут учитывать его планы «по взрывному росту».
- Какой точный набор показателей нам нужен для сайзинга каждой информационной системы? И что именно нам даст анализ каждого конкретного показателя? Иногда начинают собирать много лишних параметров, которые потом в процессе сайзинга оказываются невостребованными. При этом их сбор, хранение и обработка требуют платформенных ресурсов и времени. Выработка подхода к сайзингу при его первичном проведении «руками» поможет понять, какие показатели нам точно нужны, и не собирать лишней информации.
- Есть ли в компании какие-то выработанные и утвержденные подходы к обеспечению отказоустойчивости продуктивных систем, резервному копированию и восстановлению, разделению продуктивных и тестовых сред, другие факторы, влияющие на архитектуру решений (например, требования ИБ). Каким именно образом в рамках сайзинга мы будем все эти подходы сохранять, а требования учитывать? Стандартный пример: если просуммировать прогнозы специалистов, ответственных за приложения, то нужно добавить в среду виртуализации три сервера, но для обеспечения отказоустойчивости кластеров виртуализации необходимо дополнительно заложить еще какое-то количество серверов. Если все это сразу не отразить в виде стройной концепции и не согласовать с бизнесом, потом будет сложно доказывать, зачем покупать больше, чем указали ответственные за приложения.
- Как изменяется нагрузка на платформу в зависимости от времени суток, дня недели, месяца? Насколько важно для бизнеса, чтобы при максимальной нагрузке платформа не «проседала», или они готовы терпеть некоторое замедление работы? От этого зависит, как мы будем делать сайзинг — опираясь на максимальные или средние показатели.
- Какие инфраструктурные системы и ресурсы тоже обязательно надо сайзить? Например, LAN, SAN, СРК, межсетевые экраны, каналы Интернет и т. д. И для каждой из этих систем также надо будет определить набор показателей, которые нужно собирать и учитывать при их сайзинге.
- Не забыть про лицензии на ПО. Желательно сразу определить список всего, что может меняться в зависимости от роста бизнес-показателей и при модернизации платформы. Это, например, лицензии на терминальные фермы и VDI, на СУБД, ОС, на прикладное ПО и т. д.
- Как мы будем презентовать бизнесу результаты сайзинга? Возможно, для этого потребуются дополнительные показатели и параметры. Чтобы не собирать их в спешке и не обрабатывать руками, нужно автоматизировать их сбор и обработку заранее.
По итогам первого «ручного» сайзинга вы получите четкое представление о подходах и наборе показателей, которые надо собирать. Также поймете, как именно вы будете их собирать и хранить. И уже затем можно будет переходить к автоматизации процесса и выбору нужных для этого систем.
Анна Слесарева
Руководитель отдела по работе с аутсорсинговыми заказчиками центра проектирования вычислительных комплексов компании «Инфосистемы Джет»
