Техническая поддержка

Привет, я Максим Королев из Петрович-ТЕХа. В предыдущей статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM. Один из ключевых - «Дежурный»: с ним администраторы фиксируют аварии, регламентные работы и прочее, создают задачи в Jira, публикуют уведомления в каналы и в интранет компании.

И тут Telegram ограничивают. Когда у дежурного в разгар аварии «не грузится телега» - это риск для бизнеса. Нужно было срочно решать проблему.

Единственной стабильной альтернативой оказался - да-да - MAX. У него есть Bot API, он не попадает под ограничения РКН и уверенно работает на территории РФ.

Задача не «сделать второго бота с нуля», а сохранить одного логического Дежурного и дать ему второй вход из MAX. В статье расскажу, как я изменил архитектуру: вынес всю бизнес-логику в отдельный слой CORE, а Telegram и MAX сделал вызовами команд этого ядра.

Меня зовут Дима Синявский, я SRE‑инженер в Ви.Tech. Я решил написать о работе с инцидентами, ведь мы часто говорим, что «тушим пожары». Так вот мне стало интересно, можно ли что‑то полезного взять у реальных пожарных и чрезвычайных служб к нам в IT.

И знаете, многое похоже, но кое‑что прям явно хочется забрать.

Привет, Хабр! Меня зовут Андрей Шафоростов, и я тот самый зумер-айтишник на заводе. Конечно, айтишник — понятие многогранное. Тут трудятся и разработчики, и сисадмины, и тестировщики, а конкретно моя должность связана с сопровождением проектов: компания выпускает решение, а я и мои коллеги поддерживаем его дальнейшую жизнь. 

С 2024 года я ведущий специалист в отделе сопровождения систем управления производством НТМК в компании «ЕвразТехника ИС». В этой статье расскажу о том, как прошёл мой первый год в промышленной разработке, чем я занимался, чему учился. А ещё, когда работаешь на заводе для конечных пользователей, то есть своих коллег, начинаешь повсюду видеть места, где можно прикрутить какое-нибудь решение и улучшить жизнь всем. Так я взял на себя проекты и по своей личной инициативе. Про них тоже расскажу. В общем, если интересно, как выглядят будни разработчика в промышленности, заглядывайте под кат!

Привет, меня зовут Дмитрий Крупенин. Последние 7 лет я занимаюсь созданием и развитием внутренних продуктов для крупных компаний. Я отвечал за распределение обращений в клиентском сервисе для одного биг.теха РФ, а сейчас помогаю строить распределение задач контента в рамках другого. Захотелось освежить все знания по этой теме, а заодно структурировать это в статью, которую вы сейчас и читаете.

В чем собственно вызов в этой области: современные алгоритмы назначения обращений операторам представляют собой критически важную технологическую основу для крупных компаний, обрабатывающих миллионы клиентских запросов ежемесячно. В условиях растущих ожиданий клиентов и необходимости обеспечения высокого качества обслуживания (при оптимальных для бизнеса операционных затратах) эффективность распределения обращений на подходящих исполнителей становится одним из ключевых факторов конкурентоспособности. Исследования (раз, два, три) показывают, что передовые AI-powered алгоритмы способны снижать время ожидания клиентов на 40-60%, повышать показатели решения с первого обращения до 85%, и одновременно оптимизировать загрузку операторов, предотвращая их выгорание. Давайте разберемся так ли это и как достичь таких результатов.

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

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

Привет! Меня зовут Виктор Пантелеев, я менеджер технических проектов в Яндексе. Компьютер — основной инструмент большинства наших сотрудников. А для того, чтобы этот инструмент работал как надо, его следует настроить — быстро для конечного пользователя, в соответствии с его рабочими нуждами и требованиями безопасности.

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

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

Так как это «антигайд», советы ниже воспринимайте с точностью до «наоборот»!

Привет, я Максим Королев из Петрович-ТЕХ, занимаюсь уровнем сервиса. Моя роль — в том числе про “как хороший сервис показать пользователю, чтобы тот не отказался от нового/сложного/страшного инструмента”.

Было так: не все пользователи ходили в техническую поддержку по “правильному” маршруту, через портал. Из-за этого мы теряли случаи, составляющие общую картину проблем, и озадачились: как упростить пользователям заход в поддержку?

Решили сделать семейство Telegram-ботов, которые сократили время на создание повторяющихся задач на 50–70%, подняли заполняемость до 100%, ускорили реакцию на инциденты.

Если в новом году хотите запилить много микроавтоматизаций через боты, наш кейс к вашему столу: вот как вышло у Петрович-ТЕХа.

В ходе обучения и прохождения практики в вузе МГУТУ им Разумовского, мы выявили проблему: студенты тратят почти до 40 часов на поиск существующих исследований перед запуском новых проектов. Анализ показал, что многие работы дублируют уже выполненные исследования по AR/VR - технологиям

Началом для разработки нашего проекта V-Avatar послужил анализ научного задела факультета цифровых технологий. Мы интегрировали методы и алгоритмы, которые были уже созданы до нас, вместо того, чтобы начинать с нуля. Эти методы были описаны в данных ВКР:

1)Теоретический фундамент (ВКР за 2025 года): «Применение AR/VR-технологий в обучении сотрудников». Из этого метода был взят концепт моделирования, который стал основой для архитектуры V-Avatar. Мы воспользовались данной моделью для взаимодействия аватаров внутри образовательной среды.

2) Технологическая реализация (ВКР за 2024 год): «Разработка виртуального интерактивного музея на основе WebVR». Из данной работы были позаимствованы методы создания интерактивного 3D-контента. Также подходы к симуляции действий были адаптированы для функционала наших аватаров.

Самый важный алгоритм моделирования из ВКР 2025 года интегрирован в программный модуль src/legacy_methods.py. Это позволило создать не только визуальное решение, но и ссылаться на обоснованные методы оценки вовлеченности пользователей именно в VR-обучение.
Для создания MVP проекта V-Avatar мы выбрали гибкий технологический стек, который позволит быстро масштабировать решение и привлечь open-source контрибьюторов.

Продолжаем публиковать некоторые детали проектов по миграции больших баз данных 1С с MS SQL Server на PostgreSQL. В прошлый раз речь шла о миграции только одной 10+ Тб базы данных 1С с MS SQL на PostgreSQL. Сегодня речь пойдет о проекте миграции на PostgreSQL сразу сорока с лишним распределенных информационных систем 1C с базами размером от 50 Гб до 2 Тб каждая.

Год назад я обрабатывал тикеты по инструкциям. Сегодня анализирую логи, пишу SQL-запросы и разбираю баги с разработчиками. Как же я дошёл до жизни такой?..

Привет, Хабр! Меня зовут Азиз (по паспорту Жавлонбек, но с детства все зовут Азиз — спасибо старшему брату за второе имя, которое прижилось). Я младший специалист поддержки внутренних сервисов в Ozon. Начинал на L1, через год перешёл на L2.

Это история о том, как реально меняется работа при переходе с первой линии поддержки на вторую. Честный разбор, что изменилось, какие навыки понадобились и почему поддержка стала для меня фундаментом для роста в IT.

Привет! С вами Максим Бурцев, руководитель отдела мониторинга в Купере. Пусть название отдела не вводит вас в заблуждение: мы занимаемся не только мониторингом, но и остальными процессами, которые связаны с инцидентами. До, во время и даже после того, как проблемы решены. Сегодня хочу поделиться опытом внедрения нетривиальных инструментов и методов, которые сделали наши процессы удобными, понятными и эффективными.

Недавно пришлось вспоминать, как считать необходимый размер ЗИП-склада. Казалось бы – чего там считать? А результат оказался не совсем интуитивным.

Ежегодно 350 тысяч сотрудников Росатома создают примерно 1 200 000 обращений в поддержку. Значительная часть приходилось на систему для ведения бухгалтерского, налогового, регламентированного учета «1С: ERP 2.0 Цифровой Росатом». После внедрения ИИ-продукта «Атом.Зая» это количество сократилось на 24%. В этом тексте хочу рассказать, как мы двигались, чего удалось добиться, и какие уроки извлекли.

Привет, Хабр! Меня зовут Илья Парамошин, я ведущий инженер в МТС Web Services. В первой части мой коллега Владимир Дробот рассказал, зачем нам понадобился ИИ‑помощник для техподдержки и почему мы выбрали архитектуру на RAG. В этой статье я раскрою техническую сторону и разберу, как мы собирали данные, выбирали эмбеддинги, настраивали поиск и какие подводные камни встретили на пути. Спойлер: без костылей не обошлось, но система работает в проде и ежедневно помогает нашим инженерам.

В Yandex Cloud наблюдается сетевая недоступность многих узлов в одной из зон.

Проблемы начались в 19:00 по Москве, по информации поддержки восстановление ожидается около 03:00.

Привет всем, кто заглянул на Хабр в поисках чего-нибудь интересного под кофе!

Устраивайтесь поудобнее, поговорим про ту самую работу, где в тикете пишут просто «Не работает принтер», логов — ноль, деталей — ноль, а магазин уже горит и всем «очень срочно». И при этом ты сидишь в подсобке, смотришь в принт-сервер, веб-морду и RDP, и стараешься чинить всё, не вставая со стула.

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

Никакой занудной теории: только живой кейс из практики, рабочие шаги диагностики, немного самоиронии и мысли о том, как сделать так, чтобы уставал не ты, а только spooler.

Привет всем, кто заглянул на Хабр почитать что-нибудь интересное!

Устраивайтесь поудобнее, сейчас расскажу про работу, где принтеры постоянно зажевывают бумагу, сканеры отказываются сканировать, а пользователи твердят, что они ни при чем.

Я собрал свой набор выживания для тех, кто работает на первой линии поддержки. Расскажу, какие встроенные инструменты Windows реально выручают, когда один простой батник может спасти ситуацию, и зачем нужны свои чек-листы, чтобы не сойти с ума от общения с техникой.

Никакой скучной теории, только реальные советы, маленькие хитрости и немного самоиронии от сотрудника техподдержки.

Привет, Хабр! Я Дима, руковожу отделом информационных технологий бэк‑офиса в «Петрович‑Тех». Давно не делился историями, решил рассказать о нашем проекте по работе с восьмилетним HTML‑легаси, то есть порталом технической поддержки.

Обновление целой легаси‑системы, которая обслуживает тысячи сотрудников — та еще задачка. С одной стороны есть устаревший код и сервисы, с другой — непрерывная работа, которую нельзя тормозить: пострадают бизнес‑процессы. В этом кейсе расскажу, как мы обновили портал техподдержки, использовали ресурсы образовательных проектов для принесения реальной пользы, отбросили две ключевые, но ошибочные фичи, и поняли, что интеграция с AD стала главным приоритетом.

Привет, Хабр. Меня зовут Мария Рылик, я — старший контент-менеджер группы управления пользовательским опытом веб-поддержки «Лаборатории Касперского». И полтора года назад я столкнулась с распространенной в техписовских кругах проблемой: децентрализованной базой знаний. Чтобы найти инфу по работе с конкретным продуктом, приходилось по крупицам искать ее в разных статьях, в большинстве своем имеющих мало общего с конкретной задачей, которую я пыталась решить.

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

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