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

Всем привет, это команда Ринго! Уже не первый год Apple публикует Deployment Guide — руководство для системных администраторов, охватывающее развертывание, настройку и управление техникой Apple. После каждой WWDC в нём появляется раздел «Что нового?», и в этом году основная повестка не про новые возможности, а про потери. В  macOS 27 перестанут работать привычные MDM-команды управления обновлениями.

Разбираем ключевые изменения из What’s New for IT at WWDC26: что приходит на смену старым командам, какие декларации появились для сетевых настроек и статусов устройств и что следует проверить в инфраструктуре до массового обновления парка. Сервисы, официально недоступные для организаций, зарегистрированных в России (Apple Business Manager, Volume Purchase Program и другие), мы намеренно оставляем за скобками — говорим только про управление macOS 27.

Представьте, разработчики добавили прозрачное шифрование в файловую систему, собрали ядро и прогнали Fio — пропускная способность не изменилась. Однако после раскатки на продакшен производительность резко упала. Дело не в том, что бенчмарк ошибся: он честно измерил предел быстродействия жесткого диска, а накладные расходы на шифрование остались скрыты за дисковыми задержками. Так и возникает одна из самых типичных ошибок storage-бенчмаркинга.

Хранение до сих пор кажется многим инженерам простой подсистемой: файловая система, блочное устройство, метрика throughput. На практике это одна из самых коварных частей стека — с иерархией памяти в 4–8 порядков разницы между самой быстрой и самой медленной операцией, слоями виртуализации (LVM, программные RAID, NFS) и переключениями контекста между ядром и user-space.

Чтобы разобраться, как корректно измерять производительность систем хранения, обратимся к докладу Эреза Цадока, профессора Университета Стони-Брук, возглавляющего Лабораторию файловых систем и хранения данных.

Все подробности — под катом.

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

IDM стал таким местом — и почти сразу мы уперлись в проблему. Очередь на подключение к IDM начала превышать количество уже подключённых систем, а фич-реквесты от команд копились быстрее, чем мы успевали их разобрать. Инструмент против хаоса сам стал источником хаоса.

В одном чате по куберу меня спросили единственное, что реально важно, когда ты собрал оркестратор контейнеров внутри таблицы: а сколько оно вообще тянет? Сколько подов, пока не ляжет. Какой образ влезает в ячейки. Сколько кластеров держит одна машина. И — раз уж мы фонд с серьёзным лицом — как это смотрится рядом с настоящими: Kubernetes, Docker Swarm, Nomad.

Поэтому мы провели честное нагрузочное тестирование. Четыре измерения, два бэкенда (.xlsx на диске и живая Google-таблица), синтетика на ноутбуке и реальные Docker-образы на облачной виртуалке. А потом поставили цифры рядом со взрослыми оркестраторами.

Короткая версия: по каждой оси, которая имеет значение, мы проигрываем на 3–5 порядков. По осям, которые значения не имеют, — выигрываем вчистую. И один наш давний «факт» оказался неверным — бенчмарк нас поправил. Поехали.

Есть класс фич, которые выглядят на одну строчку в тикете и на неделю в реализации. «Хочу, чтобы статус-страница жила на моём домене» — из таких. Клиент добавляет CNAME status.client.ru → status.your-service.com, и дальше начинается интересное: кто выпустит сертификат для чужого домена, кто его продлит, как не дать одному пользователю положить всю схему мусорными доменами и почему X-Forwarded-For может превратить внутренний эндпоинт в публичный.

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

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

Вечером 02.09 у нас не вышел плановый пост в TenChat. В логе задачи планировщика — ничего осмысленного, просто ненулевой код возврата и алерт «слот не закрыт». Разбор растянулся на весь вечер, потому что там оказались не одна поломка, а три, и каждая маскировала следующую.

KubeVirt или готовая платформа? Мы сравнили Deckhouse Virtualization Platform с «ванильной» версией по-честному: API-ресурсы, миграции, хранилища, сеть, безопасность. Получилась таблица на десяток с лишним отличий. 

Собрали в одной статье всё, что реализовали поверх KubeVirt, чтобы инженеры не тратили время на настройку и интеграцию: от sizing-политик до проброса USB в ВМ.

Привет! Я Владимир Мокроусов, сисадмин в группе компаний «Синтека». Мы создаем софт для строительной отрасли и активно используем в работе ИИ-модели. 

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

У вас есть бэкапы? Хорошо, лёгкий вопрос. А когда вы в последний раз восстанавливали из них хотя бы один файл? Вот она неловкая пауза, понимаю… Между «бэкап есть» и «бэкап восстанавливается» находится пропасть, и в неё регулярно падают даже большие компании. Под катом две страшилки из реальной жизни и разбор того, как проверить свои бэкапы до того, как восстанавливать их придётся на боевом сервере.

У Яндекса есть публичная страница с 18 техническими мерами защиты Яндекс 360, и у части пунктов рядом с текстом стоит вкладка, где написано, каким методом API и с каким правом доступа эту меру проверить. Я прошёл её построчно и посчитал: вкладка «Проверка через API» есть у 10 пунктов из 18, вкладка «Настройка через API» — у 5.

Александр Жогов, основатель и руководитель компании +Альянс. И справка, и референс API открыты: весь счёт повторяется поиском по двум строкам в машинной выгрузке страницы, методику показываю целиком.

В Docker Desktop 4.86 пункт Docker VMM в настройках остался прежним, а движок под ним поменялся целиком: с версий 4.35–4.85 за ним стоял libkrun, с 4.86 собственный гипервизор Docker. Публичная бета анонсирована 12 августа, доступна на Mac и Windows.До этого Docker Desktop всегда опирался на чужой VMM: libkrun на технике Apple, Hyper-V или WSL на Windows, а Linux-версия собрана на KVM и QEMU.

Отсюда и разница в поведении между платформами, которую все давно принимают как данность.

Когда ты пишешь собственный кодек удалённого рабочего стола, последнее, что хочется услышать от человека из конкурентов:

Недавно я рассказывал про Sheeternetes — оркестратор, у которого control plane живёт в таблицах. Здесь — про следующий логичный шаг: паттерн «оператор», применённый к самим таблицам. Настоящий полноценный Sheeternetes-оператор. Не скрипт внутри таблицы, а внешний контроллер, который приводит табличку к желаемому состоянию.

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

31 августа в 14:32 по Москве у нас вышла последняя штатная публикация. Дальше cron честно стартовал по расписанию, генератор успевал выбрать тему и написать текст, но в ленте ничего не появлялось. Так повторилось четыре раза: три запуска 1 сентября и утренний запуск 2 сентября.

В один из дней в лаборатории раздался звонок. Звонил представитель организации, оказывающей услуги системного администрирования. Его первым вопросом было: «А вы умеете работать с ZFS?». Разумеется, мы пояснили, что у нас есть некоторые наработки в рамках собственных исследований, а также стандартные средства DR‑лаборатории, такие как PC-3000, где поддержка ZFS предусмотрена как минимум на базовом уровне.

Ответив на парочку каверзных вопросов клиента об устройстве ZFS, мы через некоторое время получили два SSD Samsung 870 EVO ёмкостью 2 ТБ, которые были объединены в зеркальный RAID‑массив (Mirror). Изначально комментарии сводились к тому, что оба диска рабочие, но один выпал из массива. Основная проблема заключалась в том, что был случайно удалён один из важных Zvol (блочный объект ZFS, используемый для виртуальных дисков). Клиент пояснил, что хотел откатиться к прошлой версии uberblock’а и получить снимок, когда этот Zvol ещё не был удалён, но у него это не получилось. Резервная копия сохранилась, но она была сделана ещё в апреле этого года.

Приветствуем, Хабр.

У нас вышла долгожданная новинка, посвящённая методологии «SRE» — Site Reliability Engineering. Книга называется «SRE. Новый подход к управлению инфраструктурой». Написал эту книгу выдающийся инженер Павел Рудницкий, автор «Инфраструктурного блога», разработчик с 25-летним стажем, практиковавший DevOps, когда это ещё не было мейнстримом.

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

Три месяца вместо запланированного одного. 360 попыток запуска модуля VPN, которые заканчиваются таймаутом без единой подсказки в логах. «Осиротевшие» мастер-ключи, которые формально проходят все проверки, но ломают миграцию на ровном месте. И дистрибутив ключей, который отказывается формироваться из-за одного просроченного ММК.

Звучит как список кошмаров сетевого инженера? Это наш реальный опыт перехода с ViPNet Administrator 4-й версии на ViPNet Prime. Без прикрас, с полным набором граблей и неожиданных поворотов. Если вы только собираетесь в этот путь — эта статья сэкономит вам недели работы и несколько седых волос.

Администратор выгружает список активов в Excel, распечатывает ведомость, берёт ручку — и идёт по этажам. На каждом этаже сверяет глазами, что стоит на столе, с тем, что написано на бумаге. Возвращается, вносит пометки руками. Если что-то не сошлось — идёт ещё раз. Через неделю, а то и две, ведомость с галочками и вопросительными знаками ложится на стол ИТ-руководителю.

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

Мониторинг зелёный, балансировщик отвечает, сертификат на месте — а пользователи пишут, что портала нет. Через сорок минут выясняется: часть клиентов получает новый адрес, часть — старый. Разъехался DNS. Разбираемся, почему резолвер стоит считать частью контура управления доступом, а не подписью к IP.