ITibekin | Просто о цифровом

✳️Что значит быть хорошим инженером в 2026 году?

В прошлом посте рассказывал, как 10 лет назад пришёл в НИКСИС инженером. Больших ожиданий от IT у меня тогда не было. Я не строил карьерный план на десять лет вперёд, просто видел, что хороший инженер может хорошо зарабатывать:)

И пока вспоминал тот период, поймал себя на мысли: если бы сегодня я снова начинал карьеру с нуля, профессия выглядела бы совсем иначе.

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

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

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

По данным CNCF, сегодня уже 82% компаний из числа пользователей контейнеров используют Kubernetes в production.

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

А теперь происходит ещё один переход — AI.

Сегодня инженер может за несколько минут получить скрипт, конфигурацию, Terraform-код, разбор лога или гипотезы о причине инцидента. По данным Stack Overflow, 84% разработчиков используют AI-инструменты или планируют это делать, а среди профессиональных разработчиков 51% работают с ними ежедневно.

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

AI может написать конфигурацию или предложить архитектуру. Но кто-то должен понять, подходит ли решение конкретной инфраструктуре, оценить его стоимость, безопасность и последствия. И в конечном счёте именно человек отвечает за production.

При этом 46% опрошенных Stack Overflow не доверяют точности ответов AI, тогда как доверяют 33%.

Получается парадокс: инструменты становятся мощнее, а хороший инженер — не менее, а более ценным.

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

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

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

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

AI внедряют все. А кто будет со всем этим работать?

В прошлом посте после Технопрома писал о главном наблюдении: AI постепенно перестаёт быть отдельной технологией и становится обычным инструментом внутри продукта.

Но чем больше об этом думаю, тем интереснее становится другой вопрос.

Если AI нужен всем — кто будет его внедрять, поддерживать и развивать?

Недавно наткнулся на исследование CompTIA, которое хорошо дополняет мои впечатления после Технопрома.

83% IT-руководителей и HR считают нехватку необходимых компетенций одним из приоритетов, а 62% ожидают увеличения бюджетов на обучение сотрудников работе с AI уже в следующем году.

И, кажется, здесь начинается следующий этап AI-трансформации.

✳️Купить AI — не значит внедрить AI

Сегодня получить доступ к модели несложно. Можно подключить готовый API, развернуть open-source модель или вообще построить собственную инфраструктуру.

Но дальше начинаются интересные вопросы:
➖кто определит сценарии использования?
➖кто интегрирует это в существующие процессы?
➖кто подготовит данные?
➖кто обеспечит безопасность?
➖кто будет следить за инфраструктурой и стоимостью эксплуатации?

И вот здесь AI из красивого пилота постепенно превращается в обычную инженерную задачу.

✳️Нужны не только AI-разработчики

В исследовании отдельно выделяют направления, в которых компании хотят развивать сотрудников: основы AI, работа с данными, автоматизация, безопасность AI-систем, создание AI-агентов.

Мне кажется, здесь важно не впасть в другую крайность.

Не обязательно превращать каждого инженера в ML-разработчика.

Гораздо полезнее научить существующие команды понимать, как работать с AI в своей зоне ответственности:
➖DevOps — учитывать особенности AI-инфраструктуры.
➖Разработчикам — понимать, где и как использовать модели внутри продукта.
➖Безопасникам — видеть новые риски.
➖Руководителям — хотя бы примерно понимать, во сколько всё это обходится:)

✳️Самое сложное — не обучение

Можно купить сотрудникам курсы, провести пару воркшопов и поставить галочку напротив «AI transformation».

А потом все возвращаются к своим старым процессам и ничего не меняется.

Мне как раз понравилась одна мысль из исследования: AI нужно встраивать непосредственно в рабочие процессы, а не оставлять отдельным экспериментом.

И с этим я согласен.

Если после обучения человек продолжает делать всё по-старому, значит, мы просто добавили ему ещё один курс в календарь.

А если AI действительно встроился в работу — меняется уже сам процесс.

➖➖➖➖➖➖➖➖➖➖➖

Получается интересная ситуация:

Ещё недавно главный вопрос бизнеса звучал примерно так ➡️ «Какую AI-модель нам выбрать?»

Сейчас он постепенно меняется ➡️ «Как встроить AI в компанию так, чтобы люди действительно им пользовались?»

А следующим, думаю, станет➡️ «Как сделать всё это управляемым, безопасным и экономически оправданным?»

И вот это уже точно не только задача AI:)

Китайский рынок изнутри: почему просто хорошего продукта недостаточно

Последние несколько постов я рассказывал про Китай с точки зрения технологий: цифровизация Шанхая, транспорт, WAIC и то, насколько быстро здесь внедряются новые решения.

Но есть еще одна сторона, которая мне особенно интересна как предпринимателю - как вообще работать с китайским рынком? Возможно ли это?

Чем больше я изучал материалы об этом, как там устроен бизнес, тем сильнее понимал: выйти в Китай с формулировкой: "у нас хороший зрелый продукт, сейчас найдем клиентов" получится вряд ли :)

Выделил для себя несколько особенностей.

1️⃣Без локального присутствия тяжело

Китайский рынок довольно закрытый. Привычные нам инструменты - Telegram, Google, привычные западные соцсети и сервисы (даже санкционные) - там либо не работают, либо практически бесполезны.

Вместо них своя экосистема: WeChat, WeCom, Alipay и десятки локальных платформ.

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

2️⃣Отношения здесь не менее важны, чем продукт

В B2B мы привыкли продавать через экспертизу, кейсы, рекомендации и понятную экономику проекта.

В Китае к этому добавляется еще один серьезный слой - доверие и личные связи.

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

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

3️⃣Конкурировать только ценой - сомнительная идея

Это, пожалуй, один из главных выводов для меня.

Китай сам является огромным производителем технологий и IT-решений. Здесь гигантский внутренний рынок, свои облачные провайдеры, разработчики и инженерные компании.

Поэтому прийти сюда с очередным предложением: мы сделаем дешевле - стратегия нерабочая.

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

4️⃣Китай - это отдельный рынок, а не еще одна страна в списке

Наверное, это лучше всего описывает мое впечатление.

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

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

Под него придется строить отдельную стратегию.

➡️ А что это значит для нас?

После этой поездки у меня точно не появилось мысли: Все, завтра Nixys выходит в Китай :)

Скорее наоборот.

Стало гораздо понятнее, насколько сложный это рынок и почему сначала нужно найти ответ на главный вопрос: что российская IT-компания вообще может предложить китайскому бизнесу такого, ради чего он выберет именно нас?

При этом рынок огромный, технологически очень зрелый и оттого еще более интересный.

На этом, пожалуй, я закончу небольшую серию постов про Китай 🇨🇳 Всем хорошего дня!)

Цифровизация Шанхая: транспортная инфраструктура. Сравнение с Россией

В прошлом посте я делился общими впечатлениями от Шанхая - про беспилотное метро, умные светофоры и экосистемы. Сегодня - глубже. Сравниваю транспортную инфраструктуру двух стран. Не в формате: у них лучше, у нас хуже, а как инженер - по фактам, цифрам и подходам.

Компаниям, кто занимается развитием данных систем, стоит задуматься, посмотрев на эти цифры.

Я разбил сравнение на три уровня: метро, такси и городская транспортная аналитика. В каждом - своя степень цифровизации.

1️⃣Метро: масштаб vs технологичность

Китай (Шанхай):

➡️Протяжённость линий: 831 км (21 линия, 523 станций)
➡️Беспилотное управление: полностью от 5 линий и выше(с 2014 года) - более точной информации нет в открытом доступе
➡️Интервал в час пик: 1,5-2 минуты
➡️Пассажиропоток: ~10-12 млн человек в день
➡️Система: полностью автоматизированная. Управление - из единого центра. Поезда сами корректируют интервалы в зависимости от загрузки.

Россия (Москва):

➡️ Протяжённость линий: ~560 км (15 линий, 275 станций)
➡️Беспилотное управление: 1 линия (Большая кольцевая, частично в тестовом режиме - с 2024 года)
➡️Интервал в час пик: ~2 минуты
➡️Пассажиропоток: ~8 млн человек в день
➡️Система: только начинает переход на беспилотный режим, находясь на этапе тестирования. Почти все поезда с машинистами.

Вывод: Шанхай строил метро в 2 раза быстрее и уже 10 лет назад сделал ставку на автоматизацию. Мы догоняем, но разрыв в масштабе - колоссальный. Это не про лучше или хуже, это про разный темп и обьемы инвестиций.

2️⃣Такси: интеграция с городскими данными

Китай (Шанхай) - Didi, Amap:

➡️Светофоры: 100% подключены к городской сети
➡️Данные: открыты через API для сервисов такси
➡️Функциональность: обратный отсчёт до смены сигнала на экране водителя; оптимизация маршрутов с учётом реальной загрузки перекрёстков; предсказание времени прибытия с точностью до минуты

Россия (Москва) - Яндекс Такси:

➡️ Светофоры: подключены точечно (Москва и несколько городов-миллионников)
➡️Данные: частично открыты, но не для всех сервисов
➡️Функциональность: есть информация о пробках, но нет синхронизации со светофорами в реальном времени

Вывод: У нас есть технологическая база (Яндекс это умеет). Но нет системного подхода на уровне города, региона или страны, когда инфраструктура и бизнес работают как единый организм. Все сильно разрознено.

3️⃣ Городская аналитика: данные решают всё

В Шанхае все данные с транспорта стекаются в единый городской центр управления.

Там:
➡️Мониторят загрузку всех линий метро в реальном времени
➡️Корректируют интервалы движения в зависимости от пассажиропотока
➡️Прогнозируют нагрузку на основе истории и событий (концерты, праздники)

В России: системы разрознены.

➡️Метро - своё
➡️Дороги - свои
➡️Такси - своё
➡️Единого центра управления городским транспортом, как такового - нет. Общение между департаментами управления транспортом до сих пор не выстроено в единый комплекс систем.

Вывод: это не проблема технологий. Это проблема архитектуры и инвестиций в инфраструктуру.

➖➖➖➖➖➖➖➖➖➖➖

Что это значит для нас, инженеров и руководителей:

1️⃣Технологии у нас есть. Мы умеем делать беспилотное метро, умные светофоры, интеграции. Но у нас нет системного подхода. Вопрос зрелости в управлении, осознания что это дает городской инфраструктуре, конечному потребителю.

2️⃣Разница - в инвестициях. Китай вкладывает в транспортную цифровизацию сильно больше, чем кто-либо ежегодно (это необходимость при количестве населения Китая). Мы - кратно меньше.

3️⃣Но есть и хорошая новость: догонять всегда проще, чем придумывать с нуля. Мы можем взять лучшие практики и адаптировать под свои реалии.

4️⃣Лично для меня: поездка в Шанхай - понимание, куда движется мир и насколько мы отстаём в системной интеграции. А отстаем мы сильно в этих вопросах, и компаниям, которые занимаются цифровизацией и цифровой трансформацией стоит задуматься, как ускорить развитие в данном направлении.

#цифровизация #шанхай #транспорт #метро #ит #сравнение

Как прошел DevOps Lab: ML in Production

В прошлую пятницу прошел первый митап из серии 🤩DevOps Lab. На нём мы разобрали, как ML-сервисы ведут себя в производственной среде. Выше записал вам небольшой тизер программы, а сегодня поделюсь своими наблюдениями в качестве организатора.

➡️Но сначала – важное. Спасибо каждому, кто пришёл, задавал вопросы, спорил, делился своим опытом и не расходился сразу после докладов.
Такие обсуждения превращают DevOps Lab из серии выступлений в профессиональное сообщество.

Ваш интерес и доверие мотивируют нас делать технические мероприятия в Сибири ещё сильнее. Оставил форму опроса для участников – здесь. Делитесь впечатлениями, всё учтём.

А пока, что успели обсудить:

🔴Как AI-агенты заменяют второго DevOps в компании из 50 человек
🔴LLM в проде на Kubernetes: KServe + Modelcar + OCI
🔴Интерактив по ML-инцидент менеджменту

Выводы от организатора:

1️⃣Инженеры в Сибири собираются от случая к случаю, в регионе особенно не хватает камерных мероприятий.

Как мне сказал один из пришедших гостей:

На безрыбье и рак рыба

Надо Будем этим пользоваться :)

2️⃣Аудитории определенно понравился митап, больше половины участников готовы прийти снова.
3️⃣Атмосфера – непринужденная, гости – довольные. Первое мероприятие из серии прошло успешно :)

➖➖➖➖➖➖➖➖➖➖➖

Что дальше?

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

P.S Уже через неделю мы поделимся материалами докладов, можно будет посмотреть их у меня и в @DevOps_FM

#devopslab #ИИ #агенты

LLM в проде на Kubernetes: как не сжечь бюджет на GPU

Всем привет! Продолжаем серию постов про DevOps Lab: ML Edition, который состоится уже на следующей неделе, 26 июня.

На повестке сегодня – второй анонс доклада. Актуальная тема для каждого, кто пробует запускать свои LLM. На митапе инженер Никсис Пётр Рукин разберет, как выстроить быстрый, надежный и безопасный инференс в Kubernetes.

Приватные LLM – must-have для бизнеса в 2026. Но при внедрении LLM в производство компании сталкиваются с рядом проблем:

• Модель весит десятки гигабайт
Загружать ее с диска при каждом старте нереально.
• GPU-ресурсы стоят дорого
Любой перерасход памяти приводит к росту затрат
• Холодный старт убивает UX
Пользователям приходится ждать запуска модели от 30 до 60 секунд
• Модели дублируются
Если модель нужна в десяти разных окружениях, она может быть скопирована 10 раз, что занимает место в хранилище.

На камерном митапе Пётр разберет:

1️⃣Особенности запуска приватной LLM в HA(High Availability)

Ответит на вопрос, почему стандартное развёртывание Kubernetes не подходит для LLM и покажет основные подводные камни построения HA-инфраструктуры.

2️⃣ KServer как специализированный control plane для ML-инференса

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

3️⃣Modelcar и OCI-артефакты: как ускорить загрузку модели

Расскажет, как упаковать модель в OCI-образ и загрузить ее через стандартные runtime контейнеров.

4️⃣Как избежать лишнего копирования моделей

Поделится тем, как один OCI-артефакт модели может обслуживать 10 разных деплойментов, не занимая лишнего места на диске.

5️⃣Оптимизация ресурсов: автоскейлинг, scale-to-zero, утилизация памяти

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

✔️После доклада вы будете знать:

• какую архитектуру выбрать для для запуска приватной LLM в Kubernetes
• какие инструменты реально работают
• как посчитать экономику от правильной настройки
• на какие грабли наступили мы, чтобы вы на них не наступили

А мы в Никсис завершаем подготовку к митапу. Присоединяйтесь, места ещё есть.

#devopslab #llm #kubernetes #kserve #ml

Как AI-агенты заменяют второго DevOps в компании из 50 человек

Перед тем как уйти на заслуженные выходные, поделюсь с вами кейсом от Collabo.

Продолжаю серию постов про DevOps Lab: ML Edition, который состоится 26 июня. Сегодня – анонс первого доклада. Тема близка многим руководителям и инженерам: как выживать, когда ты один DevOps на 50 разработчиков.

➡️Представьте, вы – DevOps-инженер. На вас 50 разработчиков, бесконечные алерты, тикеты, отчёты и менеджеры, которые просто хотят посмотреть, куда уходят деньги в облаках. Второго специалиста нанять нельзя, но руководство по-прежнему требует роста показателей. Вы горите, сроки горят.

Знакомая ситуация? В 2026 году она стала скорее правилом, чем исключением.

Евгений Дехтярёв, инженер Collabo, на DevOps Lab разберет:

1️⃣Почему один DevOps на 50 разработчиков - это системная проблема
Евгений не будет жаловаться. Он покажет, как справился с нерешаемой на первый взгляд задачей с помощью системы ИИ-агентов.

2️⃣Особенности Paperclip – open-source инструмента для команды ИИ-агентов
Что такое Paperclip, как он устроен и почему это не очередной чат-бот с доступом через API. А также ответит на вопрос, чем агенты отличаются от привычных LLM-обёрток.

3️⃣Как агенты забирают рутину

На реальных примерах:
• Ревью тикетов – агент сам определяет приоритет и тегирует задачу
• Разбор алертов – не просто пинг, а диагностика с выводами
• Кастомные отчёты – сбор данных по запросу

На реальных примерах Евгений покажет, как упаковать модель в OCI-образ и загрузить её через стандартные среды запуска контейнеров.

4️⃣Реальный кейс: агент видит инцидент в Slack затем диагностирует его и предлагает исправление
Полная цепочка: агент мониторит канал, распознаёт проблему (например, упала корзина товаров), проводит базовую диагностику, сообщает о причине и предлагает команду для исправления.

5️⃣Почему Евгений запретил агентам самостоятельно мержить изменения
Спикер честно расскажет, где агент чуть не положил прод и почему финальное решение остаётся за человеком. А также поделится защитными механизмами, которые он внедрил.

6️⃣Куда двигаться дальше: планы по автоматизации SRE, тестирования, обновлений, отчётов по облачным сервисам
В работу запущены автоматическое масштабирование тестовых стендов, еженедельные отчёты по бюджетам, автообновление Terraform-модулей.

✳️После доклада вы будете знать:
• как собрать свою команду AI-агентов на open-source инструментах
• какую рутину можно делегировать уже сейчас
• где безопасно поставить агента, а где - категорически нет
• сколько времени и нервов это реально экономит (на конкретных цифрах)

В следующих постах – анонс следующего доклада. Следите за обновлениями, чтобы не пропустить :)

#devopslab #ИИ #агенты #ml #автоматизация #paperclip

Приглашаю на DevOps Lab: ML in Production

Коллеги, всех с первыми летними рабочими днями! :)

Сегодня не будет разговоров о болях или чек-листов с выводами. Хочу обсудить с вами кое-что поинтереснее – камерное событие.

26 июня мы в 🤩 Никсис проводим DevOps Lab: ML Edition.

➡️Но вернемся в начало. Почему мы вообще решили пробовать делать DevOps Lab, зачем тратить на это время и ресурсы, и почему в этом году тема - ML.

Идея зародилась в далеком 2️⃣0️⃣2️⃣3️⃣ году, когда на нас стали сыпаться одни и те же вопросы заказчиков. Объединить их можно в один: Kubernetes, инфраструктура, процессы CI/CD и DevSecOps настроены, но как внедрить инновации, ML без потерь?

Ключевая проблема в 2026 для бизнеса – отсутствие практики. Про ИИ говорят много, но несистемно. В итоге у владельцев бизнеса нет понимания:

🔴как поднимать инфраструктуру для обучения моделей (нужна ли она)
🔴в чем сложность автоматизации пайплайнов для ML
🔴есть ли отличие тренинга от инференса и от чего зависит их стоимость
🔴что делать, когда GPU в дефиците

Мы с командой консультировали клиентов по отдельности и пришли к простой истине: очная встреча закроет все вопросы. Для этого нужно собрать людей в одном месте, дать 2–3 практических доклада от наших и внешних спикеров и предоставить возможность обсудить кейсы за чашечкой кофе.

Так появился первый в серии камерных встреч DevOps Lab: ML Edition, наша небольшая инвестиция в сообщество Новосибирска. Приходите, обсудим кейсы и все неудобные вопросы :)

➡️Регистрация для слушателей — здесь. Количество билетов ограничено.

P. S. В следующих постах поделюсь подробными анонсами докладов мероприятия.

#devopslab #ml #мероприятие #нетворкинг #никсис

7 маркеров, что ваш аутстаффинг работает не на вас

Сначала – важное. Коллеги, поздравляю вас с прошедшим Днём предпринимателя! Желаю, чтобы несмотря на любые изменения рынка, у нас оставались стабильные процессы, надёжные партнёры и пространство для роста.

➡️Итак, вы наняли инженера вне штата, оплачиваете его услуги по ставке опытного специалиста, а получаете проблемы, как от стажёра. Знакомо?

Мы в Никсис сами являемся подрядчиками в аутстаффе. За последние 5 лет через нашу компанию прошло больше 30 проектов с подключением DevOps-инженеров. И я собрал 7 маркеров, по которым видно, что аутстаффинг работает неправильно.

Проверьте себя. Если хотя бы 3️⃣ пункта совпали, проблема не в инженере, а в самой модели.

Чек-лист неэффективного аутстаффинга

1️⃣Тимлид тратит на специалиста более 2-х часов в день

Вместо того чтобы закрывать задачи, он объясняет, где лежит репозиторий, как зайти в Jira и почему мы не правим код в пятницу вечером.
Маркер: если это длится дольше 2 недель, возможны два сценария: подрядчик прислал специалиста не того уровня или не провёл онбординг.

2️⃣Инженер не знает контекста

Любая задача вне описанного ТЗ вгоняет его в ступор. Он не понимает, почему мы делаем так, а не иначе. Не может предложить альтернативу.
Маркер: инженер не интегрирован в команду, он просто исполнитель без нужной автономии.

3️⃣Результат есть – развития нет

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

4️⃣При замене инженера всё идет не так

Основной инженер ушёл в отпуск, взял больничный или уволился – и работа встала. Документации и контекста нет, связь с командой потеряна.
Маркер: у подрядчика не развит процесс замещения.

5️⃣Задачи формулируете вы, а не он

Инженер не проявляет инициативу. Не предлагает оптимизировать процессы для экономии ресурсов, внедрить улучшения.
Маркер: вопрос и к инженеру, и к тому, как выстроена коммуникация.

6️⃣Вы платите за присутствие, а не за результат

Инженер отсиживает часы, но конкретные фичи или улучшения не закрывает.
Маркер: модель оплаченного времени работает, только если есть понятный бэклог. Нет бэклога - нет смысла в аутстаффе.

7️⃣«Он не наш» – фраза, которая звучит слишком часто

Коллектив воспринимает инженера как чужого. На встречи не зовут, в обсуждениях не учитывают.
Маркер: если инженер не стал своим за 2-3 месяца, без внешнего вмешательства, он им не станет никогда.

Что делать, если вы собрали чек-лист?

⏺️Проверьте онбординг. Если его не было, сделайте принудительно.
⏺️Давайте обратную связь подрядчику. Не копите, говорите сразу, а лучше проводите ежеквартальные встречи.
⏺️Формируйте бэклог на месяц вперёд. Аутстафф без дорожной карты – это слив денег.
⏺️Просите замену через 2-3 недели. Если изменений нет, смените инженера или подрядчика.

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

#аутстаффинг #devops #управление #команда

Как мы превратили хаос в систему: выводы после 100+ проектов с поддержкой 24/7

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

В прошлый раз я описал две стороны медали:
✳️клиенты жалуются на долгие реакции и непонятные ответы
✳️подрядчики страдают от нехватки доступа и скрытого контекста.

Компания прошла через эти трудности в собственной практике. За 15 лет работы на рынке и при поддержке более 100 проектов мы выработали системный подход к решению проблем.

Выводы Никсис

1️⃣Прозрачность на старте решает половину проблем

Если клиент заранее знает:
• как мы работаем;
• какие у нас SLA;
• как мы отдаем внимание запросу (эскалируем) и решаем проблемы,

недопониманий и проблем с коммуникацией становится в разы меньше.

2️⃣ Документирование всего

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

Для последовательной работы мы внедрили разбор инцидентов (постмортемы) по каждому случаю уровня L2 и выше. В описании кратко указываем что случилось, почему, как исправили, как не допустить снова. База знаний растёт, повторяемость падает.

3️⃣ Регулярные ревью с клиентом

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

Что мы сделали:

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

4️⃣Эскалация как процесс

В Никсис выстроены 3 уровня поддержки:

• L1. Регистрация инцидентов, оперативное реагирование в течение 15 минут
• L2. Подключение инженера с графиком 5/2 в тандеме вашего проекта или самого ответственного инженера
• L3. Подключение к инциденту инженеров смежных отделов более высокого уровня при необходимости.

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

➡️Мы 15 лет учились делать это правильно, а сегодня я поделился выводами нашего ИТ-интегратора с вами. Коллеги, расскажите о своих принципах в комментариях.

#круглосуточнаяподдержка #техподдержка #сервис