Системное администрирование *

У Яндекса есть публичная страница с 18 техническими мерами защиты Яндекс 360, и у части пунктов рядом с текстом стоит вкладка, где написано, каким методом API и с каким правом доступа эту меру проверить. Я прошёл её построчно и посчитал: вкладка «Проверка через API» есть у 10 пунктов из 18, вкладка «Настройка через API» — у 5.

Александр Жогов, основатель и руководитель компании +Альянс. И справка, и референс API открыты: весь счёт повторяется поиском по двум строкам в машинной выгрузке страницы, методику показываю целиком.

В Docker Desktop 4.86 пункт Docker VMM в настройках остался прежним, а движок под ним поменялся целиком: с версий 4.35–4.85 за ним стоял libkrun, с 4.86 собственный гипервизор Docker. Публичная бета анонсирована 12 августа, доступна на Mac и Windows.До этого Docker Desktop всегда опирался на чужой VMM: libkrun на технике Apple, Hyper-V или WSL на Windows, а Linux-версия собрана на KVM и QEMU.

Отсюда и разница в поведении между платформами, которую все давно принимают как данность.

Когда ты пишешь собственный кодек удалённого рабочего стола, последнее, что хочется услышать от человека из конкурентов:

Недавно я рассказывал про Sheeternetes — оркестратор, у которого control plane живёт в таблицах. Здесь — про следующий логичный шаг: паттерн «оператор», применённый к самим таблицам. Настоящий полноценный Sheeternetes-оператор. Не скрипт внутри таблицы, а внешний контроллер, который приводит табличку к желаемому состоянию.

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

31 августа в 14:32 по Москве у нас вышла последняя штатная публикация. Дальше cron честно стартовал по расписанию, генератор успевал выбрать тему и написать текст, но в ленте ничего не появлялось. Так повторилось четыре раза: три запуска 1 сентября и утренний запуск 2 сентября.

В один из дней в лаборатории раздался звонок. Звонил представитель организации, оказывающей услуги системного администрирования. Его первым вопросом было: «А вы умеете работать с ZFS?». Разумеется, мы пояснили, что у нас есть некоторые наработки в рамках собственных исследований, а также стандартные средства DR‑лаборатории, такие как PC-3000, где поддержка ZFS предусмотрена как минимум на базовом уровне.

Ответив на парочку каверзных вопросов клиента об устройстве ZFS, мы через некоторое время получили два SSD Samsung 870 EVO ёмкостью 2 ТБ, которые были объединены в зеркальный RAID‑массив (Mirror). Изначально комментарии сводились к тому, что оба диска рабочие, но один выпал из массива. Основная проблема заключалась в том, что был случайно удалён один из важных Zvol (блочный объект ZFS, используемый для виртуальных дисков). Клиент пояснил, что хотел откатиться к прошлой версии uberblock’а и получить снимок, когда этот Zvol ещё не был удалён, но у него это не получилось. Резервная копия сохранилась, но она была сделана ещё в апреле этого года.

Приветствуем, Хабр.

У нас вышла долгожданная новинка, посвящённая методологии «SRE» — Site Reliability Engineering. Книга называется «SRE. Новый подход к управлению инфраструктурой». Написал эту книгу выдающийся инженер Павел Рудницкий, автор «Инфраструктурного блога», разработчик с 25-летним стажем, практиковавший DevOps, когда это ещё не было мейнстримом.

Как многие из вас знают, искусство SRE зародилось в компании Google приблизительно в середине нулевых, суть его заключается в обеспечении бесперебойной работы сайтов и сервисов даже в условиях частичных отказов, текущего ремонта и в процессе выкатывания обновлений.

Три месяца вместо запланированного одного. 360 попыток запуска модуля VPN, которые заканчиваются таймаутом без единой подсказки в логах. «Осиротевшие» мастер-ключи, которые формально проходят все проверки, но ломают миграцию на ровном месте. И дистрибутив ключей, который отказывается формироваться из-за одного просроченного ММК.

Звучит как список кошмаров сетевого инженера? Это наш реальный опыт перехода с ViPNet Administrator 4-й версии на ViPNet Prime. Без прикрас, с полным набором граблей и неожиданных поворотов. Если вы только собираетесь в этот путь — эта статья сэкономит вам недели работы и несколько седых волос.

Администратор выгружает список активов в Excel, распечатывает ведомость, берёт ручку — и идёт по этажам. На каждом этаже сверяет глазами, что стоит на столе, с тем, что написано на бумаге. Возвращается, вносит пометки руками. Если что-то не сошлось — идёт ещё раз. Через неделю, а то и две, ведомость с галочками и вопросительными знаками ложится на стол ИТ-руководителю.

Большинство компаний проводят инвентаризацию именно так — и это в 2026 году. Об автоматизации все, конечно, слышали, но непонятно, что конкретно менять и в каком порядке.

Мониторинг зелёный, балансировщик отвечает, сертификат на месте — а пользователи пишут, что портала нет. Через сорок минут выясняется: часть клиентов получает новый адрес, часть — старый. Разъехался DNS. Разбираемся, почему резолвер стоит считать частью контура управления доступом, а не подписью к IP.

Хабр, привет! Есть такой тип проектов, которые начинаются со слов «а что если» и заканчиваются тем, что ты в три часа ночи объясняешь kubelet-у, что таблица — это его новый control plane. Так вышло и тут, всё родилось из субботней шутки в одном телеграм-канале по кубернетесу.

Правила игры простые: раз весь мир можно создать в эксельке, то пускай всё состояние кластера живёт внутри электронной таблицы. Не «метаданные в таблице», не «экспорт в CSV» — а буквально: Deployments, Nodes, Pods, Events — это вкладки Google Sheets (или листы Excel). Планировщик читает и пишет ячейки. kubectl-подобная утилита ходит в таблицу. И — вот это ключевое — на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер. Таблица и есть кластер.

Проект называется Sheeternetes. Это, конечно, шутка. Но шутка, которая компилируется, проходит тесты и переживает падение ноды.

Ниже — как это устроено, как это поднять у себя за пять минут, как оно работает на bare metal без интернета (в Excel и LibreOffice), как связать несколько таблиц-кластеров в федерацию с живой миграцией, почему контейнеры можно хранить прямо в ячейках, — и что это внезапно выросло в целый фонд с 30 проектами, стандартом контейнеров и системой сертификации.

30 августа в 22:01 МСК один из наших диалоговых воркфлоу упал на ноде Chat Logic. В журнале исполнения 928811 осталось короткое сообщение:

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

Подпись действительно кое-что подтверждает. Просто не то, что от неё ждут. Она говорит: «этот файл в момент подписи выпустил вот такой издатель, и после подписи содержимое не меняли». Она не говорит: «файл безопасен», «издатель — тот, за кого себя выдаёт прямо сейчас» и «ключ не украли полгода назад».

В сентябре разбираем то, что сейчас регулярно всплывает в задачах разработчиков, DevOps-инженеров, аналитиков, тестировщиков и ML-специалистов: PostgreSQL 18, eBPF, LLM, Playwright, Patroni, Rust, GitLab Runners, высоконагруженные сервисы и не только. В подборке — 61 демо-урок с упором на практику, реальные сценарии и вопросы, которые можно напрямую обсудить с преподавателями.

Любой, кто ставил софт в Linux, набирал apt install или pacman -S. Внешне разница косметическая: одни команды длинные, другие короткие. Но за этими командами стоят две принципиально разные инженерные философии.

Почему pacman ощутимо быстрее, но при этом опаснее в руках новичка? Почему Arch категорически запрещает частичные обновления, а Debian их даже не замечает? И почему один менеджер задаёт вопросы про конфиги, а другой молча подкладывает .pacnew?

Разбираем, что происходит внутри при установке пакета: форматы архивов, базы данных, решатели зависимостей, скрипты и хуки. Погружаемся в устройство apt/dpkg и pacman/libalpm глубже, чем в большинстве туториалов.

Падает один шлюз - и дежурному прилетает пачка уведомлений: молчат хосты за ним, гаснет uptime-монитор, срабатывают метрические пороги, горит SLO. Событие одно, уведомлений десятки. Разбираю, как собрать такой каскад в одну карточку инцидента и почему наивная реализация ломается: почему группировать надо по верхнему упавшему предку, а не по прямому родителю; что делать, когда события приходят в обратном порядке; почему “молчит, потому что за него сказал корень” и “не эскалируется, потому что родитель лежит” - это два разных состояния, которые нельзя склеивать; и где в такой системе обязательно выбирать шум вместо тишины. С кодом обхода графа, схемой таблиц и списком граблей.

Про BiHA (встроенную отказоустойчивость Postgres Pro) написано немало, и почти всё написано вендором. Материалы честные и полезные, но все статьи написаны в одном продуктово-обзорном жанре: как устроено, из чего состоит, что умеет. Практической и эксплуатационной боли в них нет. Я решил зайти с другой, инженерной стороны, с замерами, аварийными сценариями и цифрами.

После этой статьи вы будете знать, как BiHA ведёт себя при отказе лидера: сколько длится простой записи, какие отказы автоматика ловит плохо, чем это поведение управляется и что нужно поправить на стороне приложения, чтобы двадцать секунд кластера не превратились в минуты простоя сервиса.

Статья посвящена завершению поддержки ingress-nginx и рассматривает это событие не просто как необходимость заменить один Kubernetes-компонент на другой, а как повод пересмотреть архитектуру маршрутизации в Kubernetes-платформе. В статье показано, как со временем простой Ingress превращается в набор NGINX-specific annotations и накопленного технического долга, который сложно поддерживать и объяснять. Так же разбираются возможности Gateway API, разделение ответственности между Platform-командой и разработчиками, а также подходы к миграции существующей инфраструктуры. Особое внимание уделяется аудиту текущих Ingress, постепенному внедрению новой модели и отказу от массовой миграции ради миграции. Основная идея статьи — не просто перенести сотни Ingress в HTTPRoute, а использовать изменения для построения более понятной, управляемой и масштабируемой Kubernetes-платформы.

В рабочем чате: «Сайт не открывается, сертификат истёк», следом — скриншот с 502. Первый рефлекс — certbot renew и перезагрузить nginx. Иногда помогает. Иногда сайт после этого не поднимается совсем.

Дело в том, что «всё из-за сертификата» — это на самом деле две разные поломки с разными решениями: сертификат не продлился или продлился, но сервер отдаёт старое. В выдаче их валят в кучу, поэтому советы вроде «просто сделай certbot renew» либо не помогают, либо роняют сайт по-настоящему.

Разбираем по шагам: как за десять минут понять, какая из двух у вас, вернуть HTTPS и настроить продление так, чтобы это не повторилось.

Мне надоело вручную кормить MikroTik списками доменов и IP для выборочной маршрутизации через VPN. CDN меняются, адреса переезжают, TCP и QUIC могут вести себя по-разному — а список приходится постоянно догонять руками.

Так появился «Сусанин»: экспериментальная система, которая не знает заранее, что нужно отправлять в VPN. RouterOS наблюдает за connection tracking, замечает подозрительный сбой DIRECT-соединения, проверяет тот же destination через уже существующий туннель и временно запоминает рабочий путь. TCP и UDP обучаются отдельно, а при падении VPN система делает fail-open обратно в DIRECT.

В статье — архитектура FAST / SOFT / JUDGE / HEALTH, C11 control plane, credentialless bootstrap, транзакционная установка, реальные грабли RouterOS API (!empty / !done), clean install 0/16 → 16/16, reboot-тест, логи и полная инструкция по установке.

Проект пока очень пилотный: ARM64, основная тестовая версия RouterOS 7.23.3. Перед установкой — обязательно backup.