⚡️ Масштабное партнерство для ИТ-рынка Казахстана: Core 24/7 и Softprom объединяют усилия

Для казахстанского бизнеса растут требования к ИТ-инфраструктуре: высокая доступность, глубинная аналитика данных и жесткое соблюдение локального законодательства. Мы вместе с Softprom объединяем компетенции, чтобы предложить рынку РК новые технологические решения:

⚪️ Гибридные облачные архитектуры «под ключ»

Создаем бесшовные и отказоустойчивые связки: надежный локальный on-premise контур в Республике Казахстан + масштабируемые мощности публичного облака AWS.

⚪️ AI/ML-решения мирового уровня (с официальной поддержкой лидеров рынка)

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

⚪️ Готовые референс-архитектуры для РК

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

❗️ Что это даст бизнесу в Казахстане?

Гибкость и инновации ИИ-гигантов и AWS, сохраняя данные в периметре страны и под полным контролем. Скорость развертывания ИТ-проектов увеличивается, а риски комплаенса сводятся к нулю.

Делаем все, чтобы синергия Core 24/7 и Softprom стала мощным драйвером цифровой трансформации для финансового сектора, ритейла, логистики и enterprise-компаний Казахстана.

Следите за нашими анонсами. В будущем мы поделимся первыми совместными кейсами и готовыми архитектурными шаблонами.

@DevOpsKaz 😛

🔥 Выступите с докладом на Cloud Native Community Day — в Алматы 13 августа

Мы готовим новый митап на 100-150 человек — и ищем сильных инженеров, которые разбираются в технологиях CNCF и готовы выступить с докладом на основе своего реального опыта.

Нам интересны любые технологии CNCF:

⚪️ Kubernetes
⚪️ Service Mesh
⚪️ Observability
⚪️ Storage
⚪️ CI/CD
⚪️ безопасность
⚪️ сетевое взаимодействие и др.

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

Какие доклады нам нужны:

⚪️ От инженеров, которые каждый день держат продакшн
⚪️ От инженеров, которые хотят поделиться реальным кейсом
⚪️ Как вы строили платформу и с чем столкнулись
⚪️ Как дебажили сложные инциденты
⚪️ Какие инструменты внедрили и как это убрало боль (или добавило новую)

​Что предлагаем спикерам:

⚪️ ​Официальный ивент CNCF — ваше выступление станет частью глобальной экосистемы
​⚪️ Аудитория: 100-150 инженеров (SRE, DevOps, Tech Leads)
​⚪️ Атмосфера: максимально теплая + фуршет, подарки и afterparty для нетворкинга

Чувствуете, что у вас есть история, которая спасет кому-то часы дебага?

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

@DevOpsKaz 😛

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

⚪️ Istio v1.30

Главный фокус последних обновлений Istio (включая релиз 1.30) — на глубокую стабилизацию бессидекарной архитектуры Ambient Mesh и упрощение эксплуатации. Разработчики добавили гайд по бесшовной миграции с классических сайдкаров, внедрили поддержку CIDR-диапазонов для внешних сервисов и добавили передачу исходной идентичности клиентов через шлюзы-вейпоинты (XFCC). Кроме того, в тестовом режиме появился компонент agentgateway, оптимизированный под сетевой трафик AI-агентов и MCP-инфраструктуры.

Istio получил полную нативную поддержку Helm v4 (включая Server-Side Apply), что устранило давние конфликты прав на вебхуках при апгрейдах. Для защиты управляющей панели istiod от OOM-киллов была интегрирована библиотека автоматического управления памятью (GOMEMLIMIT), а в прокси ztunnel добавлена поддержка списков отзыва сертификатов (CRL) для повышения безопасности.

⚪️ OpenBSD 7.9

Релиз с упором на архитектуру AMD64 (x86_64). Увеличили CPU процессора с 64 до 255 для поддержки серверов на Intel Xeon и AMD EPYC, исправили графический движок AMDGPU и обновили DRM до Linux v6.18.22. Поправили и сетевой стек со встроенным IPv6 SLAAC и отслеживанием source, state.

⚪️ Exam vouchers от Microsoft

Возможность бесплатно получить сертификации по Azure, AI, Security, Cloud и DevOps. На каждый аккаунт по 2 ваучера. Проходите учебный путь и набираете 80% practice assessment, за это приходит ваучер. AI-900, AI-103, AI-300(MLOps), SC-500 и другие. Дедлайн — 31 мая.

@DevOpsKaz 😛

🔥 Вакансия в CORE 24/7 — Middle DevOps-инженер

Алматы, офис
Требуемый опыт работы: 1-2 года
Полная занятость, полный день
Заработная плата: до 1 000 000 тг net
Контакты: Telegram @issaika

⚪️ Что нужно делать

• Поддерживать production так, чтобы бизнес мог быть спокоен
• Спасать клиентов в случае аварий: быстро, решительно, профессионально
• Выстраивать процессы CI/CD
• Переносить приложения клиента (на любом языке, фреймворке и технологии) в Kubernetes с помощью различных инструментов. Запускать и настраивать их
• Искать способы сделать более надежными и быстрыми базы данных, серверы очередей и прочий софт
• Разрушать стену между разработкой и системным администрированием; консультировать разработчиков клиента, вместе приходить к лучшим решениям и практикам

⚪️ С кем будете работать

• Со своей командой увлеченных профессионалов
• С тимлидом и ПМом, которые всегда помогут, обучат и направят
• Напрямую с клиентом, но в этом будут помогать тимлид и ПМ
• С внутренними командами, разрабатывающими инструменты, сервисы и технологии для упрощения работы

⚪️ Требования

• Отличные знания Linux-систем — ежедневная эксплуатация от 3 лет; опыт в DevOps — от 1 года
• Понимание того, как функционируют современные веб-приложения, и опыт их эксплуатации — от 3 лет
• Понимание веб-стека (HTTP, TCP/IP), устройства и работы сетей, базовые умения работы с iptables
• Понимание принципов работы СУБД, а также построения и эксплуатации распределенных систем
• Умение сформулировать алгоритм и уверенно писать скрипты
• Понимание того, что удалёнка — это серьёзная работа, а не оплачиваемый отдых

⚪️ Будет плюсом

• Опыт использования современных NoSQL-решений (особенно MongoDB и Redis)
• Опыт в Kubernetes
• Опыт настройки реляционных баз данных для отказоустойчивых/высоконагруженных систем
• Опыт разработчика
• Хорошие знания основ системы виртуализации KVM и контейнеров Docker
• Опыт работы с облачными платформами (Yandex clod, AWS, GCP, Azure и др)
• Знание Prometheus/Grafana
• Знание Elasticsearch (ELK)
• Знание RabbitMQ

Писать сюда:

👈 aissabekova@core247.io
👈 @issaika

@DevOpsKaz 😛

🔥 Конкурс совместно с Yandex Cloud Kazakhstan

Автоматизация — наше всё. И за одну идею автоматизации у вас есть шанс выиграть крутой походный набор.

💥 Призы: 3 набора с мерчем: рюкзак, чехол для ноутбука, облачный стикерпак и термос ☁️

Как участвовать:

⚪️ Подпишитесь на @DevOpsKaz и @yandexcloudkazakhstan
⚪️ Перейдите в конкурсный пост Yandex Cloud Kazakhstan по ссылке
⚪️ В комментариях под тем же постом ответьте на вопрос:

Какую рутинную задачу в IT / DevOps вы мечтаете полностью автоматизировать с помощью облаков и ИИ?

📅 Сроки:

Старт — 22 мая
Итоги — 29 мая (объявят в канале Yandex Cloud Kazakhstan)

Победителей объявят с помощью рандомайзера — из числа тех, кто ответит на вопрос.

@DevOpsKaz 😛

🔥 Релиз GitLab 19.0

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

⚪️ Автономное ведение Merge Request (MR): Duo Developer теперь может самостоятельно вести MR от первого коммита до слияния. ИИ-агента можно активировать через @assign в issue, по кнопке «Generate MR» или через @mention. Агент умеет запускать тесты и линтеры перед коммитом (настраивается через файлы AGENTS.md и agent-config.yml).

⚪️ Разрешение конфликтов слияния (Beta): появилась функция автоматического разрешения конфликтов с помощью ИИ (Resolve with Duo). ИИ анализирует конфликтующие файлы, правит их с учетом контекста обеих веток и делает коммит в source-ветку (правила protected branches строго соблюдаются).

⚪️ Групповые инструкции для ИИ-ревью: теперь правила для ИИ-кода можно задавать глобально на уровне группы. Они каскадно наследуются и дополняются проектными инструкциями, избавляя от необходимости дублировать файлы конфигурации в каждом репозитории.

⚪️ GitLab Secrets Manager: главная архитектурная особенность — принцип наименьших привилегий. Секреты больше не «прилетают» во все job'ы пайплайна автоматически как обычные CI/CD переменные, конкретный job должен явно запросить нужный секрет через конфигурацию secrets: vault:....

⚪️ SBOM-подход в Dependency Scanning: обновленный сканер зависимостей (v2) строит полный граф программных компонентов (Software Bill of Materials), что позволяет находить уязвимости глубоко внутри транзитивных зависимостей, которые старый сканер не видел. Если lock-файла нет, анализатор пытается сгенерировать его автоматически.

⚪️ Шаблоны заголовков MR: добавлена долгожданная фича — возможность жестко задать шаблон заголовка Merge Request на уровне проекта с использованием динамических переменных (например, Resolve %{issue_id} "%{issue_title}").

⚪️ Массивы в CI/CD Inputs: теперь можно обращаться к элементам по индексу ($[[ inputs.services[0] ]]), а при ручном запуске пайплайна в UI можно выбирать несколько значений из выпадающего списка, которые автоматически объединятся в массив.

⚪️ HMAC-подписи для Webhooks: вместо передачи статического токена в открытом виде (X-Gitlab-Token), GitLab теперь вычисляет и отправляет безопасную подпись HMAC-SHA256, защищая интеграции от перехвата и replay-атак.

GitLab 19.0 переходит от концепции «ИИ как ассистент, пишущий код» к концепции «ИИ как полноценный участник процессов», способный самостоятельно тестировать, проверять безопасность, разрешать конфликты веток и управлять инфраструктурными секретами, снижая нагрузку на инженеров.

@DevOpsKaz 😛

🔥 Бесплатные курсы по Git / GitHub

К концу 2025 года на GitHub было зарегистрировано более 180 миллионов разработчиков. Значительная часть мировой коммерческой разработки проходит именно через эту платформу.

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

⚪️ Слёрм: Git для начинающих

22,5 часа практики помогут эффективно управлять проектами, облегчать себе процесс разработки и минимизировать возможные ошибки.

⚪️ Хекслет: Основы Git

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

⚪️ Stepik: Основы Git и GitHub

Программа покрывает работу с репозиториями, коммитами, удаленными серверами и отдельно разбирает GitHub Copilot.

⚪️ Академия Эдюсон: Тестировщик ПО free

Это бесплатный тест-драйв полного платного курса по тестированию ПО. За три дня вы посмотрите, как Git и GitHub применяются в работе тестировщика наряду с Postman, Fiddler, тестированием API и мобильных приложений.

Сохраняйте себе и делитесь с теми, кому будет полезно 🫡

@DevOpsKaz 😛

🔥 Конкурс с Yandex Cloud продолжается: участвуйте и выигрывайте мерч!

Ещё есть время поделиться идеями и забрать подарки.

Подарки: 3 набора с мерчом — рюкзак, чехол для ноутбука, термос и облачный стикерпак.

👈 Все подробности здесь

@DevOpsKaz 😛

⚡️ Как улучшить дежурства DevOps

Улучшение ситуации с дежурствами не требует масштабной и болезненной трансформации. Все начинается с базового шага: готовности посмотреть проблеме в глаза.

Типичные факапы в On-Call и их решения:

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

⚪️ Привыкание к «шуму» алертов. Инженеры порой месяцами живут в потоке ложных и некритичных уведомлений, просто потому что не знают, «разрешено» ли им что-то отключать. В качестве решения — закрепление ответственности и карт-бланш от руководства на то, чтобы гасить мусорные алерты, чистить каналы оповещений или переходить на алертинг на основе SLO.

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

Что можно улучшить уже завтра:

⚪️ Фиксируйте простые KPI дежурств. Один из самых эффективных показателей может быть банальным: сколько алертов получила каждая команда за прошлую неделю? Новое поколение инструментов предлагает более глубокий анализ. Они объединяют операционные сигналы из GitHub, Jira и др. источников с кратким фидбеком от самих инженеров.

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

Лайфхак из практики: чтобы разбор KPI стал регулярным, отчеты должны быть адаптированы под культуру управления вашей компании. Например, можно генерировать автоматические отчеты в Google Docs и изучать их во время митингов в режиме «молчаливого чтения» в начале встречи.

@DevOpsKaz 😛

🔥 Как похоронить SRE в компании, пытаясь его масштабировать

Бывает, что мимолетный успех затуманивает трезвый взгляд на вещи. Когда одна продуктовая команда видит «классный результат» после внедрения SRE, велик соблазн сразу масштабировать этот результат на другие команды. В итоге хорошая SRE-практика быстро превращается в несовместимые друг с другом варианты.

Разбираем классические ошибки хаотичного масштабирования и то, как сделать это по уму.

⚪️ Парад кастомных велосипедов. Без единых стандартов у всех свои форматы алертов, разные метрики SLO и уникальные плейбуки.
⚪️ Размытие экспертизы. Топовых инженеров, которые запускали первые SRE-практики, начинают размазывать тонким слоем по компании и кидать на дежурства в незнакомые системы. В итоге они превращаются в «пожарных» на full-time.
⚪️ Платформа без инвестиций. Пока SRE-шники тушат локальные пожары в продуктовых командах, общие инфраструктурные инструменты остаются без внимания. Техдолг растет, команда топчется на месте.
⚪️ Лучшие люди выгорают и уходят. Компания теряет экспертизу из-за кривого менеджмента, а не из-за того, что «SRE не масштабируется».

Как масштабировать SRE, ничего не сломав

⚪️ Вводим критерии готовности. Нельзя просто так взять и прийти к SRE. Продуктовая команда сначала должна сама сделать домашку: настроить базовую инструментацию, определить SLO и написать минимальные инструкции для дежурств.
⚪️ Гибкие модели взаимодействия. Выделенный SRE нужен далеко не всем. Миксуйте форматы: используйте консалтинг со стороны SRE и Self-Service для зрелых команд.
⚪️ Защищаем правило 50/50. Помните классику из Google SRE book? Не более 50% времени на эксплуатацию (ops). Остальное время — строго на проектную работу и автоматизацию. Иначе выгорание неизбежно.
⚪️ Инвестируем в платформу (IDP). Вместо раздувания штата автоматизируйте стандарты. Нужны единые библиотеки логирования, общие конфигурации PagerDuty и готовые инструменты для работы с SLO.
⚪️ Алерт на онколл. Если нагрузка на дежурствах зашкаливает — это не кадровая проблема, которую можно решить наймом джунов. Это архитектурная проблема системы.

Масштабировать нужно не людей, а стандарты и платформенные решения.

@DevOpsKaz 😛

🔥 Вайбкодинг, AI-агенты в проде и ИБ: как прошла beetech conf 2026

Состоялась шестая beetech conf, где инженеры и продакты делились чистым практическим опытом внедрения ИИ в реальный прод. Казахстанский IT-экспорт уже пробил $1 млрд, так что экспертизы там насыпали плотно.

Собрали главное из стримов Engineering, Data & AI, что точно стоит взять на заметку:

⚪️ Пайплайны, архитектура и инфраструктура

- Поиск в госзакупках на AI-стероидах. Виталий Тренкеншу (CEO bids.do) разложил трехстадийный пайплайн Retrieve-Enrich-Rerank. Настроили архитектуру так, что обработка гигантских массивов данных сократилась с десятков тысяч позиций до точного шорт-листа всего за пару минут.

- Безопасность AI-агентов. Кутлымурат Мамбетниязов (BTS Digital) поднял больную тему: как деплоить и защищать сами LLM-системы, и как использовать ИИ для автоматического поиска уязвимостей в инфре, пока это не сделали хакеры.

⚪️ Бизнес-логика и метрики

- Почему AI в продакшене не взлетает? Виктория Татарикова (QazCode) разобрала 5 ключевых ошибок внедрения ИИ, когда пилоты жрут бюджеты, но не приносят ценности. Дала готовую модель перехода от простых чат-ботов к автономным AI-агентам с измеримыми метриками.

- Юнит-экономика головного мозга. Известный продуктовый аналитик Илья Красинский (Rick.ai) на пальцах объяснил, почему стартапы с крутым стеком и сильной командой всё равно закрываются. Спойлер: надо принимать решения на основе жестких данных и юнит-экономики, а не интуиции.

⚪️ Главный кайф — Epic Fails микрофон

Помимо классических докладов, завезли формат "квартирников" и разбор факапов. Участники со сцены честно рассказывали, из каких костылей, упавших баз и кривых архитектурных решений в итоге выросли стабильно работающие продукты.

Резюме: рынок меняется каждые полгода. Оставаться на "старых дрожжах" и просто настраивать CI/CD по старым мануалам больше не получится — приходится лезть под капот MLOps, AI-агентов и вайбкодинга.

@DevOpsKaz 😛

🔥 IBM и Red Hat защитят open source ПО от киберугроз нового поколения

Передовые ИИ-модели (типа Claude Mythos) научились мгновенно находить уязвимости в коде. Например, в рамках недавнего исследования Anthropic ИИ проверил более 1000 open-source проектов и всего за месяц обнаружил 23 019 уязвимостей, из которых более 6 тысяч оказались критического или высокого уровня опасности.

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

Project Lightwell на $5 млрд. создается, чтобы помочь с этим. Более 20 000 инженеров и современные ИИ-технологии трудятся, чтобы автоматизировать защиту.

Как это работает?

⚪️ Специальная коммерческая платформа-хаб станет своеобразным фильтром. ИИ-системы будут автоматически проверять и тестировать исправления для огромных объемов открытого кода, гарантируя, что патчи безопасны и готовы к работе в реальных корпоративных системах.

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

⚪️ Агентный ИИ. IBM планирует использовать свои новые методы ИИ-агентов, которые могут автономно выполнять сложные цепочки задач по анализу кода, приоритизации угроз и укреплению зависимостей между библиотеками.

Этот проект — попытка перевести валидацию и выпуск защитных патчей на промышленные рельсы.

@DevOpsKaz 😛

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

Многие 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 😛