Виталий Хозяинов. Финансовое управление службой ИТ в международной организации
31.08.2009
Автор: Виталий Хозяинов
сертифицированный сервис-менеджер
31.08.2009 г.
Эта статья является анализом собственного опыта автора по созданию процессов управления мощностью и финансового управления для ИТ.
«Канарейку за копейку, чтобы пела и не ела».
Народная присказка
Большинство руководителей служб ИТ рано или поздно сталкиваются с необходимостью значительного, в разы, повышения производительности своих сервисов. При этом подход к финансированию таких мероприятий в разных организациях различен. Где-то принято идти к владельцу ресурсов (финансовому или исполнительному директору) и просить высочайшего одобрения незапланированных и неотложных расходов, которое будет дано, потому что разбираться с последствиями проседания сервисов высшему руководству недосуг. В отраслях с неэластичным спросом можно и полностью проигнорировать потребность в быстром наращивании мощности – пользователи будут работать хоть ночью, но не сменят поставщика услуги. Достаточно вспомнить запуск ЕГАИС, чтобы найти пример такого подхода. А некоторых компаниях вспоминают присказку, вынесенную в эпиграф этой статьи, и предлагают службе ИТ решать проблему в рамках установленного на текущий период бюджета. Т.е. явно никто не отказывается оплачивать расходы на повышение производительности в связи со взрывным ростом основного бизнеса, но сроки и объемы предоставления финансирования предлагаются неадекватные задаче.
Именно в таком положении оказался и Ваш покорный слуга, работая в компании, занимающейся прямыми продажами. Бизнес этот имеет ярко выраженные периодические колебания. В пределах календарного месяца до 30% продаж приходится на последние 3 рабочих дня. В пределах года значительная часть продаж приходится на последние 3 месяца года и на недели перед 23 февраля и 8 марта. Потребление ИТ-сервисов, связанных с обслуживанием бизнеса компании, возрастает в это время пропорциональным образом. Наконец в один из осенних дней нагрузка в пиковые дни достигла уровня, при котором СУБД останавливалась, будучи неспособной обработать поток транзакций. Техническая сторона вопроса остается за рамками этой статьи, автор готов дать детальные пояснения в ответ на индивидуальные запросы.
Финансовый год в организации совпадал с календарным, причем этап планирования бюджета завершался в начале осени. Встала задача в течение очень краткого промежутка времени оценить затраты на замену оборудования на более производительное и провести согласование этих расходов. Принимающие финансовые решения лица сообщили, что внеплановый запрос будет рассматриваться очень долго, поэтому расходы следует включить в бюджет следующего года. Учитывая правила закупок и срок поставки оборудования, апгрейд становился возможен только через 6-7 месяцев. Неспособность обработать объем предновогодних заказов, предусмотренный в спешно пересмотренном плане продаж, стала весьма вероятной.
Для решения проблемы пришлось принять ряд организационных и технических изменений. Поскольку информационная система обслуживала несколько офисов в странах в различных временных зонах, автор достиг соглашения с заказчиками об изменении графика работы так, чтобы нагрузка была более равномерной в течение суток. График приема заказов через веб-сайт также был изменен, время окончания приема заказов, относящихся к продажам текущего месяца, перенесено на 23:59 последнего календарного дня месяца. Эти меры позволили снизить остроту проблемы в краткосрочном плане. Сделанные затем изменения в архитектуре приложения позволили снизить потребности в аппаратных ресурсах в расчете на одного пользователя информационной системы. Эти изменения позволили сохранить бизнес до момента перехода на новое оборудование. Техническая сущность сделанных изменений, не являясь предметом настоящей статьи, тем не менее весьма интересна. С экономической же стороны сделанные изменения в приложениях обошлись дороже, чем пришлось бы потратить на приобретение нового оборудования, так как в исполнении первых была задействована крупная команда программистов, бизнес-аналитиков, тестировщиков и администраторов баз данных, труд которых стоит недешево.
Пройденная кризисная ситуация заставила автора искать методы прогнозирования потребностей в ИТ-сервисах в привязке к ключевым показателям бизнеса. Такие методы должны были быть пригодны к применению в условиях взрывного роста бизнеса, позволять делать прогноз на срок до 18 месяцев (финансовый год плюс время на утверждение бюджета до начала финансового года плюс время на утверждение расходования средств в рамках согласованного бюджета плюс срок поставки оборудования) и позволять предвидеть точки, в которых производительность текущего программно-аппаратного решения не будет поддаваться линейному масштабированию.
Остановлюсь подробнее на последнем требовании. Наблюдение за работой имевшегося программно-аппаратного комплекса показало, что производительность системы в пересчете на 1 пользователя снижается с увеличением числа пользователей. Кроме этого, применяемые аппаратные платформы имели технические пределы масштабирования, не позволявшие увеличивать мощность системы простым добавлением процессоров или памяти. Радикальное изменение программного обеспечения, которое предоставило бы возможности масштабирования на имевшейся платформе, было очевидно более дорогостоящим, чем покупка любого «железа». Следовательно, в определенный момент повышение мощности могло быть достигнуто лишь заменой аппаратной платформы на принципиально более производительную и масштабируемую. Именно в предсказании таких переломных точек и состояло требование.
В качества отправных данных были взяты исторические сведения об объеме продаж, числе заказов, числе пользователей информационной системы (ИС), распределение заказов по каналам продаж, а также прогнозы названных показателей (KPI) на ближайшие два года. Для каждой из стран, офис в которой пользовался ИС совместно с другими, показатели были взяты отдельно. Результатом для ИС в целом было решено считать суперпозицию функций-прогнозов для каждой из стран в отдельности. Тут же стало понятно, что без исторических данных о нагрузке на конфигурационные единицы (КЕ) в составе ИС прогнозирование невозможно, поэтому были спешно внедрены средства мониторинга и регистрации нагрузки на процессоры, память и системы ввода-вывода.
Первым шагом было построение функции, определяющей зависимость между нагрузкой на КЕ и KPI. Пригодность полученной функции к применению было проверена на вновь полученных данных в течение 1 месяца после начала сбора информации о фактической нагрузке на КЕ. Получив подтверждение пригодности функции, автор подставил в нее прогнозируемые KPI. Точки, в которых значения функции достигали уровней, при которых ИС на текущей платформе демонстрировала снижение производительности в расчете на одного пользователя (допустим, при 80% нагрузке на КЕ), и были искомыми переломными точками. Смену платформы следовало произвести до достижения первой из таких точек. Очевидно, что в момент смены платформы соотношение между нагрузкой на KE и KPI изменится, поэтому исследуемая функция станет разрывной (см. рис. 1). Более того, указанное соотношение на новой платформе до ее появления в руках может быть оценено только очень приблизительно. Вендоры в этом деле, к сожалению, мало полезны, так как не имеют тяжелого оборудования в демо-пулах.
Имея на руках прогноз требуемой мощности, оставалось выбрать соответствующую ей платформу и составить смету расходов на приобретение аппаратной части и лицензий на ПО, стоимость размещения дополнительного оборудования в центре обработки данных и стоимость сопровождения от вендора. Не вдаваясь в технические детали, выскажу мнение, что при выборе платформы в такой ситуации лучше ориентироваться на лидера рынка. Выбор более дешевых платформ, конкурирующих с лидером рынка, или решений от лидера, продающихся под брендами универсальных поставщиков решений, влечет за собой сложности (читай – лишние затраты) в эксплуатации и в совместимости приложений. Ожидая рост потребности в мощности, следует выбирать решение с максимальным потенциалом масштабирования.
Построенная модель прогнозирования эффективно использовалась автором в течение трех бюджетных циклов, позволив добиться исполнения бюджета с погрешностью в пределах 5%. Эта же модель оказалась пригодной и для других задач финансового управления для ИТ, например для прогнозирования числа сотрудников, необходимых для сохранения существующего уровня сервиса, или оценки затрат на аутсорсинг разработки ПО. Более того, применение модели в процессе составления и согласования бюджета позволила эффективно управлять спросом на мощность. Заказчики, обозначив некоторые KPI в качестве своих целей и предлагая планы действий по их достижению, получали реалистичную оценку изменения расходной части бюджета, что позволяло им принимать более качественные решения о выборе целевых показателей и способе их достижения.
Необходимо отметить, что применение модели эффективно только при жесткой бюджетной дисциплине. Руководителю ИТ следует брать на себя ответственность не только за дальновидное составление бюджета, но и за контроль над расходами, включая учет расходов в реальном времени. Финансовые службы, конечно же, контролируют расходы, но делают это не всегда с достаточной оперативностью и не всегда представляют данные в необходимых разрезах. Собственный учет дает возможность корректировать расходы быстрее. Он также дает возможность легко ответить на вопрос о происхождении перерасхода или экономии по отдельным статьям бюджета.
Об авторе. Виталий Хозяинов – сертифицированный сервис-менеджер.
Присылайте вопросы на vitaly.khozyainov@gmail.com.
Возврат к списку