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

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

Осенью 2023 года на KubeCon в Чикаго Тим Хокин, один из тех, кто стоял у истоков Kubernetes, говорил со сцены о том, что Kubernetes становится сложнее с каждым релизом, и эта сложность не бесплатна, потому что каждая новая фича, нужная лишь кому‑то одному, ложится грузом на всех остальных; разработчики проекта всё хуже удерживают в голове всё целиком, а инженерам, которые его эксплуатируют, всё труднее разобраться во всех его настройках. Хокин предложил относиться к сложности как к бюджету, который у проекта есть и который можно потратить, но только один раз, а значит, надо научиться отказываться от того, что этот бюджет съест без достаточной пользы.

Меня эта мысль зацепила, потому что мне показалось, что у неё есть продолжение, о котором со сцены сказано не было. Если сложность, нужная машинному обучению, сетевым устройствам или промышленным контроллерам, не помещается в бюджет ядра проекта, то ей всё равно нужно какое‑то место, где она будет жить, никого не обременяя. В мире Linux такое место давно нашлось. Ядро там остаётся ядром, которое знают и трогают руками немногие, а вся специфика уходит в дистрибутивы, и никто не ждёт от Торвальдса, что он лично позаботится о роутерах, медицинских томографах и игровых консолях.

Предыдущий разбор закончился тем, что из клиентского пути убрали периодическую яму: раз в десять минут прокси проверял мёртвую первую ступень, клиент оплачивал эту проверку несколькими секундами ожидания и уходил, не получив ни одного байта. Окна исчезли, сообщение «прокси использует некорректные настройки» больше не появлялось — а через несколько часов телефон снова начал терять соединения. Лог при этом выглядел безупречно: ни одной строки ERROR за девять часов, ни одного перезапуска процесса, 2 415 клиентских сессий и 482 МБ скачанного трафика.

Дефект нашёлся по подписи из четырёх чисел: сессии, которые апстрим закрывал ровно за 0.1 с, после ~800 байт вверх и 8–28 байт вниз, и все до единой — на прямой ступени. Причина оказалась не в прокси, а в том, как из этой сети устроен путь к Telegram: из 1 270 проверенных адресов мессенджера по TCP отвечает ровно один, и это не дата-центр, а служебный узел, к которому к тому же действует молчаливый лимит на одновременные соединения. Телефон открывает пачку из тринадцати сокетов — семь проходят, шесть гаснут без единого ответного пакета. Ни один лог приложения такого не покажет.

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

15 августа я показал здесь Telemax — мост, который приносит переписку из MAX в Telegram. Пост прочитали 14 тысяч раз, под ним набралось 48 комментариев.

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

Разбанили меня только через месяц. Эта статья — о том, как прошёл этот месяц, как проект пережил его без GitHub и что из ваших комментариев за это время стало обновлениями.

После атаки на дата‑центр Яндекса в Сасово я решил на всякий случай сделать резервную копию данных с Яндекс.Диска и обнаружил, что часть файлов в галерее не открывается: в приложении «Ошибка сервера», на части миниатюр код 500. Скачивание некоторых оригиналов отдает ошибку 504, при этом часть обычных файлов (не из «галереи») также стала недоступна. Подобное поведение проявляется на большей части файлов после вывода из строя утром 11 октября датацентра Яндекса во Владимире. Разберёмся: какие из этих файлов реально не скачиваются, а какие просто теряют превью, как проверить свой Диск и почему копия вне облака не лишняя.

Привет, Хабр! Меня зовут Павел, я старший разработчик ML-платформы в Авито и последние полтора года занимаюсь MLOps. 

На прошедшей Kuber Conf я выступал с докладом про нашу платформу распределённого обучения, а теперь решил сделать на его основе статью для вас. Если вам комфортнее воспринимать такие доклады в формате видео — держите.

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

ML-платформа Авито. Как всё начиналось

В те времена, когда в Авито работало не так много дата-сайентистов, они использовали разнородные инструменты. Главным из них был так называемый DevBox — выделенная машина, на которую специалист заходил по SSH, делал свои дата-сайентистские дела, обучал модели, собирал датасеты и прочее. Время шло, число спецов росло (равно как и отделов), и мы не придумали ничего лучше, как добавить ко всему этому ещё и LLM. У неё была своя специфика в плане инструментария, и в целом жизнь она не сильно облегчила.

Так началась эволюция нашего пути — от обычного доступа к машинам по SSH, когда коллеги полностью блокировали их и выполняли задачи вручную, до нашей полноценной cloud-native-платформы, которую мы назвали Aviflow.

Сразу отмечу, что fail2ban нельзя использовать как полноценный инструмент защиты доступа к управлению маршрутизатором. Доступ к службам управления по‑умолчанию должен быть закрыт фаерволом из всех сетей за исключением management. И, возможно, с адресов из локального «белого списка». Fail2ban, применяется к management‑интерфейсу на случай, когда злоумышленник уже получил доступ в подсеть управления. Либо в подсети управления оказался вирус, троян, нелояльный пользователь. Также бывали случаи, когда трафик управления мог пропускаться из‑за ошибки в правилах фаервола. Итак, fail2ban, это скорее последний уровень защиты управления маршрутизатором.

Для начала создаем скрипт, который будет выполнять работу по поиску и извлечению адреса из тела сообщения системы «$message». Помещаем скрипт в системную библиотеку скриптов /system scripts на маршрутизаторе и присваиваем скрипту название «loginfail2ban».

Вы когда-нибудь задумывались над смыслом названия этой файловой системы? А между тем ключевая фича, с которой все начиналось, — это как раз кэширование.

В цифровую эпоху приватность и надёжность хранения данных важны как никогда.

Сетевое разделение и недоверенные посредники ломают взаимодействие: санкции, ковровые блокировки, атаки на инфраструктуру, глухомань.

Владельцы серверов владеют данными: могут их свободно читать, сливать, менять, удалять.

Наблюдается кризис доверия к софту и запрос на импортозамещение.

Техно-гильдия Giper.Dev приняла этот вызов, и вот что у нас получилось...

HAProxy должен выполнять проверки, чтобы определить роль экземпляров PostgreSQL: мастер или реплика, чтобы направлять соединения на подходящие сервера. В статье описываются способы настройки HAProxy для обнаружения переключения ролей экземпляров PostgreSQL через Patroni REST API, через параметр in_hot_standby, передаваемый сервером сразу после аутентификации клиента, или запросом select pg_is_in_recovery(); Два последних способа используются, если Patroni поставлен на паузу или не используется.

Привет, Хабр! Меня зовут Илья. Долгое время я работал в финтехах и у облачного провайдера. Занимался сопровождением информационных систем, причём не как инфраструктурщик, а как специалист по поддержке целых автоматизированных систем. То есть смотрел на ИТ не с уровня отдельного сервера, а с уровня «работает ли сервис для бизнеса и клиента».

И сразу, пока вы не пролистали до конца, вопрос к вам.

Друзья айтишники, вспомните момент, когда DRP действительно понадобился. Что пошло не так? Бэкап, который не восстановился? Резервная площадка, на которой «забыли» один сервис? Регламент, который лежал на той самой упавшей файловой шаре? Напишите в комментариях свои фэйлы. Чужие ошибки учат лучше любых методичек, а для кого‑то ваш комментарий станет поводом проверить свой план до аварии, а не после.

А теперь поговорим о том, как строятся планы DRP и почему наличие документа ещё не означает, что вы восстановитесь.

Недавно часть наших клиентов не могла подключиться к серверам Монеты. Мы проверили межсетевые экраны, собрали трассировки с обеих сторон, но причина оказалась за пределами нашей инфраструктуры. При этом сайты самих клиентов тоже стали недоступны, а уведомления о платежах на Pay URL перестали доходить. Диагностика привела нас к участку сети, где работает ТСПУ.

На связи Евгений, инженер отдела сопровождения разработки и эксплуатации ПО (DevOps-инженер) в Монете. В статье разберу, как проверить такую гипотезу и не спутать её с другими сетевыми проблемами, какие данные собрать для обращения и что делать, если заявка в ЛК ВТС уже получила статус «Частично принята», а доступ так и не восстановился. Покажу весь путь на реальном кейсе: от curl, traceroute и nping до переписки с ЦМУ ССОП и ДЦОА — без смены хостинга и IP-адреса.

Максимальный срок публичных сертификатов с марта этого года сократился с 398 до 200 дней. С 2029 года они будут действительны всего 47 дней, а забыть о продлении проще простого, ведь есть и более важные дела. Под катом собрал семь способов удобно следить за сроками SSL.

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

При эксплуатации сервера пользователь сталкивается сразу с несколькими показателями температуры процессора. У него возникает ряд вопросов: какие из них имеют практическую пользу? На что ориентироваться? При какой температуре должен срабатывать алерт и когда действительно пора беспокоиться о перегреве?

Под катом рассказываю про основные показатели температуры в серверных процессорах Intel и разбираю практическую пользу каждого для конечного пользователя.

Привет. Я Александр Донин, я технический менеджер платформы VDI и терминального доступа Termit.  В прошлой статье мы рассказывали, почему делаем собственный протокол удаленного доступа Pulsar с нуля, а не форкаем Open Source. Это не значит, что мы вообще против Open Source — используем его, когда это экономит время и не создает проблем: например, в Termit мы используем PostgreSQL для хранения данных и NGINX как веб-сервер, да и начинал Termit с RDP и X2Go. Транспорт в Pulsar — это еще один пример, когда компонент Open Source дал нам как раз то, что требовалось, и вошел в протокол в виде модуля.

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

Telegram отключал прокси с сообщением, которое выглядит как приговор конфигурации: «Подключённый Вами прокси-сервер использует некорректные настройки и будет отключён». Конфигурация при этом была в порядке — ноль ошибок в логе, ни одного перезапуска, 1 876 сессий и 933 МБ трафика за три часа.

Причина оказалась не в настройках, а в логике ретраев самого прокси: защита от мёртвой первой ступени фолбэка раз в 10 минут открывала окно, в котором клиент не получал ни одного байта. Размер окна квантуется по таймауту (4.5–8.8 с при --ws-connect-timeout 4), величина периода задаётся --ip-fail-cooldown. Лечится двумя значениями в конфиге: максимум задержки падает с 8 849 мс до 531 мс, обрывы с нулём байт — до нуля.

Внутри: как причина была найдена по логам, воспроизведена пробником, повторяющим поведение клиента Telegram, — плюс A/B на двух одинаковых сборках и инженерные выводы по конструкции этого стенда.

Привет, Хабр! На связи команда Рег.облака. С начала октября у российских пользователей Claude снова начали блокироваться аккаунты. Для тех, кто пользуется моделью время от времени через браузер, потеря доступа неприятна, но не катастрофична. Гораздо сложнее ситуация у команд, которые уже встроили Claude в рабочие процессы. Например, подключили через API к внутреннему боту, coding-agent, RAG или автоматической обработке документов.

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

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

15 сентября Cloudflare обновил правила доступа ИИ-ботов к сайтам. Блокируя сбор данных для обучения, можно заодно закрыть поиск: некоторые боты выполняют обе задачи. Я разобрал исследование Seensure по 1 046 сайтам. После обновления запросы от имени обучающих ботов стали блокировать чаще, а поисковых — реже. Это тест с подставленными именами, поэтому он не доказывает доступ настоящих краулеров. Настройки стоит проверить по категориям, а реальный доступ — по логам запросов.

Представьте кластер Kubernetes, в котором нет ни одной сетевой карты. Его узлы ничего не знают ни о TCP/IP, ни даже об Ethernet и перекликаются по радио короткими пакетами по 32 байта, как прорабы по рациям на стройке. Управляющий слой написан на языке конца восьмидесятых и вместе с сетевым протоколом занимает около 1250 строк. Чтобы запустить под, ничего не нужно скачивать: узел просто загружает модуль и вызывает в нём процедуру. А главное, всё это открывается во вкладке браузера: можно выдернуть узел из розетки, заглушить эфир, подсунуть кластеру поддельную команду и посмотреть, что из этого выйдет.

Такой кластер я собрал за последние несколько недель и назвал его Kube. Это управляющий слой Kubernetes, написанный на Обероне, языке Никлауса Вирта, и работает он на машинах Оберона, то есть на процессоре и операционной системе, которые Вирт спроектировал сам, от схемы до окон на экране. Узлы Kube тоже машины Оберона, и разговаривают они по радиосети из той же книги: Вирт написал эту сеть для своих рабочих станций ещё в конце восьмидесятых, а в новой редакции проекта её перевели на дешёвый радиомодуль.

Когда я работал над своим проектом, всю информацию об инфраструктуре (серверы и их роли, хостинги, даты следующих оплат, DNS-записи...) я хранил в файлике на рабочем столе. Сначала это был обычный текстовый документ, чуть позже — таблица в LibreOffice Calc.

Пока серверов было меньше десятка, а хостингов — от силы два, мне было несложно раз в неделю сверять информацию в таблице с DNS-серверами, хостингами и собственным бэкендом.

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