Сергей Мисюра: «В техподдержке – 95% инцидентов уникальны по содержанию»

Основатель и директор Центра технической поддержки РДТЕХ Сергей Мисюра развеял стереотипы в сфере технической поддержки СУБД, в числе которых мнение о том, что проблемы заказчиков, как правило, повторяются. Эксперт сообщил, что революции в ИТ происходят редко, и одна из них случилась в сфере СУБД. Также рассказал о трансформации процессов предоставления услуг техподдержки и об этическом характере трудностей, связанных с внедрением ИИ-инструментов.

– Сергей Петрович, как были созданы современные реляционные СУБД?

– Во времена моей молодости доминировали иерархические или сетевые СУБД – предшественники реляционных систем. Была тогда в ходу, например, СУБД IMS от IBM, в русском варианте она называлась «Ока», Adabas, ряд отечественных разработок – ИНЕС, СУБД Протва и другие.

Революция в мире СУБД произошла после того как сотрудник исследовательской лаборатории IBM профессор Эдгар Кодд формализовал представление данные в виде таблиц, описал возможные связи между таблицами и набор операций для работы с данными.

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

Тем не менее, опубликованная в 1970 году статья Кодда стала толчком для создания первых реальных прототипов, поскольку автор подробно расписал концепцию «реляционной алгебры», набор операций для работы с данными.

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

– И часто такие парадоксы встречаются в развитии ИТ?

– Обычно развитие информационных технологий идёт эволюционно, по течению, и новые решения более эффективны, чем предыдущие. Примеров, подобных возникновению реляционных СУБД немного. На моей памяти был еще один революционный скачок – он связан с RISC-серверами.

У компьютеров, которые доминировали в 70-х годах – в основном, мэйнфреймов IBM, был очень сложный набор команд процессора – их количество исчислялось тысячами. Дошло до того, что микропрограммы для этих команд нужно было загружать со специального ленточного накопителя перед началом загрузки ОС.

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

– Вам приходилось иметь дело с данными в тот период, когда вы работали в Институте физики высоких энергий?

– Я начинал в ИФВЭ как системный программист на машине ЕС-1040. Потом перешел в Отдел нейтринной физики. В середине 80-х годов в Протвино начал строиться масштабный коллайдер УНК, установка такого же уровня, что и Большой адронный коллайдер в ЦЕРНе. Мы готовились к созданию экспериментальной установки УКД на УНК. В проектах на УНК, конечно, планировалось использовать СУБД, но я не имел отношения к этой теме. Во время испытания прототипов будущих компонентов УКД, данные записывались на магнитную ленту во время сеанса ускорителя У-70. Но структура данных была слишком проста, не было необходимости в использовании СУБД для работы с этими данными.

– Как получилось, что компания РДТЕХ работала уже несколько лет, с 1992 года, а ЦТП еще не существовало?

– Это объяснялось особенностями взаимодействия с корпорацией Oracle – РДТЕХ стал одним из первых ее партнеров в России в 1993 году. Вендор в тот момент еще не был готов отдавать сервис техподдержки другим организациям, пусть даже партнерским. Хотя, например, учебные центры он активно сертифицировал, и наш УЦ РДТЕХ был открыт в 1995 году.

До сих пор корпорация Oracle во всём мире оказывает техническую поддержку только самостоятельно, не передоверяя ее никаким компаниям. Кроме стран бывшего СССР. Для них в свое время сделали исключение, поскольку в момент прихода Oracle здесь активно функционировало сообщество пользователей ПО Oracle. Было множество квалифицированных специалистов, которые умели работать с этим софтом.

Соглашение с Oracle о технической поддержке носило название First Line Technical Support Agreement, в нём компании РДТЕХ предоставлялось право оказания технической поддержки ПО Oracle первой линии. Если мы не могли самостоятельно решить проблему клиента, то должны были передавать её в Службу технической поддержки вендора. При этом требовалось, чтобы не менее 80 % обращений клиентов мы решали самостоятельно, без участия корпорации Oracle.

Название «Центр технической поддержки» родилось случайно. Помню в 1996 году, когда ЦТП только организовывался, мне предлагали называться «Департаментом технической поддержки». Но «Центр» как-то звучнее. В тот момент уже работал Учебный центр РДТЕХ. Я подумал: «А чем техническая поддержка хуже? Тоже будем называться Центром».

– Важным проектом ЦТП стал перевод и выпуск документации по СУБД Oracle.

– Технический перевод это самое первое, чем я начал заниматься, когда пришёл в РДТЕХ на работу в 1995 году. Вся компания была на это нацелена, и я тоже включился в процесс. 7-я версия СУБД Oracle была первой версией СУБД Oracle, с которой я познакомился.

– Как за 30 лет изменилось техническое сопровождение в РДТЕХ?

– Создана база знаний, накоплены материалы, статьи, кейсы.

Когда ЦТП только начинал работу, было два господствующих тезиса:

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

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

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

Также опыт показал, что на техподдержке можно неплохо зарабатывать, и довольно длительный период, лет 10-15, техническое сопровождение кормило нашу компанию. Это было тем базисом, на котором бизнесу можно было развивать инновационные направления.

После ухода Oracle из России в 2022 году техподдержка приносит значительно меньше доходов.

– Как устроен процесс техподдержки?

– В целом, мы по-прежнему работаем по правилам технической поддержки Oracle. Чтобы какая-либо проблема была решена, нужно заинтересованное участие с обеих сторон – техподдержки и клиента. Включенность со стороны заказчика заключается в подробном описании проблемы, диагностике систем, выполнении рекомендаций специалиста РДТЕХ. Первоначально такое взаимодействие проходит без подключения к информационным ресурсам клиента, через систему регистрации инцидентов. Дистанционный способ решения проблемы является стандартным для технической поддержки Oracle, и мы продолжаем работать по этой схеме.

Сейчас внутри компании происходит постепенная трансформация направления. Наряду с ЦТП существует подразделение, которое предоставляет похожие услуги. Это Сервисный центр РДТЕХ (СЦ). Мы выстраиваем схему, при которой СЦ выступает в роли «фронт-офиса», администрирует базы данных заказчика, производит их первичный мониторинг. Сложные вопросы коллеги передают нам, и ЦТП выступает как «бэк-офис» – техподдержка второй и третьей линии для СЦ.

– Системы автоматизации меняют техподдержку, искусственный интеллект помогает?

– Применимость нейросетей в техническом сопровождении вызывает вопросы.

Казалось бы, ИИ после тренировки на базе имеющихся инцидентов в техподдержке после описания той или иной проблемы может предлагать оптимальный метод решения. Но есть ряд нюансов, которые пока не позволяют это реализовать.

Во-первых, есть проблема этического характера. Если специалист-человек решает проблему самостоятельно, то он несёт ответственность за результат. И в случае неудачного исхода может быть подвергнут штрафным санкциям со стороны заказчика. Может и должен ли эксперт отвечать за последствия при подключении инструментов ИИ? Особенно, когда нейросеть предлагает уже развёрнутое решение, не объясняя, каким образом оно получено. И тем более рекомендовать решение заказчику? Не уверен. Думаю, что ИИ сегодня пока может давать администратору лишь подсказки, в каком направлении двигаться. В данный момент мы создаем именно такую систему управления знаниями.

Во-вторых, у провайдеров технической поддержки недостаточно объемов данных для обучения ИИ. В РДТЕХ за время работы ЦТП накопилось порядка 30 тысяч инцидентов. Это немало, но для полноценного обучения ИИ недостаточно.

В-третьих, корпорация Oracle сама работает в направлении автоматизации техподдержки своих клиентов, и у неё гораздо больший массив таких данных по всему миру. Внедрять инструменты ИИ быстрее и удобнее, если клиент обслуживается в облаке Oracle. В этом случае вендор берет на себя функции и администрирования, и диагностики баз данных.

Угроза состоит в том, что специалисты техподдержки могут стать не востребованными, лишиться куска хлеба в будущем. Корпорация Oracle, когда-нибудь вернувшись в Россию, может быть не готова снова отдать этот сервис партнерам.

– Вы упомянули о десятках тысяч инцидентов, собранных экспертами техподдержки РДТЕХ. Передаете ли вы знания молодым специалистам?

– Три года назад мы взяли двух новых молодых сотрудников с нулевым опытом в области баз данных. Это своего рода наставничество – способ обучения персонала, который сегодня возрождается. Правда, из двух молодых сотрудников сейчас остался только один.

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