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

Как это? У вас есть аккаунт на хабре, есть своё мнение по каждой статье, есть желание этим мнением поделиться с дедушкой, но нет своего мессенджера чтоб это сделать? Срочно исправляем.

Lim (local ip messenger) работает в вашей локальной сети, на вашем CHR или ARM64 роутере Mikrotik, без внешних сервисов. Обмен текстовыми и голосовыми сообщениями, файлами до 50мб. Публичным ключом собеседника шифруются: сообщения, файлы и имена файлов. И кнопка "Отправить", тоже зашифрована.

Если в кластере больше пяти Helm-релизов, рано или поздно появляется скрипт. Сначала десять строк с helm upgrade --install, потом sleep 30 между базой и приложением, потом sops ▎ -d values.yml | helm -f -, потом ветка if [ “$ENV” = prod ]. В какой-то момент никто не может сказать, что именно он раскатит на проде, пока он это не сделает.

▎ nelmwave заменяет этот скрипт одним манифестом

В статье рассматривается опыт миграции сети Kubernetes-кластера на новый IP-пул (Pool IP) с использованием CNI Cilium. Особое внимание уделено процессу смены IP-адресов для Pod'ов и Service'ов в работающем кластере без длительной остановки, а также подводных камнях, с которыми пришлось столкнуться при обновлении до версии 1.20.0. Материал будет полезен инженерам по эксплуатации Kubernetes использующих уже Cilium, а так же желающим познакомиться с этим инструментом.

NIST в июле 2025-го запретил требовать плановую смену паролей: SHALL NOT, раздел 3.1.1.2 финальной SP 800-63B. ФСТЭК в апреле 2026-го сделала её обязательной для госсистем и КИИ: 90 дней в системе, 30 на мобильных, с запретом на 12 последних паролей.

Разбираем три документа дословно: почему в самом приказе 117 слова «пароль» нет, где живёт требование, чем оно обернётся на оценке Кзи (штрафное обнуление группы показателей) и кого всё это не касается. Плюс таблица: парольные требования NIST и ФСТЭК рядом. Расходятся они меньше, чем принято думать.

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

EvaProject позиционируется как замена Jira. Рекламные лозунги, описания, презентации - это всё хорошо, но хочется сказать о проблемах, которые пользователь получит, когда начнёт пользоваться продуктом. Зачем? Эти проблемы не лежат на поверхности, не указаны в описании, не присутствуют в рекламных буклетах и, скорее всего, даже при первоначальной оценке EvaProject, будут упущены.

Пока идёт бинарный апгрейд nginx, systemctl reload nginx не применяет конфиг так, как вы думаете: в лучшем случае к половине процессов сервера, в худшем — вообще никуда. Код возврата ноль в обоих случаях, в error.log пусто. Что именно у вас — решает одна строчка в юните: -s reload бьёт по pid-файлу, а он после USR2 принадлежит новому мастеру; kill -s HUP $MAINPID бьёт по старому, а тот конфиг вообще не перечитывает, и это описано в документации nginx — в разделе про обновление исполняемого файла, куда по другому поводу не заходят.

Это первая из пяти проверок. Я взял пять ходовых утверждений про reload в nginx, померил каждое на стенде — и получил результаты по обе стороны: три подтвердились, два развалились. Развалившиеся оказались интереснее.

Не работают ровно те страшилки, что про слушающий сокет: listen ... reuseport бесшовность не ломает (inode’ы сокетов до и после reload одни и те же — их держит мастер, а не воркер), паузы в accept при reload не существует вовсе (msleep(100) стоит ПЕРЕД QUIT), а значит и арифметика про переполнение backlog на reload — про нагрузку, а не про reload.

Зато подтвердилось то, о чём почти не пишут. keepalive_min_timeout оставляет уходящего воркера в живых, и тот обслуживает запросы, которых в момент reload ещё не существовало — по старому конфигу. А ngx_close_idle_connections не различает направление соединения, поэтому каждый reload сбрасывает пул keepalive к бэкендам — и с 1.29.7 это касается всех, у кого есть блок upstream: пул там включён по умолчанию, 32 соединения на воркер.

Правило из первой части — «соединение, открытое до reload, нового конфига не увидит» — приходится переформулировать: держится старого конфига не соединение, а процесс.

В конце — Traefik, у которого reload’а нет вовсе, и который умеет не применить конфиг своим способом: кольцевой буфер на одно сообщение и двухсекундный дроссель.

nginx release-1.31.3, traefik v3.7.10, все опыты в репозитории, запуск одной командой.

Медные коммуникации дороги в обслуживании и энергозатратны — а в некоторых странах еще и регулярно становятся добычей охотников за металлом. Неудивительно, что телекомы массово переходят на оптоволокно: старую медь можно выгодно продать, а в бывших телефонных станциях устроить ЦОДы. На словах их поддерживают и руководства стран, но на деле не все так гладко: например, американскому AT&T отказаться от медных сетей в Калифорнии попросту не разрешили — дело дошло уже до суда. Посмотрим, что происходит с медной инфраструктурой в мире и при чем тут «поставщики последней инстанции».

Мощная и действительно "нано" по размерам – Nano Pi R3S. Это одна из крутых плат, которую можно купить по низкой цене и реализовать на ней много проектов - особенно если на ней стоит Docker!

Мне было интересно протестировать как там работает zapret и реализовать мою задумку с двумя сетями. Свободная и без блокировок сеть, которая еще и расширяет зону покрытия основной сети.

В настройках Chrome появился переключатель «ИИ на устройстве». Он относится к моделям, которые запускаются прямо на компьютере, причем, для целей довольно разнообразных (в частности, даже для обнаружения мошеннических сайтов). В каталоге профиля браузера при этом действительно лежат несколько гигабайт весов Gemini Nano. Хочется сказать: раз модель уже скачана, то встроенный Gemini должен работать локально - например, читать и пересказывать открытую страницу без обращения в облако!

Увы, для Google это оказалось не самым логичным решением. Более того, они даже с неймингом не справились до конца, чем здорово всех запутали.

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

Ask Gemini / Gemini in Chrome — облачный сервис. Когда вы просите его пересказать страницу или ответить на вопрос по открытым вкладкам, их содержимое передаётся в инфраструктуру Google.

Gemini Nano — локальная модель. Chrome скачивает её на компьютер и запускает на CPU или GPU. Отдельной кнопки «спросить Gemini Nano» у пользователя нет. Этой моделью пользуются сайты и расширения через специальные API Chrome, а также сам браузер — например, при первичной проверке подозрительных страниц.

25 марта 2026 года голосовая и видеосвязь Discord перестала нормально работать для большинства пользователей. Причиной стал не один большой сбой, а цепочка событий: изменение конфигурации Kubernetes привело к потере части пользовательских сессий, затем система столкнулась с лавиной переподключений и новыми узкими местами в инфраструктуре.

В статье команда Discord разбирает этот инцидент изнутри: как 17% остановленных сессий запустили каскадный отказ, почему механизмы восстановления сами стали источником нагрузки и какие архитектурные изменения помогли сделать систему устойчивее.

Разбираю тот же сценарий увольнения, который в прошлый раз хвалил за гейтинг и идемпотентность - но теперь прикладываю к нему приказ Роскомнадзора № 179 про подтверждение уничтожения персональных данных. Из пяти обязательных сведений журнал закрывает от силы полтора, экспорта нет вообще, а подпись под актом в любом случае ставит человек. Отдельно - почему резервная копия уволенного может жить бессрочно, даже когда с документами всё в порядке.

7 августа 2026 года появилась информация о TONTOU — новой технике атаки на механизмы защиты от Spectre v2. Интересна она не столько скоростью утечки — она как раз невелика, — сколько способом обхода защиты.

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

Назвали этот класс уязвимостей «TONTOU» — Time‑of‑Neutralization to Time‑of‑Use, по аналогии с хорошо известным классом TOCTOU (Time‑of‑Check to Time‑of‑Use). В TOCTOU объект успевает измениться между проверкой и использованием; здесь то же происходит с состоянием предсказателя — его нейтрализовали, но до следующего использования прерывание успевает снова его изменить.

За подробностями, а также за ответом, когда и что делать, прошу под кат.

Есть вещь, которую я до сих пор считаю лучшим, что случалось с развёртыванием Windows: ты подходишь к машине, выбираешь в начале всё, что тебе нужно, — и больше её не касаешься. Идёшь пить чай. Через несколько минут возвращаешься к готовому компьютеру с именем, в домене, с драйверами и софтом.

Это MDT. И его больше нет.

Дальше — история о том, как я в него влюбился, как он у меня разваливался, как я упёрся в стену, и что из этого получилось.

Деплой делает nginx -s reload. Команда возвращает ноль, nginx -T показывает новый конфиг, в error.log ровно одна строка — reconfiguring. А keep-alive соединение, открытое секундой раньше, в этот момент закрывается.

Само по себе это не ошибка: сервер вправе закрыть простаивающий keep-alive когда угодно. Ошибку даёт гонка — FIN уходит в тот момент, когда клиент уже записал в сокет следующий запрос. Идемпотентный он повторит, POST — нет.

Разбор по исходникам на фиксированных тегах: nginx release-1.31.3, httpd 2.4.68, traefik v3.7.10, плюс замер всех четырёх (с HAProxy) на одном стенде в одном прогоне. Выясняется, что мастер nginx конфиг не перечитывает вообще: он строит новый цикл целиком и форкает новых воркеров, а старым остаётся ровно то, что у них было. Apache приходит к тому же контракту через счётчик поколений, HAProxy — через замену процесса. А у одного из четырёх второй запрос в том же самом сокете возвращает уже новый конфиг — и причина не та, о которой вы подумали.

Внутри: почему документация nginx сама создаёт половину недоразумения; почему WebSocket и SSE не попадают под ngx_close_idle_connections и держат старого воркера сколько угодно долго, а HTTP/2 попадает всегда и получает GOAWAY; как сигнал родителя у Apache доезжает до конкретного соединения через пять звеньев; и таблица из двенадцати клеток, в которой четыре реализации расходятся ровно в одной.

Со стендом (один docker build, один docker run), полными выводами ps и тремя claims-*.tsv, где каждое утверждение о коде проверяется скриптом.

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

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

Это заключительная статья цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна.

В первой и второй частях мы разобрались с постановкой задачи и выбрали себе фаворита из локальных LLM, в третьей — занимались скучным проектированием HLD и LLD. Теперь же переходим к самому интересному — прикладному материалу. В этой статье рассмотрим, что получилось, когда архитектурный каркас начали последовательно превращать в рабочий self-hosted сервис в коде, и с какими узкими местами пришлось столкнуться в процессе.

DISCLAIMER: к сожалению, выпуск задержался, ведь основное место работы отнимает огромное количество времени, только отпуск позволяет вернуться к личным проектам.

Часть 1: Вводная и формирование ТЗ

Часть 2: Выбор локальной LLM

Часть 3: Формирование HLD и немного LLD

Часть 4: Что из этого вышло (Вы здесь)

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

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

В первой статье я говорил, что безопасность — это свойство архитектуры, а во второй разложил по полочкам способы построить logical air gap. Теперь самое главное: «А зачем вообще это всё? У нас есть firewall, WAF, TLS и патч-менеджмент».

Привет, это Данил Киселев, сетевой инженер в Yandex Infrastructure. Представьте себе, что у вас не просто офис, а очень большой офис с тысячами пользователей, которые ходят с созвона на созвон, перемещаясь между переговорками. Разумеется, им хочется оставаться на связи в процессе и не думать о ближайших точках доступа к Wi‑Fi. Для сетевого инженера это не выглядит проблемой на небольших масштабах. Но что если скоро ваш офис вырастет и таких точек доступа в сетевой фабрике может стать уже 20 000 и больше?

В статье расскажу про опыт использования технологии VxLAN в корпоративных сетях Яндекса. В частности речь пойдёт про построение Wi‑Fi поверх VxLAN‑туннелей, которые таким образом смогли помочь нам с большим доменом и заодно избежать широковещательного шторма.

Российский рынок observability парадоксален. У нас есть сильные продуктовые и внутренние инженерные команды, сложные заказчики, открытые технологии и редкое окно для развития собственного рынка. И одновременно десятки компаний параллельно оплачивают один и тот же фундамент: сбор, хранение, права, аудит, обновления, дедупликацию и корреляцию.

13,84 млрд рублей потерялись. Моя гипотеза: заметную часть этой суммы мы тратим на повторное создание одинаковых платформенных функций. Размер этой части ещё нужно измерить, но он точно существенен. И эта часть вместо мультиплицирования технологического задела в тиражируемых решениях российских вендоров остается технологиями для одного клиента.