апрель    2026

Пн	Вт	Ср	Чт	Пт	Сб	Вс
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

показать все 

01.04.2026

Группа «Борлас» вошла в топ-10 крупнейших интеграторов и поставщиков услуг поддержки решений 1С по версии TAdviser

Читать далее 

30.03.2026

Менее 10% компаний в РФ фиксируют экономический эффект от внедрения ИИ

Читать далее 

30.03.2026

Эксперт Т1: „Внедрять ИИ-агентов надо уже сегодня, даже если эффект пока небольшой

Читать далее 

25.03.2026

Компания РДТЕХ сообщила о назначении Глеба Желтова заместителем генерального директора компании

Читать далее 

23.03.2026

Контур.Налоговый мониторинг и платформа «Боцман» интегрированы для локального развертывания

Читать далее 

показать все 

23.03.2026

Эволюция бизнес-процессов от ИИ-инструментов к мультиагентным командам

Читать далее 

23.03.2026

Время внедрения: ИИ в вашем бизнесе – эксперимент или реальная прибыль?

Читать далее 

18.03.2026

Ах, если бы сбылась моя мечта!

Читать далее 

06.03.2026

Как компьютеры понимают текст?

Читать далее 

06.03.2026

Как компьютеры понимают текст?

Читать далее 

29.07.2025

Точность до метра и сантиметра: как применяют технологии позиционирования

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

22.09.2023

Эпоха российской ориентации на Запад в сфере программного обеспечения завершилась

Читать далее 

22.09.2023

Сладкая жизнь

Читать далее 

22.09.2023

12 бизнес-концепций, которыми должны овладеть ИТ-руководители

Читать далее 

показать все 

Главная / Интервью / Сергей Мисюра: «В техподдержке – 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 лет они превращаются в полноценных экспертов. Таких выросших в ЦТП действующих сотрудников – почти половина.

В начало⇑