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

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.

Система удаленного доступа — это клиент, брокер, агенты на серверах. Все это нужно, чтобы десятки тысяч пользователей попали к нужным приложениям на нужных серверах с нужными политиками. Но когда соединение установлено, в дело включается протокол: будет ли картинка рваться при плохой связи, пробросится ли нужное устройство, будет ли соединение зашифровано по ГОСТ без костылей. Год назад мы в Orion soft решили, что работать в рамках чужих архитектурных решений дальше невозможно, и начали писать протокол с нуля.

Меня зовут Александр Донин, я технический менеджер платформы VDI и терминального доступа Termit. В этой статье я расскажу, как устроен наш протокол Pulsar и какие решения мы принимали в процессе его разработки, чтобы было понятно, почему российскому энтерпрайзу недостаточно допиливания Open Source и чем отличается протокол, с самого начала спроектированный под реальные сценарии использования.

ora2pg переносит схему с Oracle на PostgreSQL, и в целом переносит хорошо. Интересное начинается там, где он чего-то не осилил: он не падает и не ругается, а молча делает не то.

Процедура с AUTHID исчезает из вывода целиком, без ошибки и без строки в логе. TO_DATE с форматом RR молча возвращает 1 год до нашей эры. LONG RAW превращается в text, хотя сам ora2pg документирует bytea. Обработчик исключений после конвертации ловит SQLSTATE, которого PostgreSQL не возбуждает никогда.

Двадцать таких мест, все проверены на реальном ora2pg 25.0 и живом PostgreSQL 16, по каждому написано чем чинить.

Моя домашняя сеть уже давно перестала быть просто «вайфаем в квартире». Сейчас этот зоопарк состоит из: нескольких роутеров, прошитых под на OpenWrt, NAS, МФУ, а также IoT-устройств (робот-пылесос, умные лампочки, бризер, кондиционер, три канарейки, черепаха, золотые рыбки и старый глупый хомяк). А на роутерах ещё куча сервисов крутятся (например, https-over-dns и сервис-который-нельзя-называть).

В какой-то момент я поймал себя на мысли, что трачу кучу времени на рутину: копаться в заметках, вспоминать команды для OpenWrt, вручную проверять сервисы; понял, что выступаю для своей сети сисадмином на побегушках. Так я и решил настроить локально Qwen3.6-35B-A3B + несколько инструментов.

В этой статье я расскажу о MVP моего домашнего Skynet-а: настроенный агент умеет сам ходить по SSH на роутеры, проверять статус сервисов — и сам поддерживает документацию по сети (на основе подхода llm wiki). Чтобы не бояться, что LLM случайно уронит сеть, я выстроил строгие правила: все деструктивные действия требуют моего подтверждения, а любые скрипты, которые агент напишет, я запускаю только после ручного ревью (не самый оптимальный вариант — но для MVP хватило).

Итак, далее вас ждёт пошаговая инструкция для новичков, как поднять подобную систему в вашем контуре. И пример, как с её помощью поднять себе РКН следить за состоянием принтера по протоколу SNMP.

И сразу скажу: я фанат Powershell, так как эта командная оболочка работает и под Windows, и под Linux и построена на основе горячо любимого мною .NET. Поэтому все дальнейшие действия (и генерируемые скрипты) будут приведены для кроссплатформенного Powershell.

«1С тормозит» — это не техническое утверждение, а начало спора. Бизнес говорит «тормозит», подрядчик говорит «у нас всё в норме», и обе стороны правы, потому что меряют разное: пользователь меряет секунды до открытия документа, подрядчик — загрузку CPU на сервере.

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

Я собираю мониторинг 1С в составе своей платформы наблюдаемости и за последние месяцы прошёл все три уровня, включая пару очень неочевидных граблей на Windows. Ниже — разбор по уровням: что видно, чего не видно, чем это ловится и где именно молча ломается.

Я в одиночку делаю и эксплуатирую платформу мониторинга: метрики, логи и трейсы для чужой инфраструктуры, мультитенантно, на VictoriaMetrics cluster / VictoriaLogs / VictoriaTraces, FastAPI, nginx и Postgres. Прод — один сервер: Debian 12, 4 CPU, 8 ГБ, четырнадцать контейнеров.

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

Это статья не про то, «как правильно проводить НТ» — таких статей достаточно. Она про то, какие именно виды нагрузки ломают систему приёма телеметрии, почему привычный сценарий «загоним 1000 rps через k6 и посмотрим на перцентили» проходит мимо всех трёх, и как выглядит воспроизводимый прогон, который эти отказы ловит.

Все цифры ниже — с живого сервера, не синтетика.

Привет, читатель! Посмотрим, как древнючий Broadwell аж из 2015 года выжимает все соки из своей подсистемы памяти (напомню, что это 1150 сокет с DDR3 оперативной памятью), приближаясь по её латентности к более современным решениям.

Автор, это явно какое‑то противоречие! Как процессор, работающий с оперативкой, старше многих школьников, умудряется догонять те же Skylake вроде i7-6700K?

Ответ кроется в той самой подсистеме памяти, а вернее в L4 кэше. Он же — eDRAM

eDRAM (embedded Dynamic Random Access Memory) изначально создавался как быстрый буфер, созданный для повышения ПСП (пропускной способности памяти) для встроенной графики Iris Pro 6200. Но если бы все было так просто...

Представьте картину: вы руководитель склада на пищевом производстве, вам нужно распечатать и раздать сотрудникам задания, а рабочий МФУ в очередной раз уходит в «циклическую кому». Добавьте в уравнение ещё одну переменную: в компании попросту нет не то что ИТ‑отдела — эникея, которому можно было бы поручить дебаг. И эта вакханалия происходит изо дня в день у всего нашего офиса.

Полгода на Arch, одно обновление ядра и AmneziaWG выходит из строя. Snapper молчит, бэкап сломан. Решил попробовать NixOS…

Я строю мультитенантную платформу мониторинга на стеке VictoriaMetrics + Grafana + vmalert: у каждого клиента — изолированный tenant в хранилище и собственный набор правил алертинга, которые он редактирует через личный кабинет. Расскажу про два сцепленных инцидента, которые изменили моё понимание изоляции тенантов, — с конкретными числами, конфигами и кодом фиксов. Спойлер: изолировать данные — этого мало.

У меня в проекте было четырнадцать копий одного IP‑адреса. По одной в каждом скрипте, который ходит на боевой сервер: деплой, перезапуск сервиса, правка DNS, диагностика почты. Классический копипаст, который живёт до первого переезда.

Переезд случился. Адрес поменялся. Четырнадцать скриптов стали указывать в никуда.

Дальше начинается то, ради чего я это пишу.

Для примера будем использовать наш продукт для просмотра топологии и верификации(EDA) и расскажем, как мы построили его лицензирование.

Каждый коммерческий продукт рано или поздно упирается в один вопрос: кому именно вы продаёте право пользоваться программой.

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

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

В этот момент плохо работает модель «один бинарь и проверка лицензии есть или нет».