OpenSource и отечественное ПО в треугольнике проактивного управления ИТ

Импортозамещение западного проприетарного программного обеспечения (ПО) в российских госструктурах и муниципальных организациях вот уже год является главной темой отечественного ИТ-рынка. И если многим сначала казалось, что эта линия будет быстро свернута, то сейчас, когда принят Федеральный закон № 188 и постановление Правительства №1236, крупные организации-заказчики осознали, что переход на отечественное ПО и Open Source неизбежен. Причем, чтобы не остаться в отстающих, первые шаги придется сделать уже в середине следующего года, а это очень короткое время по меркам госкорпораций и сегмента Enterprise. 

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

Иными словами, при переходе на новые виды ПО, государственным и крупным коммерческим организациям крайне важно сохранить главное достижение периода проприетарных ИТ — уверенное внедение и надежную работу ИС, качественную поддержку непрерывности основной деятельности, а также возможность для подразделений взаимодействовать с ИТ-службами на основе формализованных соглашений о качестве обслуживания (SLA). Еще лучше, если параметры этих SLA при переходе на новые виды софта не ухудшатся, в частности, не возрастет их вариативность. Именно это сейчас —главное. Поскольку, если эта задача будет решена, реальные проекты импортозамещения не станут источником разочарований. Можно ли решить эту задачу на практике? В этой статье мы даем ответ на этот вопрос.

Для этого мы сначала посмотрим на то, что достигнуто в области внедрения и сопровождения западного проприетарного софта, а потом выясним, как перенести эти достижения в сферу Open Source и отечественного программного обеспечения.

Жизнь с опорой на ITSM

Сегодня российские организации – крупные, средние и даже малые – четко разделились на два лагеря. В одном – те, кто не умеет управлять ИТ, несмотря на штат ИТ-специалистов и напряженное «латание дыр». Во втором – предприятия, уверенно использующие возможности ИТ. Их секрет — в умении применить современные подходы к управлению информационными технологиями.

По-настоящему эффективно и уверенно управлять ИТ-системой любой сложности позволяет т. н. сервисный подход (ITSM), основные черты которого определены в стандартной библиотеке ITIL. Библиотека предлагает классификацию событий, возникающих при обслуживании ИС на протяжении их жизненного цикла, и задает требования к алгоритмам их обработки и их взаимосвязям. Это и есть ИТ-процессы.

В настоящее время для подавляющего большинства российских компаний актуальны не более 10 взаимосвязанных ИТ-процессов, а для конкретной государственной или коммерческой организации, число действительно нужных ей процессов, как правило, еще меньше. На схеме № 1 показана матрица, с помощью которой любое предприятие, вне зависимости от масштаба и специализации, может правильно выбрать наименьший комплект процессов, которые (в совокупности) делают управление информационной системой прогнозируемым, качественным и измеримым. Внедрив эти процессы, организация не только поддерживает работоспособность своей ИС в соответствии с периметрами SLA, но и может прогнозировать ее простои и возможные потери за месяц, квартал и т. д. 

Приведу определения трёх важнейших ИТ-процессов:

• Управление инцидентами – это алгоритмизированный набор действий, позволяющий наиболее быстро и эффективно устранить любое нарушение в работе ИТ-системы. При этом он уменьшает или исключает отрицательное воздействие нарушения. 

• Управление проблемами – это четко выстроенная последовательность действий, помогающая максимально точно и оперативно выявить и устранить скрытые причины постоянно повторяющихся проблем (серий инцидентов).

• Управление изменениями – это процесс, отвечающий за результативную работу с жизненным циклом всех изменений информационной системы при модернизации существующих и внедрении новых элементов, а также при поддержке соответствующих проектов. В рамках этого процесса разрабатывается перечень и очередность всех изменений, а также комплекс мероприятий по восстановлению исходного состояния, если внедрение пошло не так, как было задумано.

Замечу, что эти ИТ-процессы (в комплексе с подсистемой Service Desk, являющейся пользовательским интерфейсом всей системы ИТ-процессов) играют важнейшую роль не только в устоявшейся поддержке ИС крупного предприятия, но и при внедрении и обслуживании новых решений, базирующихся в том числе на Open Source и отечественных ИТ-продуктах.

Только опираясь на целостную систему внедренных и используемых на практике процессов, любая компания (муниципальная, государственная или коммерческая) может слаженно работать в части ИТ, а ее информационные системы будут сопровождаться с понятным всем участникам уровнем сервиса. Благодаря «лестнице» SLA (Service Level Agreement), построенной на фундаменте процессов ITSM, организации получают шанс для эффективной работы и правильного ведения дел — автоматически попадая в «поле» конкретных показателей качества, отражающих деловые и ИТ-потребности. При этом ранжирование ИТ-процессов опирается на реальное, а не на желательное значение рабочих процессов. Например, скорость реакции ИТ-службы на критичные инциденты в работе СЭД, крайне важной для госучреждений, будет составлять 30 минут, а время решения инцидента – 1 час. Для коммерческих компаний наиболее значимой будет скорость реакции на остановку/потерю темпа продаж или отгрузок (плохая работа «1С», CRM, торгово-складских программ). Скорость реакции здесь может составлять 15-30 минут, а скорость закрытия инцидентов – также 1 час.

Процессы по размеру и правильные SLA

Однако разным компаниям, в зависимости от их масштаба, степени ИТ-зрелости, финансовых и организационных возможностей, нужны разные по реализации процессы управления запросами, инцидентами, проблемами, мощностями, релизами и т.д.

Если, скажем, крупная государственная компания реализует процессы слишком упрощенно, их слишком мало, они недостаточно детально проработаны или не опираются на реальные рабочие алгоритмы компании, предприятие обязательно угодит в ловушку неверных SLA. И не повысит, а понизит управляемость ИТ. Аналогично обстоят дела и с крупным бизнесом с высокой зрелостью ИТ. Процессов может быть слишком много, или они могут быть чересчур сложными (слишком детальная автоматизация процессов в Service Desk). Если процессов много, то ИТ-специалисты просто не будут пользоваться ими. Но если процессы слишком сложны, сотрудники ИТ-департамента привыкнут обманывать систему, потому что: «Как ни делай, правильно не получается!». Т.е. целевые значения SLA не будут достигнуты, что сразу негативно скажется на основной деятельности организации.

И вот, появляется OpenSource…

Но сегодня на организации влияет не только внутренняя ситуация или положение на рынке, но и целый ряд внешнеполитических факторов: взлетевшая до небес стоимость лицензий на западное ПО (в 2-2,5 раза с момента первой подписки год назад и это не последний «взлет»), тренд на импортозамещение и др. Импортозамещение заставляет государственные структуры и коммерческие предприятия разворачиваться в сторону отечественных разработок и решений на базе OpenSource. Или же в сторону их интеграции. Но реализация планов быстрого перехода на свободное и отечественное ПО приносит в жизнь крупных компаний, особенно с невысокой зрелостью ИТ, совершенно новые риски. Вызванные неподготовленностью ИТ-процессов к внедрению и обслуживанию OpenSource-решений.

Это риски, связанные с выбором, внедрением, поддержкой, эксплуатацией и развитием «свободных» проектов. Сложности могут возникнуть (и возникают!) на каждом этапе. Вот лишь несколько примеров.

Выбор замены Равноценная замена любому определенному виду многофункционального проприетарного ПО — как правило, целый «букет» OpenSource-решений со схожим функционалом. Да, стэк «свободного ПО» закроет до 80% нужд заказчика. Но выбор и тестирование нужных функций основного и дополняющего ПО грозят затянуть исследовательскую стадию проекта в 3-5 раз. Т.е. вместо двух она будет длиться 6–10 месяцев. И «тянуть» из заказчика и деньги, и ресурсы все это время. Здесь, конечно, проявляется полезный для крупного заказчика плюс — стэк правильно выбранного СПО дает только нужные на практике функции, без overselling-a. Но риск ухода проекта в бесконечность уже на этапе НИОКР — крайне велик. Единственно верным решением здесь будет применение готовых технологических платформ, покупка уже протестированных конфигураций и выбор из их числа (с помощью интегратора, специалиста в штат).

Внедрение СПО Нет привычной опоры на связку «заказчик-внедренец-вендор». Опора переносится либо на сообщество разработчиков, если оно зрелое и следит за развитием продукта, либо на недешевого для заказчика эксперта. Но лучшим решением, на мой взгляд, здесь будет сформированный у исполнителя центр компетенций по OpenSource. Внутри такого центра все продукты и решения должны быть разделены на ключевые и дополнительные. По ключевым у интегратора нет «белых пятен», а компетенции — консалтингового уровня (3 линия техподдержки — т.е. не только решение экспертных вопросов, но и проактивный поиск замен в привычных связках продуктов, сборка новых решений и пр.). На 2 линии — компетенции в стадии «довода» до экспертных. На 1-м идет прием и обработка инцидентов, а также опора на компетенции более опытного в части «своих» OpenSource-продуктов и решений партнера-интегратора.

Сопровождение Привычные процессы сопровождения проекта ломаются, т.к. внутри этих процессов, рассчитанных на проприетарное ПО, изначально заложен этап эскалации проблем на вендора, а в случае использования продуктов Open Source его просто нет. Получается, что почти ни один системный интегратор или аутсорсер, кроме крупных и/или успевших развить компетенции и за много лет наладить отношения с сообществами, развивающими и поддерживающими эти продукты, не может гарантировать решение проблем в режиме NBD (Next Business Day) или даже NBD+. Честная позиция состоит в том, чтобы отражать это ограничение интегратор в отдельных пунктах SLA, связанных с сопровождением проектов на OpenSource.

Возрастает и нагрузка на службу сопровождения, т.к. инцидентов, проблем и изменений в окружающей инфраструктуре становится, как минимум, в 2 раза больше. Только дополнительное исследование инцидентов (например, медленная работа связки «1С»+PostgreSQL) может растянуть решение инцидента в 2-3 раза (новые консультации, выбор другой конфигурации, новые тесты). И это немного, т.к. решением, скорее всего, станет обходной путь. А этап диагностики и поиска решения проблем, генерирующих инциденты (проблемы с кодом «1С»), может вырасти во времени до 5 раз!

Когда внедрений OpenSource немного (2-4 в год на интегратора) – риски могут не стать системой, т.к. нивелируются каждым исполнителем в зависимости от уровня компетенций. А когда поток внедрений начинает расти в 3-5 раз, общий вес всех рисков, может обрушить 90% OpenSource-проектов и привести к массовым разочарованиям и сотням миллионов убытков у заказчиков. Потому что на OpenSource переносится поддержка ключевых бизнес-функций, от которых зависят коммерческие успехи крупного бизнеса и качество работы госкорпораций. Продажи, финансовый контур («1С+PostgreSQL), надежность производства услуг (Zabbix+Puppet), коммуникации (Asterisk и «форки»). Чтобы не допустить коллапса, интеграторам стоит предложить решение, позволяющее снять основные риски при внедрении и сопровождении OpenSource. Причем, не консервативное — рост резерва времени, сил исполнителя и затрат заказчиков на проекты — а проактивное. Построенное на принципиально иных подходах к проектной, процессной и предпроектной составляющим. Но ИТ-зрелость интегратора и клиентов должны совпадать.

Интегрированное ИТ — путь от разочарований к победам OpenSource

Интегрированное управление ИТ-проектами, ИТ-процессами и ИТ-аудитом хорошо подходит для сложных внедрений и адаптирующего сопровождения OpenSource-проектов. Все три ранее обособленные подхода, объединяются в один, тесно связанный «кластер» работ. В треугольник, стороны которого равноценны и непрерывно обмениваются информацией. Правильно накопить, распределить и «обменять» данные по каждому блоку работ уже в ходе, а не исключительно по итогам проекта (что поздно!), помогает обязательный процесс управления знаниями или база знаний (схема №2). Ниже я расскажу о самых важных частях и результатах «обмена».

От ИТ-аудита во внедрения (проекты) Сделав обязательным «нулевым» этапом общий аудит инфраструктуры, ответственные за OpenSource-проект получают верную и полную информацию о ее состоянии, реализации и настройках ИТ-сервисов, о взаимосвязях между ними. И, главное, о том, какие проблемы и риски могут ожидать их при внедрении и где именно (например, нехватка серверных мощностей на региональном участке инфраструктуры). Эти данные целесообразно не только учесть при внедрении, но и сразу заложить в процессы управления изменениями. Конечно, общий аудит добавит 1,5-2 месяца и до 15% затрат к стоимости проекта, но само внедрение пройдет максимально правильно - без 50% перезакладывания средств. Точнее будут заложены и ресурсы (на 15-25% меньше), что существенно для проектов длительностью 6-12 и даже 4-6 месяцев!

От ITSM-процессов — в проекты. Управление инцидентами, проблемами, изменениями и релизами ПО — встроенные в поддержку проекта, минимизируют его ключевые риски («невзлет», провалы по срокам, бюджетам, ресурсам). А также максимально быстро снимают риски срыва, например, полугодового проектного этапа, когда что-то пошло не так (управление инцидентами, проблемами).

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

Так, при миграции на «свободную» СУБД «нулевой» ИТ-аудит позволит определить все системы, которые обращаются к ней в ходе миграции, а процесс управления изменениями, в свою очередь, даст возможность не забыть ни об одной из 50-100 систем, предусмотреть для каждой детальный план отката, если конфигурация оказалась неоптимальной и пр.

Миграция на «свободную» СУБД — проект в «треугольнике»

При объеме проекта в 50—100 ИС я рекомендую государственным компаниям и коммерческим корпорациям разбивать слишком долгое двухлетнее внедрение «свободной» СУБД на 10-12 микропроектов, длительностью по 2, 5 месяца. И с полезным результатом в финале каждого (скажем, перенесли группу «А» из 10 столичных баз данных на новую СУБД, сэкономили миллионы рублей на лицензировании). В случае, если старту каждого микропроекта предшествуют обязательные микроаудиты, снимается риск срывов (и неоплаты!) долгих и сложных полугодовых этапов. Общий ИТ-аудит поможет сделать главное — учесть и правильно сгруппировать все базы данных и ИС. Например, по территориальному признаку, по цене лицензирования (сначала те, что требуют самого дорогого) или по похожести информационных систем.

Если все сгруппировано правильно, тогда каждый микропроект пойдет быстрее предыдущего, т.к. коммерческие СУБД в таком проекте — однотипны, а ИС — во многом похожи. Причем микроаудиты в начале каждого этапа (1—2 дня, упрощенное оформление) позволят проверить правильность группирования конкретных систем, учесть все связи СУБД и ИС на конкретном участке инфраструктуры, а не в целом, снять слабые точки именно на этом участке (не хватает мощностей — докупить в облаке) и информировать заказчика о том, насколько быстрее пройдет следующий этап. Кстати, переключив на проверенную конфигурацию СУБД группу «А» из 10 ИС в столичных филиалах компания получает успешный «пилот». И может идти дальше, по четкому плану, поддерживаемому «обменом информацией» с ИТ-процессами. Так как именно процесс управления изменениями помогает безошибочно спланировать все этапы внедрения. Например, перенести базы при подключении сервисов к новой СУБД в минимально-критичный для компании период — без «пиков» продаж. А серию нагрузочных тестирований на новой СУБД — в максимально-активный. Учитывается и оптимальное количество серверных мощностей для параллельной работы сначала двух, потом одной СУБД, возможность быстрого возврата к прежней СУБД (15 минут), если «свободная» в пики нагрузки покажет критично-низкую производительность.

На выходе такое взаимодействие «сторон треугольника» улучшает не только планирование проекта, снижая общие сроки по отношению к первой оценке на 40%. Но и проектные затраты, — в среднем, на 50% (нет внедрения «наживую» — меньше замен компонентов и откатов системы назад, нет ночных переработок специалистов и т.д.).

От OpenSource – к отечественному ПО

К сожалению, уже становится ясно, что многие вендоры российского ПО не слишком способны помочь интеграторам, внедряющим их продукты. И в этом смысле они мало чем отличаются от сообщества разработчиков OpenSource. Поэтому для работы с российским ПО будут справедливы такие принципы рассмотренной методики, как разбиение на обособленные и обладающие самостоятельной ценностью для заказчика «микропроекты», «нулевой» ИТ-аудит, дающий полное представление о состоянии ИТ-инфраструктуры, каскад мини-аудитов, описывающий сильные и слабые стороны инфраструктуры на каждом конкретном участке внедрения (региональные, центральные участки, участки, расположенные в других часовых поясах и пр.). А также вынесение самых хлопотных или дорогостоящих для компании этапов (НИОКР, тестирование продуктов в разных средах) в число первых микропроектов. Но надо учитывать, что на таких проектах даже хорошо работающие процессы управления ИТ будут работать хуже, чем обычно: пока в достаточной мере не накоплены практики работы с целыми линейками отечественных продуктов.

В заключение

Ориентация рынка на OpenSource неизбежна. И, скорее, положительна. Но она требует комплементарных изменений в процессе управления ИТ. Причем, как при внедрении, так и при сопровождении внедренных решений. А также на важных этапах, предшествующих внедрению (ИТ-аудиты). Здесь компании могут двигаться по-разному — применяя консервативный подход, где все части работ на проектах ведутся обособленно. Или же взяв за основу проактивную формулу, где проектное управление, ИТ-процессы и аудит применяются интегрировано, циклически обмениваясь друг с другом важной информацией. Проактивная методика («треугольник») позволит государственным и коммерческим компаниям получить серьезную финансовую и технологическую выгоду от OpenSource-проектов и внедрений отечественного ПО. А также избежать разочарований, в основе которых — ошибочная оценка состояния инфраструктуры, недостаточная продуманность самого внедрения и неверное применение матрицы ИТ-процессов при поддержке.

Важно, что в рамках такого подхода проекты на базе «свободного» программного обеспечения можно реализовывать в целом в 1,5-2 раза быстрее, чем в рамках подхода традиционного. И, соответственно, максимально приближать временные затраты к привычным внедрениям с участием проприетарного западного ПО.

Этому способствует сразу несколько факторов: а) непременный учет новых условий и обязательная опора на интегрированные составляющие работы с ИТ: аудиты, процессы, оптимальное проектное планирование б) четкая и целенаправленная работа центров экспертных компетенций у системного интегратора, подразумевающая налаживание и расширение связей с производителями ПО и сообществами разработчиков. Наряду с постоянным поиском и предложением крупным государственным и бизнес-заказчикам новых, еще более эффективных свободных продуктов и созданных на их основе технологических платформ. Если же ограничиться применением стандартной методики, то рост времени на проекты с участием OpenSource и отечественных решений грозит сделать их нежизнеспособными уже на первых этапах (НИОКР, подбор нужных конфигураций, тестирования и др.), а разочарования от качества поддержки работы компании станут практически неизбежными.