Как стать крутым в ТехПоде?
Добавляем в коллекцию новый совет от руководителей в ТехПоде. Делится Ольга Елисеева, руководитель технической дирекции, Инфосистемы Джет:
Важно понимать, за что клиент платит деньги: чаще всего это за работоспособность оборудования и процессов целиком, иногда он платит компании за ваши компетенции и ожидает, что вы станете полноценным членом его команды. Когда ты это понимаешь, тебе легче «встать в тапки» клиента, понять мотивы его действий, начать думать «как клиент» и где-то играть на опережение — чтобы он мог спать спокойно. А это тебе самому обеспечит не только профессиональный рост, но и финансовый.#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍4🤝3❤1
Forwarded from Вот это сервис! от Supprt.Science
Сегодня мы с коллегой Ринатом Саитовым знакомим вас с материалами о работе с инцидентами.
Речь о ITIL, способах строить процессы так, чтобы 31 декабря в 17.59 никто не катил срочные обновления, а поддержку не заваливало тикетами, чтобы жалобы клиентов влияли на решения продукта, а бизнес не терял связи с клиентом.
Ринат — шеф поддержки и автор канала «ТехПод от А до Я». Он умеет раскладывать сложные процессы по полочкам.
🧷 В карточках — тезисы из его статей, а полные версии тут:
⚪️ Incident Management часть 1 и 2
⚪️ Problem Management
⚪️ Change Management
#ITIL #техпод #incidentmanagement #ТочкаТрения
Речь о ITIL, способах строить процессы так, чтобы 31 декабря в 17.59 никто не катил срочные обновления, а поддержку не заваливало тикетами, чтобы жалобы клиентов влияли на решения продукта, а бизнес не терял связи с клиентом.
Ринат — шеф поддержки и автор канала «ТехПод от А до Я». Он умеет раскладывать сложные процессы по полочкам.
#ITIL #техпод #incidentmanagement #ТочкаТрения
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14✍4👍3🤩3🤝3
Как стать крутым в ТехПоде?
Продолжаем собирать 100 коротких советов от руководителей и директоров в ТехПоде.
Сегодня в главной роли - Инга Лабахуа, основательница консалтингового агентства Supprt.Science, ex-шеф clients operations Рокетбанка, перезапускала поддержку в Райффайзен, Яндексе и десятке компаний финтеха и ритейла:
— Ответ во многом зависит от того, что именно считать «крутым»: хочется вырасти вверх или прокачать навыки в роли спеца поддержки. Отвечу скорее на второе.
По моему опыту, в техподах часто упор делают на харды: продуктовая экспертиза, база в IT, профильное образование. Но только харды не помогут вырасти ни конкретному специалисту, ни команде поддержки, ни тем более компании.
Бизнес всегда будет стараться привлекать больше клиентов и расширять ЦА, поддержке нужно уметь работать с очень разными людьми с разным бэком, уровнем знаний. Без софтов, умения вести диалог, разруливать конфликты, считывать собеседника даже самый классный спец разрушит лояльность клиента. А бизнес потеряет деньги и репутацию.
Клиенты же точно становятся всё более требовательными. Решить проблему уже недостаточно. Важно оставить приятное послевкусие. Поэтому мой совет — качайте софты. Вы точно не должны быть психотерапевтами, но понимать, где уместно признать ошибку и извиниться, а где спуститься на уровень клиента и успокоить, супер-важно.
#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤7👍6👏2
TOPdesk_Inside_ITSM_2026_The_Future_of_Internal_IT_brochure_EN.pdf
3.9 MB
TOPdesk Inside ITSM 2026: The Future of Internal IT
Будущее внутреннего IT
Охват: опрос 6000 ИТ-специалистов Европы, август 2025 г.
Ключевые выводы
▪️ИТ - основа бизнеса: критичен для продуктивности, удовлетворённости сотрудников и инноваций.
▪️Кризис реактивности: 40% ИТ-специалистов заняты только "тушением пожаров", нет времени на профилактику. 29% организаций сталкиваются с серьёзными сбоями еженедельно.
▪️Новая роль: переход от "пожарной команды" к стратегическому партнёру, фокусирующемуся на устойчивости и инновациях.
Главные направления
1️⃣ Опыт сотрудников (DEX) - приоритет
▪️Инвестируют 95% организаций. Качество ИТ напрямую влияет на продуктивность (90%).
▪️Барьеры: высокая нагрузка (51% в Великобритании), гибридная работа (58%), нехватка ресурсов (43%).
2️⃣ Критерии "будущего" IT
▪️Главное - кибербезопасность (53%). Далее: использование ИИ (49%), самообслуживание (38%).
▪️Только 45% отделов считают себя "готовыми к будущему".
▪️Барьеры: нехватка кадров (28%), бюджета (27%), автоматизации (22%), разобщённость (16%).
3️⃣ ИИ как ускоритель
▪️Великобритания лидирует: 36% организаций полностью внедрили ИИ для стратегических целей.
▪️Драйвер - ИТ-отдел (70%). 86% видят в ИИ позитивное влияние, 74% не считают угрозой.
▪️Риски: безопасность данных (37%), излишняя зависимость (31%).
▪️Роль ИТ-специалистов смещается в сторону кибербезопасности (34%), сложных задач (21%), стратегии (21%).
Суть
Будущее ИТ - стратегическое партнёрство с бизнесом, где ИИ и автоматизация усиливают профессионалов, а не заменяют их. Ключ - проактивность, интеграция и человекоориентированный подход.
Вопроса для старта:
1️⃣ Главная проблема DEX для решения завтра?
2️⃣ Какая рутинная задача съедает больше всего времени команды?
3️⃣ Какую задачу можно отдать ИИ уже сегодня для высвобождения времени?
#Исследования #Тренды #HelpDesk
Будущее внутреннего IT
Охват: опрос 6000 ИТ-специалистов Европы, август 2025 г.
Ключевые выводы
▪️ИТ - основа бизнеса: критичен для продуктивности, удовлетворённости сотрудников и инноваций.
▪️Кризис реактивности: 40% ИТ-специалистов заняты только "тушением пожаров", нет времени на профилактику. 29% организаций сталкиваются с серьёзными сбоями еженедельно.
▪️Новая роль: переход от "пожарной команды" к стратегическому партнёру, фокусирующемуся на устойчивости и инновациях.
Главные направления
▪️Инвестируют 95% организаций. Качество ИТ напрямую влияет на продуктивность (90%).
▪️Барьеры: высокая нагрузка (51% в Великобритании), гибридная работа (58%), нехватка ресурсов (43%).
▪️Главное - кибербезопасность (53%). Далее: использование ИИ (49%), самообслуживание (38%).
▪️Только 45% отделов считают себя "готовыми к будущему".
▪️Барьеры: нехватка кадров (28%), бюджета (27%), автоматизации (22%), разобщённость (16%).
▪️Великобритания лидирует: 36% организаций полностью внедрили ИИ для стратегических целей.
▪️Драйвер - ИТ-отдел (70%). 86% видят в ИИ позитивное влияние, 74% не считают угрозой.
▪️Риски: безопасность данных (37%), излишняя зависимость (31%).
▪️Роль ИТ-специалистов смещается в сторону кибербезопасности (34%), сложных задач (21%), стратегии (21%).
Суть
Будущее ИТ - стратегическое партнёрство с бизнесом, где ИИ и автоматизация усиливают профессионалов, а не заменяют их. Ключ - проактивность, интеграция и человекоориентированный подход.
Вопроса для старта:
#Исследования #Тренды #HelpDesk
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10✍3🔥1
3 ключевые задачи руководителя технической поддержки
Когда-то Билл Гейтс сформулировал три ключевых задачи CEO:
1️⃣ Привлекать капитал.
2️⃣ Нанимать ключевых людей.
3️⃣ Закрывать ключевые сделки.
Просто. Гениально. Вся суть - в трёх строчках.
А вот как выглядит эта формула, если вы "СЕО" техподдержки?
Я конечно не миллиардер из Сиэтла, с моей колокольни триада такая:
1️⃣ Обеспечивать доверие клиентов - через надёжность, прозрачность и скорость решения проблем.
2️⃣ Формировать сильную команду - нанимать, развивать и удерживать специалистов, которые делают поддержку конкурентным преимуществом.
3️⃣ Превращать опыт поддержки в ценность для бизнеса - через обратную связь, знания и данные, которые улучшают продукт, процессы и стратегию компании.
Деньги - капитал компании. Доверие - ваш капитал. Ваша работа - делать его ликвидным.
Если короче:
Доверие, команда, влияние. Всё остальное - тактика.
#TechSupport #Management
Когда-то Билл Гейтс сформулировал три ключевых задачи CEO:
Просто. Гениально. Вся суть - в трёх строчках.
А вот как выглядит эта формула, если вы "СЕО" техподдержки?
Я конечно не миллиардер из Сиэтла, с моей колокольни триада такая:
Деньги - капитал компании. Доверие - ваш капитал. Ваша работа - делать его ликвидным.
Если короче:
Доверие, команда, влияние. Всё остальное - тактика.
#TechSupport #Management
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9✍4❤2🔥2💯2
Зачем руководителю поддержки читать книги?
Большинство думает: «Зачем читать? У меня и так X лет опыта!»
Отлично! Опыт - это здорово.
Но опыт без рефлексии - это как бег по кругу с граблями в руках. Вы уже наступили на них сотню раз. А книги? Это чужие грабли, аккуратно выложенные на стол. С подписями: «Тут споткнулись - не повторяйте».
Зачем наступать самому, если можно заранее увидеть яму?
Клиентский сервис - это не про «реагировать».
Это про проектировать.
И книги - это не сборник советов «как быть вежливым».
Это как строить системы, которые уже работают.
Книги дают вам:
▪️Процессы вместо хаоса: не «как ответить на гневное письмо», а как создать схему, чтобы такие письма просто не появлялись.
▪️Метрики, которые имеют смысл: не просто «удовлетворённость», а точки влияния на неё - от первого ответа до решения проблемы.
▪️Карту клиентского пути: где на самом деле ломается опыт, и как это починить - на уровне логики, а не эмоций.
▪️Инструменты масштабирования: как растить команду, не теряя качества. Не магией, а процессами.
Когда вы читаете про компании - ДОДО, Southwest, ВкусВилл и др. - вы видите не «улыбки».
Вы видите систему решений.
И в следующем посте я покажу это на живом примере - книге про ДОДО.
Там будет не про «быструю пиццу» и «просто будьте вежливыми».
А про то, как система принятия решений создают тот самый «вау-эффект», который все хотят, но мало кто строит.
Читайте. Внедряйте. Систематизируйте.
Ваш автор, который верит в силу книг, систем и здравого смысла.
#TechSupport #Книги
Большинство думает: «Зачем читать? У меня и так X лет опыта!»
Отлично! Опыт - это здорово.
Но опыт без рефлексии - это как бег по кругу с граблями в руках. Вы уже наступили на них сотню раз. А книги? Это чужие грабли, аккуратно выложенные на стол. С подписями: «Тут споткнулись - не повторяйте».
Зачем наступать самому, если можно заранее увидеть яму?
Клиентский сервис - это не про «реагировать».
Это про проектировать.
И книги - это не сборник советов «как быть вежливым».
Это как строить системы, которые уже работают.
Книги дают вам:
▪️Процессы вместо хаоса: не «как ответить на гневное письмо», а как создать схему, чтобы такие письма просто не появлялись.
▪️Метрики, которые имеют смысл: не просто «удовлетворённость», а точки влияния на неё - от первого ответа до решения проблемы.
▪️Карту клиентского пути: где на самом деле ломается опыт, и как это починить - на уровне логики, а не эмоций.
▪️Инструменты масштабирования: как растить команду, не теряя качества. Не магией, а процессами.
Когда вы читаете про компании - ДОДО, Southwest, ВкусВилл и др. - вы видите не «улыбки».
Вы видите систему решений.
И в следующем посте я покажу это на живом примере - книге про ДОДО.
Там будет не про «быструю пиццу» и «просто будьте вежливыми».
А про то, как система принятия решений создают тот самый «вау-эффект», который все хотят, но мало кто строит.
Читайте. Внедряйте. Систематизируйте.
Ваш автор, который верит в силу книг, систем и здравого смысла.
#TechSupport #Книги
👍9🔥7💯2
Как небольшой пиццерии из Сыктывкара удалось стать лидером рынка и попасть на страницы мировых изданий?
История «Додо Пиццы» - это не история удачи, а результат выстроенной системы.
Когда основатель Фёдор Овчинников пришёл работать в Papa John’s, он не искал «секретный соус». Он искал систему.
Потом он создал свою.
В основе этой системы - принцип «гемба». Руководители компании, включая гендиректора, регулярно работают на кухне полную смену. Они моют полы, готовят пиццу и общаются с клиентами. Это не ритуал, а способ оставаться в реальности процессов, находить «узкие горлышки» и понимать, как решения из офиса работают на практике.
Ключевое отличие «Додо» - гипердифференциация через тотальную прозрачность. Пока многие говорят о клиентоориентированности, компания строит её. Онлайн-трансляции с кухни, публикация финансовых отчётов и стриминг совещаний - это пиар, инструменты создания доверия и постоянного самоулучшения.
Когда другие сети прятали кухни, «Додо» открыла их.
Когда другие боялись критики, «Додо» написала: «Пожалуйста, критикуйте».
Внутри компании действует философия без поиска виновных. Ошибка считается сбоем в системе, а не поводом для наказания. Если клиент недоволен, проблема решается мгновенно в его пользу.
▪️Именно поэтому холодную пиццу не оспаривают - её просто переделывают.
▪️Именно поэтому в день рождения не требуют паспорт - верят на слово.
▪️Именно поэтому кофе после опрокинутого стакана приносят до того, как клиент успевает попросить.
Такой подход превращает лояльность в долгосрочный актив.
Компания борется с «ресурсным мышлением». Вместо того чтобы в час пик требовать больше сотрудников, команда ищет узкие места в процессах. Оптимизация, подготовка заготовок, умный трекинг с помощью ИИ заказов и голосовой помощник «Оленька», которая говорила: «Поторопитесь!» или «Так держать!», которые позволяют повышать эффективность без раздувания штата.
Такая надёжная операционная основа позволяет «Додо» экспериментировать с инновациями. Компания первой в мире испытала доставку пиццы квадрокоптером. Мировые СМИ - от The Washington Post до Le Monde - написали об этом.
Поэтому при выборе партнёров для франшизы «Додо» смотрит не на размер инвестиций, а на готовность разделить этот подход. Готов ли будущий партнёр начать с работы на кухне? Принять принцип тотальной открытости? Улучшать процессы, а не наращивать ресурсы?
«Додо Пицца» - это больше, чем сеть пиццерий. Это доказательство того, что бизнес можно строить на системном подходе, доверии и постоянном поиске лучших решений. Именно это превращает простую пиццу в успешную бизнес-модель.
#Книги
История «Додо Пиццы» - это не история удачи, а результат выстроенной системы.
Когда основатель Фёдор Овчинников пришёл работать в Papa John’s, он не искал «секретный соус». Он искал систему.
Потом он создал свою.
В основе этой системы - принцип «гемба». Руководители компании, включая гендиректора, регулярно работают на кухне полную смену. Они моют полы, готовят пиццу и общаются с клиентами. Это не ритуал, а способ оставаться в реальности процессов, находить «узкие горлышки» и понимать, как решения из офиса работают на практике.
Ключевое отличие «Додо» - гипердифференциация через тотальную прозрачность. Пока многие говорят о клиентоориентированности, компания строит её. Онлайн-трансляции с кухни, публикация финансовых отчётов и стриминг совещаний - это пиар, инструменты создания доверия и постоянного самоулучшения.
Когда другие сети прятали кухни, «Додо» открыла их.
Когда другие боялись критики, «Додо» написала: «Пожалуйста, критикуйте».
Внутри компании действует философия без поиска виновных. Ошибка считается сбоем в системе, а не поводом для наказания. Если клиент недоволен, проблема решается мгновенно в его пользу.
▪️Именно поэтому холодную пиццу не оспаривают - её просто переделывают.
▪️Именно поэтому в день рождения не требуют паспорт - верят на слово.
▪️Именно поэтому кофе после опрокинутого стакана приносят до того, как клиент успевает попросить.
Такой подход превращает лояльность в долгосрочный актив.
Компания борется с «ресурсным мышлением». Вместо того чтобы в час пик требовать больше сотрудников, команда ищет узкие места в процессах. Оптимизация, подготовка заготовок, умный трекинг с помощью ИИ заказов и голосовой помощник «Оленька», которая говорила: «Поторопитесь!» или «Так держать!», которые позволяют повышать эффективность без раздувания штата.
Такая надёжная операционная основа позволяет «Додо» экспериментировать с инновациями. Компания первой в мире испытала доставку пиццы квадрокоптером. Мировые СМИ - от The Washington Post до Le Monde - написали об этом.
Поэтому при выборе партнёров для франшизы «Додо» смотрит не на размер инвестиций, а на готовность разделить этот подход. Готов ли будущий партнёр начать с работы на кухне? Принять принцип тотальной открытости? Улучшать процессы, а не наращивать ресурсы?
«Додо Пицца» - это больше, чем сеть пиццерий. Это доказательство того, что бизнес можно строить на системном подходе, доверии и постоянном поиске лучших решений. Именно это превращает простую пиццу в успешную бизнес-модель.
#Книги
👍12✍4🤩3❤1
Так, а теперь о деньгах и карьере в БигТехе.
Нашёл два разбора, кому и сколько платят в IT-сфере:
Зарплаты в IT-2025
Куда уходят айтишники: анализ 30 000 резюме
А теперь - про техническую поддержку. Недавно давал комментарий для одного дружелюбного медиа про саппорт и операторов:
Источник
#Карьера
Нашёл два разбора, кому и сколько платят в IT-сфере:
Зарплаты в IT-2025
Куда уходят айтишники: анализ 30 000 резюме
А теперь - про техническую поддержку. Недавно давал комментарий для одного дружелюбного медиа про саппорт и операторов:
Хочешь в техпод? Сначала спроси себя: «А моё ли это?»
Всё начинается с простого, но главного: кем я хочу быть? Что меня зажигает?
Техподдержка - это люди, детектив и драйв. Если тебе не нравится помогать, объяснять, копаться в проблемах до победного и постоянно учиться - это не твоя дорога.
Работа отнимает львиную долю жизни. Она должна приносить удовольствие. Неважно, поддержка это, разработка или тестирование. Если дело по душе - ты сам тянешься за знаниями, следишь за трендами, растешь. Ты на острие, а значит - растешь в скиллах и в зарплате.
Вот правда: если перестанешь прокачивать хард- и софт-скиллы - за тобой придёт ИИ. Быстро. Не через пять лет, а через год-два. Рутина уровня L1 уходит в историю. Это эволюция. Держи себя в тонусе.
А что с деньгами?
Инженеры L2/L3 - те, кто знают продукты и инфраструктуру наизнутрь.
Зарплаты от 100 до 400+ тысяч - не редкость. Потолок определяешь ты сам. Глубиной знаний. Скоростью реакции. Умением видеть корень проблемы.
Совет бывалого: стремись в крупные IT-компании. Там, где IT - не статья расходов, а основной источник дохода. Там поддержку ценят по-настоящему. Платят хорошо. Прокачаться можно в разы быстрее.
Запомни: инженеров нанимают не для закрытия заявок. Их нанимают, чтобы они приносили пользу бизнесу и делали клиентов довольными.
P.S. Запомнилась фраза:
«Я твёрдо верю в удачу. И я заметил: чем больше я работаю, тем я удачливее».
— Томас Джефферсон
Удачи. Побольше.
Источник
#Карьера
👍13🔥8✍3😁1
Переосмысление мониторинга.
От метрикориентированного ада к клиентоцентричности и бизнес влиянию.
Коллеги, давайте честно: сколько раз вы видели в ночном алерте «CPUThrottlingHigh 99.93%» и первые 7 минут тратили не на решение проблемы, а на расшифровку - какой клиент сейчас страдает или на что это влияет?
Метрикоцентричные алерты: "Что это? Разберём за 3 минуты"
Эти алерты - классика "метрикориентированного ада". Они фокусируются на сырых цифрах или статусах, без контекста. Инженер видит - бежит гуглить, что за workflow или метрика. Пользователь/бизнес? Им плевать, пока не упадёт SLA.
Примеры:
▪️CRITICAL❗️: node_exporter_target_down{instance="10.45.12.87:9100"} #
Перевод для дежурного: «Что-то где-то упало. Найди в инвентаре, что это за IP, потом пойми, зачем оно нужно».
▪️High🔥: kube_pod_status_phase{phase="Pending"} > 5 for 10m
Перевод: «В кластере 5 подов висят. Клиенты не могут загрузить корзину? Не могут оплатить? Или это фоновые воркеры для отчетов? Удачи разобраться за 3 минуты до эскалации».
▪️CRITICAL❗️: http_request_duration_seconds{quantile="0.99"} > 5s
Перевод: «Медленно. Где? Для кого? Что именно не работает - логин, оплата, выгрузка данных?»
▪️ALERT⚠️: postgresql_locks_waiting > 0
Перевод: «База под нагрузкой». А клиент в это время видит вечный спиннер при сохранении заказа. Но алерт об этом молчит.
Видите? Кто страдает? Какой impact? Сколько клиентов/денег под угрозой? Названия как из логов или стандартных шаблонов мониторинга - технарь поймёт(возможно), но on-call инженер в 3 ночи подумает: "А это влияет на клиентов или просто шум?"
Такие алерты заставляют инженера тратить драгоценные минуты на перевод с «метрического» на «человеческий» - а клиент в это время уже звонит в поддержку с вопросом «Почему не проходит оплата?».
Что имеем в итоге? MTTR растёт, SLA падает, клиенты злятся.
Это не мониторинг - это "охота за метриками".
Клиентоцентричные алерты: когда название алерта = инструкция к действию.
Алерт должен кричать: "Кто? Что? Последствия!"
▪️[CRITICAL][IMPACT:PAYMENTS] Payment processing unavailable for 100% of Enterprise customers
→ Действие: Срочно эскалировать в платежную команду + информировать менеджеров по работе с корпоративными клиентами
▪️[WARNING][RISK:ORDER_RECOVERY] There are no backup copies of orders from 01.02 - in case of failure, customers will lose 14,000 unpaid carts without the possibility of recovery.
→ Действие: Проверить retention policy, подготовить сценарий восстановления из cold storage
▪️[CRITICAL][IMPACT:ALL_USERS] SSO authentication failure rate 92% - users cannot access any application modules
→ Действие: Активировать fallback-механизм аутентификации, запустить массовую коммуникацию через статус-страницу
Почему это работает?
Когда дежурный видит [CRITICAL][IMPACT:PAYMENTS], он не думает - он действует. И это сокращает не только MTTR, но и количество звонков в поддержку от разъяренных клиентов.
Как внедрить:
1. Аудит: Определите метрики по влиянию на клиентов.
2. Перепишите алерты: Добавьте шаблоны "[SEVERITY][STATUS] Service - impact for [audience])".
3. Тестируйте: Симулируйте в Chaos Engineering, измерьте MTTR до/после.
Подытожим:
Алерты должны говорить на языке бизнеса и боли клиентов: не «CPU загружен на 99%», а «пользователи не могут оформить заказ». Потому что в 3 ночи клиенту всё равно, какая метрика упала - ему важно, чтобы его платеж прошел. А ваша задача как руководителя/инженера - сделать так, чтобы команда увидела проблему глазами клиента до того, как клиент позвонит вам.
#monitoring #bestpractices
От метрикориентированного ада к клиентоцентричности и бизнес влиянию.
Коллеги, давайте честно: сколько раз вы видели в ночном алерте «CPUThrottlingHigh 99.93%» и первые 7 минут тратили не на решение проблемы, а на расшифровку - какой клиент сейчас страдает или на что это влияет?
Метрикоцентричные алерты: "Что это? Разберём за 3 минуты"
Эти алерты - классика "метрикориентированного ада". Они фокусируются на сырых цифрах или статусах, без контекста. Инженер видит - бежит гуглить, что за workflow или метрика. Пользователь/бизнес? Им плевать, пока не упадёт SLA.
Примеры:
▪️CRITICAL❗️: node_exporter_target_down{instance="10.45.12.87:9100"} #
Перевод для дежурного: «Что-то где-то упало. Найди в инвентаре, что это за IP, потом пойми, зачем оно нужно».
▪️High🔥: kube_pod_status_phase{phase="Pending"} > 5 for 10m
Перевод: «В кластере 5 подов висят. Клиенты не могут загрузить корзину? Не могут оплатить? Или это фоновые воркеры для отчетов? Удачи разобраться за 3 минуты до эскалации».
▪️CRITICAL❗️: http_request_duration_seconds{quantile="0.99"} > 5s
Перевод: «Медленно. Где? Для кого? Что именно не работает - логин, оплата, выгрузка данных?»
▪️ALERT⚠️: postgresql_locks_waiting > 0
Перевод: «База под нагрузкой». А клиент в это время видит вечный спиннер при сохранении заказа. Но алерт об этом молчит.
Видите? Кто страдает? Какой impact? Сколько клиентов/денег под угрозой? Названия как из логов или стандартных шаблонов мониторинга - технарь поймёт(возможно), но on-call инженер в 3 ночи подумает: "А это влияет на клиентов или просто шум?"
Такие алерты заставляют инженера тратить драгоценные минуты на перевод с «метрического» на «человеческий» - а клиент в это время уже звонит в поддержку с вопросом «Почему не проходит оплата?».
Что имеем в итоге? MTTR растёт, SLA падает, клиенты злятся.
Это не мониторинг - это "охота за метриками".
Клиентоцентричные алерты: когда название алерта = инструкция к действию.
Алерт должен кричать: "Кто? Что? Последствия!"
▪️[CRITICAL][IMPACT:PAYMENTS] Payment processing unavailable for 100% of Enterprise customers
→ Действие: Срочно эскалировать в платежную команду + информировать менеджеров по работе с корпоративными клиентами
▪️[WARNING][RISK:ORDER_RECOVERY] There are no backup copies of orders from 01.02 - in case of failure, customers will lose 14,000 unpaid carts without the possibility of recovery.
→ Действие: Проверить retention policy, подготовить сценарий восстановления из cold storage
▪️[CRITICAL][IMPACT:ALL_USERS] SSO authentication failure rate 92% - users cannot access any application modules
→ Действие: Активировать fallback-механизм аутентификации, запустить массовую коммуникацию через статус-страницу
Почему это работает?
Когда дежурный видит [CRITICAL][IMPACT:PAYMENTS], он не думает - он действует. И это сокращает не только MTTR, но и количество звонков в поддержку от разъяренных клиентов.
Как внедрить:
1. Аудит: Определите метрики по влиянию на клиентов.
2. Перепишите алерты: Добавьте шаблоны "[SEVERITY][STATUS] Service - impact for [audience])".
3. Тестируйте: Симулируйте в Chaos Engineering, измерьте MTTR до/после.
Подытожим:
Алерты должны говорить на языке бизнеса и боли клиентов: не «CPU загружен на 99%», а «пользователи не могут оформить заказ». Потому что в 3 ночи клиенту всё равно, какая метрика упала - ему важно, чтобы его платеж прошел. А ваша задача как руководителя/инженера - сделать так, чтобы команда увидела проблему глазами клиента до того, как клиент позвонит вам.
#monitoring #bestpractices
👍9🔥6✍4❤1
Как стать крутым в ТехПоде?
Сегодня делится опытом Никита Мельников, директор по клиентскому сервису Selectel 🏢
Помимо знаний предметной области и навыков коммуникации, самыми важным в работе сотрудника поддержки я считаю способность отвечать на вопрос «Зачем это нужно?» вместо «Что необходимо сделать?».
Ответ на этот вопрос помогает понять выгоду, цель и контекст, чтобы найти оптимальный путь решения для клиента. Такой подход выводит специалиста из операционного уровня на уровень аналитики и стратегии.
#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥4🤝1
12 февраля 2026: что ждать от официального выхода ITIL v5
ITIL - это библиотека лучших практик для структурированной и эффективной организации работы IT-подразделения.
Этот фреймворк лежит в основе работы IT-служб множества крупных компаний по всему миру, включая Россию. И новая версия - ITIL 5 - пришла как раз тогда, когда от команд требуют: внедрять AI, автоматизировать процессы и ускоряться, но при этом не потерять в надёжности и качестве.
Хорошая новость: если вы уже используете ITIL 4, вы не начинаете с чистого листа. Фреймворк просто догнал современный мир, где ценность создается через цифровые продукты и AI.
Что принципиально нового в ITIL 5?
1️⃣ AI - это теперь «по умолчанию». ITIL 5 признаёт, что AI - не просто модное слово, а реальный инструмент с рисками. Поэтому фреймворк учит не просто «автоматизировать», а делать это ответственно. Главный вопрос теперь не «Можем ли мы?», а «Кто отвечает за результат ИИ и как мы его контролируем?».
2️⃣ Конец войне между разработкой и поддержкой. ITIL 5 ломает стену между продуктом (который создают) и сервисом (которым пользуются). Теперь это единый сквозной поток. Меньше перекидывания задач, больше ответственности за весь клиентский путь.
3️⃣ Создан для немедленного применения. Нет времени на годовые трансформации? И не надо. ITIL 5 - это про то, как улучшить реальную работу здесь и сейчас, а не про красивые дорожные карты, которые пылятся в углу.
5️⃣ Вышел за пределы IT-башни. Фреймворк теперь говорит на языке всего бизнеса: HR, юристы, финансы - все, кто предоставляет внутренние услуги, могут использовать его принципы. Это про управление ценностью для всей компании.
Что делать, если вы на ITIL 4?
Отставить спокойствие и сохранять панику. Главное не начинать «Большой Переход». Просто посмотрите на свои процессы от начала до конца, найдите узкие места и разрывы (особенно между командами) и постепенно начинайте применять новые принципы, особенно в части управления AI.
Ваши знания и наработки по ITIL 4 не устарели. Вы просто получите более современную и четкую карту для движения вперед.
Важное уточнение: на данный момент вышел только релиз-анонс ITIL v5. Официальный полноценный выход новой версии фреймворка ITIL® 5 запланирован на 12 февраля 2026 года
#ITIL #ITILv5
ITIL - это библиотека лучших практик для структурированной и эффективной организации работы IT-подразделения.
Этот фреймворк лежит в основе работы IT-служб множества крупных компаний по всему миру, включая Россию. И новая версия - ITIL 5 - пришла как раз тогда, когда от команд требуют: внедрять AI, автоматизировать процессы и ускоряться, но при этом не потерять в надёжности и качестве.
Хорошая новость: если вы уже используете ITIL 4, вы не начинаете с чистого листа. Фреймворк просто догнал современный мир, где ценность создается через цифровые продукты и AI.
Что принципиально нового в ITIL 5?
Что делать, если вы на ITIL 4?
Ваши знания и наработки по ITIL 4 не устарели. Вы просто получите более современную и четкую карту для движения вперед.
Важное уточнение: на данный момент вышел только релиз-анонс ITIL v5. Официальный полноценный выход новой версии фреймворка ITIL® 5 запланирован на 12 февраля 2026 года
#ITIL #ITILv5
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8✍6👍6
Ключевые метрики надежности. Часть Вводная.
Вы наверняка слышали расхожую мудрость: «Нельзя управлять тем, что нельзя измерить». Звучит умно, да?
Но вот в чём заковыка.
Гораздо опаснее измерять неправильно. Тратить часы на красивые дашборды, которые ведут вас в тупик. Собирать цифры, которые успокаивают - но бесполезны.
Вас ждет три важных разговора. О трех метриках, которые формируют ландшафт надежности любой IT-системы. MTTR, MTBF, MTTF. За каждой аббревиатурой скрывается принципиально разный взгляд на вашу инфраструктуру.
1️⃣ - про скорость реакции. 2️⃣ - про устойчивость. 3️⃣ - про долговечность.
Мы начнем с самой критичной и болезненной - MTTR. Среднее время ремонта/восстановления. Той самой метрики, которая напрямую конвертируется в деньги, репутацию и лояльность клиентов при каждом сбое.
А затем поднимемся на уровень выше. Увидим полную картину.
Готовы? Тогда идём дальше. За сутью.
#reliability #incidentmanagement #ITIL
Вы наверняка слышали расхожую мудрость: «Нельзя управлять тем, что нельзя измерить». Звучит умно, да?
Но вот в чём заковыка.
Гораздо опаснее измерять неправильно. Тратить часы на красивые дашборды, которые ведут вас в тупик. Собирать цифры, которые успокаивают - но бесполезны.
Вас ждет три важных разговора. О трех метриках, которые формируют ландшафт надежности любой IT-системы. MTTR, MTBF, MTTF. За каждой аббревиатурой скрывается принципиально разный взгляд на вашу инфраструктуру.
Мы начнем с самой критичной и болезненной - MTTR. Среднее время ремонта/восстановления. Той самой метрики, которая напрямую конвертируется в деньги, репутацию и лояльность клиентов при каждом сбое.
А затем поднимемся на уровень выше. Увидим полную картину.
Готовы? Тогда идём дальше. За сутью.
#reliability #incidentmanagement #ITIL
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥4✍3❤2
Ключевые метрики надежности. Часть 1/3: MTTR
Mean Time to Repair (MTTR) - это среднее время восстановления системы после сбоя. Ключевая метрика, которая показывает, насколько быстро ваша команда устраняет инциденты и снижает время простоя.
Формула проста:
Что важно знать о MTTR:
▪️Что это? MTTR измеряет промежуток от момента обнаружения сбоя до полного возврата системы в рабочее состояние.
▪️Зачем нужно? Метрика помогает анализировать и улучшать процессы, сокращать простой, повышать надежность и обосновывать решения по управлению инфраструктурой.
Не путайте. У MTTR есть важные вариации:
▪️Mean Time to Repair (ремонт) - время на физический ремонт (диагностика, замена, проверка).
▪️Mean Time to Recovery (восстановление) - время на полное восстановление сервиса для пользователей (включая перезапуск, восстановление данных).
▪️Mean Time to Resolve (решение) - время на устранение корневой причины, чтобы проблема не повторилась.
▪️Mean Time to Respond(ответ) - время от обнаружения до первой реакции команды.
Пример.
Отказ сервера из-за перегрева:
▪️15 минут (ответ) - команда отреагировала, клиент уведомлён.
▪️2 часа (ремонт) - заменён диск, система запущена (ремонт завершён).
▪️3 часа (восстановление) - сервис прошёл нагрузочное тестирование и вернулся в продакшен (восстановление завершено).
▪️5 часов (решение) - выявлена неисправность системы охлаждения, заменён кулер, настроено предиктивное оповещение (решение завершено).
Разница между «починили» и «больше не повторится» - именно в этих двух часах постинцидентного анализа.
Как сократить MTTR: три практических шага
1️⃣ Определите единую точку завершения
Когда инцидент считается закрытым? После замены компонента или после верификации под нагрузкой? Без чёткого критерия все цифры становятся условными.
2️⃣ Сделайте знания доступными
Структурированная база решений, шаблоны диагностики и внутренние гайды позволяют инженеру найти ответ за минуты, а не часы. Это самый высокодоходный актив для ускорения ремонта.
3️⃣ Автоматизируйте рутину, развивайте мышление
Автоматическое создание тикета по алерту сокращает время реакции. Но только системный анализ корневых причин (например, через метод «5 почему») снижает время разрешения. Без него вы лечите симптомы, а не болезнь.
Современный контекст
Продвинутые системы мониторинга, точные правила оповещения и применение ИИ для предиктивной аналитики позволяют не только быстрее реагировать на сбои, но и предотвращать их - смещая фокус с восстановления на проактивное управление надёжностью.
Итог:
MTTR - это не просто цифра для отчёта, а показатель зрелости процессов команды. Сбои неизбежны, но скорость и качество восстановления - ваше реальное конкурентное преимущество.
Главное:
MTTR - это зеркало вашей операционной зрелости.
Сбои неизбежны. Но интервал между «сломалось» и «забылось» - это и есть ваше конкурентное преимущество
#reliability #incidentmanagement #ITIL #MTTR
Mean Time to Repair (MTTR) - это среднее время восстановления системы после сбоя. Ключевая метрика, которая показывает, насколько быстро ваша команда устраняет инциденты и снижает время простоя.
Формула проста:
MTTR = Суммарное время на восстановление / Количество инцидентов.
Что важно знать о MTTR:
▪️Что это? MTTR измеряет промежуток от момента обнаружения сбоя до полного возврата системы в рабочее состояние.
▪️Зачем нужно? Метрика помогает анализировать и улучшать процессы, сокращать простой, повышать надежность и обосновывать решения по управлению инфраструктурой.
Не путайте. У MTTR есть важные вариации:
▪️Mean Time to Repair (ремонт) - время на физический ремонт (диагностика, замена, проверка).
▪️Mean Time to Recovery (восстановление) - время на полное восстановление сервиса для пользователей (включая перезапуск, восстановление данных).
▪️Mean Time to Resolve (решение) - время на устранение корневой причины, чтобы проблема не повторилась.
▪️Mean Time to Respond(ответ) - время от обнаружения до первой реакции команды.
Пример.
Отказ сервера из-за перегрева:
▪️15 минут (ответ) - команда отреагировала, клиент уведомлён.
▪️2 часа (ремонт) - заменён диск, система запущена (ремонт завершён).
▪️3 часа (восстановление) - сервис прошёл нагрузочное тестирование и вернулся в продакшен (восстановление завершено).
▪️5 часов (решение) - выявлена неисправность системы охлаждения, заменён кулер, настроено предиктивное оповещение (решение завершено).
Разница между «починили» и «больше не повторится» - именно в этих двух часах постинцидентного анализа.
Как сократить MTTR: три практических шага
Когда инцидент считается закрытым? После замены компонента или после верификации под нагрузкой? Без чёткого критерия все цифры становятся условными.
Структурированная база решений, шаблоны диагностики и внутренние гайды позволяют инженеру найти ответ за минуты, а не часы. Это самый высокодоходный актив для ускорения ремонта.
Автоматическое создание тикета по алерту сокращает время реакции. Но только системный анализ корневых причин (например, через метод «5 почему») снижает время разрешения. Без него вы лечите симптомы, а не болезнь.
Современный контекст
Продвинутые системы мониторинга, точные правила оповещения и применение ИИ для предиктивной аналитики позволяют не только быстрее реагировать на сбои, но и предотвращать их - смещая фокус с восстановления на проактивное управление надёжностью.
Итог:
MTTR - это не просто цифра для отчёта, а показатель зрелости процессов команды. Сбои неизбежны, но скорость и качество восстановления - ваше реальное конкурентное преимущество.
Главное:
MTTR - это зеркало вашей операционной зрелости.
Сбои неизбежны. Но интервал между «сломалось» и «забылось» - это и есть ваше конкурентное преимущество
#reliability #incidentmanagement #ITIL #MTTR
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍4✍3❤1
Как стать крутым в ТехПоде?
Добавляем в коллекцию новый совет от руководителей в ТехПоде.
Сегодня слушаем Евгения Кусайло, руководитель экспертной поддержки ИТ сервисов. И просто хороший парень) Kaspersky:
Я наверное сделаю акцент на теме роста хард скиллов.
Фиксируй всё новое в своей базе знаний.
Предварительно её конечно стоит завести.
Ищи причины возникающих проблем. И фиксируй. В базе знаний)
Пробегайся периодически по зафиксированному в базе знаний)
Для типовых проблем можно сделать чек-листы, поможет и тебе через полгода и коллегам, они будут тебе благодарны.
Старайся осваивать что-то новое регулярно.
Если ты хочешь быть крутым востребованным спецом тебе 100% понадобится вкладывать своё личное время. Выдели сколько-то часов в неделю и прокачивайся.
Регулярно читай техническую литературу и пробуй прочитанное на домашнем стенде.
Старайся максимально автоматизировать свою работу. Это прокачает скилы и освободит время для освоения нового.
Документируй автоматизацию. Можно даже в своей базе знаний.
Обсуждай с руководителем своё развитие - ИПР (индивидуальный план развития) крутая штука, особенно если ему следовать.
Самый глупый вопрос - тот, который ты не задал. А, вопросы, которые возникают, тоже надо фиксировать, пока они свежи в памяти)
Сети - база, кмк нужны любым техническим специалистам в ИТ.
Знай свои системы. Держи в порядке документацию по ним.
Ну и надо уметь задавать правильные вопросы гуглу.
Различные ИИ инструменты зачастую сильно упрощают жизнь. Однако к ним нужно подходить не как к штуке, которая решит за тебя проблему, а как к инструменту преумножения своих знаний. Проси не решить проблему, а объяснить почему что-то происходит.
#TechSupport #Сто_Советов_ТехПод
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤8🔥6✍3
Ключевые метрики надёжности. Часть 2/3: MTBF
Mean Time Between Failures (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
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: три проверенных подхода
Производители могут указывать теоретический MTBF. Реальная надёжность зависит от нагрузки, конфигурации и условий эксплуатации. Только замеры в вашей среде дают объективную картину.
Если система падает повторно по одной причине (например, утечка памяти), устранение симптома не увеличит MTBF. Только исправление корневой причины повышает надёжность.
Ошибки при развёртывании, конфигурировании или обновлениях - частая причина отказов. Автоматизация развёртываний и управление конфигурациями снижают количество событий, влияющих на MTBF.
Современный контекст
Современные системы мониторинга выявляют аномалии до перехода в состояние отказа: деградация дисков, рост задержек, отклонения в потреблении ресурсов. ИИ-алгоритмы связывают такие паттерны с историей инцидентов и предлагают превентивные действия. Результат: потенциальные отказы устраняются до фактического сбоя - и MTBF растёт.
Главное
MTBF - это индикатор надёжности актива.
Идеала не бывает: всё ломается. Но разница между "каждую неделю чиним" и "месяцами работаем без потери сервиса" - это и есть зрелость инженерной культуры.
#reliability #incidentmanagement #ITIL #MTBF
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6✍3🔥3