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

Система удаленного доступа — это клиент, брокер, агенты на серверах. Все это нужно, чтобы десятки тысяч пользователей попали к нужным приложениям на нужных серверах с нужными политиками. Но когда соединение установлено, в дело включается протокол: будет ли картинка рваться при плохой связи, пробросится ли нужное устройство, будет ли соединение зашифровано по ГОСТ без костылей. Год назад мы в 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, временные ключи, один ноутбук на нескольких сотрудников.

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

Бэкапы с моих серверов уезжают в объектное хранилище, и стоило это около десяти тысяч в месяц. Потом пришло письмо, что средства заканчиваются, а по расходу за трое суток выходило уже сорок с лишним. Провайдер ни при чём: репозиторий раздулся до 291 ГиБ, из которых 190 были чистым дублем, а prune не отрабатывал вообще никогда — репозиторий был повреждён, плюс шесть виртуалок конкурировали за один эксклюзивный лок. Разбираю по шагам, что нашёл и как перестроил схему.

В этой статье будет разбираться резервное копирование и восстановление PostgreSQL. Покажу все на небольшом практическом docker-compose стенде. Я специально сделаю ошибочное изменение данных, после чего восстановлю базу до состояния непосредственно перед этой ошибкой.

Восстановление данных буду делать с помощью второго PostgreSQL контейнера. Если кратко - данные WAL и base_backup будут прокидываться с помощью volume и контейнер будет стартовать с новыми данными.

Пока что рабочий стенд будет ограничиваться PostgreSQL 17 в Docker (без S3, Kubernetes, автоматизации и т.п), потом возможно сделаю дополнительные статьи, охватывающие более сложные production случаи.

Строка из документации n8n про возобновление с места остановки читается как гарантия перезапуска с точки сбоя. Проверка привела в ветку форума 2021 года, где смысл настройки объясняют иначе, - и дальше ещё в пять вопросов к движку автоматизации перед необратимым шагом. Все ссылки и даты сверки (27 августа 2026 года) - в тексте.

Заявка была скучная: клиент не проходит проверку по списку разрешённых адресов. Адрес его я вижу, адрес в списке есть, файрвол пакет пропускает. Приложение отвечает «доступ запрещён».

В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.

Компьютер начал тупить в середине дня. VS Code переставал отвечать, новые вкладки редактора не открывались по минуте, а лимит подписки на ИИ-ассистента сгорал к обеду вместо конца недели. Виноватым оказался не ассистент, а плагин, который ведёт для него память между сессиями.

Строчка, которая встречается в скриптах повсеместно:

mysql -u admin -pSecretPass123 -e "select 1"

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

В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.

Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM — собственная система управления виртуализацией.

От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси

Если вы когда-нибудь поднимали свой MTProto-прокси для Telegram и он у вас "работает, но как-то не очень" — эта статья для вас. Я прошёл путь от "просто добавить relay" до "переписать всю цепочку на VLESS+Reality с нуля", и по дороге собрал приличную коллекцию граблей. Расскажу всё по порядку, чтобы вам не пришлось наступать на те же.

Исходная ситуация

Была задача простая на первый взгляд: поднять MTProto проксю для Telegram на сервере в РФ. Причина стандартная — хочется, чтобы телега работала

Взял mtg (ghcr.io/9seconds/mtg:2 — отличная реализация MTProto-прокси с поддержкой fake-TLS), поднял на сервере — и оно не работает. Точнее, работает, но еле-еле: то подключается, то нет, на мобильном интернете почти всегда фейл.

Первая мысль, которая приходит в голову почти всем в такой ситуации: "провайдер блокирует адреса Telegram". И это отчасти правда — но, как выяснилось, правда не вся.

Первая попытка: спрятать Telegram за релеем

Логика была такая: раз провайдер режет соединения именно к IP Telegram, то уберу эти IP из виду. Арендую второй сервер за границей, туда ставлю настоящий mtg, а на RU-сервере — просто TCP-релей (HAProxy или голый iptables DNAT), который прозрачно перекидывает байты дальше.

Клиент → RU-сервер (HAProxy, чистый TCP passthrough) → Зарубежный сервер (mtg) → Telegram

Казалось бы, логично: сервер в РФ теперь физически ничего не знает про Telegram, он просто гоняет байты во внешний IP. Провайдер не должен видеть ничего подозрительного.

И вновь я всех приветствую! Сегодня я бы хотел рассказать о такой теме как воспроизводимые приложения/сборки.