⚡️ Ловушка самодельных платформ

Многие IT-руководители считают, что их внутренняя инфраструктура уникальна, и поэтому единственно верный путь — заняться Platform Engineering своими силами с нуля.

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

Проблемы самодельных платформ:

⚪️ Обслуживание франкенштейна. Платформа, собранная из множества скриптов, open-source инструментов и связок, требует постоянных обновлений, исправления багов и адаптации. Со временем команда инженеров платформы тратит 100% своего времени просто на то, чтобы поддерживать систему «на плаву», вместо того чтобы развивать её.

⚪️ Выгорание команды. Инженеры платформы оказываются заложниками ситуации. Они перегружены рутиной, а разработчики (внутренние клиенты) постоянно недовольны качеством, багами и сложным интерфейсом платформы. Это приводит к сильному выгоранию сотрудников и высокой текучести кадров.

⚪️ Иллюзия уникальности. Компании часто переоценивают уникальность своих процессов. На самом деле около 80% потребностей в оркестрации, деплое и управлении инфраструктурой стандартны для большинства. И куда быстрее закрыть эти потребности готовыми инструментами.

К созданию IDP стоит подходить с точки зрения продуктового менеджмента и учитывать главные моменты:

⚪️ Платформа должна приносить ценность конечным пользователям, делать их жизнь проще, а деплой — быстрее.

⚪️ Если платформа неудобна, разработчики будут искать обходные пути, разрушать безопасность и стандарты компании.

Какое решение более правильное?

⚪️ Использовать готовый фундамент. Довериться проверенным open source технологиям или коммерческим оркестраторам и базовым платформенным решениям для закрытия стандартных 80% задач (например, управление конфигурациями, базовые пайплайны).

⚪️ Создавать только ключевые отличия. Фокусировать силы своих инженеров исключительно на оставшихся 20% — тех уникальных бизнес-требованиях и специфических интеграциях, которые действительно отличают вашу компанию от конкурентов.

Мы в Core 24/7 готовы снять с вашей организации огромный пласт работы и заточить платформу под вас с вашим минимальным участием. Организуем Platform Engineering — и создадим внутренние платформы для ускорения разработки.

@DevOpsKaz 😛

🚀 «Мой кейс недостаточно интересный»

Так думает почти каждый спикер перед первым докладом. Если вы прочитали про поиск спикеров на Cloud Native Community Day и подумали «звучит круто, но мне-то нечего рассказать» — это та мысль, которая приходите половине инженеров. И почти всегда она неверна.

Нам не нужен «прорыв года», а лишь реальный случай из прода. Узнаете себя?

⚪️ Чинил кластер ночью и понял причину только под утро — расскажи, как искал
⚪️ Внедрял service mesh или ArgoCD и набил шишек — твои грабли сэкономят кому-то недели
⚪️ Резал счёт за облако — как нашел причину оверкостов
⚪️ Мигрировал на K8s, и половина пошла не по плану — это и есть лучший доклад
⚪️ Настроил observability и впервые увидел, что реально творится в проде

Если хоть один пункт про вас — доклад может получиться. Структуру и подачу поможем довести до ума на прогонах.

👈 Подать заявку как спикер

@DevOpsKaz 😛

Если у вас есть знакомые девушки в IT, которые хотят развиваться в облаках и AWS, то сейчас открыт набор в AWS She Builds Mentorship Program 2026.

Программа бесплатная, на 12 недель. Будет персональный ментор от AWS, общение с коллегами со всего мира и встречи с лидерами AWS.

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

Заявки принимают до 30 июня.

🐈Подписаться

#aws

🔥 Парадокс observability: больше сигналов, меньше ясности

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

Доля команд с MTTR > одного часа растет из года в года: 7% в 2021 году, 64% в 2022 году, 74% в 2023 году и 82% в 2024 году. При этом среднее количество инструментов, используемых одной командой, выросло до 8–9 различных платформ.

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

Однако после определенного порога избыток данных observability приводит к когнитивной перегрузке. Это мешает поиску первопричин (RCA) и лишь увеличивает MTTR. Как ни парадоксально, больше сигналов часто означает меньше ясности.

Инженер не способен сопоставить 8 дашбордов на 4 разных платформах, когда инцидент происходит в 2 часа ночи. Он ищет сигнал, похожий на то, что он уже видел ранее.

Анализ подходов к снижению MTTR показывает, что скорость восстановления стабильно обеспечивают 3 вещи:

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

Что с этим можно сделать?

⚪️ Измеряйте то, куда уходит внимание инженера. Что конкретно он открывал во время аварии? На какие графики смотрел дольше 30 секунд? Какие действия предпринимал? А что полностью проигнорировал?

⚪️ Проектируйте дашборды под инциденты, а не под покрытие. Каждая панель должна отвечать на конкретный вопрос, который возникает у инженера во время сбоя. Если вы не можете сформулировать этот вопрос — удаляйте панель.

⚪️ Качество сигнала важнее его объема. Один точный алерт, указывающий на корень проблемы, ценнее 50 алертов, требующих расшифровки. Регулярно проверяйте соотношение алертов к действиям. Если инженеры постоянно «гасят» или игнорируют уведомления — система шлет вам сигнал о собственной неэффективности.

⚪️ Проводите аудит внимания после крупных сбоев. Общайтесь с инженерами: что они открывали, что сработало, а что только мешало. Три месяца такой практики дадут вам более честное понимание ценности вашего observability-стека, чем любой отчет.

@DevOpsKaz 😛

⚡️ PROFIT Contact Day — 12 июня в Алматы

Общение с клиентами — самый уязвимый момент в бизнесе, ведь «один довольный клиент расскажет максимум троим, а недовольный — минимум девяти». Так как же бизнесу нивелировать и даже предотвратить недовольства клиентов, как сделать их более лояльными. Как вообще узнать, что ваши клиенты недовольны?

Ответы на эти и другие вопросы лежат в основе современных решений для контакт-центров. Что это за решения, каков их функционал, какую аналитику можно получить с их помощью, какой Call-центр выбрать — корпоративный или аутсорсинговый — вы узнаете в рамках конференции PROFIT Contact Day.

PROFIT Contact Day — конференция о технологиях контакт-центров, омниканальности, ИИ, аналитике, клиентском сервисе и управлении персоналом.

👈 Регистрация открыта

Узнайте, как поднять общение с клиентами на новый уровень и извлечь максимум выгоды от ИТ!
 
@DevOpsKaz 😛

🔥 Доклады с DevOpsDays Tashkent 2026

Во вложении видео о том, как мы с Core 24/7 съездили в Ташкент.

Если вы пропустили какой-то доклад (или саму конференцию) или просто хотите пересмотреть интересные моменты — теперь это можно сделать в любое время.

👈 Доклады DevOpsDays Tashkent 2026

А ещё мы подготовили aftermovie DevOpsDays Tashkent 2026.

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

@DevOpsKaz 😛

🔥 Новости мира DevOps, которые вы могли пропустить

⚪️ Релиз Kagent 0.96 — опенсорсного фреймворка класса Cloud Native Agentic AI, который превращает ИИ-агентов в полноценные ресурсы Kubernetes, управляемые через привычные YAML-файлы

⚪️ OpenYurt получила версию v1.7.0, которая повышает стабильность и автоматизацию — это платформа расширяет возможности нативного Kubernetes на Edge Computing

⚪️ История о том, как AWS перестроила свою сеть на основе теории случайных графов и сэкономила миллионы

⚪️ NATS, edge-native система обмена сообщениями, выпустила сервер версии v2.14. Добавили поддержку feature flags в конфигурации сервера, функцию пакетной публикации с высокой скоростью обработки и планирование отправки сообщений на основе интервалов и cron-выражений

⚪️ Опубликовали чек-лист готовности Kubernetes к проду

@DevOpsKaz 😛

🚀 Хотите прокачать свои навыки в AI-разработке?

Приглашаем на Build with AI: Astana — событие для разработчиков, которые хотят прокачать навыки работы с искусственным интеллектом и узнать, как применять AI-инструменты на практике.

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

👈 Регистрация

12 июня, 12:00-18:00, пр-т. Мангилик Ел. 55/1, Астана
Для входа необходимо заранее скачать мобильное приложение Astana Hub

Спикеры:

⚪️ Ramesh Chander — Regional Lead, Developer Ecosystem, MENA, Turkey & Central Asia, Google
⚪️ Alexander Tyutin — DevSecOps, Semrush
⚪️ Adkham Zokhirov — CAIO, Mohirdev LLC
⚪️ Bilguun Jargalsaikhan — Founder & AI Researcher, Deep Tech LLC

❗️Мероприятие пройдёт на английском языке.

Такие мероприятия возможны благодаря нашим партнерам из Astana Hub — крупнейший международный технопарк IT-стартапов в Центральной Азии. Здесь создаются условия для свободного развития казахстанских и зарубежных IT проектов.

@DevOpsKaz 😛

🚀 Как мы провели полный аудит IT-инфраструктуры для Bilim Group

BilimGroup — IT-платформа Казахстана, которая предлагает клиентам образовательные программы. Это 24 крупных проекта и около 3 млн пользователей. В группу входит более 15 цифровых образовательных компаний.

Перед Bilim стояла задача выявить узкие места, риски и точки роста в IT-инфраструктуре перед масштабированием и возможной миграцией. Группа компаний обратилась к нам в Core 24/7 для комплексного аудита:

⚪️ Поговорили с ключевыми сотрудниками
⚪️ Собрали и проанализировали артефакты
⚪️ Определили ожидания и глубину анализа
⚪️ Провели аудит и составили рекомендации

О ходе аудита и результатах читайте в новом кейсе.

👈 Читать

@DevOpsKaz 😛

⚡️ До нового Cloud Native Community Day — 2 месяца

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

❗️ Чтобы подготовиться без аврала, заявку стоит подать до 15 июня.

Слотов для спикеров всего 4-5. Берём доклады по реальному опыту, а не по громкости темы: сертификация, service mesh, ArgoCD, инциденты, платформа, FinOps. Если у вас есть история «было больно — вот как решили» — она нам нужна.

Подавайте заявку — свяжемся и поможем довести доклад до ума.

👈 Подать заявку как спикер

@DevOpsKaz 😛

🔥 Отладка bash: а что, так можно было?

Каждый DevOps-инженер или системный администратор рано или поздно оказывается в персональном аду, имя которому — отладка чужого (или забытого своего) Bash-скрипта на 500+ строк. Когда всё, что у тебя есть — это разбросанные по коду echo.

На Хабре рассказали:

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

⚪️ Все знают про set -x, но мало кто умеет кастомизировать переменную PS4. Как вывести в трейс время выполнения команды, имя функции и даже глубину вложенности

⚪️ Про утилиты, которые позволяют «дебажить» Bash как нормальный язык программирования

⚪️ Как отловить 95% глупых багов и скрытых уязвимостей в синтаксисе еще до того, как уронишь прод

👈 Читать статью на Хабре

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

@DevOpsKaz 😛

🔥 Yandex Cloud CDN стал доступен в Казахстане

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

Сейчас клиентам в Казахстане доступны локации суммарной емкостью сети порядка 1 Тбит/с. Оплата только за исходящий трафик — из CDN к потребителю контента. Также компания может самостоятельно настраивать время кеширования, что позволяет оптимизировать инфраструктуру.

Подробнее о сервисе рассказал архитектор Yandex Cloud Иван Кабанов в статье для The Tech:

👈 Читать статью

@DevOpsKaz 😛

🔥 Datadog внедряет ИИ-агентов глубоко в DevOps-процессы для автоматизации мониторинга и исправления ошибок

Datadog объявила о масштабном апдейте своей ИИ-платформы Bits, чтобы дать DevOps-командам автоматически находить и устранять инфраструктурные и программные сбои на основе телеметрии.

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

⚪️ Bits Code — ИИ для написания кода, встроенный во всю линейку продуктов Datadog. На основе данных мониторинга он сам предлагает варианты исправления ошибок и генерирует необходимый код.

⚪️ Bits Release — агент для проверки изменений в коде. Он анализирует потенциальный эффект от правок, формирует план валидации, запускает тесты в staging-окружении и контролирует процесс развертывания.

⚪️ Bits Testing Agent — инструмент для автоматического создания и поддержки синтетических тестов. Он сканирует приложение, выявляет критические сценарии пользовательского опыта и формирует под них тестовые наборы.

⚪️ Bits Remediation и Bits Infrastructure Operations — модули автоустранения неполадок со скриптами исправления ошибок. ИИ может автономно находить и чинить повторяющиеся проблемы в инфраструктуре, опираясь на ранее одобренные действия.

⚪️ Bits Memories — «память» ИИ-системы, которая аккумулирует информацию из прошлых расследований, runbook-инструкций, postmortem-отчетов и переписок в Slack, чтобы автоматически компилировать и запускать скрипты исправления.

⚪️ Bits Detection — для автоматического расширения зоны мониторинга при добавлении в ИТ-окружение новых эндпоинтов и рабочих нагрузок.

@DevOpsKaz 😛