Раскопал на Medium интересное эссе от разработчика Krzyś про Elixir. Написано так захватывающе и самобытно, что не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Поэтому разбиваю его на две части — сегодня делюсь первой.

В начале недели взял задачу, которая выглядела на удивление просто. Сначала я попробовал решить ее одним способом, вторым, пятым, десятым — и очнулся ближе к ночи. Вот тебе и девопс…

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

Ну что, думаете что для запуска LLaMA 3 70B вам нужна серверная стойка за лярд рублей? Поздравляю, вас обманули маркетологи GPU-вендоров. Модели с сотнями миллиардов параметров — LLaMA 3 70B, DeepSeek-V3 с его 671 лярдом параметров — жрут vRAM как не в себя, но есть способ запихнуть это все в обычную потребительскую видюху.

Сегодня в статье разберем, как работает чудо квантизации под капотом, чем отличаются PTQ и QAT, почему MoE-модели (DeepSeek-V3, Mixtral, LLaMA 4 Scout) квантизовать сложнее и как выбрать между GPTQ, GGUF и AWQ.

Материал будет полезен как мимо проходящим ИИ-любопытствующим, так и ML-инженерам и специалистам по инференсу LLM, которые хотят запускать большие модели на ограниченном железе. Покажу, как все это гонять на практике и с кодом.

В прошлый раз я рассказывал, как работает Guardrails Filter: зачем вообще понадобился отдельный слой защиты данных при работе с LLM и какие задачи он решает.

В этот раз хочу обсудить то, какие подводные камни могут оказаться под капотом этой технологии. Пока мы делали свой Guardrails Filter, быстро выяснилось, что найти персональные данные — далеко не самая сложная часть задачи. Гораздо сложнее оказалось встроиться между приложением и моделью так, чтобы ничего не сломать.

Как это сделать? Сейчас расскажу.

Наткнулся на интересный материал про тестирование GitOps на масштабируемость и нагрузку. Его целых три недели проводила компания iits-Consulting. Оригинал читать не меньше 40 минут, поэтому сократил его, сохранив все самое важное — и теперь делюсь со всеми обитателями Хабра.

Полночь, деплой горит, а ты вручную поднимаешь десятый сервер за неделю: копируешь ISO, тыкаешь Enter в консоли анакон­ды, правишь fstab, чинишь grub — и на утро выясняешь, что забыл gpg-ключ репозитория на трех машинах из десяти. Признавайтесь, бывало? Эта статья для тех, кто устал платить временем и нервными клетками за ручную сборку образов.

В этой статье расскажу, как построил полностью автоматизированный пайплайн для сборки образов закрытого дистрибутива Linux на базе RedHat — без единого ручного клика после старта. Ansible управляет хостом-билдером, Packer с shell-провижионерами собирает сам образ, и в итоге мы получаем готовый RAW, оптимизированный для OpenStack. Подход не привязан к конкретной ОС: если у вас другой дистрибутив, достаточно заменить ks.cfg на preseed.cfg или любой другой автоустановщик — остальная логика пайплайна должна работать без изменений. На десерт расскажу, как оформил часть решения в модуль для Ansible и отправил его в официальную коллекцию community.general.

Думаю, многие сталкивались с ситуацией, когда облачный провайдер честно обещает 99.95% или даже 99.99% SLA, но в реальности бизнес-система падает на часы. Формально облако работает, виртуалки доступны, диск жив, сеть отвечает. Фактически пользователь открывает приложение и получает ошибку.

Самый неприятный момент заключается в том, что в такие минуты невозможно показать пальцем на провайдера и сказать «проблема на стороне облака», потому что технически облако действительно работает, а вот система нет. Точнее работает, но не как единое целое.

Я намеренно не погружаюсь сильно в техническую реализацию того или иного описанного метода по улучшению отказоустойчивости. Сейчас эту задачу прекрасно решает почти любая LLM. Цель статьи – поделиться своим майндсетом: на какие вещи я обращаю внимание, когда передо мной стоит задача улучшить стабильность highload-сервиса.

В cloud-native-среде безопасность давно не ограничивается защитой периметра. Уязвимость может появиться в IaC-шаблоне, попасть в контейнерный образ, пройти через CI/CD и проявиться уже в продакшене.

Тема очень сложная, поэтому когда я наткнулся на большой англоязычный материал о cloud-native-безопасности в публичном репозитории Security Technical Advisory Group, то сразу решил его перевести.

Cобрал практическое саммари: какие риски возникают на этапах разработки, сборки, развертывания и эксплуатации (runtime) и какими механизмами их закрывают — от DevSecOps и защиты цепочки поставки до Zero Trust и политик для работающих нагрузок.

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

Но в какой-то момент прогресс практически остановился.

Сначала я думал, что проблема в моделях, качестве промптов или архитектуре агентов. Но причина оказалась совсем в другом — в подходе к автоматизации. Сейчас расскажу, в чем именно.

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

Сложность теперь не столько в том, чтобы разобраться в задаче и выполнить ее, сколько в том, чтобы совладать с потоком информации, количеством дел и балансировать между ожидаемыми сроками и качеством.

Эта статья — честный рассказ о четырех навыках, которые лично меня держат на плаву. Буду очень рад, если в комментариях поделитесь своими лайфхаками — хотелось бы немного переопылиться опытом.

Нужно было заменить OIDC на Kerberos при внедрении платформы в облако заказчика. Простая замена не сработала: пользовательский контекст и межсервисные вызовы оказались плотно завязаны на OIDC.

В статье рассказываю, как мы искали компромиссное решение, пересматривали границы между бизнес-логикой и инфраструктурой и довели проект до приемки без полной переработки платформы.

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

Рассказал, как решить эту проблему. Материал будет полезен ML-инженерам и backend-разработчикам, которые сейчас затаскивают ИИ-агентов в продакшен, а также техлидам и архитекторам, которые проектируют такие системы.

Я давно привыкла первым делом спрашивать «а как это упадет?». Когда в наш ландшафт пришли ИИ‑агенты, выяснилось интересное: привычные ответы на этот вопрос здесь просто не работают. Агент в проде, дашборды настроены по классике: latency, error rate, uptime. Алертов нет, агент исправно отвечает на каждый запрос. А то, что он три дня подряд уверенно врет, вы узнаете из жалобы пользователя, и никак иначе.

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

В статье я расскажу, как решал проблемы погружения в проект сначала вручную, а потом с помощью ИИ-инструментов и как мне удалось сократить путь от дней и недель до нескольких часов. Мой опыт пригодится QA-инженерам, которым приходится разбираться в новых проектах, систематизировать знания о продукте и поддерживать документацию в актуальном состоянии.

Что такое гиперскейлер и в чем его неотъемлемая связь с облачными вычислениями и советскими НИИ?

Сегодня мы попробуем ответить на этот вопрос, а также рассказать, как развитие технологий позволило AWS, Google Cloud, MS Azure и российским Yandex Cloud и Cloud.ru стать крупнейшими облачными провайдерами. 

Меня зовут Никита, я технический лидер команды, которая занимаемся управлением безопасностью контейнерных сред — и как отдельным продуктом для внешних клиентов, и как внутренним решением для команд, которые используют Managed Kubernetes под свои сервисы.

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

Пару дней назад Cloud.ru выложил исходный код Guardrails Filter в открытый доступ. Это прозрачный обратный прокси между клиентом и LLM-провайдерами, он убирает чувствительные данные из запросов к модели и восстанавливает их в ответах. Я один из разработчиков этого инструмента и хотел бы рассказать подробнее, зачем вам вообще может быть нужно опенсорс-решение, как его можно внедрить в свою инфраструктуру, ну и ответить на вопрос: зачем облаку бесплатно делиться своими наработками с рынком?

Представьте, однажды вы приходите в новую компанию на позицию Automation QA и перед вами возникает задача: на пустом поле проекта посеять зерна автотестов, которые прорастут в регулярный процесс тестирования и будут отлавливать различные баги. Такая задача возникла и передо мной, поэтому я хочу поделиться своим опытом, как строил тестирование кастомного K8s CNI-плагина в новой для себя области. Статья будет полезна QA-инженерам, которые на «ты» с Python, но на «вы» с тестированием Kubernetes с помощью автотестов. При решении задачи я столкнулся с вопросами, на которые нигде не нашел ответа. Возможно, раз мне помог описанный путь, поможет и вам.

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

Сначала туда попадают предсказуемые вещи: CRM, ERP и внутренняя отчетность. Но потом добавляются документы, записи разговоров, данные для ML, генеративный ИИ и еще десяток сценариев, о которых никто не думал, когда проектировал DWH десять лет назад.

Что тогда делать? Сейчас расскажу.

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

В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.