ТехПод от А до Я

🚀 Дайджест ТехПода за сентябрь · продолжение

💬 Что обсуждали на Reddit

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

AI ускоряет ответ. А кто проверяет решение?
28 сентября · r/sysadmin

В обсуждении «AI is killing my passion for computers» участники жалуются на коллег, которые пересылают пользователю ответ Copilot или ChatGPT без проверки. Другие делятся положительным опытом: AI ускоряет поиск информации и освобождает время для инженерной работы.

Для поддержки здесь важный вопрос: мы стали быстрее писать ответы или действительно быстрее решать проблемы?

👉 Обсуждение

Почему универсал получает меньше узкого специалиста?
22 сентября · r/sysadmin

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

История одного человека не задаёт зарплатный ориентир, но поднимает знакомый вопрос: как оценивается работа специалиста, который поддерживает понемногу всё?

👉 Обсуждение

Что нужно новичку в help desk
4 сентября · r/InformationTechnology

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

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

При найме первой линии стоит проверять и техническую базу, и умение разговаривать с человеком, у которого что-то сломалось.

👉 Обсуждение

🎤 ITIL и конференции: что смотреть дальше

• ITIL Tool Day, 30 сентября. В программе - Bank of England, JERA Nex bp и обслуживание банкоматов. Интересны процессы, согласования и взаимодействие команд. Записи пока не проверены - ориентируемся на программу.

• SREcon EMEA, 13–15 октября. На радаре будущий доклад MIT и Bloomberg о применении STPA: какие риски взаимодействия компонентов не видны в SLO. Для тех, кого заинтересовала тема CAST, стоит присмотреться. Программа.

• itSMF UK ITSM26, 9–10 ноября. Заявлены практики Barclays, Mastercard, Vodafone и BT. Подробнее.

• Pink Elephant - Pink27. Опубликована будущая программа: ITSM, организационные изменения, employee experience и Lean IT. Посмотреть.

#ТехПод #ДайджестТехПода #ITSM #IncidentManagement

RAG внедрили. А пользователь всё равно пишет «помогите».
⠀
Слежу за тем, как RAG используют в поддержке, с вполне прикладным интересом.
⠀
Особенно интересно, на каком этапе она включается в работу. Когда обращение уже пришло инженеру? Или ещё до того, как пользователь нажал «Отправить»?
⠀
Потому что до создания заявки тоже хватает работы.
⠀
Представьте. Каталог услуг собрали. Формы настроили. Базу знаний наполнили. А человек открывает портал, смотрит на всё это и идёт писать в чат:
⠀
«Не могу подключиться к виртуалке. Помогите».
⠀
Его можно понять. На виртуалке приложение, с которым нужно работать. Разбираться, какую услугу выбрать - виртуальную инфраструктуру, сетевую связность или управление доступом, - сейчас хочется меньше всего.
⠀
Дальше подключается первая линия. Какая ВМ? В каком проекте? По SSH не пускает или приложение не отвечает? Какая ошибка? Когда началось? Что меняли?
⠀
Потом собрать ответы в описание, классифицировать обращение и при необходимости передать профильной команде. Вопросы нужные. Но сбор исходных данных тоже занимает время. Особенно когда каждую деталь приходится вытягивать отдельным сообщением.
⠀
У SimpleOne вышла статья как раз про этот участок работы. В их ITSM системе появился ИИ-гид на портале: пользователь описывает задачу своими словами, а помощник ищет подходящую информацию и помогает оформить запрос.
⠀
Если примерить этот подход к ситуации с виртуалкой, сценарий мог бы выглядеть так.
⠀
Пользователь пишет, что не может подключиться к ВМ. Если есть подходящее объявление о работах - помощник показывает его. Есть известная ошибка с обходным решением - находит в KEDB. Есть инструкция по проверке подключения - подтягивает из базы знаний.
⠀
Если подходящего решения нет, помогает собрать данные для инцидента. Конкретный набор зависит от того, как настроен процесс.
⠀
Инженер получает обращение, в котором уже есть с чего начать диагностику.
⠀
Здесь можно посмотреть демонстрацию возможностей ИИ-гида.
⠀
Под капотом тот самый RAG. Поиск по корпоративным источникам, затем ответ на основе найденного. После настройки новые и изменённые записи синхронизируются автоматически.
⠀
И здесь знакомый нюанс: кто-то всё ещё должен поддерживать эти источники в порядке. Устаревшая инструкция сама актуальной не станет. Даже если теперь её пользователю показывает ИИ.
⠀
Такой сценарий интересен тем, что результат можно проверять на конкретной рутине. Сколько обращений получилось предотвратить. Сколько заявок пришло сразу с нужными данными. Сколько раз инженеру пришлось переделывать за помощником.
⠀
Вот это я бы и смотрел на пилоте.
⠀
В статье — подробнее про ИИ-гида SimpleOne, примеры работы и расчёт возможного эффекта.

🚀 Новая рубрика - «Дайджест ТехПода»

Смотрим, что интересного произошло в мире технической поддержки, ITSM и эксплуатации и что попало на наш радар.

В первом выпуске - итоги сентября: материалы IT-компаний, обсуждения на Reddit и конференции.

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

1. Google: к инциденту нужно готовиться до инцидента

15 сентября Google опубликовал руководство по работе с облачными сбоями: проверить → расследовать → сообщить → восстановить → разобрать.

Локальная проблема может не попасть на публичную страницу статуса - стоит проверять Personalized Service Health. Телеметрия, инструкции и контакты должны оставаться доступными, даже когда основной сервис уже лежит.

Отдельный акцент - учебные инциденты, передача смены и разбор без поиска виноватых.

👉 Руководство Google

2. AWS: агент расследует, знания инженеров становятся инструкциями

29 сентября AWS показал связку: Dynatrace обнаруживает проблему → ServiceNow создаёт инцидент → DevOps Agent исследует телеметрию → выводы и план восстановления возвращаются в заявку и Slack.

Это технический пример. Обещание сократить расследование «с часов до минут» - заявление AWS, которое нужно проверить на своих инцидентах.

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

👉 Интеграция систем · Как писать Skills

3. Microsoft: автономность агента нужно настраивать

В материале от 3 сентября Microsoft описал планы реагирования Azure SRE Agent на инциденты ServiceNow.

Можно задать условия отбора обращений, выбрать профильного агента и определить, какие действия требуют согласования. Фильтры проверяются на недавних инцидентах.

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

👉 Разбор Microsoft

4. HDI: почему улучшения поддержки быстро исчезают

28 сентября HDI опубликовал опыт команды, у которой улучшения service desk начали сходить на нет примерно через шесть недель.

Знакомые причины: встречи превращаются в чтение показателей, решения теряются, ответственных нет.

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

👉 Статья HDI

5. DigitalOcean: тайм-аут ещё не означает, что действие не выполнено

В разборе от 23 сентября - практические проблемы AI-агентов: повторные запросы, устаревшие данные, ошибки интеграций.

Агент не получил ответ и повторил действие. В результате - две заявки или два сообщения пользователю.

Полезный принцип: проверять фактический результат, ограничивать повторы и защищаться от дублирования. Описанный Action Gateway находится в public preview и не снимает с приложения ответственность за эти проверки.

👉 Разбор DigitalOcean

Продолжение - в следует.
#ТехПод #ДайджестТехПода #IncidentManagement

AI экономит время. Куда оно исчезает?

В SolarWinds 84% опрошенных говорят: отдача от AI оправдала или превзошла ожидания. А у 71% нагрузка команды не снизилась.

Это ответы на разные вопросы одного опроса. Но соседство показательное. Быстрее закрывать заявки ещё не значит меньше работать.

Кто-то должен проверять ответы, исправлять ошибки и поддерживать новые инструменты. Эта работа тоже занимает время.

Собрал по пять тезисов из Freshworks, SolarWinds, SysAid и Ivanti. В последней карточке - что меня удивило и какого ответа мне не хватает.

Исследования полезно читать, чтобы видеть, куда движется отрасль. Пользу для своей поддержки всё равно придётся проверять на собственных цифрах.

Подборка включает более ранние отчёты 2026 года. Выборки разные - напрямую проценты не сравниваем.

#ТехПод #Исследования #ITSM #AI #Автоматизация

К суткам часов не прибавить. А вторую пару рук я оформил по подписке.
⠀
В прошлом посте рассказывал, как ИИ помог за несколько минут решить сетевую проблему. И как я немного погрустил о семи годах, потраченных на hard skills.
⠀
Но инженерные задачи у меня сейчас бывают редко. А вот менеджерские - каждый день.
⠀
И тут подход простой: вместо замены седла у лошади - берём трактор. Не пытаюсь делать всю рутину быстрее - смотрю, что вообще можно не делать самому. Причём некоторые задачи я отдал ИИ с особым удовольствием.
⠀
1️⃣ Презентации
⠀
Делать презентации вообще не моё. С чувством прекрасного в слайдах не сложилось: вроде всё по делу, но смотреть грустно.
⠀
Раньше жутко прокрастинировал над ними. Даже читал книги про прокрастинацию, лишь бы не открывать презентацию. Боролся с проблемой как мог.
⠀
Сейчас даю ИИ корпоративный шаблон и описываю, что нужно. Или загружаю свою кривую-косую презу и прошу привести в порядок.
⠀
За 15 минут до встречи уже можно собрать то, что раньше откладывал несколько дней. Мысли всё ещё мои. Двигать прямоугольники теперь есть кому.
⠀
2️⃣ Аналитика поддержки
⠀
ИИ помогает собрать сводку за период: сколько пришло обращений, что изменилось в SLA, FCR и CSAT. Можно оценить работу всей поддержки или отдельно посмотреть на конкретного клиента.
⠀
Если замечаю что-то необычное, прошу копнуть глубже: какие продукты и группы повлияли на показатели, что было в самих обращениях. Так от «обращений стало больше» перехожу к конкретике: с чем приходят клиенты, где возникают сложности и какие проблемы повторяются.
⠀
3️⃣ Разбор ночных и выходных смен
⠀
Периодически нужно понять, что происходило, пока меня не было. Чем занимался инженер, в каких системах работал, как распределялась активность по часам.
⠀
Данные есть, но обычно лежат в разных местах. ИИ помогает собрать из них картину смены. Уже по ней проще понять, что стоит обсудить с командой.
⠀
5️⃣ Задачи в Jira
⠀
Описываю, что нужно сделать, кто отвечает, какой срок и в каком пространстве создать задачу. Сразу ставлю напоминание.
⠀
Мелочь, но из таких мелочей состоит заметная часть рабочего дня. Особенно когда между встречами вспомнил о задаче и хочешь сразу её поставить, пока снова не забыл.
⠀
5️⃣ Пространства и статьи в Confluence
⠀
В Confluence куча макросов, с которыми можно сделать красивую и удобную страницу. Их, конечно, можно освоить.
⠀
Можно, а зачем? Сегодня мне нужна готовая страница.
⠀
Поэтому описываю структуру и содержание, а с оформлением помогают Cursor или Codex. Минут за десять уже есть результат, который можно доработать и использовать.
⠀
6️⃣ Порядок в папках
⠀
Разобрать накопившиеся файлы, нормально назвать, разложить по папкам. Та самая задача, которую постоянно переносишь, потому что прямо сейчас есть что-то поважнее.
⠀
Наконец и до неё дошли руки. У ИИ.
⠀
7️⃣ Разбор инцидентов
⠀
Собрать хронологию из тикетов, переписки и заметок. Отдельно выписать подтверждённые факты, версии и вопросы, на которые пока нет ответа.
⠀
Но для работы в таком режиме должна быть настроена защита от утечек конфиденциальных данных. В обращениях, логах и внутренних документах хватает того, что нельзя отправлять во внешний сервис. Нужно заранее понимать, какие данные можно передавать, что нужно обезличить, а что должно оставаться внутри компании.
⠀
Сейчас на ИИ трачу примерно 150 долларов в месяц. Мои Чип, Дейл и третий на подстраховке - Cursor, ChatGPT (Astra) и Claude. Спешат на помощь, когда я слишком долго не спешил.
⠀
У Дэна Кеннеди есть фраза: «К суткам часов не добавить, как не добавить себе лишней руки…»
⠀
Часов в сутках действительно не прибавилось. А вот дополнительная пара рук, кажется, нашлась.
⠀
Пока писал, понял, что в один пост всё не уместить. В списке «аналитика» занимает пару абзацев, а внутри - десятки разных задач.
⠀
Поэтому дальше буду собирать подборки: где и как ИИ используют инженеры, а где - руководители. С конкретными примерами: что дали на вход, что получили и сколько потом пришлось доделывать.
⠀
#ТехПод #ТехПод_Management

Postmortem vs CAST

После инцидента обычно остаётся документ.
Что сломалось. Когда заметили. Как восстановили. Что сделаем, чтобы не повторилось.
Это postmortem - разбор, который помогает команде учиться на сбоях.
Но глубина такого разбора бывает разной. Можно восстановить хронологию и найти технический дефект. А можно разобраться, почему существующие проверки, правила и взаимодействие команд позволили этому дефекту дойти до пользователя.
Вот здесь интересен CAST.

Сначала важное уточнение
Postmortem и CAST - разные по назначению вещи.
▪️ Postmortem - практика разбора инцидента и фиксации выводов. Конкретный метод анализа может отличаться от команды к команде.
▪️ CAST - метод анализа на основе теории систем. Он помогает исследовать решения участников, доступную им информацию, ограничения и обратную связь.
Поэтому CAST можно использовать внутри postmortem. Хороший postmortem тоже может учитывать организационные причины - это не эксклюзив CAST.

Что показали в Google
На SREcon26 Americas Ruben Barroso разобрал инцидент Google Maps: после импорта данных US Census на картах появились неправильные названия городов.
Данные прошли проверку. Ошибки обнаружили пользователи.
Первоначальный разбор выявил ограничения инструмента проверки и отсутствие определённой стратегии выборки. Предложили усилить автоматические проверки и ревью.
CAST помог рассмотреть контекст решений:
▪️ Команда считала существующие правила проверки достаточными. Предыдущий опыт поддерживал это представление, хотя новый набор данных имел другие особенности.
▪️ Откат задержался из-за неясного масштаба проблемы и размытой ответственности между командами.
К техническим исправлениям добавились вопросы: как пересматривать правила при изменении данных, кто принимает решение об откате и какую информацию он для этого получает.

Что добавляет CAST
Он задаёт структуру для такого исследования. Нужно понять:
▪️ за что отвечал каждый участник и на что реально мог повлиять;
▪️ какую информацию получал;
▪️ как представлял себе состояние системы;
▪️ какие правила и условия влияли на его действия;
▪️ где потерялась обратная связь.

Подробное в руководстве Nancy Leveson.

Что я бы взял для следующего разбора
Один вопрос:

Почему это решение казалось человеку разумным в тот момент?

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

Доклад Google: видео и материалы

#ТехПод #incidentManagement #ProblemManagement #Postmortem #CAST

Мясной прокси. 7 лет опыта за 5 минут.

Семь лет. Столько я вкладывал в hard skills.

После ночных смен в каспере приходил домой. Немного спал. Дальше - лабораторные. Поднимал виртуальные машины, роутеры, изучал протоколы, дампил трафик, смотрел, как ходят пакеты, курил логи. Смотрел тонны курсов. Тратил много денег на подписки. Решал инциденты на инфраструктуре - чем больше, тем быстрее росли hard skills. Знал всех блогеров. Смотрел все конференции. Получал международные сертификаты. ccnp, например.

Годами. По крупицам. Через недосып и напряжение мозга.

И вот недавно.

Потребовалось настроить сетевую связность между VPS и домом. Туннель поднялся не сразу. Провести траблшутинг - не проблема: перепроверить конфигурацию, запустить tcpdump, настроить логирование. За пару часов по старинке проблему бы решил. Может, чуть раньше. Руки всё помнят, как происходят рукопожатия в TCP/TLS, тоже.

Но я решил пойти другим путём. Попросил ИИ помочь отладить проблему.

Конечно, он сразу запросил диагностику. Конфиг. Дамп. Логи.

Через 3-5 минут всё работало.

Внутри возникло интересное чувство. Чувствуешь себя мясным прокси между проблемой и ИИ. Семь лет обучения. Время. Деньги. Силы. Чтобы сейчас технические проблемы решать за несколько минут.

Немного обидно, если честно. Стоишь, смотришь на работающий туннель и думаешь: а я-то тут зачем? Раньше я был тем, кто чинит. Теперь я тот, кто пересылает логи.

Общаюсь с товарищами, руководителями, инженерами. Всё чаще приходим к одному выводу: ценность hard skills падает. С текущим развитием - падает быстро.

Достаточно базовой эрудиции и насмотренности. Представления, как должно работать.

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

К чему я всё это.

Учиться нужно быстрее. Осваивать всё как можно быстрее. Чтобы было какое-то value от вашей работы - желательно extra value. И то, что ИИ не закрывает пока. Всё то, что привязывает тебя к цели продукта и клиента. Ожидания по производительности у всех растут.

Раньше твоя производительность была около 1 л.с. Сейчас с агентами - может быть и все 10. Или 100.

Разница ощутимая. И она будет только расти.

Так что единственный способ не оказаться мясным прокси - стать тем, кто управляет прокси. Иначе через пару лет твой ccnp/rhce будет стоить столько же, сколько сейчас умение заваривать чай. Норм навык. Но не то, за что платят.

Если хочешь догнать быстрее - вот подборка хороших бесплатных курсов от облачных провайдеров, которую сделал мой инженер. Помогает расширить кругозор и двигаться быстрее:
https://habr.com/ru/companies/cloud_ru/articles/1076738/

Так как я уже давно не инженер, в следующем посте поговорим о прикладных инструментах, которые реально экономят часы в менеджменте. То, что я сам использую.

#TechSupport

😀😃🙃😇Встреча для саппортов!

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

📎 techsup meetup 📎

📍 Санкт-Петербург, Failover Bar, 2-я Советская улица, дом 18
🗓 10 сентября, четверг, с 19:00 (можно прийти попозже)

🖥 Билеты: sup2line.ru/techsup-meetup

✅ Будем: болтать, есть, слушать короткие доклады и хорошо проводить время.
❌ Не будем: хвастаться успешным успехом, душнить про ML и скучать.

Ждём: специалистов клиентского сервиса и CSM | инженеров технической поддержки L1/L2/L3 | тимлидов и руководителей поддержки | тех, кто только хочет попасть в саппорт | и вообще всех, кому нужна поддержка

Коллегам репостните, вдруг они там грустят!

Иш чиво зодумали

Товарищи из Второй Линии и TechSupportConf оффлайн митап делают.
Подробности ниже.
Сентябрь. Питер. Приходите.

8️⃣
Как стать крутым в ТехПоде?

Советует Влад, Руководитель 2-ой линии технической поддержки по продукту VK Cloud

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

ТехПод от А до Я
#Сто_Советов_ТехПод

Cаммари ключевых идей из отчета «2026 IT Priorities Report» Freshworks

▪️От знаний к движкам решений: сотрудники не должны искать ответы - ИИ сам определяет проблему по контексту (скриншот, лог) и запускает исправление без участия человека.
▪️От ассистивного ИИ к агентным рабочим процессам: ИИ не просто помогает, а самостоятельно оркестрирует задачи между IT, HR, финансами и другими отделами, используя общие данные и чёткие ограничители.
▪️От SLA к XLA (соглашения об уровне опыта): скорость закрытия тикета больше не главное. Важно, как сотрудник чувствует процесс - объединяются операционные (переназначения, задержки) и метрики удовлетворённости.
▪️От реактивного мониторинга к проактивной устойчивости сервисов: ИИ объединяет алерты, отделяет шум от реальных проблем и помогает предотвращать сбои до того, как они повлияют на сотрудников. Объединение IT Service Management и IT Operations Management.
▪️От изолированных функций к единой архитектуре управления предприятием - сквозные сценарии для сотрудника (онбординг, смена роли, увольнение) без ручных передач между отделами.

ИТ-2026: опыт вместо скорости, проактивность вместо реакции, единое управление вместо разрозненных функций, агентный ИИ вместо ассистивного, автономное разрешение вместо баз знаний

ТехПод от А до Я
#исследования

ServiceNow Knowledge 2026

Я задрот в сфере технической поддержки. У каждого свои увлечения: кто-то ждет презентацию Apple, кто-то - финал чемпионата, кто-то - новую модель автомобиля. Я ждал ServiceNow Knowledge 2026. Чтобы знать, в какую сторону движется индустрия.

Конференция прошла в Лас-Вегасе с 5 по 7 мая. Это ежегодное событие для пользователей и партнеров платформы. В этот раз акцент сместили с демонстрации возможностей на вопросы внедрения, контроля и безопасности. Если коротко: начинается эра Agentic Business.

Представили Action Fabric - механизм, который позволяет любому ИИ-агенту выполнять действия внутри ServiceNow. Не просто читать данные, а запускать процессы: сброс пароля, онбординг, создание заявки. Подключение идет через открытый протокол MCP, поэтому неважно, на чем построен агент - на Claude, Copilot или кастомном решении. При этом все действия проходят через стандартные процедуры согласования и аудита.

Но если агенты получают право действовать, возникает вопрос контроля. Что, если агент ошибется или его скомпрометируют? На конференции показали демонстрацию: агент под управлением вредоносного промпта начал менять цены и скрывать логи. AI Control Tower - новый модуль платформы - обнаружил аномалию, отозвал доступ и остановил процесс.
(Вот это очень интересная концепция.)

Для полноты картины в платформу интегрировали данные от Armis (инвентаризация устройств и инфраструктуры) и Veza (управление правами доступа). В связке с графом знаний ServiceNow это дает возможность в реальном времени отслеживать три параметра: что подключено к сети, у кого есть доступ и какие действия выполняются. Без задержек и ручных сверок.

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

В рамках партнерства с NVIDIA анонсировали Project Arc - агента для автоматизации задач на рабочем столе. Он работает в изолированной среде, каждый шаг логируется, доступ к файлам и API контролируется. Это про делегирование рутинных многошаговых операций с сохранением корпоративных стандартов безопасности.

То, что показали в Лас-Вегасе, - не революция, но анонсы заслуживают внимания.

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

ТехПод от А до Я
#News

Пора

Пора осознать, признать и зарубить себе на носу: ИИ-агенты изменят техническую поддержку

Сразу пример из жизни.
Понадобилось посмотреть статистику по задачам в Jira. С JQL (Jira Query Language) я не силён. Чтобы освоить его на уровне сложных запросов, нужно несколько дней.

Задачу я решил за десять минут. Подключил агенту нужный скилл - пять минут. И ещё через пять минут у меня в командной строке был полный анализ: сколько задач в проекте, какие статусы, самая быстрая задача, самая долгая, среднее время решения. И ещё с десяток параметров.

Короткое отступление
Прочитал книгу бывшего CEO Intel Эндрю Гроува «Выживают только параноики». И он вводит два понятия: Стратегический переломный момент и десятикратная сила.

Стратегический переломный момент - это период в жизни компании, когда происходит кардинальное изменение её фундаментальных принципов, структуры и способов ведения бизнеса.
Для Intel это был выбор в пользу процессоров, а не оперативной памяти. Почему? На рынке RAM они проигрывали японцам по всем параметрам. Перепрофилировать восемь заводов под CPU, когда всю жизнь делали другое, - это смело.

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

К чему я веду.

Техническую поддержку на повороте ждет стратегический переломный момент. Потому что ИИ-агенты - это как раз такая десятикратная сила. Они будут менять всё. Рынок труда. Привычные процессы. Скорость работы.

Именно поэтому для себя сделал это направление фокусным. Если проморгать момент - отстанешь. И догонять будет больно.

Моя главная задача на ближайший год - создать агентный слой вокруг своей работы.

На чём фокусироваться?
Критически важный навык - контекст-инжиниринг. Чтобы понимать, что видит модель и какими инструментами управляет. Это превращает чёрный ящик в понятный интерфейс с предсказуемым действием.

Вторая вещь - базовая IT-грамотность и понимание принципов кода. Не нужно быть программистом. Но знать терминал и Git необходимо. Это позволяет создавать надёжные автоматизации и не зависеть от разработчиков по каждому чиху.

Фундамент всей системы - умение писать точные промты. Без этого ничего не взлетит.

И важно задавать себе вопрос: зачем мне эта система? Какую задачу она решает? Иначе получится «молоток, которому всё гвозди».

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

ps. Хочу отдать агентам на откуп одну задачу. Для того чтобы оставаться в курсе индустрии, я читаю и мониторю примерно 20 источников, в основном зарубежных. Так вот: пусть каждый день они приносят мне краткую сводку того, что произошло за последние сутки. А если новости хорошие, я обязательно поделюсь ими с вами

#TechSupAI

Техническая поддержка в ТОПе 8/10!

https://joshkale.github.io/jobs/
https://karpathy.ai/jobs/

Андрей Карпаты выложил проект - karpathy/jobs.

Он взял данные по 342 профессиям из статистики BLS (≈143 млн работников в США) и с помощью LLM оценил, насколько каждая из них подвержена влиянию AI по шкале 0–10.

Результат он визуализировал в виде treemap.
Средний показатель по всем профессиям: 5.3 / 10.

Примеры:
▪️разработчики ПО: 8–9
▪️кровельщики: 0–1
▪️специалисты по расшифровке медицинских записей: 10 / 10 💀💀

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

По оценке Карпати, около 57 млн работников в США - почти 40% всей рабочей силы - находятся в зоне высокого риска изменений из-за AI.

Размер блока показывает число занятых, а цвет - насколько работа уязвима для ИИ по шкале от 0 до 10.
Чем больше цифровой работы, тем выше риск автоматизации.

Это приблизительные оценки, а не точные прогнозы. Высокий балл не означает, что профессия исчезнет. Техническая поддержка получает 8/10 баллов, потому что ИИ трансформирует их работу.

А как трансформирует? В этом и будем разбираться.

#AI