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

😀😃🙃😇Встреча для саппортов! Мы ежедневно общаемся с сотнями пользователей, и почти никогда — друг с другом. Мы знаем, как успокоить разгневанных людей и пережить релиз, но когда хочется встретиться с людьми, которые тоже понимают, почему «ни чего не работает» — это проклятие, оказывается, что идти некуда. Вот решаем вопрос. 📎 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

Погода на завтра. Какая точность вангования у исследований? Есть такая компания Gartner. Люди в пиджаках, которые считаются главными предсказателями будущего, IT в том числе. Их графики - это вообще Библия для тех, кто решает, во что вкладывать миллионы. Но есть нюанс. Большой и жирный. Сейчас поговорим о нем. Я люблю цифры. И кажется, если исследование - значит, там всё по полочкам, железобетонно. Особенно если это Gartner. А тут исследования на исследования Gartner за 24 года. И знаете, что получилось? Из всех их громких прогнозов сбылось только 57,9%. Это небольшой перевес в пользу орла или решки. Каждая третья технология, которую они хоронили или, наоборот, возносили до небес, так и осталась красивой картинкой. Не долетела. Где именно споткнулись пророки? Смотрите, в чем штука. Самое интересное происходит, когда вокруг технологии начинается слишком много шума. Чем громче хайп, тем хуже работает хрустальный шар у экспертов. ▪️Они слишком долго не замечали Open Source и NoSQL. Думали, ерунда. ▪️Автономный транспорт - ну, мы все еще ждем, когда робот сам отвезет нас куда-нибудь. ▪️Сейчас мы должны жить в шлемах виртуальной реальности. И знаете, что произошло с самим «пророком» Gartner? Начиная с 2021 года они тоже подкрутили настройки. Теперь они дают ровно 25 технологий в отчете. Срок жизни «тренда» теперь - полтора года. Да и прогнозы стали более размытыми. Какой из этого вывод? Тренды и исследования на этом канале будут. Обязательно. Это интересно, это пища для ума. Но теперь, когда вы увидите очередной красивый слайд с прогнозом до 2028 года, просто вспомните про эти 57,9%. #исследования

Ловите подборку вакансий для инженеров в ТехПод: Cloud.ru ищет по всей вертикали: Инженер техподдержки L2 удалённо или гибрид, 2/2 Откликнуться Дежурный сетевой инженер (L2) удалённо или гибрид, 2/2 Откликнуться Инженер L3 удалённо или гибрид Откликнуться Системный инженер L4 удалённо или гибрид Откликнуться ГисТех Специалист технической поддержки / Дежурный инженер 127 000 ₽ Москва, офис, 3/3 Откликнуться VK Cloud Инженер технической поддержки L2 удалённо, 2/2 Откликнуться MWS Системный администратор Москва, офис, 5/2 Откликнуться Хотите найти себе крутого инженера в ТехПод? Присылайте вакансию. #ТехПод_вакансии

7️⃣ Как стать крутым в ТехПоде? Делится Сергей Князев, руководитель ситуационного центра в компании Гистех и просто Заботливый человек: Для приготовления блюда «Как стать крутым в техподдержке?» я бы использовал следующие ингредиенты: 1. Любознательность 2. Систематизацию 3. Дисциплину 4. Эмпатию 5. Смелость Любознательность стоит на первом месте, поскольку это ключевой навык любого начинающего специалиста («самурая») техподдержки. Если ты выполняешь работу исключительно по инструкции и не задаёшь себе вопросов «Как именно это устроено?», то, увы, выше сотрудника первой линии поддержки тебе не подняться. Именно твоя любознательность станет главным инструментом повышения квалификации и успешного решения более сложных задач. Любознательность позволяет собрать огромное количество информации, однако важно уметь правильно её организовать и хранить. Тут нам помогает второй ингредиент — систематизация. Как верно заметил Евгений Кусайло из Kaspersky: обязательно веди собственную базу знаний. Причём не ограничивайся короткими однострочными заметками или командами, а стремись максимально подробно фиксировать всю полезную информацию, сопровождая её рисунками и схемами. Без подробного описания спустя месяц или даже неделю ты рискуешь забыть зачем использовалась та или иная команда или запись. И, разумеется, ни одна база знаний невозможна без третьего важного компонента — дисциплины, которая является одним из ключевых факторов успеха практически в любом деле. Однако работа в техподдержке — это не только техническая сторона. Это ещё и взаимодействие с людьми. Клиенты воспринимают тебя как настоящего супергероя, способного оперативно устранить возникшую проблему. Вспомним известную мудрость: «Относись к другим так, как хочешь, чтобы относились к тебе». Этот же принцип действует и тут: сегодня клиент обращается к тебе за помощью, а завтра ты сам можешь обратиться в службу поддержки провайдера домашнего интернета. Разумеется, ты предпочёл бы быстрое восстановление сети, а не сухой ответ типа: «Проблем у нас нет. Попробуйте перезагрузить роутер!» 😉 Последним штрихом нашего рецепта становится смелость. Даже если ты искренне хочешь помочь клиенту, но боишься попробовать нестандартные подходы или привлечь более опытного коллегу, то никакого прогресса не произойдёт. Завершая рецепт, хочется напомнить простую истину: «Люби то, что делаешь, и делай то, что любишь» #TechSupport #Сто_Советов_ТехПод

Пока я собираю вам новый материал (вакансии, советы рукводителей и инструменты для продуктивности), товарищи из supprt.science круто оформили мой прошлый пост. Можно полюбоваться.

🔅 Когда книга о бизнесе Фёдора Овчинникова только вышла, нас очень впечатлил его подход к факапам. Идея о том, что винить рядовых сотрудников в сбоях странно, ведь зачастую проблема в слабых процессах и отсутствии чёткой системы. Шеф технической поддержки Cloud. ru Ринат Саитов как поклонник структурного подхода увидел в издании не только классные практики клиентского сервиса, но огромное число других полезностей, которые стоит перенять бизнесам. Сегодня в колонке #СервисноеЧтиво обсуждаем «ДОДО книгу». #полезныйконтент #SupprtScienceрекомендует

Ключевые метрики надёжности. Часть 3/3: MTTF Mean Time To Failure (MTTF) - среднее время до отказа. Это метрика надёжности для невосстанавливаемых компонентов: она показывает, сколько времени устройство проработает до первого критического отказа, после которого требуется полная замена. Чем выше MTTF - тем дольше компонент служит без замены. Базовая формула: MTTF = Общее время работы всех экземпляров / Количество отказов Важный нюанс: расчёт проводится для группы одинаковых компонентов. Суммируется время работы каждого экземпляра до его отказа, затем результат делится на число отказавших устройств. Зачем измерять Анализ MTTF помогает: ▪️планировать замены компонентов до наступления массовых отказов; ▪️оптимизировать запасы критичных запчастей; ▪️прогнозировать расходы на обновление инфраструктуры; ▪️оценивать надёжность поставщиков при закупках оборудования. Важно: невосстанавливаемые компоненты ▪️MTTF применяется к элементам, которые после отказа заменяют целиком: лампы, жёсткие диски, блоки питания, твердотельные накопители. ▪️После отказа такой компонент не ремонтируется - его извлекают и ставят новый. ▪️MTBF, напротив, используется для восстанавливаемых систем: серверов, сетевого оборудования, приложений, которые возвращаются в строй после ремонта или перезагрузки. Пример В дата-центре эксплуатируются 100 одинаковых жёстких дисков в течение года (8 760 часов). За этот период отказали 8 дисков. Общее время работы всех дисков до отказа: 100 дисков × 8 760 часов = 876 000 часов MTTF = 876 000 часов / 8 отказов = 109 500 часов Это означает: в среднем диск такой модели проработает около 12,5 лет до отказа. На практике это позволяет планировать замену партии дисков заблаговременно - например, начать закупку новых накопителей на 10-м году эксплуатации. Ограничения метрики ▪️MTTF предполагает постоянную интенсивность отказов, что не всегда соответствует реальности (например, старение ускоряет отказы в конце срока службы). ▪️Метрика не учитывает зависимости между отказами: если один диск вышел из строя из-за перегрева стойки, другие диски в той же стойке могут отказать раньше расчётного срока. ▪️Для полной картины надёжности MTTF следует рассматривать вместе с другими показателями: интенсивностью отказов (failure rate) и данными о гарантийных заменах. Как работать с MTTF на практике 1️⃣ Контролируйте условия эксплуатации Температура, влажность, вибрация напрямую влияют на фактический срок службы компонентов. Поддержание параметров в рекомендованных производителем пределах приближает реальный срок службы к заявленному MTTF. 2️⃣ Планируйте замены на основе статистики Не ждите массовых отказов. При приближении к 80% от расчётного MTTF начинайте закупку замены для критичных компонентов. 3️⃣ Используйте избыточность Если отдельный компонент неизбежно выйдет из строя, избыточность (RAID для дисков, резервные блоки питания) гарантирует, что отказ одного элемента не приведёт к потере сервиса. Современный контекст Производители дисков и других компонентов указывают MTTF в спецификациях (часто 1-2 миллиона часов). Однако реальный срок службы зависит от нагрузки и условий эксплуатации. Современные системы мониторинга отслеживают параметры износа: количество циклов записи у SSD, температуру и скорость вращения у HDD. На основе этих данных формируются прогнозы оставшегося срока службы - что превращает пассивное ожидание отказа в проактивное планирование замены. Главное MTTF - это статистическая оценка для группы одинаковых компонентов, а не гарантия срока службы отдельного экземпляра. Идеального компонента не существует: всё имеет конечный срок службы. Но разница между «ждём отказа» и «меняем по графику до сбоя» - это и есть зрелость подхода к управлению надёжностью. #reliability #incidentmanagement #ITIL #MTTF

Ключевые метрики надёжности. Часть 2/3: MTBF Mean Time Between Failures (MTBF) - среднее время между отказами. Это метрика надёжности, которая показывает, сколько времени система или оборудование работает без сбоев. Чем выше MTBF - тем надёжнее актив и предсказуемее его работа. Базовая формула: MTBF = Общее время работы системы / Количество отказов за период Важный нюанс: в расчёт включаются только незапланированные отказы - события, при которых система перестаёт выполнять свою функцию. Плановые остановки на обслуживание, обновления или перезагрузки в расчёт не идут. Зачем измерять Высокий MTBF напрямую влияет на: ▪️предсказуемость работы сервиса и доверие клиентов; ▪️планирование ресурсов и графиков обслуживания; ▪️экономику: меньше аварий - меньше потерь и срочных работ; ▪️оценку надёжности критически важных активов. Важно понимать ограничения MTBF ▪️Метрика не показывает причины отказов. Два актива с одинаковым MTBF могут ломаться по разным причинам: износ или дефект проектирования. ▪️Метрика не учитывает тяжесть отказа. Мелкая неисправность и критический сбой в расчёте имеют одинаковый вес. ▪️Частота отказов (failure rate) - величина, обратная MTBF: чем выше частота отказов, тем ниже надёжность. Пример Серверный кластер работал 720 часов (30 дней). За этот период произошло 3 незапланированных отказа: ▪️отказ диска с потерей доступности (восстановление за 40 минут); ▪️сбой питания с остановкой узла (восстановление за 20 минут); ▪️критическая ошибка приложения с падением сервиса (перезапуск и патч за 1 час). MTBF = 720 часов / 3 отказа = 240 часов Это означает: в среднем кластер работает 240 часов (10 дней) между отказами. Как увеличить MTBF: три проверенных подхода 1️⃣ Собирайте фактические данные Производители могут указывать теоретический MTBF. Реальная надёжность зависит от нагрузки, конфигурации и условий эксплуатации. Только замеры в вашей среде дают объективную картину. 2️⃣ Анализируйте корневые причины Если система падает повторно по одной причине (например, утечка памяти), устранение симптома не увеличит MTBF. Только исправление корневой причины повышает надёжность. 3️⃣ Автоматизируйте рутинные операции Ошибки при развёртывании, конфигурировании или обновлениях - частая причина отказов. Автоматизация развёртываний и управление конфигурациями снижают количество событий, влияющих на MTBF. Современный контекст Современные системы мониторинга выявляют аномалии до перехода в состояние отказа: деградация дисков, рост задержек, отклонения в потреблении ресурсов. ИИ-алгоритмы связывают такие паттерны с историей инцидентов и предлагают превентивные действия. Результат: потенциальные отказы устраняются до фактического сбоя - и MTBF растёт. Главное MTBF - это индикатор надёжности актива. Идеала не бывает: всё ломается. Но разница между "каждую неделю чиним" и "месяцами работаем без потери сервиса" - это и есть зрелость инженерной культуры. #reliability #incidentmanagement #ITIL #MTBF