SRE‑инженер Mindbox рассказывает, как DevOps‑команда столкнулась с неконтролируемым запуском хаос‑тестов, когда проводила плановые проверки с помощью Chaos Mesh. Что запускало «зомби‑тесты», какие пробовали решения и на чем в итоге остановились — делимся в статье.
macOS — сертифицированная UNIX система (формально — UNIX 03), и большая часть того, что набираешь в терминале, ведет себя, как в любом BSD: ls, grep, ps, ssh — все на месте. Но рядом лежит второй слой команд, которого нет ни в одном дистрибутиве Linux и нет в POSIX: defaults, sysadminctl, mdfind, say, afplay.
Часть из них выросла из архитектуры Darwin, часть — из графической и звуковой подсистем, а часть существует исключительно ради управления экосистемой Apple.
Таких утилит в macOS не один десяток, а в статье мы разобрали самые интересные и востребованные, по критериям: команда входит в macOS по умолчанию, не имеет штатного аналога в Linux и создавалась под задачи экосистемы Apple.
Если CREATE INDEX CONCURRENTLY или REINDEX INDEX CONCURRENTLY завершается с ошибкой, Postgres оставляет после себя невалидный индекс. Многие инженеры считают такие индексы безобидными заготовками, которые просто ждут удаления. В конце концов, планировщик ведь не использует их в запросах, верно?
Нет. Невалидные индексы совсем не безобидны. Они продолжают потреблять ресурсы, генерировать ввод‑вывод, мешать оптимизациям и даже создавать конкуренцию за блокировки — при этом не давая никакого выигрыша в производительности запросов.
В этой статье мы на реальных примерах рассмотрим скрытые издержки невалидных индексов, о которых должен знать каждый администратор Postgres.
Когда приходишь на аудит СУБД к разным компаниям, картина удивительно похожа: одни и те же проблемы, одни и те же причины. Меня зовут Андрей, я DBA в группе поддержки системного ПО Центра экспертизы по комплексному сервису К2Тех, сертифицированный эксперт Postgres Pro. В этой статье представлен ТОП-10 ошибок, с которыми мы встречаемся чаще всего. Я разберу, чем они опасны, почему возникают, и как их можно решить. Скорее всего, многие пункты покажутся вам до боли знакомыми:
Управление десятками и сотнями Helm-релизов быстро перестает быть тривиальной задачей, особенно когда появляются зависимости между релизами, CRD, несколько окружений и своя логика деплоя.
Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами.
Со временем у меня появилось несколько серверов: VPS, домашний NAS и ещё пара машин под разные задачи. Для подключения я использовал PuTTY. Он работает, но управлять несколькими серверами в нём неудобно. Сессии хранятся в реестре Windows, список хостов плоский, вкладок нет. Чтобы открыть два сервера, нужны два отдельных окна.
Termius устроен иначе. Там есть нормальный список хостов, вкладки и синхронизация. Но для работы нужен аккаунт, данные хранятся в облаке, а часть функций доступна только по подписке.
Мне не хотелось регистрироваться и загружать список своих серверов в облако ради обычного SSH‑подключения. Поэтому я начал делать собственный клиент - LucidSSH. Это не попытка собрать ещё один комбайн для системных администраторов. Мне нужен был простой локальный SSH‑клиент с несколькими дополнительными функциями: защитой от опасных команд и понятными объяснениями ошибок.
Я не занимаюсь администрированием каждый день. Поэтому делал программу прежде всего для таких же пользователей, как я: тех, кто впервые настраивает VPS, NAS, Raspberry Pi или небольшой домашний сервер. Разрабатываю LucidSSH в свободное от основной работы время.
Разработчикам регулярно требовались виртуальные машины, но self-service не существовал. Образ, ресурсы, сеть и доступы настраивала инфраструктурная команда. По отдельности операции были несложными, но в сумме пользователи ждали, а инженерное время уходило на повторяемую ручную работу.
Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.
В статье показано как на базе KubeVirt получился цельный внутренний продукт с минимальными трудозатратами, в котором разработчик действует самостоятельно, а платформа сохраняет контроль над dev-контуром и блокирует создание VM сверх бюджета команды.
Откройте терминал и выполните cat /etc/hosts. Скорее всего, там лежит пара строк про localhost и, может быть, несколько ваших локальных записей… А когда‑то этот файл содержал адреса всех компьютеров интернета и обновлялся по телефонному звонку. Под катом расскажу, как весь интернет работал через один текстовый файл, кто его обновлял и куда он в итоге делся.
Хабр, привет!
В эфире - команда из центра компетенций VMware. Недавно мы разбирали интересное поведение в работе ПО у одного из наших заказчиков — облачного провайдера.
Вы знали, что в vCloud Director с NSX‑V добавление новой внешней сети на шлюз может тихо отключить уже существующую? Система предательски завершит задачу без ошибок, а заказчик заметит пропажу только по упавшим ВМ. Мы воспроизвели это в тестовом контуре и проследили всю цепочку — от галочек в интерфейсе до delete-запроса в PostgreSQL.
Статья — для тех, кто сопровождает vCD с NSX‑V в продакшне. Если вы хоть раз правили внешние сети через UI, вы в группе риска. Покажем, как именно это происходит, и дадим два рабочих обхода — без танцев с БД и перехода на NSX‑T.
Пятнадцать лет я писал код руками. Был тимлидом, вёл команды по восемь-десять человек, успел поработать и в Минцифре, и в структуре «Газпрома».
А в начале этого года я уволился из найма и ушёл в исследование возможностей ИИ в разработке.
За полгода я собрал несколько продуктов, здесь упомяну три. Телеграм-бота я написал за одиннадцать часов, а систему защиты кода от копирования делал несколько месяцев. Но даже это вышло быстрее, чем справилась бы целая команда. Поначалу казалось, что возможностям нейросети нет предела.
На деле за эти полгода я трижды менял подход к работе с ИИ, а первые проекты выкидывал и переписывал с нуля. Один проект и вовсе провалился из-за нехватки предметной экспертизы, но об этом в конце.
Хочу поделиться с вами тем, как менялся мой подход на примере трёх проектов: какими моделями и инструментами я пользовался и в каких задачах нейросеть оказалась бессильна.
Проект NextBSD, который многие уже успели забыть, неожиданно получил вторую жизнь. Его идея — объединить ядро FreeBSD с открытыми системными компонентами Darwin, такими как launchd, Mach IPC, Grand Central Dispatch и другими технологиями, которые сегодня лежат в основе macOS. Первая попытка была предпринята почти десять лет назад, но безуспешно. Сейчас разработку начали заново, используя современную кодовую базу FreeBSD и накопленный за это время опыт.
На первый взгляд, идея выглядит странно: зачем переносить системный слой одной операционной системы поверх ядра другой, если обе давно развиваются своими путями? Однако у разработчиков есть вполне практичная цель. Они не пытаются создать «бесплатную macOS», а хотят сделать FreeBSD более современной платформой, сохранив ее совместимость и сильные стороны. Разберемся, что именно уже удалось реализовать, зачем это вообще нужно и насколько жизнеспособным может оказаться такой подход.
Привет, Хабр! На связи команда Рег.облака, а это третья статья про Free Tier. В первой мы считали, что помещается в один‑два гигабайта памяти, во второй перевозили сайт с виртуального хостинга на бесплатный сервер с ispmanager.
В обеих статьях был раздел, где мы перечисляли, чего на Free Tier делать не стоит: тяжелые CMS, неоптимизированные проекты под трафиком, серьезные базы. Этот раздел пора переписывать. Стартовал третий этап программы: юрлица получают на два месяца сервер 2 vCPU / 4 ГБ RAM / 40 ГБ NVMe. Под каждую задачу своя конфигурация, и с четырьмя гигабайтами круг задач заметно шире. Разбираем, что на них живет.
Звонки в управляющую компанию различаются по срочности: один жилец хочет узнать про график капитального ремонта, другому нужен электрик — починить освещение на площадке, третий хочет сообщить о затоплении. Но когда все обращения попадают в общую очередь, повседневные вопросы начинают конкурировать со срочными заявками. Это ведет к повторным звонкам, жалобам и долгой реакции на инциденты.
Диспетчер должен быстро понимать, какую заявку поставить в очередь, а по какой — сразу соединить с аварийной службой. Но при ручной обработке линия может быть занята не срочным обращением, и в итоге аварийная заявка будет обработана с задержкой.
Привет, Хабр! В этом материале делимся подробным гайдом, как собрать голосового робота и автоматизировать первую линию диспетчерской с помощью сервиса API МТС Exolve. Так срочные звонки будут мгновенно попадать на линию, а несрочные — в очередь для обработки в рабочие часы.
В первой части мы остановились на том, что Продуктовая аллея DevOpsConf 2026 показала рынок как поиск более зрелых эксплуатационных моделей. AppSec, observability и AIOps важны, потому что заставляют команды ответить на важные вопросы: где остаётся ответственность, кто владеет дефектом, с какого SLO начинается мониторинг и какие решения нельзя отдавать автоматизации без контроля.
Во второй части мы поищем ответы на вопросы кто и на какой платформе будет сопровождать production через Kubernetes, инфраструктурные платформы, DevOps as a Service, облака, data-платформы и инструменты разработчика. Команды пытаются снять рутину эксплуатации, собрать внутренние платформы, автоматизировать инфраструктуру через API и Terraform, а заодно встроить AI и data-инструменты в SDLC так, чтобы они помогали разработчику, но не получали бесконтрольный доступ к критичным средам.
Привет, Хабр! Это Данила Трусов, директор продукта «Инферит ИТМен».
В этой статье расскажу, что изменилось в новой версии 7.2 нашей системы учета, инвентаризации и контроля ИТ‑активов, и почему эти обновления сделают управление инфраструктурой прозрачнее и проще.
Если ваша инфраструктура постоянно растет, в ней регулярно появляется новое оборудование, меняются конфигурации и проводятся плановые работы, вы наверняка знаете, как важно держать руку на пульсе. Система инвентаризации ИТ‑инфраструктуры должна быть не просто инструментом сбора данных, а предсказуемым и управляемым помощником. Именно на этом мы сфокусировались в версии 7.2.
В Яндекс облаке есть маркетплейс решений, в котором достаточно много вариантов установки разных ОС с готовым набором пакетов. Но Windows Server в виду особенностей лицензирования недоступен. Но бывают случаи когда очень надо, поэтому решил написать эту инструкцию.
Сборку необходимо осуществлять на базе Windows Server (2016,2019,2022) английской версии. Cloud init не понимает названия групп на русском.
Вопрос производительности работы сервера Angie и различных оптимизаций не раз поднимался в других статьях цикла. Поэтому здесь мы соберём основные приёмы и подходы к настройке Angie для высоких нагрузок, а за подробностями по отдельным вопросам будем направлять читателя в специализированные статьи.
Я делаю внутреннего read-only LLM-агента для инфраструктурных расследований. Инженер задаёт вопрос обычным языком, а агент собирает доказательства из Kubernetes, метрик, логов, GitLab, Grafana и других эксплуатационных источников.
Один реальный кейс показал, почему «умного промпта» недостаточно: edge вернул 502, хотя приложение для того же request_id записало успешный редирект 302. Чтобы найти причину и не придумать удобное объяснение, агенту пришлось научиться связывать источники, удерживать время и scope, различать факты, гипотезы и отсутствующие данные.
В статье разбираю архитектуру агента на Go, DeepSeek, Qwen и MCP: планирование по evidence, контракты tools, память треда, подключение командных skills через n8n и evaluation на реальных сценариях. В последнем полном прогоне прошли 44 из 45 сценариев, включая все 29 обязательных.
Заказывая бэкап облака, компания незаметно отдаёт наружу три вещи: доступ к данным, ключи шифрования и место хранения. Разбираю по пунктам, как вернуть контроль над каждой - end-to-end шифрование с закрытым ключом только у клиента, запись копий в свой S3, NAS или СХД на территории РФ, запирание выпуска сертификатов на роль owner - и как эта архитектура закрывает требования ФЗ-152. В конце - чек-лист, по которому имеет смысл проверять любой такой инструмент.
273 «уникальных посетителя» за трое суток и ни одного пользовательского скачивания. Разбираю сырые логи nginx руками: почему фильтр по User-Agent ловит только честных роботов, какой поведенческий признак отделяет живой браузер от сканера и как из 273 адресов остаётся 21.