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

WAIC 2026: как Китай превращает AI в современную инфраструктуру В прошлых постах я рассказывал о транспортной цифровизации Шанхая. Сегодня - про то, ради чего, собственно, многие представители инженерии/ИТ едут в этот город в июле. Я не попал на неё в этот раз (не совпало с визитом), но я следил за новостями и материалами - и, масштаб происходящего впечатляет. Это не просто ещё одна конференция. Это срез того, куда движется мир AI в ближайшие 3–5 лет. Цифры конференции: более 140 сессий, 300+ мировых продуктов, 1100+ компаний-экспонентов, представители из более чем 100 стран. Для сравнения: масштаб, которого у нас в России пока нет ни на одной профильной конференции. Но самое важное в этом - не масштаб, а содержание. WAIC 2026 чётко показала три тренда, которые меняют рынок AI. Я рассмотрю их с инженерной и бизнесовой точек зрения. 1️⃣Эволюция AI-инфраструктуры Ещё пару лет назад главный вопрос на AI-конференциях был: Сколько у вас GPU? В 2026 он сменился на: Как вы считаете эффективность использования этих GPU? WAIC 2026 показала: AI-инфраструктура больше не про количество карт. Она про: ➡️Связность и масштабирование ➡️Энергоэффективность ➡️Программный стек Перевод на язык DevOps: конкурентное преимущество смещается от наличия железа к мы умеем это железо эффективно использовать. И это прямая зона ответственности DevOps/SRE-инженеров, которые строят инфраструктуру для ML. В России таких специалистов - единицы. 2️⃣AI-агенты перестали быть тестом. Теперь это рабочий инструмент Главное слово WAIC 2026 - не модель, как раньще, а агент. В 2026 году агенты: ➡️Назначаются на задачи и могут работать автономно (разбивать цели на шаги, вызывать API, принимать решения) ➡️Встраиваются в операционные системы смартфонов и корпоративных приложений ➡️Начинают существовать в цифровых городах - инфраструктуре, специально созданной для них крупными облачными провайдерами По сути, WAIC показала: агенты становятся цифровыми сотрудниками. Они не отвечают на вопросы, а делают работу. Что это значит для нас: если вы до сих пор не внедряете AI-агентов в свои процессы (ревью кода, мониторинг, DevOps-рутина) - вы уже отстаёте. И отставание будет только расти. 3️⃣ Экономика AI: от тестирования к окупаемости На WAIC 2026 звучало слово, которое раньше на таких конференциях было не в почёте - ROI. Более подробно я писал об этом в одном из прошлых постов. Аналитики на сессиях приводили цифры: в 2026 году около трети крупных компаний всё ещё не вышли в плюс от AI-инвестиций. Более 40% AI-проектов в бизнесе замораживаются в первый год. И конференция, по сути, была посвящена ответу на вопрос: Как сделать AI-инвестиции прибыльными? Ответы в WAIC 2026: ➡️Переходить от экспериментов к системным внедрениям (не просто поставить модель, а перестроить под AI целый бизнес-процесс под ключ) ➡️Считать эффективность инфраструктуры - не количество GPU, а стоимость одного инференса и время от идеи до релиза ➡️Активно внедрять практику Agent Economy - когда AI-агенты автоматизируют рутину и снижают нагрузку на людей, вместо того чтобы просто отвечать на запросы ➖➖➖➖➖➖➖➖➖➖➖ WAIC 2026 - это не просто выставка. Это демонстрация новой реальности AI-рынка: 1️⃣AI перестаёт быть наукой и становится инженерией. В фокусе - не модели, а системы, которые можно строить, масштабировать и считать. 2️⃣Профессия DevOps/SRE для ML - становится критически востребованной. Компании, которые умеют строить эффективную инфраструктуру и внедрять агентов в пайплайны, получают конкурентное преимущество. 3️⃣Российский рынок - пока сильно позади. У нас нет WAIC-масштаба, нет сотен выставок и тысяч компаний. Но именно поэтому - это возможность. Мы можем брать лучшие практики и адаптировать их. 4️⃣ИИ-агенты - это не будущее, это уже настоящее. И если вы ещё не задумываетесь, как агенты могут автоматизировать часть работы вашей команды (DevOps-рутина, мониторинг, тикеты, отчёты) - пора задуматься.

Цифровизация Шанхая: транспортная инфраструктура. Сравнение с Россией В прошлом посте я делился общими впечатлениями от Шанхая - про беспилотное метро, умные светофоры и экосистемы. Сегодня - глубже. Сравниваю транспортную инфраструктуру двух стран. Не в формате: у них лучше, у нас хуже, а как инженер - по фактам, цифрам и подходам. Компаниям, кто занимается развитием данных систем, стоит задуматься, посмотрев на эти цифры. Я разбил сравнение на три уровня: метро, такси и городская транспортная аналитика. В каждом - своя степень цифровизации. 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️⃣Лично для меня: поездка в Шанхай - понимание, куда движется мир и насколько мы отстаём в системной интеграции. А отстаем мы сильно в этих вопросах, и компаниям, которые занимаются цифровизацией и цифровой трансформацией стоит задуматься, как ускорить развитие в данном направлении. #цифровизация #шанхай #транспорт #метро #ит #сравнение

Цифровизация Шанхая глазами ИТ-инженера из Сибири В начале июля я улетел в Шанхай. Не в командировку, а в отпуск. Но, как любой технический руководитель, я всё равно обратил внимание на то, как устроены городские цифровые сервисы и ИТ-инфраструктура. До поездки ожидал увидеть просто большой мегаполис. Но Шанхай оказался городом, где цифровые технологии стали частью повседневной жизни. Уровень внедрения, к которому мы в России пока только движемся. Ближе всех к конечной точке – Москва 🙂 И, конечно, не могу не поделиться с вами впечатлениями. Сегодня – общий обзор того, что бросилось в глаза. В следующих постах подробнее расскажу про транспорт, конференцию WAIC и другие особенности инфраструктуры города. 1️⃣Беспилотное метро – не фантастика, а реальность 2026 В Шанхае поезда метро с 2014 г. работают без машинистов. Транспорт приходит каждые 1-2 минуты в час пик. Автоматическая система управляет интервалами, скоростью и остановками. Как инженер, меня впечатлил уровень надёжности автономной системы. За таким решением стоят годы эксплуатации и отладки. Как пассажир, я просто наслаждался поездками. Никаких задержек, никакого человеческого фактора. ➡️В Москве тоже запустили беспилотное метро, но Шанхай впечатляет именно масштабом внедрения. Управление транспортом в Китае вышло за рамки эксперимента и стало повседневной практикой и стандартом. 2️⃣Такси, которое знает, когда загорится зелёный Сел в такси через Didi, аналог нашего Яндекса, а на экране отобразлась карта с обратным отсчётом до смены сигнала каждого светофора. Показатели точные и без задержек. На каждом светофоре приложение синхронизируется с городской системой управления трафиком. Для пассажира это просто удобная функция. А как инженер я сразу обратил внимание на интеграцию сервисов в единую цифровую экосистему. Это пример Industrial IoT, управления с умными датчиками и контроллерами. Примечательно, что данные со светофоров открыты для сервисов через API. ➡️В России подобные технологии применяются точечно. Например, отдельные элементы уже можно увидеть в Яндекс Картах, но не на уровне синхронизации с каждым светофором в реальном времени. 3️⃣Amap и Didi – экосистема, а не просто карты Alibaba (Amap) и Tencent (Didi) – платформы, в которые встроено всё: навигация, такси, общественный транспорт, оплата и даже доставка еды. Сервисы в одном интерфейсе, работа без задержек с полным пониманием контекста пользователя. ✳️Важно, что люди действительно пользуются этими сервисами каждый день. Уровень проникновения цифровых сервисов в Шанхае ~ 95%. Неудивительно, что город называют одной из мировых столиц цифровизации Азии. В России интегрированы похожие экосистемы от Яндекс и Сбера, но раздробленность функционала приложений выше. И уровень интеграции с городскими данными сильно ниже. Есть куда расти и что развивать. P.S У меня Т-Банк, ТОП-1 по использованию цифровых решений, открывается дольше, чем я успеваю оплатить покупку через AliPay 😁 4️⃣WAIC 2026 – недостижимый уровень 17-20 июля в Шанхае прошла конференция по искусственному интеллекту WAIC (World Artificial Intelligence Conference). Я не был на ней в этот раз, но следил за новостями. Правительство Китая вкладывает миллиарды в развитие ИИ-инфраструктуры. Масштаб инвестиций ощущается даже в городской среде: камеры, сенсоры, IoT, управление трафиком, общественная безопасность. А ежедневные новости на локальных каналах – только о гуманоидах и областях их применения. ➖➖➖➖➖➖➖➖➖➖➖ После поездки окончательно убедился в том, что Шанхай – это живой пример того, как цифровизация становится базовой составляющей города. В России движение в эту сторону тоже есть. Но пока оно развивается в отдельных городах и проектах. Сильные инженеры, интересные команды и качественные технологические решения формируют наш потенциал. Вопрос лишь в масштабе, инвестициях и мышлении. А как вы оцениваете уровень цифровизации в своём городе? Какие решения уже стали привычными, а каких технологий, на ваш взгляд, пока не хватает? #цифровизация #китай #ит #iot #waic

Материалы DevOps Lab: ML Edition уже доступны В конце июня мы провели первый 🤩DevOps Lab: ML Edition в Новосибирске. Собрали инженеров, техлидов и всех, кому интересно, как ML-сервисы живут в реальной производственной среде. Не устану благодарить всех, кто слушал доклады вживую. Ваши вопросы, споры и живое обсуждение превратили встречу из очередного митапа во встречу настоящего профессионального сообщества. Мы это ценим. Обещали поделиться с вами материалами – и держим слово. Все доклады уже доступны на Rutube, VK Video и YouTube: 1️⃣LLM в проде на Kubernetes: KServe + Modelcar + OCI Про особенности запуска приватных LLM в HA, работу с OCI-артефактами, ускорение загрузки моделей и экономию ресурсов на GPU. 😉 Youtube 🥰 Rutube 😄 VK 2️⃣Как AI-агенты заменяют второго DevOps в компании из 50 человек Про Paperclip, автоматизацию рутины, разбор алертов и почему автор до сих пор не разрешает агентам мержить изменения. 😉 Youtube 🥰 Rutube 😄 VK ➡️Что дальше? Следующий митап DevOps Lab: AI Edition планируем провести поздней осенью. Тема – ИИ-агенты. Программа – продолжение второго доклада, но с упором на практику использования в командной работе. Также расскажем об агентах собственной разработки. P.S. А пока делитесь впечатлениями от просмотра, задавайте вопросы. Будем рады вашей обратной связи в комментариях к записям :) #devopslab #ml #никсис

Как прошел 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 лет учились делать это правильно, а сегодня я поделился выводами нашего ИТ-интегратора с вами. Коллеги, расскажите о своих принципах в комментариях. #круглосуточнаяподдержка #техподдержка #сервис

Особенности техподдержки 24/7: проблемы клиентов и взгляд изнутри В этом месяце хочу поделиться болями внешних подрядчиков (аутсорса). Но не всех сразу, а только тех, кто обеспечивает заказчиков поддержкой 24/7. Мы в Никсис как раз специализируемся на этом уже более 15 лет. ✔️За 2025 и первую половину 2026 года через нашу поддержку прошло более 100 заказчиков. Запросы разнообразны, от «помогите развернуть проект» до «упал сайт в 3 часа ночи». За это время накопился целый комплекс проблем, как со стороны клиентов, так и с нашей стороны как подрядчика. Ниже делюсь наблюдениями. Начну с клиентских болей. Их видно сразу, всё на поверхности. Чего боятся и на что жалуются клиенты: 🔴Нас не слышат. Клиент описывает проблему своими словами, а инженер отвечает шаблонно, ещё и переспрашивает одно и то же. Специалисты поддержки первого уровня, L1, узнают детали задачи, а уже потом делегируют. Во время расспросов растёт раздражение, ресурсы простаивают ровно до тех пор, пока проблема не будет передана на следующий уровень, L2. 🔴Инженеры долго реагируют. Особенно это критично в ночное время, а также в выходные и праздничные дни. Для клиента реакция на инциденты (SLA) за 15/30 минут – это время простоя бизнеса. А подрядчику необходимо оперативно включиться в работу в 2 часа ночи на проекте, на который инженер не заходил больше месяца. И это ещё без учёта графика дежурных смен 2/2 или 3/3 по местному часовому поясу. Скорость реакции – приоритет подрядчика. 🔴Ничего не понятно. Клиент получает разъяснения на техническом языке: поправили ingress controller, рестартанули поды, очистили кэш Redis. А ему нужно простое: починили, работает. Разговор ведется на разных языках, время идёт, замешательство растёт. 🔴Одни и те же проблемы по кругу. Клиентский день сурка – одни и те же сложности раз в неделю, и никто не ищет причину возникновения. Причина кроется в системном сбое работы команды или инженера. ➖➖➖➖➖➖➖➖➖➖➖ А теперь взгляд изнутри – проблемы подрядчика: Клиенты об этом редко задумываются, но они есть. ⏺️Инженер не может воспроизвести проблему, клиент в это время пишет: «всё упало». Специалист заходит и подтверждает проверочными командами, что всё работает. Клиент нервничает, инженер в ступоре, так как не может найти причину сбоя. А проблема оказалась разовой, и локализовать её можно только в логах приложения или инфраструктуры. ⏺️Нет доступа к критичным внешним контурам и системам. Клиент требователен к безопасности, не выдает доступ во внешние контуры, зависимые от проекта. В итоге, инженер не может зайти на проблемный участок, оценить масштаб и тратит больше времени на поиск решений. Появляются проблемы в разделении зон ответственности в контурах между заказчиком и подрядчиком. ⏺️Нехватка необходимой информации. Клиент пишет в поддержку: «срочно, всё горит!». А сам не отвечает на уточняющие вопросы по ~2 часа. Пока инженер ждёт подробностей, нужных для решения задачи, он теряет время и деньги клиента. ⏺️Проблемы в коммуникации при синхронизации работ. Например, клиент не рассказывает, что неделю назад штатные сотрудники или другой подрядчик перенастраивали сеть в контуре или что за день до инцидента обновляли ядро ОС на группе серверов. Инженер тратит время, не зная отправной точки, и без данных от заказчика. ➡️Что в итоге? Идеальной поддержки 24/7 не существует. Это всегда компромисс между скоростью, качеством и стоимостью с учетом проблемы в эксплуатации с обеих сторон. Каждая из сторон должна понимать это и учитывать в работе. Коллеги-подрядчики, какие проблемы в работе возникают у вас? Делитесь историями в комментариях 🙂 #никсис #техподдержка #сервис

Неутешительные цифры 2025 В прошлом посте я делился тем, что мы запланировали полномасштабный редизайн нашего сайта в 2026, чтобы повысить текущие показатели конверсии и не потерять потенциальных заказчиков. О техническом оснащении мы уже поговорили, сегодня обсудим рынок, на который не влияет малый бизнес. Первый квартал 2026 закрыт, отчетность за 2025 сдана в ФНС, данные опубликованы в публичных источниках (rusprofile.ru, audit-it.ru). Посмотрим на показатели. Для анализа я взял топ-3 ИТ-игроков по стране: 🔴КРОК Выручка: ~33 млрд. руб (рост 2%) Чистая прибыль: 277 млн руб (снижение на 56.8%) 🔴Ланит Выручка: 9.4 млрд. руб (снижение на 33%) Чистая прибыль: 17.4 млн. руб (снижение на 63.6%) 🔴 Softline Выручка: 131.92 млрд. руб (рост 9%) Чистая прибыль: 13.7 млн. руб (снижение на 90% и выше) Итак, у всех 3-х компаний наблюдается снижение чистой прибыли на 100% в значимом процентном соотношении и у 2/3 игроков виден небольшой рост общей выручки. ➡️Рынок сжимается уже второй год подряд. Причины следующие: • Дорогие деньги. Кредиты недоступны для развития, инвестиции заморожены, проекты откладываются или идут с минимальным бюджетом. • Оптимизация бизнес-процессов. Компании сжимаются, убирают всё, без чего можно прожить. ИТ-услуги, которые не дают быстрого роста коэффициента рентабельности (ROI), попадают под оптимизацию в первую очередь. • Автоматизация при помощи ИИ. Да, учитываем и этот фактор. Задачи, которые раньше требовали команды из 5 человек, сейчас решает 1 человек с языковой моделью (LLM). Спрос на прикладные задачи в ИТ падает. Казалось бы, зачем эти данные нам, малому и среднему бизнесу? Всё просто, крупные игроки – маркеры состояния всего рынка. Если у корпораций падает прибыль, дело в изменении поведенческих привычек клиентов. Заказчики платят меньше, откладывают проекты, уходят в экономию и стагнацию. Что делать небольшим ИТ-компаниям? 1️⃣Бороться за каждого клиента. Рынок не растёт, значит компании развиваются за счет улучшения работы и сервиса, точечного «перетягивания» доли у конкурентов. 2️⃣Ставить на эффективность и практичность. В текущих условиях выигрывает тот, кто умеет решать задачи бизнеса дешевле, быстрее или с большей ценностью для клиента. 3️⃣Искать ниши, где ещё есть рост. Да, рынок падает, но в нём можно найти сегменты, которые продолжают расти: импортозамещение, ИБ, ИИ-интеграция. Рассматривайте эти направления. 4️⃣Быть готовым к долгой дистанции. В условиях кризиса 2024-2025 переждать пару месяцев не получится. Мы живем в новой реальности, к ней необходимо адаптироваться. Цифры, конечно, невесёлые. Но лично для меня, повода для паники нет, если скорректировать планы. Никсис не ждёт волшебных изменений рынка. Мы готовимся к ужесточению конкуренции, сокращению бюджетов и перестраиваем стратегию, чтобы оставаться полезными для своих заказчиков в текущих условиях. А вы смотрели отчётности своих контрагентов или сферы? Делитесь наблюдениями в комментариях. Интересно собрать картину из разных сегментов ИТ-рынка. #отчет2025 #мсб #руководитель

Как управленцу сохранять себя, когда внешние обстоятельства давят Всем привет! В прошлом посте я анонсировал редизайн сайта, поделился текущей ситуацией и прогнозами. Сегодня поговорим про то, как выстраивать рабочие процессы, когда жизнь начинает давать трещины. Я обещал делиться не только успехами, но и реальными ситуациями за кадром. И сейчас – тот самый случай. Если коротко, последние недели выдались непростыми. Смешалось всё: обстоятельства, на которые я не могу повлиять, работа, личная жизнь. Знакомо? Я не психолог, но за годы управления выработал несколько правил, которые помогают не развалиться на части и продолжать работать. ТОП-5 принципов, которые помогают поддерживать опору в условиях турбулентности 1️⃣Разделять внешнее и внутреннее Самый сложный и важный навык. Когда работаешь с операционкой или проводишь встречу с клиентом управленец должен находиться в моменте, влиять на решения здесь и сейчас. Не в переживаниях о том, что случится завтра или что уже случилось вчера. В теории звучит легко, на практике не всегда получается. Для быстрого переключения разделяю зоны ответственности на: ⁃ Бизнес/рабочие задачи ⁃ Решение личных проблем Пересечений быть не должно, иначе рискуете проиграть и тут, и там. 2️⃣Принять, что контроль – иллюзия Как управленец, вы наверняка привыкли всё контролировать: план, бюджет, команда, результат. Но в условиях турбулентности этот принцип просто не работает. Процессы, которые зависели от вас на 100%, вдруг привязаны к внешним обстоятельствам. Рекомендую перестать бороться с неизбежным и сфокусироваться на вашей зоне влияния. Это снижает тревожность в разы. 3️⃣ Создать якоря для заземления В условиях неопределенности нужны собственные внутренние точки опоры. Для меня это: • контрастный душ каждое утро, практикую уже почти 2 года • 30 минут без телефона утром, пока приводишь мысли в порядок • спорт, тренировка раз в 2 дня, даже если голова занята совсем не тем 4️⃣Найти того, с кем можно быть слабым Раньше я думал, что управленец должен быть непоколебимым и стойким, несмотря на проблемы и сложности. Но несгибаемых нет – это путь в выгорание и проблемы с нервами. У меня есть 1-2 человека, которым я могу сказать: мне сейчас тяжело, я не знаю, что будет. Просто выговориться и не держать в себе, не ожидая советов или решений. 5️⃣И это пройдет На первый взгляд звучит как отговорка. Каждый год приносит перемены, тревожность, переживания, но из раза в раз сложные периоды заканчиваются. Компания растет и развивается, клиенты приходят, и команда сплочается. А проблемы… они решаются или вовсе перестают представлять угрозу. Главное об этом помнить. Как вы оптимизируете работу, когда внешние обстоятельства давят на бизнес и личную жизнь? #турбулентность #управленец #бизнес #кризис #личное

Так ли сильно сайт влияет на конверсию в B2B? Всем привет! Пропал аж на 2 недели — жизнью придавило, как говорится :) Сегодня возвращаюсь к еженедельным постам, и в этом поделюсь полезными деталями одной из внутренних целей нашей компании в 2026 — редизайн основного сайта nixys.ru. Поговорим о необходимости редизайна, метриках до/после, потенциальном выхлопе, даже в условиях кризиса. Обещал делиться новостями и полезными кейсами компании по ту сторону кулис. Держу слово. ✳️Необходимость редизайна сайта назрела уже давно, но всегда находились задачи важнее. Началось все в 2023 году, когда в компании появился полноценный брендбук, который задал планку в дизайне и стилистике всей компании. Изменения прошли повсеместно, а в 2026 добрались и до сайта. Почему именно сейчас? Если коротко — старый сайт перестал работать, как инструмент продаж. При растущем рынке, который наблюдался в РФ с 2021 года по весну 2024, достаточно было и прежней версии, которая конвертила так, что мы не успевали расширять «закулисную» часть производства — инженерный состав. Сейчас ситуация в корне изменилась: узкое горлышко — нехватка входящих лидов, вследствие разных внешних и внутренних факторов. Но если на внешние мы повлиять не в силах, то на внутренние — легко. На какие метрики мы ориентируемся, выполняя редизайн? 🔴Количественные метрики ДО: • CTR (Click Through Rate) — насколько объявление цепляет аудиторию: 0,25% • CPL (Cost Per Lead) — стоимость привлечения лида: 9000 руб. • Органический трафик: 100% (относительные значения на 01.04.2026) 🔴Качественные метрики ДО: • CSI (Customer Satistaction Index) по навигации — пользователи находили нужную функцию за 2 клика и более 10 секунд • Time to Value (TTV) — время, за которое пользователь понимал, чем мы занимаемся: > 15 секунд • Количество сценариев поведения на сайте: 1-3 • Соответствие брендбуку: 10-15% ➖➖➖➖➖➖➖➖➖➖➖ 🟢Количественные метрики ПОСЛЕ: • CTR: 1,50% (рост в 6 раз) • CPL: 6000 руб. (снижение на 33%) • Органический трафик: 125-150% вместо 100% 🟢Качественные метрики ПОСЛЕ: • CSI по навигации: 80% пользователей находят нужную функцию за 2 клика и менее 10 секунд • TIme to Value (TTV): <5 секунд (вместо >15) • Количество сценариев воронок: 5+ ключевых для клиента • Соответствие брендбуку: 100% Цель редизайна сайта в B2B сводится не к красоте, а к достижению измеримых бизнес-метрик и повышению эффективности инструмента продаж. Что мы ожидаем получить после запуска новой версии: 1️⃣Снижение стоимости лида — CPL должен снизиться на треть за счет попадания в ЦА и повышенного доверия на старте. 2️⃣Больше органического трафика – поисковики любят удобные и современные сайты, а пользователи — понятную структуру. 3️⃣Повышение конверсии на каждом этапе — когда посетитель понимает, кто мы и чем можем быть полезны за 5 секунд, с большей вероятностью он оставит заявку. 4️⃣Снижение нагрузки на продажи — клиенты сами находят ответы на нужные вопросы. 5️⃣Единый стиль — сайт и главная посадочная страница компании начинает работать на узнаваемость бренда. Что дальше? Макет уже в работе, как только запустим, сделаю отдельный пост с разбором по полученным метрикам, сошлись ли цели с реальностью. Ждите апдейт в середине/конце лета 2026. Готовы поделиться текущими метриками сложной B2B-услуги вашего бизнеса в комментариях? #редизайн #b2b #сайт #метрики #никсис

Есть ли альтернативы мессенджеру Telegram для корпоративной коммуникации? Весна 2026 года в самом разгаре, как и новости о том, что Telegram может прекратить работу на территории РФ с 1 апреля 2026 года из-за невыполнения части требований Роскомнадзора. 🔴Какие требования РКН предъявляет к мессенджеру? • удалить противоправные материалы; • соблюдать законодательство РФ; • удалить рекламу; • модерировать контент. ✔️Чем это грозит нам, обычным пользователям? Несмотря на удобство мессенджера, мы вынуждены искать альтернативу Telegram, а при выборе учитывать функциональность, технические возможности и удобство интерфейса сервисов. Чему отдают предпочтение компании? В НИКСИС | NIXYS более 150 активных клиентов. В марте мы провели опрос среди большинства из них — активных пользователей Telegram. Из выборки исключили ряд средних и крупных компаний, у которых не стоял вопрос выбора корпоративного мессенджера. По итогам мы собрали обратную связь и составили список возможных альтернатив. Какие мессенджеры предпочитают? • Telegram — 50%; • MAX — 24%; • Битрикс24 — 16%; • Signal | Яндекс.Мессенджер | Mattermost — 8%; • VK — 0,5%. Оставшиеся 1,5% — малоизвестные платформы. О чём это говорит? 1️⃣Большой процент компаний до сих пор использует Telegram, несмотря на предупреждения РКН о блокировке. Даже в условиях ограничений компании готовы перевести деловое общение на другую площадку только в случае, если мессенджер станет недоступен. 2️⃣Почти 25% заказчиков рассматривают MAX как рабочую альтернативу, несмотря на активную доработку платформы. 3️⃣Битрикс24 остаётся одним из самых надёжных on-prem решений для малого и среднего бизнеса, но требует значительных трудозатрат на освоение как со стороны представителей компании, так и со стороны сотрудников. Надеюсь, результаты опроса помогут вам сориентироваться в доступных альтернативах Telegram для корпоративной коммуникации среди ИТ-компаний, интеграторов и диджитал-агентств, и вы подберёте оптимальное решение для вашего бизнеса. Какой мессенджер предпочитаете вы, даже с учётом блокировки Telegram? P.S. Мы в НИКСИС | NIXYS подходим к выбору мессенджера с позиции клиентоориентированности и без нарушения законодательства. #блокировка #ркн #telegram #мессенджер

Инфраструктура для ML: от пилота до продакшена Хорошего вторника и продуктивной рабочей недели всем! А в этом посте я поделюсь, чем запомнились мои будни. 18 марта в Новосибирск приезжал Selectel с ML-туром по регионам. Спикером мероприятия был Владислав Кирпинский, директор облачной интеграции в Selectel. Конечно, я не мог не посетить мероприятие :) ✔️Чем интересным делился Владислав? • какие тренды и вызовы в ML существуют • в чем разница между тренингом и инференсом • как инференс превращает модели в деньги • иерархия инфраструктурных продуктов для запуска AI: от серверов с GPU до Inference-платформ На чем хочется остановиться детальнее? В начале встречи Владислав поделился аналитикой рынка ML от Selectel. Меня сильно удивил процент внедрения ML в российских бизнесах. По состоянию на март 2026 только ~5% российских компаний применяют у себя ML решения для оптимизации бизнес-процессов. 5% — это невероятно мало, с учетом развития рынка ML в России более 2 лет. ➡️Основная причина, со слов экспертов из Selectel, — это непонимание оцифрованной цели и метрик эффективности при внедрении ML конечным заказчиком. Иными словами – проблема в целеполагании как со стороны заказчика, так и большинства ML-интеграторов. По этой причине 88% пилотов ML проваливаются, не доходят до окончания стадии тестирования, чтобы оценить эффективность от его внедрения. Какие выводы можно сделать, исходя из этих цифр? 1️⃣Главная проблема — не технологии, а планирование. Нужно четко отвечать самому себе на вопрос: какую бизнес-задачу мы решаем и как измерить результат? 2️⃣Пилот должен быть пилотом. 88% провалов на стадии тестирования — это ошибка формата. Проект должен иметь сроки, бюджет, метрики и критерии принятия решений. 3️⃣ML — это в первую очередь инструмент, и как любой инструмент, он эффективен только когда есть понимание цели его применения. P.S.: а кому интересно, как посчитать ROI от внедрения ML, то на прошлой неделе я записал подкаст «За кулисами DevOps — как ИИ меняет бизнес-процессы», слушаем, включаемся! #машинное_обучение #нетворкинг

Build-ферма для геймдева: когда облако дороже железа и как это просчитать Друзья, всем привет!) 14 марта мой коллега, технический руководитель НИКСИС | NIXYS Петр Рукин выступил на Gamedev Cityfest 2026 с темой, которая и по сей день волнует многих в геймдеве: облако или своё железо для сборки проектов? Тема родилась не случайно. За прошлый год к нам пришло небольшое количество запросов от геймдев-студий с одной и той же болью: как выбрать между облаком и on-prem. Петр разобрал эту дилемму на реальных цифрах и кейсах. Делюсь ключевыми выводами. 🔴Облако vs железо: считаем TCO правильно Главная ошибка — сравнивать цену аренды облачных мощностей с ценой покупки сервера. Что забывают учесть в облаке: • Стоимость хранения артефактов сборки • Исходящий трафик • API-запросы к облачным сервисам • Прерываемые или спот инстансы Что забывают учесть в своем железе: • Простои мощностей • Стоимость ФОТа за сопровождение железок • ЭЭ и охлаждение • Амортизацию и замену оборудования 🔴Когда облако становится дороже своего железа В докладе у Петра приведен конкретный пример просчета для небольшой геймдев-студии: • 50 разработчиков, digital • 5-10 полных сборок • Ночные сборки • Пиковые нагрузки перед релизами Облачная модель (с учетом ФОТа, ЭЭ, сеть): • Ежемесячная стоимость: 575 000р/мес • Годовые траты: 6 900 000р/год On-prem модель (с учетом тех же статей расхода): • OPEX: 462 000р/мес • CAPEX: 5 555 000р/год Вывод: если вы тратите на облачные сборки близко к OPEX on-prem модели, смотрите в сторону своего железа или гибрида. 🔴Гибридная модель — золотая середина 2026 Самый интересный кейс из доклада Петра — гибридная build-ферма. Как это работает: • Постоянные мощности под ежедневные задачи • Dev-сборки, ночные билды • Хранение артефактов и кеша Облачный burst-контур: • Подключается только в пики (перед релизами) • Нагрузочное тестирование • Сборки под нестандартные платформы • Задачи с неравномерной нагрузкой ✔️Чек-лист для принятия решения: Если ваша геймдев-студия сейчас выбирает между облаком и железом, пройдитесь мысленно по следующим пунктам: • Посчитайте текущие облачные расходы за 12 месяцев • Оцените динамику роста (команда, количество сборок, количество проектов) • Замерьте пиковые периоды (дни релизов) • Посчитайте TCO своего железа с учетом всех скрытых расходов • Сравните сценарии на горизонте 3-х лет • Рассмотрите гибридную модель, как компромисс Выводы: 1️⃣Облако не всегда дороже. Для небольших команд и стартапов это идеальный старт — не надо думать о железе, дешевый выход из этой истории если не взлетело. 2️⃣ Железо не всегда дешевле. Оно окупается только при определенном масштабе и стабильной нагрузке. 3️⃣Гибрид — тренд 2026 в том числе и при проектировании обычной инфраструктуры. Компании используют облако для гибкости, а свое железо — для экономии при базовой нагрузке. 4️⃣Считать нужно только на своих данных. Универсальных цифр не существует — только ваш конкретный расчет. Всем правильного TCO и оптимизации расходов! P.S.: запись выступления выложим позже на каналы компании НИКСИС | NIXYS, подписывайтесь!