DevOps *

На скрине показано 40 минут графиков с балансировки некоторого эндпоинта. На выделенном участке видно 129.01 рпс успехов и 7.27 ошибок 4xx, которые являлись 429 от рпс-лимитера. Настройка рпс-лимитера находилась на уровне “не более 150 запросов с интервалом в 1 секунду”. Не странно ли видеть такое уверенный и постоянный фон ошибок про превышение лимита?

Сейчас многие компании внедряют ИИ-агентов в свои процессы. И сталкиваются с проблемами. Классический пример: ИИ-агент по продажам самостоятельно пообещал клиенту скидку 50% на которую ему никто не давал разрешения. Явный провал разработчиков ИИ-агентов, хотя на прошлой неделе в демо всё работало идеально.

Мир явно разделился: одни говорят, что агенты готовы к продакшену, другие кричат что это не работает и работать не будет. Энтузиасты показывают впечатляющие демо. Чистые данные, правильные API, никаких сюрпризов. Но продакшен это другой зверь. Отчёт MIT показал, что 95% пилотов генеративного ИИ не достигают ожидаемых результатов. Модели не тупые. Инфраструктура вокруг них не готова.

Я это понял на собственном опыте, строя своего агента на базе OpenClaw, который отчитывается мне ежедневно в Telegram. Все здесь крайне интересно, но реальные области использования нащупать сложно.

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

И пока большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.

Привет, я давно не заходил. Лет десять (или даже пятнадцать...) прошло с того момента, как я написал статьи о парсинге бинарных документов, типа doc, pdf или rtf, ради получения текста (кстати, я недавно обновил репозитории, немного пересобрал старые проекты, можете глянуть). Вы бы знали сколько воды с тех пор утекло, но это всё ностальгия и былое - давайте к серьёзному.

С пару недель назад я возвращался домой на метро и в голову пришла идея, которую не возможно было отбросить. А что если есть неуверенные люди (а они есть)? А что если есть неуверенные люди, которым нужен толчок свыше? А что если эти неуверенные люди среди нас, в разработке - на бэкэнде, в devops или среди продактов? А что если им всем помочь?..

И родился проект Deploy Tarot. Да, это расклады таро на успех деплоя. Что если я, техлид, сегодня задеплою новую версию API? Нет проблем, карты расскажут. А что если наш бизнес аналитик захочет обновить документацию? Арканы помогут понять. А вдруг наш CTO возьмётся за старое, вспомнит про порох в этих самых и... сделает масштабный рефактор (ИИ, ну вы знаете)? Колода определённо знает. А если наша офис-леди?.. Ну, вы поняли.

Всем привет! Меня зовут Александр Барыков, я руковожу платформенной командой DevOps и являюсь лидером DevOps-комьюнити в нашей компании.

Сегодня хочу поделиться опытом, который мы накопили за последние четыре года. Речь пойдет о достаточно специфической, но знакомой многим теме – организации процесса скачивания и проверки внешних артефактов для размещения во внутреннем закрытом контуре. Эта статья будет полезна разработчикам, DevOps-инженерам и архитекторам, которые сталкиваются с необходимостью соблюдения строгих требований безопасности без потери темпа разработки, особенно в финансовом секторе, где есть регуляторные требования.

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок.

В этой статье разберём, как на самом деле работает transform processor: какую модель данных он использует, как вычисляются инструкции, где чаще всего ломается логика и почему это не всегда видно сразу. На примере разбора JSON-логов и реальных конфигураций покажем, как писать преобразования, которые дают контролируемый результат и не ломают телеметрию в продакшене.

Если вы уже имели опыт написания Ul-тестов для проверки страниц и форм, то, вероятно, задумывались: "Почему бы не протестировать весь сценарий целиком?" Так родилась идея делиться опытом, как мы внедрили подобный подход: начиная с первых шагов, объясняя, почему объединили UI, АРІ и SSH в единый интеграционный контур, и какие инструменты используем.

Знаете, что общего между щенком лабрадора и корпоративным AI-проектом? Оба сначала кажутся милыми и недорогими, а через полгода жрут столько, что хочется плакать. Только щенок хотя бы ласкается, а нейронка просто молча выставляет счет за GPU. В этой статье мы вместе с Александром Меркушевым (AI-консультант, архитектор облачных и AI решений, руководитель экспертной группы по внедрению ИИ в Яндексе) разбираемся, как AI меняет структуру инфраструктурных затрат, что с этим делать уже сейчас и, главное, поможет ли тут FinOps.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

AI ассистенты уже просто вошли в процессы разработки кода, но что на счет DevOps задач и CI/CD в частности? Думаю здесь их полезность может оказаться не чуть не меньше.

Как часто к вам или вы прибегали с круглыми глазами и просьбами помочь с упавшим пайплайном?

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

К счастью теперь за нас это могут нейросети и давать дельные советы (не все, но могут)

Сервер лагает. Смотришь на диск — df -h говорит 95% занято. Запускаешь du -sh /* — в сумме набирается 20%. Куда делись остальные 75%? Файлы не найти, место не освободить, сервис падает.

Это не баг и не магия. Это фундаментальная особенность того как Linux работает с файлами. Разберём почему так происходит и как это чинить за две команды.

Продолжаем тему эпических багов. В прошлый раз мы говорили про AT&T, положивших свою ультранадежную сеть одним «Break» в коде. Сегодня на очереди Knight Capital Group, решивших переиспользовать старый флаг в бинарном протоколе, затем там был мёртвый код, который забыли удалить и деплой, проверенный на семи серверах из восьми. Итог: уход в минус 450 миллионов долларов за 45 минут.

На Хабре этот инцидент упоминался несколько раз, но даже в самой большой статье (к слову, переводу, со всеми странными атрибутами инопрессы, вроде фраз «Атака зомби из „Кода убийцы“» и пространным вступлением) инцидент рассматривался скорее как финансовый. А нас же больше интересуют именно технические детали.

Kubernetes-кластер без сети — не кластер, а просто набор несвязанных компонентов. Чтобы «оживить» его, важно понимать, что такое Container Network Interface (CNI) и как он работает.

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

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

Если вы работаете с мониторингом в Prometheus или VictoriaMetrics, то наверняка знаете, и Alertmanager для удобного конфигурирования алертов. А если вы ещё и используйте EvaTeam (российский аналог Jira) и хотите автоматизировать полностью цикл создания, работы над алертами в этих систмах, то это решение очень вероятно вам поможет осуществить такую связку!

Alertmanager-evateam это Alertmanager (webhook) плагин, который создаёт и управляет задачами в EvaTeam на основе алертов, с акцентом на гибкость.

Мониторинг PostgreSQL сломан: 150 метрик в pg_stat_*, и ни одна не отвечает на вопрос «база здорова?». В статье — как устроен Health Score: единое число от 0 до 100, которое агрегирует состояние базы и заменяет 30 дашбордов Grafana.

Всё началось с простого желания: чтобы AI-агент мог потихоньку развивать мои проекты, пока я занят другими делами. Поставил задачу, ушёл, вернулся к готовому результату. За неделю из этого желания выросла мультиагентная система с шиной сообщений, мониторингом, делегированием задач и собственной веб-админкой. Система, которая в значительной мере построила сама себя.

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

Статья будет о том, как быстро начать работать с vLLM и vLLM Production Stack: от первого запуска модели до базовых режимов инференса через OpenAI-совместимый API. Разберем практические настройки и сценарии запуска — tool calling, thinking/non-thinking, мультимодальные и CPU-модели, а так же какие стартовые параметры сильнее всего влияют на память, производительность и стабильность. Отдельном рассмотрим полезные оптимизации для production-сценариев: FP8, Tensor Parallelism, KV-cache offloading, Speculative Decoding и ускорение холодного старта больших моделей.

На связи Андрей Леодоров, ведущий инженер по автоматизации процессов компании «Гарда». За время работы с Jenkins я видел разные сценарии его использования: от локальных инсталляций под одну команду до масштабируемых инстансов с централизованным сопровождением. Я пришёл к выводу, что Jenkins отлично подходит для использования на уровне продукта — когда команда может сама определять, какие инструменты и ресурсы нужны для организации процессов CI/CD.

Статья — это практический гайд для небольшой команды или отдельного проекта, которому нужен собственный воспроизводимый Jenkins в Kubernetes. Мы развернём Jenkins в Kubernetes, настроим хранение конфигураций как код и зафиксируем версии плагинов. Такой подход позволит разворачивать идентичные среды с нуля, не завися от конкретных версий плагинов. Я также добавил несколько готовых примеров со ссылками на GitHub, которые можно взять за базу и доработать под свои нужды.

Сталкивались уже с EvaTeam (российский аналог Jira)? Чувствуете боль при работе с бизнес-процессами (workflow)? Думаю я могу вам немного помочь

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

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

Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.

Неделю назад мы запустили DevOps-челлендж в честь 5-летия нашего блога на Хабре. Участникам нужно было разобраться, почему приложение не может синхронизироваться в ArgoCD, найти ошибку в конфигурации и довести деплой до зеленого статуса.

Челлендж завершен, а значит, пришло время подвести итоги и пошагово разобрать решение.

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

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

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