Администрирование

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

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

В рамках этой статьи расскажу, как реализовалась идея о псевдорандоме и магии внутри пайплайна, и как я выложил инструмент который гадает «удачный ли будет релиз?» с помощью Таро на GitHub Market.

В 2025 году в Вирджинии несколько дата-центров разом отвалились от сети — и 1,5 ГВт исчезли за секунды. Оператор чудом избежал каскадной аварии. Проблема ЦОД для энергосети оказалась не в том, сколько они потребляют, а в том, как: рывками, синхронно и в пределах миллисекунд. Разбираемся, почему ИИ-нагрузка ломает привычную логику планирования сетей.

На днях Линус Торвальдс объявил о выходе Linux 7.2. Новое ядро получило улучшенный планировщик, ускоренную работу с файловыми системами, поддержку передачи данных между компьютерами через USB4 и множество обновленных драйверов. Значительная часть изменений касается оборудования AMD, Intel и Apple.

Одновременно разработчики продолжили избавляться от кода, который был нужен устаревшим процессорам и совсем уж древним девайсам. Речь идет не только об Intel^® i486^®, прощание с которым началось еще в Linux 7.1. Из ядра постепенно убирают поддержку целой группы старых x86-процессоров, которые мало где используются. Что ж, давайте обсудим.

Ситуация, знакомая многим командам: в кластере Kubernetes живут обычные бизнес сервисы, нагрузка на которые днём растёт, а ночью падает. Обычно используют два плохих варианта: держать статический пул нод под дневной пик, которые ночью простаивают и стоят денег, или положиться на cluster autoscaling — и тогда при дневном росте нагрузки бизнес-поды проведут в статусе Pending до создания новой ноды.

Проблема ожидания, пока Cluster Autoscaler развернёт новую ноду, решается паттерном node overprovisioning, настраиваемым через PriorityClass и механизмы Cluster Autoscaler: мы заранее запускаем ничего не делающие capacity-overprovisioning поды (в документации Kubernetes они называются placeholder-подами), которые занимают небольшую часть ресурсов нод. Когда приходит нагрузка и реплики бизнес-приложений увеличиваются — поды бизнес-приложений немедленно занимают освободившееся место, вытесняя capacity-overprovisioning под за секунды. Вытесненный capacity-overprovisioning под уходит в Pending, Cluster Autoscaler добавляет ноду.

Ключевая выгода паттерна — экономия. Ночью и утром, когда нагрузка падает, KEDA снижает число реплик бизнес-приложения, Cluster Autoscaler удаляет недозагруженные ноды, и кластер схлопывается до минимального числа нод. Утром при росте нагрузки capacity-overprovisioning поды отдают место мгновенно.

В этой статье разберём, как это устроено внутри, и развернём демо-стенд: от KEDA-автоскейлинга бизнес-приложения по RPS, который генерирует генератор нагрузки, до живого вытеснения capacity-overprovisioning подов, которое можно наблюдать своими глазами в kubectl get events.

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

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

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

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

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

Большой текст пугает: часть читателей уходит на середине, часть пролистывает не читая. Поэтому дальше — только факты, действия и последствия: что изменилось в метаданных, как это изменение попало в production и что в итоге получилось — результат, который до сих пор помогает находить источник проблем.

Представьте: пятница, 17:45, вы уже мысленно в пивной. И тут тишина... Мониторинг орет красным. Ваш Proxmox кластер из 4 нод превратился в группу статуй. Ни одна VM не отвечает, команды qm list висят, а в логах — таинственные вопросительные знаки на месте дисков.

😱 Диагноз: NFS-сервер упал, а монтирование было с опцией hard. Все ноды дружно вошли в D-state (непрерываемый сон) и отказались просыпаться.

Мораль: hard монтирование в NFS — это как клей Moment. Склеивает намертво. И оторвать потом невозможно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Судя по всему операции с доменом без Госуслуг будут доступны и после 1 сентября, успейте!

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

Или как получить полный доступ к изнанке CPU через скремблирование DRAM — PSP, C6, микрокоду, среде SMM и всему остальному, что не попало на страницы спецификации.

Всё-таки не всегда &x == &x...

Через вмешательство в работу контроллера DRAM можно сделать так, что обращение по определённому адресу будет вести в любую нужную область памяти. skitter-creek-bath-salts изменяет нижние слои структуры памяти, перестраивая трансляцию физический адресов DRAM. Такой скрэмблинг раскрывает защищённые области памяти, в том числе изолированные зоны, которые не видит даже само ядро. Когда ломается трансляция памяти, следом рушатся построенные на ней механизмы безопасности, и мы получаем доступ буквально ко всему.

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

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

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