Что такое "футбол" в техподдержке российского ПО и как с ним бороться

Курс на импортозамещение взят давно — в конце 2014 года. И хотя по-настоящему широкомасштабная замена импортозависимого ПО на российское еще не начиналась, разработчики ПО и организации-заказчики не сидели сложа руки: проводили отбор продуктов, оценивали их качество в пилотных проектах, отрабатывали методики внедрения. Еще продолжают звучать вопросы: «А есть ли нормальное российское ПО»? «Насколько оно хорошее (функциональное, надежное, свободное от ошибок, совместимое с технологическим ландшафтом)»? «Какой же офисный пакет все-таки выбрать»? Но их острота значительно снизилась. Реестр отечественного софта содержит около 5000 наименований — федеральным и региональным министерствам и ведомствам, как правило, есть из чего выбирать. Даже в части «тяжеловесов»: ОС, СУБД, почтовых или коммуникационных систем, СЭД и т.д. Лидеры категорий многократно прошли проверку в пилотных проектах и доказали, что российские организации могут доверять отечественному ПО. Поэтому отношение к нему меняется в лучшую сторону. Это не очень заметная, но устойчивая тенденция.

В реальных проектах по внедрению и сопровождению импортонезависимого ПО (а не обсуждаемых чисто теоретически) всплывают совсем другие проблемы. Одна из них связана с тем, что замены сложным программным продуктам по схеме «один в один» не существует, причем это относится и к прикладному, и инфраструктурному ПО. Адекватная замена происходит на целый комплекс программных продуктов, в который зачастую входит не только софт, созданный российскими разработчиками, но и ПО, развиваемое международным сообществом Open Source. Соответственно, сложность сопровождения и обслуживания таких комплексов возрастает. А ведь есть еще и их стыки! Именно здесь возникают проблемы, определить и устранить которые особенно трудно, т.к. для этого нужен иной набор компетенций. И хотя российские разработчики достаточно быстро учатся работать с крупными заказчиками, здесь этой гибкости не хватает. Ведь их продукты в разных проектах объединяются то с одним ПО, то с другим. И накопление компетенций для всех возможных конфигураций неприемлемо дорого. Самые дальновидные разработчики стараются отдать эту непрофильную деятельность на аутсорсинг профессиональным сервисным компаниям или интеграторам. И построить с ними стратегические альянсы.

Но и здесь есть «загвоздка», которая портит даже эту — уже сложившуюся схему. Мы называем ее— «футбол».

Один мяч и пять ворот

«Футбол» в техподдержке программных продуктов — утомительное и бесперспективное для конечных пользователей ПО явление. Знакомое всем и каждому по… западным ИТ-решениям. Техподдержка каждого вендора отправляет пользователя к разработчику другого продукта, и это повторяется раз за разом. Для сервисных компаний — это конфликтный и тяжелый процесс, во время которого, в основном, выясняется не «что делать?», а «кто виноват?». Причем, на выяснение того, к какому вендору из 4-5, участвующих в проекте, на самом деле относится особо сложный ИТ-инцидент или проблема, уходит намного больше времени, чем на поиск решения. Рекорд в двенадцать эскалаций и «передач мяча» от вендора к вендору я разбирал лично, еще когда мой департамент работал только с западным проприетарным ПО.

«Лекарство» против «футбола» и его последствий

Проблему «перепасовки», случившейся при штатной работе ИС, можно снять простым дообучением инженеров техподдержки 1-й или 2-й линии. Штатных или оказывающих ИТ-услуги на аутсорсинге. Тут хорошо помогает классическое усиление и наращивание недостающих компетенций. Исключение составляют ИТ-специалисты с изначально «двойными» компетенциями (Linux/Windows). Но их на рынке немного.

Если же ИТ-проблема серьезна и требует подключения вендора ПО (на импортозамещающих проектах на такую ситуацию приходится 20-40% случаев), то снять её можно только особым образом выстроенной вендорской техподдержкой. Как это сделано в хорошо зарекомендовавшей себя первой открытой шине технической поддержки российского ПО. Здесь разные сочетания программных продуктов поддерживаются как единое целое по принципу «одного окна», с общими параметрами SLA на реакцию и решение ИТ-проблем.

Столь высокий процент (20-40%), с одной стороны, связан с «юностью» российского ПО. С другой — с недостатком компетенций по российскому и свободному ПО у штатных ИТ-служб компаний, которым нужно рассчитать или выполнить ИТ-проекты по импортозамещению в ИКТ. Другая причина — слишком частое обращение их ИТ-специалистов в вендорскую техподдержку.

Рассмотрим признаки правильно выстроенной поддержки российского ПО «от вендора».

Наличие компетенций по системообразующим и «безвендорным» продуктам

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

Особняком стоят т.н. «безвендорные» продукты — чистый Open Source. Такие продукты (например, nginx, puppet, ansible и др.) создает и развивает не коммерческая компания, а сообщество добровольцев, взаимодействовать с которыми нужно совершенно иначе. Без этого нужный результат не получить, и продукт останется без аналога 3-й линии техподдержки. Поэтому очень важно, чтобы сервисные компании или системные интеграторы придерживались этих правил. А сами были способны обеспечить для таких продуктов 1-ю и 2-ю линии поддержки. Это пока еще редкий, но очень важный навык, поскольку такое ПО всё шире применяется в импортозамещающих ИТ-проектах. Не будет большим преувеличением сказать, что Open Source уже является частью почти любого готового ИТ-решения (замещения «один в один» не существует, помните?).

Современные инструменты: мультивендорный портал техподдержки, ServiceDesk

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

• ИТ-процессы, адаптированные к поддержке российского ПО и Open Source

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

• SLA на только на реакцию, но и на решение ИТ-проблем

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

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

• Единый уровень SLA для всех программных продуктов в комплексе

Это не очень просто. Потому что у каждого вендора свое время реакции/решения ИТ-проблем (SLA). Он привык к нему, этот уровень «зашит» и в его Service-Desk, и в его процессах. Но для пользователей комплексов импортонезависимого ПО (федеральные и региональные министерства и ведомства) удобнее и выгоднее именно единое время реакции/решения ИТ-проблем. Потому что им важен конечный результат («проблема решена в срок»), а не разговоры о том, что она долго решалась из-за того, что вендоров уже не один-два, а пять или семь. Однако, тут и вендоры, и сервисная компания должны хорошо понимать ценность друг для друга.

• Широкая география поддержки

Техподдержка на основе гарантированных SLA должна вестись на всей территории России, включая Крым и Севастополь. Это еще один пункт, по которому вендорская поддержка российских продуктов выгодно отличается от того, что предлагают западные производители ПО. Такая поддержка возможна, если сервисная компания или интегратор развивают региональную партнерскую сеть, обучают партнеров и привлекают их к собственным федеральным/региональным проектам у крупных корпоративных заказчиков. А не действуют по модели «главный-подчиненный».

Как работает вендорская техподдержка

Представьте, что в ИТ-службу компании-заказчика импортонезависимого решения пришла заявка: «Медленно работает СЭД в среде ОС АЛЬТ». Заказчик обратился к вендору. Тот сразу, не пытаясь самостоятельно разобраться, где именно проблема — в ОС, СУБД, системе виртуализации — отправляет пользователя к сервисной компании (на мультивендорный портал техподдержки). Или же пользователь попадает туда сам сразу. Может быть и так, что заявку об ИТ-проблеме создает вендор («очень низкая производительность СЭД, помогите»). Но это редкость.

Сервисная компания, отвечающая за 1-ю и 2-ю линии вендорской техподдержки, выясняет, в каком модуле СЭД произошла проблема. И старается решить ее в рамках SLA между ним и вендором. В 95% случаев — успешно. Если же проблема относится не ко 2-й, а к 3-й (экспертной) линии (т.е. непосредственно к разработчикам), она будет направлена не наугад, а сразу по правильному пути. К вендору, к которому она действительно относится. И с результатами всей предшествовавшей диагностики (действия 1-й, 2-й линий, логи, дампы, присвоенный приоритет, уровень SLA). Тогда вендор отрабатывает свою часть проблемы максимально компетентно и в срок, предоставляя обходное решение («костыль»), которое позже будет заменено на окончательное (системное) решение.

При этом пользователь новых типов ПО не тратит время на попытки самостоятельно диагностировать проблему и определить, в каком компоненте импортонезависимого решения она случилась. Не «стучится» к вендорам, не теряет время на тот самый «футбол». А из одного окна получает гарантированное решение, точно в рамках SLA.

Это не только вопрос удобства пользователя. Систематическое «перекидывание», скрывающее плохую организацию работ, некомпетентность или неумение разработчиков договориться и реализовать кооперацию, может поставить под вопрос успешность внедрения почти любого импортонезависимого ПО. Напротив, четко отработанная схема взаимодействия, позволяющая забыть о «футболе» и получать квалифицированную техподдержку в срок, точно отвечает потребностям современного заказчика. И показывает, что российские сервисные компании и разработчики ПО всего за четыре года смогли превзойти западных вендоров на этом критически важном участке работ.