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


Kanal geosi va tili: Rossiya, Ruscha


Все про Техническую Поддержку
Конкретно. Просто. Классно.
Для связи @RinatSaitov

Bog‘liq kanallar

Kanal geosi va tili
Rossiya, Ruscha
Statistika
Postlar filtri


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


Вторая линия 💌 поддержка для саппорта dan repost
Video oldindan ko‘rish uchun mavjud emas
Telegram'da ko‘rish
😀😃🙃😇Встреча для саппортов!

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

📎 techsup meetup 📎

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

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

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

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

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


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

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


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

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

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


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


2026 IT Priorities Report.pdf
19.0Mb
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


TeDo-insights-gartner-hype-cycle-2026.pdf
33.7Mb
Погода на завтра. Какая точность вангования у исследований?

Есть такая компания 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 круто оформили мой прошлый пост.
Можно полюбоваться.


Вот это сервис! от Supprt.Science dan repost
🔅 Когда книга о бизнесе Фёдора Овчинникова только вышла, нас очень впечатлил его подход к факапам. Идея о том, что винить рядовых сотрудников в сбоях странно, ведь зачастую проблема в слабых процессах и отсутствии чёткой системы.

Шеф технической поддержки 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

18 ta oxirgi post ko‘rsatilgan.