В октябре беспилотники за четыре дня выбили три дата-центра Яндекса. Через пять дней после первого удара наш прод уже жил на собственной платформе: три зоны у разных провайдеров, контрольный узел в Амстердаме (чтобы было) и ни одного managed-сервиса.
ИИ резко упростил производство контента, и корпоративные базы знаний это почувствовали первыми. Инструкции, обучалки, расшифровки, саммари теперь размножаются быстро и без усилий.
Но количество — не значит качество, и уж тем более сомнительно, что огромный массив данных удобен для восприятия. Их нужно собрать в удобоваримый и понятный структурный маршрут.
В редакции МТС мы недавно разбирали проблему нейрослопа. Теперь на этом примере посмотрим, что за новая опция плейлистов появилась в MWS TeamStream и чем она отличается от привычных папок и пространств.
Сперва напомню, что такое MWS TeamStream. Это видеоплатформа для бизнеса с ИИ: вместо бесконечных созвонов вы записываете видео с экрана (при необходимости с собой в кадре) и комментируете происходящее. Сервис делает ИИ-расшифровку, интерактивные субтитры с таймкодами, саммари и много прочих удобных фич. Подробный обзор сервиса я уже делал. Если вы с TeamStream не знакомы, вам туда.
Почему спор «арендовать или владеть» снова открыт, при чём здесь HBM и на что способен младший выделенный сервер, если посадить его собирать ядро Linux в CI/CD?
Sextant — бесплатный open-source клиент Kubernetes на Rust и Tauri 2: всё, что вы делали в Lens, но без аккаунта, подписки и телеметрии. Его код целиком сгенерировал ИИ (Claude Code). Человек ставил задачи, принимал архитектурные решения и проверял каждое изменение, а тесты прогонялись многократно. В наших замерах Sextant запускается в 4–7 раз быстрее Freelens и Lens и занимает примерно вдвое меньше памяти. Есть встроенный MCP-сервер, через который AI-агента можно пустить в кластер только с выданными правами и с подтверждением каждого изменения. Под катом — как это устроено, цифры замеров и честно о том, где мы пока проигрываем.
Kind + Gateway API + Cilium в качестве Load Balancer
В этой статье я делюсь опытом развертывания и предлагаю заглянуть в настройку этой технологии — сетевой стек на базе Gateway API и Cilium, выступающего в роли балансировщика. Это практический стенд, демонструет возможности Cilium и декларативный подход к маршрутизации в локальной среде.
Единого подхода к тому, что считать широкополосным доступом к интернету (ШПД), не существует — требования отличаются от страны к стране. Различаются и проблемы, мешающие расширять покрытие: где-то все дело в изношенной инфраструктуре, на базе которой приходится строить новые сети, а где-то палки в колеса операторов вставляют (внимание!) железнодорожные компании. Посмотрим, с какими необычными трудностями сталкиваются телекомы в США, ЕС, Канаде и других странах, как можно их обойти, и какие планы по развитию ШПД строят у нас в России.
Лет десять назад я делал инструмент сверки таблиц для мультимастера — крайне неэффективным способом: брал снапшот и под ним просто шёл по таблице, матчил строки. С тех пор задача стала только актуальнее: одни и те же данные всё чаще живут в разных дата-центрах, на разных инстансах с надёжным failover’ом, и рано или поздно приходится задумываться о проверке их идентичности.
Готовые инструменты для сравнения таблиц в мире Postgres есть — pg_comparator, pgCompare, ACE. Однако давайте сегодня поразмышляем, стоит ли ради большей эффективности городить огород с дополнительным софтом. Может быть, хватит простой транзакции и golang-скрипта, выполняющего SQL на обоих инстансах?
У меня несколько кластеров Ceph с S3, они стоят в разных ЦОД, и у каждого свой адрес, свои пользователи и свои ключи.
Каждый переезд кластера превращался в обход всех сервисов с правкой конфигов, и в какой-то момент мне это надоело.
В статье расскажу, как я сделал для всех один адрес и балансер, который по access key сам находит нужный кластер, не трогая подпись и не зная секретов, как он переживает отказы, переезды и multisite, и почему в итоге по карте трафика у меня ездят машинки.
«Утром никто не может зайти: начало сеанса запрещено». «Пользователь ушёл домой ещё вчера, а его сеанс до сих пор висит и держит лицензию». «rphost опять съел всю память, перезагружаем сервер, как каждую неделю». Если вы хоть раз администрировали 1С, у вас сейчас дёрнулся глаз.
А потом я сделал то, от чего у любого безопасника поднимется давление: посадил ИИ-агента за большой рабочий кластер. Без RDP, из обычного чата. В тестовую базу, не паникуйте, но кластер настоящий: 16 баз, два сервера, 512 ГБ памяти. Пятнадцать минут диагностики, тринадцать минут разработки. Ниже протокол без купюр: что агент нашёл, где споткнулся, чего я ему не разрешил и что пока не проверял.
Честно сразу: инструмент, через который агент лез на сервер, мой. Называется Local Commander. Так что если вам покажется, что я его хвалю, дочитайте до раздела про то, что в нём надо чинить. Он длинный.
Можно ли запустить Kubernetes Pod без самого Kubernetes?
Познакомимся с Podman и попробуем на практике:
Запустить два контейнера из обычного Kubernetes YAML.
Проверить общий localhost и volumes.
Разобраться, где заканчиваются возможности Podman и начинается полноценная оркестрация.
Пользователи входят в систему, 1С открывается, файловые ресурсы доступны. С Active Directory, кажется, всё в порядке — и замена контроллеров на Windows Server 2008 или 2012 R2 снова откладывается. Более заметные задачи всегда найдутся.
Проблемы вылезают, когда инфраструктуру нужно изменить. Добавить современный контроллер, ужесточить LDAP, восстановить политики или автоматизировать выпуск сертификата. Тогда выясняется, что репликация каталога и SYSVOL живут своей жизнью, резервное копирование пропускает обработку гостевой ОС, время задаётся конфликтующими GPO, а приложения завязаны на давно устаревшие настройки.
Ниже — два обезличенных случая. В первом готовили домен с двумя виртуальными контроллерами Windows Server 2012/2012 R2. Во втором задача с HTTPS привела к проверке домена на 2008 и 2012 R2. На этих примерах видно, зачем разбирать AD заранее и почему новая Windows Server решает только часть задачи.
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. Однако из ста подтвержденных заказов в копии оказалось только десять.