DevOps *

Я спроектировал архитектуру команды из 9 ИИ-агентов, которая проектирует, пишет, тестирует и деплоит других ИИ-агентов. Стоимость — от одной RTX 4090 до кластера A100.

Не бывает «лучшей модели» — бывает лучшая модель для конкретной роли. Оркестратору нужен reasoning (GPQA 88.4%), билдеру — кодогенерация (HumanEval 92.7%), критику — понимание tool use (tau-bench 87.4%). Поэтому вместо одного GPT-5 на все задачи — 6 open-source моделей на 9 ролей.

Внутри: конкретный маппинг модель → роль с обоснованием через бенчмарки, трюк с шарингом инстансов (9 агентов = 3-4 модели), три конфигурации развёртывания от одной RTX 4090 (24 GB) до кластера A100 (211 GB), честное сравнение self-hosted vs. API, квантизация, инфраструктура инференса и интерактивный дашборд.

Kubernetes полюбился разработчикам своим удобством: описал развертывание, в любой момент изменил параметры — и все работает. Но вот раскатка самих кластеров долгое время оставалась лоскутным одеялом: Terraform, Ansible, десятки плейбуков и пайплайнов. Потерял стейт — и начинается квест. 

Cluster API (CAPI) закрыл этот разрыв и за последние годы стал едва ли не стандартом для управления Kubernetes-кластерами. Он превратил развертывание и сопровождение инфраструктуры в такой же декларативный процесс, как деплой приложения.

В нашей платформе «Штурвал» мы уже давно используем Cluster API в продакшене. И довольно быстро стало понятно: это не просто удобный способ развернуть Kubernetes, а смена парадигмы эксплуатации. Но вместе с предсказуемостью приходят новые сложности — от обновлений управляющей плоскости до нетривиальных сценариев отказа. В этой статье разберемся, чем хорош Cluster API, а в чем его подводные камни, о которых обычно узнают уже в ходе эксплуатации.

Настройка OpenClaw — это один JSON5-файл и CLI на сотню с лишним команд. Документация разбросана между официальным справочником, GitHub issues и постами сообщества. Собрали всё в одном месте: структура конфигурации, управление шлюзом, модели, каналы, песочница, горячая перезагрузка, переменные окружения и безопасное хранение секретов.

Что происходит с инженерной практикой, когда код в проекте пишет не человек, а агент, а команда занимается средой, ограничениями и контурами проверки? В этом тексте — разбор реального эксперимента OpenAI, где внутренний продукт собирали через Codex почти без ручного кода: с собственными правилами для агентов, архитектурными инвариантами, наблюдаемостью, документацией внутри репозитория и постепенным ростом автономности. Это любопытный взгляд на разработку в режиме, где главным дефицитом становится уже не скорость написания кода, а человеческое внимание.

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

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

Сервер внезапно перестал отвечать, а в логах ошибка Too many open files? Дело не в нехватке памяти или перегруженном процессоре — просто ваш процесс исчерпал свои файловые дескрипторы. Под катом расскажу, что это такое, почему они заканчиваются, как быстро обнаружить проблему и как её пофиксить.

OSPF, BGP, VLAN, ACL — вы знаете их как свои пять пальцев. А потом приходит Kubernetes и предлагает «просто описать желаемое состояние в YAML». Звучит как магия? На самом деле под капотом K8s работают всё те же сетевые протоколы, просто теперь их настраивает не инженер с консолью, а код в репозитории. Эта статья — мост между классической сетевой инженерией и миром контейнеров. Без маркетинга, только факты: veth-пары, BGP-пиринги Calico, DNAT в iptables и почему ClusterIP не пингуется.

В этой статье разбираются все случаи, когда под в кластере может исчезнуть сам — без kubectl delete и без вашего ведома. Перезапуск kubelet, нехватка памяти, taint с эффектом NoExecute, высокоприоритетный под в очереди планировщика — любой из этих сценариев способен остановить под, даже если вы настроили плавное завершение.

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

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

Что если переход на локальную инфраструктуру (вроде Ollama) это решение, которое не просто поможет сэкономить, но изменит саму динамику разработки?

В данной статье описывается процесс реализации песочницы для регулярных выражений с помощью платформы для контейнеризации Docker и утилит Linux. Цель - получить ограниченную среду, куда пользователь может подключиться по SSH и где у него будет минимум возможностей, чтобы он ничего не сломал, но мог свободно использовать регулярные выражения как со встроенными в среду txt заготовками, так и со своим произвольным пользовательским вводом.

Всем привет! Меня зовут Анатолий Зотов, я системный архитектор SOC в RED Security. Как центр мониторинга и реагирования на кибератаки, мы должны быстро и внятно видеть, что происходит с железом и ОС на хостах: не кончается ли место на диске, не улетела ли память и не уперся ли CPU в потолок. Как это реализовать, да еще и безопасно?

Когда мы только приступали к задаче, первой мыслью, конечно, был Zabbix, как и у половины планеты. Но у нас никто не горел желанием поднимать еще одну систему, раскатывать агенты, подбирать шаблоны и разбираться с нюансами. Времени, как обычно, не завезли. А вот Grafana у нас уже была, поэтому я подумал — а что, если просто использовать то, что уже есть? Так я и наткнулся на связку «node_exporter → Prometheus → Grafana».

Эта статья для тех, кто хочет быстро начать мониторить хосты и не готов тратить вечность на внедрение тяжелой системы, особенно если Grafana уже живет в вашей инфраструктуре. Если Grafana и Prometheus у вас еще нет, то дополнительно расскажу быстрый старт через Docker Compose.

Я студент, который только начинает заходить в devops‑тематику. Сам я не админ и не держу в проде десяток серверов, поэтому решил не выдумывать «боли» из головы, а посмотреть, на что реально жалуются люди в интернете.

Одна жалоба повторялась достаточно часто: «Когда что‑то падает, приходится обходить несколько серверов, смотреть логи по отдельности и пытаться сложить картину вручную. ELK/syslog решают, но ради пары сервисов это перебор.»

После этого я решил собрать небольшой прототип LogRanger — CLI‑утилиты, которая по SSH забирает логи с нескольких серверов и открывает их в lnav одной командой. Ниже коротко расскажу, какую проблему хочу закрыть и что именно делаю.

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

Иногда компания ищет такого специалиста 2–4 месяца, проводит десятки интервью — и всё равно не находит подходящего кандидата.

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

Создать реплику PostgreSQL на базе в 1 TiB — задача, где быстро выясняется, что NVMe и сеть в 75 Гбит/с сами по себе ничего не гарантируют: упираешься в инструмент, который копирует данные в один поток. В статье разбираемся, как обойти этот потолок с помощью pgBackRest и параллельной передачи, какие настройки реально влияют на скорость, где легко потерять порядок величины на «мелочи» вроде хранилища под spool, и почему в PostgreSQL 18 внезапно стало лучше — но недостаточно.

OpenStack — это ваш собственный «Self Hosted AWS». Звучит пугающе, но с kolla-ansible развернуть его можно за вечер. Рассказываю как — от ip addr show до рабочего дашборда Horizon. Гайд, которого мне не хватало на русском.

Это перевод статьи с opensource.com, которая мне показалась особенно полезной и практичной, поэтому решил поделиться адаптированной версией для русскоязычной аудитории. Оригинал доступен по ссылке: https://opensource.com/article/22/10/docs-as-code

В статье разбирается подход Docs as Code — способ встроить документацию в процесс разработки так, чтобы она проходила через Git, ревью и автоматическую сборку вместе с кодом. Материал будет полезен разработчикам, тимлидам и тем, кто выстраивает инженерные процессы в команде.

Heartbeat-мониторинг — единственный способ проверить cron-задачи, фоновые процессы и устройства за NAT. Рассказываю, как работает эта технология в PingZen, и почему она проще и надежнее self-hosted решений.

В начале 2025 года компания MinIO в лице сооснователя Harshavardhana начала поэтапно сворачивать свою версию Community Edition. В феврале из open-source версии был вырезан веб-интерфейс администрирования - управление политиками, мониторинг, репликация, IAM - всё это переехало в коммерческий продукт AIStor с ценником от $96 000 в год. Пользователям оставили лишь базовый object browser и CLI-утилиту mc. В мае последовало удаление поддержки OIDC-аутентификации. В октябре MinIO прекратил публикацию Docker-образов и готовых бинарников - причём аккурат в момент раскрытия критической CVE-уязвимости. А в декабре 2025-го проект официально перешёл в режим maintenance mode: никаких новых фич, pull request'ы не принимаются, только точечные security-фиксы по усмотрению компании.

Привет. Мне стало интересно, насколько реально одному разработчику собрать продакшн‑подобную инфраструктуру мессенджера без managed‑решений и облачной магии. Не стартап‑презентацию, а инженерный эксперимент: развернуть стек, заставить его жить, увидеть слабые места и понять, что в этой системе действительно критично.

На Хабре уже есть материалы про базовую установку Synapse + Element, но моя цель чуть другая - показать сборку, где к Matrix добавляется внешний слой идентификации (OIDC), VoIP‑инфраструктура (LiveKit + TURN) и механизм подписанных обновлений Android‑клиента.

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

Всем привет! Это моя первая статья на Хабре и я надеюсь и рассчитываю на вашу критику, дельные замечания, внимание и аплодисменты. Сим я начинаю серию статей посвящённых тому как создавать SaaS продукты, как подбирать нишу, как его собственно программировать и отлаживать, как выводить на рынок и всё в таком духе. Поделюсь своим опытом, так сказать.

Эта статья (и несколько последующих) будет посвящена сугубо технической части вопроса. Я расскажу о своём шаблоне для разработки и тестирования MVP, который ускоряет дело. Он у меня появился потому, что я любитель экспериментов и много раз делал разные микропроекты — боты, игры, сайты, парсеры и тому подобное В какой‑то момент я заметил что таскаю между проектами один и тот же кусок кода, который здорово ко всему подходит и с которого начинается каждый мой новый проект.

Итак, вашему внимаю представляю МЕГА ШАБЛОН УДОБНОГО БЫСТРОГО ПРОГРАММИРОВАНИЯ

«Чем же он так хорош?», спросите вы. И правильно сделаете что спросите! А я вам отвечу.