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

8-11 октября после атак беспилотников пострадали три дата-центра Яндекса: Сасово, Калуга и Владимир. 11 октября Яндекс отключил в веб-версии Диска скачивание папок, альбомов и нескольких файлов сразу. У меня на Диске 1,8 TB файлов и еще около 160 GB фото в безлимите. Терять это не хочется, так что я сел делать бэкап.

План был простой: rclone, VPS в Нидерландах, Google Drive на 2 TB. На деле почти каждый шаг уперся в какую-то особенность Яндекса. Ниже по порядку: что сломалось, какие цифры получились и как обошел. Скрипты и инструкции выложил на GitHub, ссылка в конце.

Ночная смена. На мониторинге краснеет алерт — что-то опять не так на одном из серверов. Ты открываешь терминал, листаешь логи, лезешь в конфиги, пытаешься вспомнить, как именно три года назад настраивал этот сервис, грепаешь историю bash в поисках той самой команды… Знакомая картина?

Сегодня первый порыв — спросить ChatGPT. Он подскажет, где копать. Но давайте честно: он работает медленно и односторонне. Ты копируешь ему кусок конфига, он советует, ты идёшь применять, возвращаешься с результатом, он советует снова. Он не видит твои файлы, не правит inventory, не прогонит playbook и не перечитает логи после рестарта. Он — советник по переписке, а тебе нужен напарник в машинном зале.

Мне нужен был кто-то (или что-то), кто работает прямо в моём терминале, с моими файлами, под моим контролем. Но при этом — кто не выйдет за рамки дозволенного и не наломает дров на проде. Так я пришёл к агентам, а конкретно — к опенсорсному pi.

Эта статья — не обзор фич и не реклама. Это рассказ о том, как агент вписался в реальную работу инфраструктурного инженера: от написания Ansible-ролей до документации и настройки самого себя. С кодом, граблями и честными выводами.

Клиент написал: сайты лежат, похоже на DDoS. На сервере около 5 500 сайтов WordPress, nginx, PHP-FPM 8.4, MariaDB, 125 ГБ памяти, Debian 13. Я нашёл сканер, закрыл его в nginx, сайты поднялись. Через два дня клиент написал снова: всё падает каждые пять минут.

Причина оказалась не снаружи. Каждый новый воркер PHP-FPM с первого же запроса весил около 600 МБ, и OOM-killer по очереди убивал базу и nginx. Воркеры раздувал баг в OPcache, который срабатывает на каждом сбросе кеша под нагрузкой. Сбрасывал кеш Yoast SEO при обновлении. Причём не массовое обновление по всем сайтам, а догоняющее, на 467 сайтах, где плановое когда-то не прошло. Всё решил порядок двух команд.

Один VLAN на весь этаж, STP по привычке и размытая граница между L2 и L3 — решения, которые могут годами работать без нареканий, пока сеть не начнёт расти. А затем появляются неожиданные простои, неоптимальные маршруты и инциденты, в которых сложно найти источник проблемы. Разбираемся, какие ошибки в проектировании L2/L3 приводят к таким последствиям и как выстроить сетевую архитектуру, чтобы избежать их.

Пустыми фундаменты энергоцентра простояли недолго: в сентябре на них появились установки. Также в этом выпуске раскрываем решение, которое нас выручило.

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

Сравним результаты с данными за 2022, 2023, 2024 и 2025 года и посмотрим на динамику.

Цели, условия, методика и формат анализа остались без изменений, их можно прочитать в предыдущих статьях или спойлером ниже. Данные по каждой должности сравним с предыдущими периодами по количеству вакансий и по заработным платам.

В компании редко бывает один прокси. Обычно это пара Squid в основном ЦОДе, свои прокси в филиалах и отдельные внешние выходы для облачных сервисов. Клиенты при этом настроены просто: PAC‑файл с двумя адресами по порядку, и всё.

Беда в том, что «какой прокси лучше» зависит от сайта. Партнёрский банк пускает в API только с согласованных адресов, и выход питерского филиала в этот список не попал. Зеркало пакетов через европейский выход отдаёт втрое быстрее, чем через московский. Канал в филиале узкий, и выгрузка отчёта через него идёт минутами. Health check всё это не видит: прокси жив и отвечает, просто конкретный сайт через него не работает.

Fairway решает именно эту задачу. Он встаёт перед вашими прокси, копит статистику по каждой паре «домен, прокси» и на каждом запросе выбирает лучший выход для этого сайта. Это один бинарник на Go без зависимостей, с веб‑панелью внутри, под лицензией Apache 2.0.

Disclaimer: статья проверена по документации и репозиторию Uncloud для стабильной версии v0.20.0. Проект активно развивается, поэтому отдельные CLI-команды и Compose-возможности могут меняться между релизами.

Как всегда, всё начинается со специфического запроса от Заказчика: «Мы хотим забыть Kubernetes как страшный сон и вернуться к Docker Compose!».

На этом месте, наверное, многие DevOps-инженеры с пониманием улыбнутся. 

Но после ещё было: «Только, пожалуйста, сделайте так, чтобы было возможно масштабирование. И ещё бесшовное обновление приложений! Но чтобы остался Docker Compose».

В этот момент становится понятно, что задача перестает быть тривиальной.

А если оставить Docker Compose, но добавить к нему часть возможностей, ради которых в подобных сценариях начинают рассматривать Kubernetes? Оказывается, можно. Есть целый класс промежуточных решений: Docker Swarm, Nomad, Kamal, различные PaaS-инструменты, собственные deployment-скрипты. И еще — Uncloud.

Для небольшого проекта мне понадобилось настроить резервное копирование SQLite. База используется постоянно, останавливать приложение ради каждого бэкапа не хотелось. При этом копия должна сохранять все подтвержденные транзакции. Я рассматривала несколько вариантов: обычное копирование файлов, SQLite Backup API и VACUUM INTO.

Я начала с самого простого способа — скопировать только app.db. В скрипте для этого использовалась функция shutil.copy2(), то есть обычное файловое копирование. Копия создалась без ошибок, а проверка PRAGMA integrity_check вернула ok. Однако из ста подтвержденных заказов в копии оказалось только десять.

Во второй части история подходит непосредственно к VDI. Первая часть закончилась на терминальных серверах середины 1990-х: приложения вернулись на сервер, но каждый пользователь по-прежнему делил одну операционную систему с остальными. Разберемся, почему терминальных серверов оказалось недостаточно, как VMware научила x86 делать то, для чего эта архитектура вообще не проектировалась. Также рассмотрим, как из экспериментов заказчиков вырос отдельный класс виртуальных рабочих мест и почему его судьбу в итоге определили не только гипервизоры, но и протоколы удаленного доступа, BYOD, облака и пандемия.

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

Сегодня я проверю, можно ли с помощью MWS Tables полностью синхронизировать форму заявок, таблицу их хранения/контроля и таск-трекер в едином сервисе (спойлер: можно). 

Почти детектив: как в августе‑сентябре 2026 года массово взламывали гипервизоры Proxmox VE, прятали майнеры даже от root‑а, исправляли уязвимости на захваченных серверах и возвращались после восстановления инфраструктуры.

7 сентября 2026 года хостинг‑провайдер Netfront завершил восстановление кластера из 22 гипервизоров Proxmox VE. За предыдущую неделю злоумышленники получили административный доступ к серверам, внедрили руткиты, установили майнеры и проникли внутрь клиентских виртуальных машин. Администраторы восстанавливали системы из резервных копий, меняли пароли и SSH‑ключи, проверяли целостность файлов. После нескольких суток работы инфраструктуру наконец вернули клиентам.

За время расследования выяснилось, что на серверах побывали атакующие с как минимум тридцати трёх разных внешних IP‑адресов. Одни атакующие последовательно обходили узлы кластера, другие выполняли тысячи команд, третьи устанавливали средства скрытого доступа. На части гипервизоров системные утилиты перестали нормально работать: top аварийно завершался, команды зависали, а load average достигал 160 при отсутствии соответствующей вычислительной нагрузки.

В общем, администраторы Netfront не спали почти неделю, восстанавливая всё и вся. Однако вечером 7 сентября, вскоре после объявления о восстановлении инфраструктуры, злоумышленники снова вошли в кластер. В 20:31 началась новая подозрительная активность, а в 22:22 неизвестный пользователь запросил расписание резервного копирования и сразу после этого — список виртуальных машин, для которых резервное копирование не настроено. Позднее выяснилось, что атакующие заранее создали десятки API‑токенов и дополнительные учётные записи. Эти механизмы доступа сохранились в общей конфигурации кластера и пережили восстановление всех 22 серверов.

«Три зоны доступности» внутри одного облака не спасают, когда отказывает само облако. Собираем S3, который переживает отказ провайдера: один endpoint для приложения, за ним несколько облаков, переезд без простоя и без правок в коде. Всё на rclone — union, combine и serve s3. Два режима: старое облако работает или после аварии отдаёт данные только на чтение.

Подробный чек-лист, чтобы проверить, готова ли ваша инфраструктура к форс-мажорам.

Когда ИТ-инфраструктура даёт сбой, последствия ощущает весь бизнес: клиенты не могут оплатить заказ или воспользоваться услугой, сотрудники — получить доступ к рабочим системам. Причиной может стать высокая нагрузка, кибератака или отказ оборудования. 

Меня зовут Никита Демянчук, я руковожу группой технического взаимодействия с клиентами EdgeCenter. В этой статье разберу семь шагов, которые помогут проверить готовность инфраструктуры: найти слабые места, выбрать подходящие меры защиты и подготовиться к восстановлению после сбоя.

«Вайбкодинг» стал словом 2025 года, а каждый второй, мне кажется, стал вайбкодером именно в 2026 году. Codex, Claude Code, Cursor и даже KIMI за вечер могут написать тебе красивый и полезный сервис. Осталась ерунда — повесить его куда-то, чтобы работал и им могли пользоваться другие. Авось людям пригодится и денег принесёт... Под катом разберу, куда нести ваш классный пет-проект.

Админка Microsoft 365 и Graph не умеют главного — показать, что изменится, до того как изменится. Я делаю открытую утилиту, где любое действие сначала строит план «было → станет» и только потом применяет его, будь то Graph, Exchange PowerShell или LDAP. Вышла версия 2.0.

В статье — не обзор кнопок, а грабли, о которые пришлось споткнуться: Exchange PowerShell, который не работает на Mac, откат Conditional Access и Intune к снимку (где Intune подсовывает маски вместо секретов), и как запускать чужие PowerShell‑скрипты с админским токеном, не отдавая им всё.

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

Привет! Меня зовут Александр Щербаков, я DevOps-инженер в X5 Tech. В одной из прошлых статей я рассказывал о домашних серверах на потребительском железе. Сегодня поговорим о том, как моя лаборатория доросла до серверной платформы и двух CMP 50HX с 20 ГБ видеопамяти каждая.

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

Патч UniqueKeys для PostgreSQL предлагает научить планировщик распознавать случаи, когда строки запроса уже гарантированно уникальны. Сейчас он (планировщик) не всегда может это определить и выполняет лишнюю работу: повторно проверяет данные на дубликаты, хотя в этом нет необходимости, или упускает более дешеый план выполнения. Механизм UniqueKeys позволяет прослеживать уникальность данных через сложные соединения и подзапросы, чтобы исключать ненужные операции DISTINCT и GROUP BY и точнее оценивать стоимость запросов. В Tantor Postgres этот механизм уже реализован, а патч предложен для рассмотрения сообществом PostgreSQL в рамках CommitFest.

За одной командой docker run скрывается целая последовательность операций с файловой системой Linux. Но что потребуется, чтобы воспроизвести их вручную? Пройдём путь от создания пространств имён и настройки rootfs до запуска приложения в собственном контейнере, используя стандартные инструменты Linux.