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

После многих лет домашнего использования попеременно то Debian GNU/Linux, то win10, у меня возникло желание побороть в себе консерватизм и поиграться с rolling-release дистрибутивом, но не debian-sid, это уже из чистого любопытства. Выбор пал на арч потому, что он удовлетворял критерию свежести софта и модели rolling-release, но не требует массы времени для сборки софта из исходников, как генту, плюс он достаточно популярен и у меня не возникло оснований выбрать что-то слишком малоизвестное. В юности не боялся и слаки, и ядро тогда собирать было не лень, но это было очень давно.

Устанавливал на комп с процессором intel core i9-10940, 96гб озу, 1 диск м2 ссд 1тб под систему и софт, 2 диск м2 ссд для данных (/var), 3 диск сата ссд 2тб для /home, видеокарта- nvidia 3090ti. Подключение к инету- по ethernet через роутер mikrotik hap ac2, так что при установке настройка wifi не потребовалась. В результате я хотел получить систему с оконным менеджером kde для домашних задач типа просмотра фильмов и переписки с друзьями, а также для работы, плюс хотел раздать через комп вайфай через amnezia+wireguard.

Привет! Меня зовут Руслан Мамлеев, я эксперт курса «Архитектор ПО» в Практикуме и технический директор (CTO) в GetFloorPlan. 

Недавно на фоне кризиса и сокращения бюджетов у нас ушёл DevOps. А вместе с ним исчезла и целостная картина инфраструктуры — только он понимал, какие серверы, домены и прокси у нас есть, где что живёт, какие доступы выданы, что мониторится, а что нет. Два месяца провели в хаосе. 

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

Бывают такие проблемы, о которых узнаешь не от новостной ленты или агрегатора, а на собственном опыте одним прекрасным утром. Например, включаешь ноутбук, а вместо входа видишь черный экран с кодом ошибки или с запросом ключа восстановления BitLocker, которого под рукой нет. И все это после того, как вчера ты обновил свой компьютер. С июньским накопительным апдейтом Windows 11 она стала реальностью для некоторого числа пользователей, в основном с бизнес-ноутбуками. Разберемся, кого это реально касается, а кого нет, и что делать.

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

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

Классический сценарий: весь учёт ИТ-активов вёл один человек – желательно в Excel, ещё желательнее в голове. Человек уходит, и выясняется, что никто толком не знает, сколько серверов в серверной, когда заканчиваются гарантии и где документы на закупку. 

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

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

VK Cloud активно использует РЕД ОС от РЕД СОФТ — в том числе в VK Secure Cloud, аттестованном контуре для значимых объектов критической информационной инфраструктуры (ЗОКИИ). На ее примере покажу, как поднять производительность гипервизора, просто обновив легаси и не трогая железо. Вместе с дистрибутивом на ноду приезжает свежий стек целиком: ядро, эмулятор, клиент хранилища, системные библиотеки. Каждый слой подтягивает свой кусок. А для тех, кто застрял на CentOS, ушедшем в EOL, у истории есть вторая часть: обновление закрывает технический разрыв и регуляторику одним движением. Ниже разберу механику по слоям с командами, которые можно выполнить на своей системе.

Статья про то, как я связал Obsidian с Claude и Codex через домашний сервер, CouchDB и MCP, а по дороге поймал баг, который тихо съедал куски заметок.

🔧 Это не про «как всё стало умным», а про нормальную историю с self-hosted, авторизацией, странностями LiveSync, мобильными клиентами, CORS, OAuth 2.1.

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

Заходите, читайте и делитесь своим опытом ❤️

Схема входящего траффика в кластер Kubernetes простая: web → Envoy Gateway → Ingress Nginx → backend. За Ingress Nginx, помимо обычного HTTP, живут долгоживущие WebSocket-соединения. Штатная нагрузка - около 100 RPS. Ничего экзотического.

В один прекрасный день всё в кластере легло. Клиенты получают 503/500. В логах Envoy - флаг UF и upstream_reset_before_response_started{connection_timeout}. То есть ingress-nginx просто перестал отвечать.

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

Привет, постоянные и не очень читатели!

Во второй части мы занимались самым неблагодарным этапом любого проекта миграции — подготовкой. Проводили аудит инфраструктуры, искали забытые зависимости, считали RPO и RTO, выбирали стратегии переноса и пытались понять, какие сервисы стоит переносить, а какие лучше оставить в прошлом вместе с Windows Server 2008.

Рано или поздно (скорее поздно) аудит закончится, миграционные волны согласуют, а руководство одобрит проект и бюджет. И тогда придётся переходить к самому опасному и сложному этапу — великой и ужасной миграции.

У Huawei Cloud Stack для этого под капотом есть целый стек инструментов: HCCCMS (нет, кнопку не заело) для миграции серверов и виртуальных машин, IMS для работы с образами, DRS (Data Replication Service) для переноса баз данных, CDM (Cloud Data Migration) и DataArts для миграции данных, а также великое множество сетевых и облачных сервисов из публичного облака Huawei Cloud.

Про них и поговорим.

19 июня Линус Торвальдс влил merge, который убрал из ядра Linux функцию strncpy — шесть лет работы, 362 коммита, семьдесят человек ради одной функции стандартной библиотеки C. Разбираю, почему «просто заменить небезопасную функцию» в C совсем не просто: strncpy только выглядит как «безопасный strcpy» из-за параметра n, а на деле это даже не строковая функция, а реликт fixed-width полей из AT&T Unix 1979 года. Главное в истории не сам выпил, а его цена: заменить нельзя автозаменой, потому что каждый из 362 вызовов требует понять намерение — нужна C-строка, padding или бинарное поле. Урок выходит за пределы ядра: в любой C/C++ базе на проде strncpy — это не баг, а код, который надо перечитать.

Как держать несколько проектов на одном VPS так, чтобы каждый работал на своём домене с HTTPS, а все порты были закрыты снаружи — без Kubernetes и ручных конфигов Nginx. Nginx Proxy Manager, Docker-сети и три реальных проекта на практике.

От CRUD на FastAPI до видеоплатформы: история одного pet-проекта

История о том, как учебный CRUD-проект на FastAPI постепенно превратился в стенд с микросервисами, мониторингом, Kubernetes.

История о том, как я загнал главную страницу форума с 88 запросов до 15, выяснил, что половину работы делал впустую один невинный аддон, и в конце снял ещё четверть серверного времени строчкой в конфиге — не сломав при этом ничего из того, что работало. А заодно — полная документация на стек из четырёх своих расширений и preload, на которых форум сейчас и держится.

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

Наша задача была достаточно прагматичной: понять, можно ли сократить время доставки конфигураций до минут, сохранив при этом контроль изменений, аудит и предсказуемость откатов. Пилот показал: подход работает. Но отсутствие полноценного dry-run и каскадные зависимости внутренних объектов вендора заставили нас попотеть. Под катом — разбор архитектурного подхода, а не инструкция «как перевести всё на GitOps за выходные». 

В домашней инфраструктуре у меня крутится десяток сервисов: Grafana, Zabbix, n8n, Navidrome, ollama, БД, пара дашбордов и тестовых API. Каждый раз, когда нужно было выставить новый сервис наружу, я открывал дашборд Cloudflare и руками проходил один и тот же путь: создать туннель, прописать ingress‑правило, добавить DNS записи, настроить Zero Trust Access. Минут пятнадцать, если без ошибок. С ошибками — больше, потому что один неверно скопированный tunnel ID ломает всю цепочку и приходится откатывать вручную.

На какой‑то раз стало понятно, что это рутина, которую можно свернуть в одну команду. Так появился cfzt — CLI на Go, который сейчас умеет:

zt up grafana 3000

И через несколько секунд grafana.domain.com смотрит на localhost:3000 через Cloudflare Tunnel, с настроенным Zero Trust Access и systemd сервисом, который переживет ребут.

Чуть больше месяца назад я впервые рассказал об IncidentRelay, open-source и self-hosted системе для дежурств, маршрутизации алертов и эскалаций.

В первой версии основная цепочка уже работала:

Monitoring -> Route -> On-call -> Notification -> ACK / Resolve

С тех пор проект добрался до v1.0.21-beta. Цепочка стала длиннее, но пользоваться системой стало проще. В отличие от некоторых корпоративных процессов, здесь усложнение действительно пошло на пользу.

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

В менеджерской среде есть изречение: «Управлять можно только тем, что можно измерить». Рискнем его дополнить — данных сейчас генерируется так много, что одного измерения уже мало: «…а эффективно управлять — лишь когда результаты измерений представлены наглядно». В предыдущих статьях про адаптивное администрирование Sigla Vision мы описывали, как собирать данные об изменении объектов BI-системы. Теперь покажем, как представить эти данные наглядно, и приведем примеры наших дашбордов — мы назвали их «системными», чтобы отличать от пользовательских.

Статья пригодится BI-разработчикам и ИТ-специалистам, которые развивают или сопровождают Sigla Vision и другие BI-системы.

Здесь мы разбираем, как системные дашборды помогают решать задачи администрирования Sigla Vision, и прикладываем код для PostgreSQL, который готовит таблицы-источники датасетов для комплексного дашборда «Состояние системы». В нем можно отслеживать, как меняются во времени количественные показатели по объектам: дашбордам, подключениям, ролям, пользователям, рабочим книгам, элементам корзины и т. д.

В марте 2024 года Redis сменил лицензию и, тем самым, положил начало развитию Valkey. Два года Valkey активно развивался: набирал количество контрибьютеров, коммитов, был встроен в многие проекты — в общем, показал себя на практике. Пришло время подвести итоги и понять: есть ли в этом сравнении победитель.

В статье разберем обе технологии. Будет немного про историю развития и хронологические предпосылки, разбор ключевых фич и почти детективное расследование о жизни двух хранилищ. Также, покажем за кем будущее (по нашему мнению) и зачем мы контрибьютим в одно из них.

Хочу рассказать про несколько новых возможностей AWS Elastic Container Registry (ECR), о которых, как мне кажеться, знают немногие.

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

На основе этой статьи была составлена и прочитана лекция на одном обучающем мероприятии для телекоммуникационной сферы.

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