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

Привет, Хабр! На связи команда Рег.облака. Мы давно следим за развитием Retrieval-Augmented Generation (RAG) и хотели проверить, как эта технология работает в живых сценариях. У нас есть ИИ-ассистент — это образ виртуальной машины с предустановленными Ollama, Open WebUI и набором моделей. Его можно развернуть в пару кликов и сразу работать с LLM в приватном окружении. Но мы решили пойти дальше и проверить, как он справится в прикладной задаче: собрать чат-бота для нашей техподдержки.

Если клиент жалуется в соцсетях, от бренда вы с 99% вероятностью увидите один сценарий — извинение и предложение решить проблему в личке. Но что делать, если жалоба откровенно хамская? Разбираем результаты недавнего исследования.

Перед прочтение приглашаю в свой канал про рост продуктов.

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

Сегодня хочу затронуть тему регламентного обслуживания баз данных MS SQL. А позже поговорим и про обслуживание баз PostgreSQL.

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

Недавно своем Telegram-канале, где я регулярно разбираю кейсы из судебной практики по IP, задал вопрос: зачем в фильмах, сериалах или рекламных видеороликах замазывают логотипы на машинах, одежде и прочем реквизите?

Ответы разделились интересно:

• 33% уверены, что дело в риске нарушения прав на товарный знак;

• 25% полагают, что речь может идти о праве на изображение (т. е. объект авторского права);

• 33% решили, что это, скорее, «традиция жанра».

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

Эту заметку я разделю на две части. В первой (то есть в этой) мы поговорим исключительно о товарных знаках (ТЗ), а во второй - про объекты авторского права (к примеру, просто картинки).

Привет! Меня зовут Олег Безушко, и наша команда отвечает за эксплуатацию видеоконференцсвязи (ВКС) в Яндексе. Мои коллеги уже писали, как мы управляем переговорками с помощью инструмента Room Passport, а сегодня я расскажу, что происходит «на земле»: чем живут инженеры ВКС и как справляются с огромным объёмом задач силами очень компактной команды.

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

Привет! Меня зовут Роман Ляшенко, и я лид команды RPA в Эксплуатации ИТ ПАО «Ростелеком».

От автоматизации к гиперавтоматизации

Абсолютно любой бизнес рано или поздно испытывает потребность в улучшении корпоративных процессов и повышении операционной эффективности. Оптимизация: как усовершенствовать качество и скорость работы, не привлекая дополнительных ресурсов? Этот вопрос постоянно волнует как крупные корпорации, так и представителей средних и малых структур. Способов его решения огромное количество. Выбирая среди множества, «Ростелеком» пошел путем развития RPA-процессов.

RPA (Robotic Process Automation) – те самые технологии, которые используют программных роботов, позволяющих автоматизировать повторяющиеся/ рутинные задачи в бизнесе. Это направление стремительно развивается из некогда «местечковых» решений до комплексных стратегий гиперавтоматизации. 

Впервые ЭВМ были использованы в бизнес-процессах в пятидесятые годы (UNIVAC, IBM 702). В те времена компьютеры выполняли простые задачи в бухгалтерии, складском учёте, статистике.  Сегодня же речь идет о сквозном подходе, который направлен на создание взаимосвязанной экосистемы автоматизированных процессов, включая внедрение ИИ-инструментов.

Больше, чем стандартные решения

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

Меня зовут Курбатов Даниил, я тимлид поддержки кредитного конвейера в Банке Уралсиб. Наша команда занимается широким спектром задач — от DevOps и SRE до обработки обращений Service Desk. Когда я стал руководителем, передо мной встала амбициозная задача: за три месяца нанять восемь новых сотрудников и максимально быстро ввести их в курс дела.

Очень странный заголовок, знаю. Прежде чем угорать и осуждать - разложу всё по полочкам. Модератор, не будь бессердечным, пожалей.

Пост сделан подобно https://habr.com/ru/articles/651509/ Хабр, спасибо тебе за идею, это гениально!

Уже проводя много времени на сайтах знакомств, я составил анализ девушек:

Я работаю Delivery Manager в компании, которая разрабатывает сервис для рассылки уведомлений клиентам. Наш продукт помогает салонам красоты, фотостудиям, фитнес-клубам и другим сервисным компаниям автоматизировать коммуникацию с клиентами.

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

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

Иногда запрос на слияние (merge request) даже не стоит отправлять на код‑ревью, так как при его составлении кто‑то злоупотреблял искусственным интеллектом, и это повредило как проекту, так и команде. Например:

1. Удалив часть кода, можно значительно улучшить запрос на слияние.
2. Вы не знаете основ языка, на котором подавали запрос.
3. Спам в документации.
4. Вопиющая несогласованность материала.
5. Чрезмерно подробно рассмотрены пограничные случаи.
6. Вы добавили бессмысленные или нежелательные зависимости и сами не понимаете, зачем.

Если я прислал вам обратно ваш запрос на слияние с невычищенным ИИ и без всяких прочих комментариев — значит, какие‑то из этих пунктов вы выполнили.

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

Скажу сразу — написать данный пост меня вынудила моя полная, тотальная, абсолютная беспомощность в попытке достучаться до техподдержки сервиса Авито и КАК‑ТО убедить их, что работа сервисмена в суппорте не ограничивается выбором шаблона, а закрывать тикет надо его РЕШЕНИЕМ, а не коронной фразой «Мне очень жаль, я понимаю, что ответ вас не устраивает».

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

Хочу вернуться к старой проблеме с хранением журнала регистрации 1С в формате SQLite. История стара как мир, но мы нет-нет, а продолжаем с ней сталкиваться, поскольку очень часто большие информационные системы работают далеко не на самых свежих версиях платформы 1С, а администраторы системы не уследили за форматом хранения журнала регистрации (ЖР).

Наглядно посмотрим к чему может приводить ЖР в формате SQLite в многопользовательской нагруженной системе, а также выясним как администраторам и разработчикам понять, что проблема просадки производительности связана с чтением ЖР.

В этом уроке расскажу как можно использовать n8n (платформу для автоматизации рабочих процессов) в связке с api2app. Создам виджет чата с ИИ для встраивания на сайт. У n8n есть свой виджет для встраивания, но возможностей кастомизации маловато.

Всем привет! Решил я тут собрать в кучу все свои знания по онбордингу новых сотрудников поддержки. За свою карьеру я построил несколько отделов саппорта с нуля и, признаться, порядком устал от бездушных корпоративных регламентов, от которых клонит в сон уже на третьей странице. Писать очередной талмуд «делай хорошо — не делай плохо», который никто не дочитает, — гиблое дело, особенно для молодого поколения, выросшего в эпоху TikTok.

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

Когда-то в нашем институте один из телефонов, по несчастью находившихся в комнате, где я сидел, отличался всего на одну цифру от телефона местного жэка. Хуже того, кто-то, видимо, бестолковый сотрудник того же жэка, нанося этот телефон на двери подъездов вверенного ему дома, сделал ошибку в одной цифре. Угадайте, в какой. В общем, нам звонили. По самым разным вопросам. Сначала мы не понимали и ругались. Потом выяснили правильный телефон и стали его давать страждущим. Даже хотели отрядить добровольца, который бы прошелся по подъездам и исправил ошибку. А потом я стал находить даже некоторое странное удовольствие, общаясь с недовольными людьми по телефону.

Всем привет! Меня зовут Максим Бурцев, и я руководитель отдела мониторинга в Купере. Мы отвечаем за управление инцидентами и проблемами: следим за стабильностью продакшена, сопровождаем и разбираем все технологические инциденты, развиваем и контролируем процессы. В этой статье я поделюсь практикой, которая помогает нам выжимать из Postmortem максимальные результаты и масштабировать Action Items.

Дух захватывает от возможностей, которые появляются сейчас для саппорта. Это нам приходилось сначала мучить архитекторов и разработчиков, самим осваивать предметные области, в которых работали поддерживаемые продукты и системы. Сейчас любой мало-мальский сервис имеет базу знаний, продвинутую систему подсказок, а мы всё это собирали сами — в том числе делали руководства пользователя.

Часто доводится слышать, будто протокол HTTP прост. Естественно, чаще всего — от тех, кто не слишком поднаторел в обращении с ним и слабо представляет, как именно этот протокол реализован. Думаю, сам я тоже мыслил в таком ключе, когда ещё только начинал работать с HTTP.

К настоящему времени я уже без малого три десятка лет усердно пишу клиентский код, взаимодействующий с HTTP. Я участвую в работе IETF и приложил руку ко всем спецификациям HTTP, составленным примерно с 2008 года. Поэтому полагаю, что вполне имею право развёрнуто высказаться об этом протоколе. Протокол HTTP не прост. Далеко не прост. Даже если предположить, что те, кто отмечает его простоту, имеют в виду лишь HTTP/1.

Около 10 лет назад мы получали «двойки» за ИТ‑сервисы, но не понимали, почему так происходит. Сначала мы просто смотрели и не понимали, а что вообще делать. Потом стали искать виноватых. Потом начали ставить цели сотрудникам. А потом поняли, что дело не в ошибках, а в самой системе и подходе к оценке.

Меня зовут Алина, я в СИБУРе отвечаю за техподдержку. Делюсь с вами историей, как мы собственно ее чинили. Внутри — реальные заявки пользователей, наши мысли на этот счет и то, как это исправляли.

Эта история о нас. И, если честно, про то, как мы все научились быть чуть человечнее.