Главная проблема миграции на Open Source и пути ее решения
Нормативная база и действия регуляторов четко определяют: для большей части отечественного ИТ-рынка импортозамещение в сфере ПО не когда-то будет, а уже началось.
Сегодня это касается и госзакупок (на основе ФЗ-44), и закупок госкорпораций (конкурсы, соответствующие ФЗ-223). Реестр импортозамещающего ПО, насчитывающий свыше 700 замещающих продуктов, стал зримым практическим результатом подготовки к импортозамещению. В число подобных продуктов входит и свободное ПО, которое развивает международное сообщество. А это широчайшая номенклатура решений и технологий. В таких условиях указанным категориям заказчиков будет трудно выдерживать «импортозамещающую паузу». Тендеры начнутся в третьем квартале текущего года, а в 2017-м внедрение как свободного, так и российского ПО станет одним из главных векторов развития отечественного ИТ-рынка.
Но по какому сценарию пойдет внедрение? Будет ли это ПО использоваться в ключевых информационных системах (ИС), поддерживающих основную деятельность организаций, или в малозначащих проектах? Ответ зависит от ожиданий заказчика в отношении функциональности и надежности нового ПО. И от уверенности в том, что при внедрении и эксплуатации оно будет обеспечено качественной сервисной поддержкой на всей территории страны. То есть смогут ли новые решения создать не менее (а иногда и более!) надежный фундамент для основной деятельности, чем традиционные проприетарные, от западных поставщиков.
К сожалению, сегодня у потенциальных заказчиков преобладают неадекватные представления, хотя многие из них активно изучают новую область. Особенно когда речь идет об СПО. Так можно ли положиться на него именно сейчас?
Импортозамещение на СПО как технология: критерии и риски
Избежать разочарований при развертывании и эксплуатации решений на базе Open Source можно только с помощью качественных и экономически просчитанных внедрений, превращенных в технологию. И технология эта должна быть подкреплена четырьмя факторами: правильной оценкой начального, меняющегося и достигнутого состояния ИТ-инфраструктуры; особой методикой внедрения и сопровождения проектов, опирающейся на новые категории ПО; применением матрицы ИТ-процессов при поддержке систем; получением гарантированных параметров такой поддержки, согласованных с конкретными бизнес-целями заказчика.
Понятие «качество внедрения ИТ-решений на базе стека свободных продуктов» также требует уточнения. Сегодня качественным можно считать такое развертывание, которое соответствует сразу трем критериям: занимает такое же или меньшее время, чем внедрение проприетарного ПО; сопоставимо с последним по ресурсным и материальным затратам; дает надежное в эксплуатации решение.
Чем грозят некачественные внедрение и поддержка проектов на базе OpenSource?
Если проигнорировать первые два условия, проект грозит стать разорительным долгостроем. Только одна ошибка — неправильное планирование внедрения — повлечет за собой сильно завышенные материальные затраты. Так, при общем аудите состояния ИТ-инфраструктуры они будут превосходить нормы на 50%. Ресурсы исполнителя, скорее всего, тоже окажутся избыточными. Что выльется в лишние расходы для заказчика. А ресурсов может оказаться больше, чем нужно, на 15–25%.
Неверно спроектированные ИТ-процессы, призванные обеспечивать проект, несут еще больше бед, так как от них не приходится ждать главного — надежности и предсказуемости при поддержке решения. С использованием свободного ПО, инцидентов и изменений в окружающей инфраструктуре становится как минимум вдвое больше. Значит, удваивается нагрузка на службу технической поддержки. И это — если исключить самые сложные случаи. Стадия же дополнительного исследования самых сложных инцидентов (недостаточно быстрой работы связки 1С+PostgreSQL) может замедлить их решение еще в 2–3 раза, так как потребуются повторные консультации, выбор другой конфигурации, тесты. Продолжительность же этапа диагностики и решения проблем, генерирующих инциденты, связанные с использованием СПО (например, с кодом «1С»), может вырасти до 5 раз.
А если заказчик при этом опирается на недостаточные, избыточные или неправильно спроектированные ИТ-процессы, он гарантированно попадает в поле надуманных показателей качества, тогда как ему нужно. чтобы качество поддержки любого решения на СПО было реальным и полностью гарантированным. Прежде всего, единым уровнем SLA, причем по всей России, ведь у заказчика распределенная структура с множеством филиалов!
Как я уже говорил, качество поддержки импортозамещающих решений должно быть как минимум не хуже, чем решений на базе проприетарного ПО. Скажем, госучреждение с внедренной СЭД должно автоматически получать 30-минутную реакцию и закрытие инцидента за 1 час. А крупное предприятие, для которого чрезвычайно важна непрерывная работа «1С» и торгово-складских программ, может рассчитывать реакцию в 15 минут и на тот же 1 час на закрытие инцидента. И подобное качество поддержки должно быть не индивидуальным, а типовым. Его может дать только сформированный и проверенный на практике SLA. Кстати, в договор о гарантированном качестве услуг должны быть включены и «подводные камни», связанные, например, с невозможностью поддержки в режиме NBD (NextBusinessDay) или NBD+ (NextBusinessDayPlus) из-за отсутствия вендора.
Интегрированное управление ИТ и смягчение кризисных рисков
Типичное для кризисных периодов непредсказуемое замораживание финансирования ИТ-проектов или значительное урезание ИТ-бюджетов тоже оказывают сильное влияние на успех миграции на Open Source. Традиционная проектная методика в этих условиях буксует, создавая высокие риски и для исполнителей, и для заказчиков. Чтобы миграция не закончилась тем же долгостроем, рекомендую применять интегрированное управление ИТ-проектами, аудитом и процессами, в основе которого лежит подход Agile.
Этот метод позволяет разбить слишком длительное (двухлетнее), сложное и дорогое внедрение (например, той же PostgreSQL), на 5–10 независимых стадий по 1–2,5 месяца. Содержание работ надо выбирать так, чтобы в конце каждого этапа компания-заказчик получала полностью действующую систему, в которой произошло ощутимое приращение функциональности. Начальное, промежуточное и итоговое состояния контролируются ИТ-аудитами. При этом только первый аудит оказывается относительно дорогим и долгим. А остальные — узконаправленными и быстрыми, поскольку нужно оценивать малый объем изменений.
Типичный пример такого подхода — внедрение ИТ-решения во многих филиалах. Переведя один-два функционала на новую СУБД (в приоритетных группах филиалов), компания получает качественный «пилот» и эталон процесса внедрения. Дальше она может подключить к эталону правильно выстроенный ИТ-процесс управления изменениями, позволяющий верно спланировать остальные этапы миграции (нагрузочные тестирования в активные периоды, подключение сервисов к новой СУБД в праздники и пр.). А финальные микроаудиты помогут за несколько дней проверить качество реализации каждого этапа. Такой типовой проект можно без особых рисков тиражировать в 40–70 и более регионах.
Хочу подчеркнуть, что управление изменениями не может строиться в отрыве от других составляющих. Только весь пакет ИТ-процессов (управление изменениями, инцидентами и проблемами) предоставляет возможность оперативно, в соответствии со SLA, устранять неполадки и выявлять их причины. И при этом обеспечивать минимальную вариативность каждого показателя, включенного в соглашение. Соответственно, заказчик контролирует и снижает не только расходы, но и риски, связанные со временем внедрения и эксплуатацией решения, то есть избегает самых тяжелых разочарований, вызванных СПО и импортозамещением.
Это не значит, что разочарований не будет совсем. Открытое ПО, как, впрочем, и многие классы российского программного обеспечения, пока не прошло многолетнюю обкатку в реальных условиях. Однако, профессиональные сервисные компании, имеющие все необходимые компетенции для работы со свободным ПО и взаимодействия с российскими проектировщиками, вполне способны кардинально смягчить возможные риски. В том числе вдумчиво подходя к созданию SLA с низкой вариативностью показателей.
Правильный SLA — залог качественного ИТ-обслуживания
В связи со SLA возникает еще одна весьма существенная проблема, которую пока мало обсуждают даже в отраслях, где жесткий SLA давно стал нормой. Для одних категорий центральных и региональных клиентов выгоден единый, статический SLA (SMB, фармацевтика, туризм, госорганизации, где ведется постоянная работа с населением), а для других приемлем только динамический или Smart SLA с параметрами, обусловленными спецификой конкретного региона, филиала, магазина, отделения. Это распространяется и на OpenSource-решения. Но для них реализация Smart SLA — совершенно новая тема, требующая от сервисной компании создания множественных регламентов одноименных ИТ-процессов.
Очевидно, что интегратор или поставщик аутсорсинговых услуг не может самостоятельно настроить и проконтролировать выработку Smart SLA в регионах. Но он должен показать, как это правильно делать, научить своевременно переводить территориальные единицы из группы в группу, если условия в регионе или в данной единице изменились (понизилась проходимость, устарело и требует замены оборудование, выросла критичность отказа, увеличился риск простоя и убытков).
Не менее очевидно, что ИТ-компания, берущая на себя ответственность за SLA и Smart SLA на всей территории РФ, должна не просто располагать партнерской сетью, но и уметь передавать партнерам часть технологии работы с новыми видами ПО, а также замыкать ИТ-процессы на собственный центр компетенции по Open Source и импортозамещению. И на аналогичные центры других компаний, среди которых могут быть не только партнеры, но и конкуренты. А это, с одной стороны, требует особой технологии оперативного взаимодействия центров компетенции в рамках одного инцидента. Технологии, управляемой своими, более жесткими, SLA. С другой стороны, перед партнерами открывается возможность развития за счет наращивания и продажи компетенций по определенным продуктам в рамках всей сети. Региональная компания, не входящая в партнерскую сеть, таких возможностей не имеет.
Недостаточность компетенций по СПО. Ситуация в регионах и работа с партнерами
Применение обоих видов импортозамещающего ПО поднимает непростой для всего рынка вопрос, связанный с невозможностью использовать стандартную для интегратора технологию приобретения компетенций по конкретным продуктам. В большинстве категорий ПО есть множество вариантов, но лидеры не определились. И на данный момент интеграторы, особенно крупные, для которых инвестиции в компетенции очень велики, а риск ошибки особенно весом, плохо понимают, какие компетенции нарабатывать или покупать, какие доводить до экспертного уровня (2-я и 3-я линия техподдержки), а для каких достаточно базового (1-я линия). В случае СПО не только не удается вывести гистограмму популярности продуктов, но и неясно, как на практике быстро приобрести нужную квалификацию по тем, что выбраны. Готовых специалистов нет, вендора с его отработанными программами обучения и сертификации тоже нет, учебные центры не располагают нужными знаниями...
Инвестировать в то, что завтра может оказаться невостребованным или неприбыльным, ни одна разумная ИТ-компания не может. Но и терять драгоценное время — тоже. Значит, решение проблемы нужно искать в другой плоскости. Наиболее реальный выход — создание заинтересованными в успехе импортозамещения ИТ-компаниями сети сотрудничающих между собой узкоспециализированных центров компетенций. Это делает внедрение у любого заказчика максимально надежным и быстрым, а также сокращает сроки обкатки проектов на СПО. Причем взаимодействие генерального подрядчика и соисполнителей позволяет довести SLA на конкретных проектах до уровня, характерного для западных проприетарных решений.
От реактивной к проактивной поддержке проектов на базе Open Source
У ужесточения SLA есть естественные пределы, преодоление которых невозможно или нерентабельно. Или же оно по умолчанию предполагает переход от реагирования на проблемы к их предотвращению, то есть к проактивной поддержке проектов, в том числе на свободном ПО.
Для этого мало внедрить систему ИТ-мониторинга. Нужно большее — коммерческий сервис централизованного мониторинга и контроля. Это профессиональная команда из нескольких специалистов (аналитик, системный администратор, специалисты по определенным продуктам инфраструктурного и прикладного уровня), которые, используя комплекс технических инструментов и методик, постоянно отслеживают ситуацию с конкретной ИС, заблаговременно выявляют ее переход в «желтый сектор», вырабатывают корректирующие решения и немедленно применяют их — дистанционно или с помощью сотрудника из организации-заказчика. Или же с помощью местного партнера. Создав такой сервис (на базе ПО Open Source) и располагая опытом его практического применения, мы уверены, что нашли наилучшее решение для компаний, которым нужны особая надежность ИТ-систем, непрерывный контроль за их работой, интеллектуальное управление производительностью приложений. А их, особенно в Enterprise-сегменте, сегодня более чем достаточно. И методы, и инструменты, описанные в этой статье, для них жизненно необходимы.
