🔥 Конкурс совместно с 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 😛

⚡️ 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 😛