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

Сегодня делится опытом Никита Мельников, директор по клиентскому сервису Selectel 🏢

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

#TechSupport #Сто_Советов_ТехПод

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

Ключевые метрики надежности. Часть Вводная.

Вы наверняка слышали расхожую мудрость: «Нельзя управлять тем, что нельзя измерить». Звучит умно, да?
Но вот в чём заковыка.
Гораздо опаснее измерять неправильно. Тратить часы на красивые дашборды, которые ведут вас в тупик. Собирать цифры, которые успокаивают - но бесполезны.

Вас ждет три важных разговора. О трех метриках, которые формируют ландшафт надежности любой IT-системы. MTTR, MTBF, MTTF. За каждой аббревиатурой скрывается принципиально разный взгляд на вашу инфраструктуру.
1️⃣ - про скорость реакции. 2️⃣ - про устойчивость. 3️⃣ - про долговечность.

Мы начнем с самой критичной и болезненной - MTTR. Среднее время ремонта/восстановления. Той самой метрики, которая напрямую конвертируется в деньги, репутацию и лояльность клиентов при каждом сбое.

А затем поднимемся на уровень выше. Увидим полную картину.
Готовы? Тогда идём дальше. За сутью.

#reliability #incidentmanagement #ITIL

Ключевые метрики надежности. Часть 1/3: 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: три практических шага
1️⃣ Определите единую точку завершения
Когда инцидент считается закрытым? После замены компонента или после верификации под нагрузкой? Без чёткого критерия все цифры становятся условными.
2️⃣Сделайте знания доступными
Структурированная база решений, шаблоны диагностики и внутренние гайды позволяют инженеру найти ответ за минуты, а не часы. Это самый высокодоходный актив для ускорения ремонта.
3️⃣Автоматизируйте рутину, развивайте мышление
Автоматическое создание тикета по алерту сокращает время реакции. Но только системный анализ корневых причин (например, через метод «5 почему») снижает время разрешения. Без него вы лечите симптомы, а не болезнь.

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

Итог:
MTTR - это не просто цифра для отчёта, а показатель зрелости процессов команды. Сбои неизбежны, но скорость и качество восстановления - ваше реальное конкурентное преимущество.

Главное:
MTTR - это зеркало вашей операционной зрелости.
Сбои неизбежны. Но интервал между «сломалось» и «забылось» - это и есть ваше конкурентное преимущество

#reliability #incidentmanagement #ITIL #MTTR

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

Добавляем в коллекцию новый совет от руководителей в ТехПоде.
Сегодня слушаем Евгения Кусайло, руководитель экспертной поддержки ИТ сервисов. И просто хороший парень) Kaspersky:

Я наверное сделаю акцент на теме роста хард скиллов.
Фиксируй всё новое в своей базе знаний.
Предварительно её конечно стоит завести.
Ищи причины возникающих проблем. И фиксируй. В базе знаний)
Пробегайся периодически по зафиксированному в базе знаний)
Для типовых проблем можно сделать чек-листы, поможет и тебе через полгода и коллегам, они будут тебе благодарны.
Старайся осваивать что-то новое регулярно.
Если ты хочешь быть крутым востребованным спецом тебе 100% понадобится вкладывать своё личное время. Выдели сколько-то часов в неделю и прокачивайся.
Регулярно читай техническую литературу и пробуй прочитанное на домашнем стенде.
Старайся максимально автоматизировать свою работу. Это прокачает скилы и освободит время для освоения нового.
Документируй автоматизацию. Можно даже в своей базе знаний.
Обсуждай с руководителем своё развитие - ИПР (индивидуальный план развития) крутая штука, особенно если ему следовать.
Самый глупый вопрос - тот, который ты не задал. А, вопросы, которые возникают, тоже надо фиксировать, пока они свежи в памяти)
Сети - база, кмк нужны любым техническим специалистам в ИТ.
Знай свои системы. Держи в порядке документацию по ним.
Ну и надо уметь задавать правильные вопросы гуглу.
Различные ИИ инструменты зачастую сильно упрощают жизнь. Однако к ним нужно подходить не как к штуке, которая решит за тебя проблему, а как к инструменту преумножения своих знаний. Проси не решить проблему, а объяснить почему что-то происходит.

#TechSupport #Сто_Советов_ТехПод

Ключевые метрики надёжности. Часть 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

Ключевые метрики надёжности. Часть 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

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

Делится Сергей Князев, руководитель ситуационного центра в компании Гистех и просто Заботливый человек:

Для приготовления блюда «Как стать крутым в техподдержке?» я бы использовал следующие ингредиенты:

1. Любознательность
2. Систематизацию
3. Дисциплину
4. Эмпатию
5. Смелость

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

Любознательность позволяет собрать огромное количество информации, однако важно уметь правильно её организовать и хранить. Тут нам помогает второй ингредиент — систематизация. Как верно заметил Евгений Кусайло из Kaspersky: обязательно веди собственную базу знаний. Причём не ограничивайся короткими однострочными заметками или командами, а стремись максимально подробно фиксировать всю полезную информацию, сопровождая её рисунками и схемами. Без подробного описания спустя месяц или даже неделю ты рискуешь забыть зачем использовалась та или иная команда или запись.

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

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

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

Завершая рецепт, хочется напомнить простую истину: «Люби то, что делаешь, и делай то, что любишь»

#TechSupport #Сто_Советов_ТехПод