Обновить

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

Сначала показывать
Порог рейтинга

Передача параметров ssh с помощью суффиксов имени хоста

В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).

Host tproxy
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:

  • изнутри с переадресацией портов,

  • изнутри без переадресации портов,

  • снаружи с перадресацией портов,

  • снаружи без переадресации портов,

для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.

Сущность предлагаемой доработки

Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.

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

Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
  Hostname srv-10-79.rtk.company.com

Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
  ProxyJump gate-10-1+yota

Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:

Match originalhost "tproxy,tproxy+*"
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602

В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.

Match originalhost "*+rsa,*+rsa+*"
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa
Теги:
Всего голосов 6: ↑6 и ↓0+9
Комментарии0

Если вы сидите на MacOS / iOS и у вас VPN на VLESS+XTLS‑Reality, то при очередном обновлении системы/VPN-клиента с высокой вероятностью всё сломается или уже сломалось. Это не баг Shadowrocket и не баг xray-core. Apple ввела квантово-безопасное шифрование TLS 1.3 по умолчанию в iOS 26 / macOS 26, которое увеличивает размер TLS ClientHello на ~1216 байт. REALITY-сервер xray-core не может корректно прочитать такое большое сообщение — отсюда firstLen = 0 и отсутствие соединения. Windows это не затронуто. Простого/универсального решения нет, т.к. откат на предыдущую версию в экосистеме Apple — тот ещё квест. Если ваше клиентское приложение VPN позволяет настроить TLS → Fingerprint, тогда там необходимо выбрать firefox или Crome110 — для которых ещё не было поддержки X25519MLKEM768. В этом случае всё легко чинится.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии2

Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов

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

В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.

Если хотите закрыть базу по Linux и автоматизации

Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)

Если работаете с контейнерами и Kubernetes

Если отвечаете за стабильность систем

Если зона ответственности включает защиту инфраструктуры

Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии0

GitOps без романтики: эксплуатация, советы, решения

Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.

В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.

Что на повестке

Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.

Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.

Смотрите видео на площадках:

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Теги:
Всего голосов 25: ↑23 и ↓2+21
Комментарии0

Седьмая локация для облачных серверов

Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.

Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.

Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.

Уже доступно в панели, проверяйте →

Теги:
Всего голосов 11: ↑11 и ↓0+16
Комментарии0

Puppet 8 for DevOps Engineers — книга, после которой лучше понимаешь инструмент

Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.

И книга оказалась просто 10 из 10.

Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.

Что внутри:

Сначала автор рассказывает историю создания Puppet и задачи, ради которых он создавался. Потом переходит к философии: почему он устроен именно так, как работает декларативный подход, зачем нужна идемпотентность и почему это важно для управления инфраструктурой.

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

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

Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.

Так же в этих главах становится понятно что автор не просто пользуется Puppet, а является частью его команды разработки. Отсюда и такой уровень погружения в разные аспекты инструмента.

По итогу:

Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.

Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.

Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Представлен аналог Discord — открытый проект GoofCord, который:

  • быстрее официального клиента, не глючит и не тормозит;

  • внутри заблокирована вся слежка и сбор данных о пользователе;

  • переписка шифруется паролем;

  • демонстрация экрана в любом разрешении и с любой частотой кадров;

  • можно выбирать, звук какого приложения стримить;

  • игры, музыка или видео встают в ваш статус автоматически;

  • плагины для кастомизации Vencord, Equicord и Shelter работают из коробки;

  • глобальные хоткеи работают даже со свёрнутым окном;

  • можно стримить со звуком на Linux, работает также на Windows и macOS.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Открытый проект Go Interview Practice содержит обширный репозиторий для подготовки к собеседованиям на Go:

  • внутри — целая интерактивная платформа с задачами всех уровней. Могут готовиться как новички, так и профи.

  • ИИ‑интервьюер проверяет решения и сразу дает подсказки.

  • есть таблица лидеров, чтобы соревноваться с топами и видеть свой прогресс.

  • можно задать вопросы коммьюнити, если задача оказалась слишком трудной.

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Почему у Bitcoin несколько типов адресов и в чём их отличие

Большинство пользователей просто копируют Bitcoin-адрес и отправляют средства, не особо задумываясь, почему одни адреса начинаются на 1A1zP1..., другие на 3J98t1..., а третьи выглядят как длинный набор символов вроде bc1qw508....

На практике это не “разные виды биткоина”, а результат эволюции самой сети Bitcoin. Каждый новый формат адресов появлялся как попытка решить конкретные проблемы: высокие комиссии, ограниченную пропускную способность, сложность транзакций или недостаточную эффективность сети.

Самые старые Bitcoin-адреса - это Legacy-адреса. Обычно они начинаются на 1. Это первый массовый формат адресов в сети Bitcoin, который использовался ещё задолго до появления современных обновлений. Главный минус таких адресов сегодня - менее эффективная структура транзакций, из-за чего комиссии обычно выше.

Позже появился формат SegWit. Чаще всего такие адреса начинаются на 3. Его главная задача была довольно практичной: уменьшить размер транзакций и снизить нагрузку на сеть. Благодаря этому комиссии стали ниже, а сама сеть - эффективнее. По сути, SegWit стал одним из самых важных обновлений Bitcoin за последние годы.

Следующий этап - Native SegWit или Bech32. Именно эти адреса начинаются на bc1. Сейчас они считаются более современным вариантом для обычных переводов. Такие адреса занимают меньше места в блоке, ещё сильнее снижают комиссии и лучше подходят для современной инфраструктуры Bitcoin. Именно поэтому всё больше кошельков и сервисов по умолчанию используют формат bc1.

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

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

Именно поэтому один пользователь может отправлять BTC на адрес формата 1A1zP1..., другой на 3J98t1..., а третий на bc1qw508... - и все они всё равно работают внутри одной сети Bitcoin.

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии2

Открытый проект SecretScanner помогает парсить пароли, API‑ключи, токены и другие ценные данные из приложений. Сервис проверяет Docker образы и файловую систему, чтобы отыскать секреты. Внутри у каждой программы есть целая база важной инфы — можно почерпнуть множество полезностей.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Добрый день, уважаемые коллеги!

Прошу прощения за задержку тары сообщения, но новость о прекращении разработки и сопровождения pgbackrest более неактуальна: https://github.com/pgbackrest/pgbackrest#maintenance-update

Спасибо @Harliff: https://habr.com/ru/articles/820349/#comment_29976278

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии1

Нужна ли кувалда, чтоб вынуть один кривой гвоздь?

Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.

Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.

И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.

Полный откат – не всегда ответ

С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.

Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.

Не «всё умерло», а:

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

Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.

А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.

Почему полное восстановление неудобно

Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».

Для аварии это нормально.

Для точечной ошибки – не всегда.

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

Получается выбор без хорошего варианта:

1️⃣ откатить больше, чем нужно;

2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;

3️⃣ вручную разбирать, что именно поменялось.

Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.

Что хочется иметь на практике

В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».

А что именно изменилось между текущим состоянием каталога и снимком:

– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.

И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.

Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.

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

Где здесь РЕД АДМ 2.1 и Granulex Recovery

В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.

Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.

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

Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.

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

Теги:
Всего голосов 7: ↑4 и ↓3+1
Комментарии0

Так получилось, что мне приходится работать с достаточно древними серверами (причины оставаться на старом железе и софте разные, но достаточно веские). Я и так стараюсь держаться на два шага позади переднего края (чаще всего это Debian oldoldstable), но иногда приходится делать резкий шаг вперёд (обновляться до oldstable, который скоро oldoldstable станет).

Вот и сейчас обновил кое-что с Bullseye на Bookworm. И получил при попытке зайти со старого OpenSSH 5.3 на новый 9.2 “no hostkey alg”. В новой версии OpenSSH по умолчанию отключены алгоритмы ssh-rsa и ssh-dss (первый из-за небезопасного хеша SHA1, второй из-за общей проблемности DSA); а старые версии ещё не умеют rsa-sha2-256, rsa-sha2-512 (не говоря уж об эллиптических кривых).

К счастью, эти алгоритмы ещё не удалены напрочь! Поэтому для обеспепчения возможности подключения старого клиента OpenSSH 5 к новому серверу OpenSSH 9 достаточно записать такие строки в файл /etc/ssh/sshd_config.d/local.conf (и перезапустить sshd):

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

В обратную сторону тоже работает, чтобы иметь возможность заходить новым клиентом OpenSSH 8 (и выше) на старый сервер OpenSSH 5 (и ниже) достаточно прописать такие три строки в файл ~/.ssh/config:

Host old-server
        Hostname 1.2.3.4
	. . .
        HostKeyAlgorithms +ssh-rsa
        PubkeyAcceptedKeyTypes +ssh-rsa
        KexAlgorithms +diffie-hellman-group14-sha1
Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Ближайшие события

Напрямую или через бот-платформу: как лучше интегрировать чат-боты

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

1. Прямая интеграция с каналом 

➕  Полный контроль над функциональностью — например, в случае VK можно обрабатывать не только запросы в личных сообщениях, но и комментарии под постами, на стене, под фото.
➖  Разные API, авторизации, ограничения и нюансы. Требуется закладывать время на поддержку каждого канала.

2. Интеграция через Botmother

➕  Визуальный конструктор — менять сценарии могут не-разработчики. Один сценарий обработки обращений достаточно просто раскатать на разные каналы.
➖  Меньше гибкости в тонкой настройке маршрутизации и аналитики по сравнению с другими платформами.

3. Интеграция через Fasttrack

➕  Расширенные шаблоны ответов, точная маршрутизация по командам, продвинутая аналитика.
➖  Сложнее в настройке сценариев в отличие от того же Botmother.

Что же в итоге? Можно остановиться на способе 2-в-1. Для отдельных сценариев — прямая интеграция, в других случаях — через бот-платформу. Так сделано у одного крупного клиента ITSM 365.

Подробнее про кейс, нюансы в поддержке интеграций и практические шаги по внедрению — в полной версии статьи на Хабре.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

K2 Cloud курирует трек “Облака” на ДевФест 21-22 мая


21-22 мая в Омске пройдёт ДевФест 2026, партнером которого стал K2 Cloud. Мы будем на площадке оба дня: со стендом, спикерами и целым тематическим треком “Облака”, который курируем в программе конференции.

В треке поговорим про архитектуру, безопасность, CI/CD, бесшовные релизы, dogfooding, облако в облаке, BI-конструкторы и федеративное обучение. За доклады отвечают эксперты из K2 Cloud, Авроры/ОМП и Битрикс24.

И приятный бонус для тех, кто уже открыл вкладку с билетами: промокод BESTCLOUDEVER даст 10% скидки.

Сам ДевФест пройдет 21 и 22 мая с 10:00 до 18:00, а наш облачный трек – в оба дня с 11:00 до 14:00. Программу конференции можно посмотреть на сайте, а расписание трека дополнительно вынесем сюда:

21 мая

11:00 – JWT в геораспределённой архитектуре: аутентификация пользователей веб-консоли мультирегионального облака (Никита Трунов, K2 Cloud)

Никита разрабатывает инфраструктурные сервисы K2 Cloud на Python и работает с логированием, мониторингом, безопасностью и управлением пользователями. В докладе он разберёт, как устроить аутентификацию в мультирегиональном облаке: где JWT помогает, какие сложности появляются при синхронизации и в каких случаях стоит смотреть в сторону альтернативных или комбинированных подходов.

12:00 – Бесшовные релизы глазами разработчика: обновляем код Облака без отключения API (Игорь Анохин, K2 Cloud)

Игорь как руководитель платформенной разработкой в нашем облаке расскажет про особенности обновления высоконагруженной системы без остановки API. В фокусе будут эволюция релизных подходов от Big Bang до Rolling-Out, требования к коду, миграциям и контрактам, а ещё компромиссы, без которых бесшовность не работает.

13:00 – CI/CD Flutter-приложений для ОС Аврора (Ирина Житницкая, Аврора/ОМП)

Ирина занимается тестированием и CI/CD-процессами публичных проектов ОС Аврора. Она покажет, как перевести сборку Flutter-приложений под ОС Аврора из ручного процесса в прозрачный pipeline, какие архитектурные решения помогают сделать его воспроизводимым и где чаще всего возникают проблемы.

22 мая

11:00 – Архитектура BI-конструктора Битрикс24 (Александр Сербул, Битрикс24)

Александр занимается архитектурой и разработкой высоконагруженных отказоустойчивых проектов в Битрикс24. На примере BI-конструктора он разберёт путь от проектирования до запуска облачного сервиса: архитектурные решения, масштабирование, развитие команд и практическое применение Python и Kubernetes.

12:00 – Ешь, молись, люби своё облако: Dogfooding как драйвер развития (Александр Чернев, K2 Cloud)

Александр участвовал в запуске KaaS и PaaS-платформ K2 Cloud, работал над релизными процессами, тестированием и стабилизацией платформы. В докладе он расскажет, как мы используем собственное облако для разработки и тестирования: зачем нужен dogfooding, как работает “облако в облаке” и как внутреннее использование продукта помогает быстрее находить слабые места.

13:00 – Сломанные веса: как разное железо мешает федеративному обучению и что мы можем с этим сделать (Максим Мухамедов, K2 Cloud)

Максим – Python-разработчик в K2 Cloud, который до разработки успел поработать с инфраструктурой датацентра на физическом уровне модели OSI. Он разберёт, как особенности железа, сенсоров и версий ОС искажают данные в федеративном обучении ИИ, почему возникает system-induced bias и какие подходы помогают отличить проблему данных от проблемы устройства.

Если будете в это время Омске, обязательно заглядывайте к нам: будем ждать вас на стенде и докладах!

Теги:
Всего голосов 7: ↑6 и ↓1+5
Комментарии1

VDI в Termit на базе zVirt: как оптимизировать рутинные операции по работе с ВРМ

19 мая Orion soft проведет технический вебинар с демонстрацией функциональности VDI в платформе виртуализации рабочих столов и приложений Termit. Системный инженер Дмитрий Руссу покажет, как выполнять рутинные операции в Termit максимально быстро и эффективно.

На вебинаре подробно рассмотрим:

- Как развернуть виртуальное рабочее место Windows и Linux

- Как подготовить золотой образ и экономить время на создании ВРМ

- Как объединять ВРМ в ресурсные группы и управлять ими

- Как создать каталог и работать с ним

Только для участников вебинара — проведем опрос о пожеланиях по функциональности следующих релизов Termit. Лучшие предложения реализуем, а их авторам подарим эксклюзивные паки мерча Orion soft.

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

Кому будет интересно:

- Системные администраторы

- Инженеры (по виртуализации, VDI, ИТ-инфраструктуре, ИБ, технической поддержке и др.)

- Архитекторы (виртуальной инфраструктуры, рабочих мест и др.)

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

Сервер для PyTorch: как выбрать конфигурацию под обучение и инференс

PyTorch запустится почти на любом сервере, но между «запустится» и «работает стабильно под нагрузкой» — большая разница. Частая ошибка — выбирать VRAM по размеру модели, но видеопамять занимают контекст, KV-cache, размер батча и служебные расходы фреймворка. 

В новой статье разобрали, когда хватает CPU и в каких сценариях нужен GPU. Показали, как заранее проверить совместимость драйвера NVIDIA и версии CUDA, как эмпирически измерить фактическое потребление VRAM и сколько RAM закладывать под DataLoader с несколькими воркерами. И собрали ориентиры по конфигурациям — от прототипирования и небольшого инференса до обучения на 2–4 GPU и больших моделей.

Все подробности — в блоге Рег.облака.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы

Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML. 

В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком. 

Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы: 

  • «Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс) 

  • «ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech) 

  • «Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon) 

  • «Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud) 

  • «ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк) 

  • «Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)

Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.

Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.

Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.

Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.

Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.

  • CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.

  • TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.

  • Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.

  • SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.

  • QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.

Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.

Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.

Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.

TG @CIOlogia

Теги:
Всего голосов 7: ↑7 и ↓0+7
Комментарии0

Здесь многих морщит, когда они видят откровенно ИИ-шный текст, недостаточно хорошо отражающий суть того о чем он как бы написан. НО!

Вот появилась тут буквально вчера статья на тему "старый ноутбук, мало памяти, zram, swapspaces".
Явно - писана с помощью ИИ, и как справедливо было замечено - из серии "как нарисовать сову": долго готовим рабочее место и инструменты, потом рисуем один глаз, второй, ну а потом остальную сову.

Провисела она тут весьма недолго, пока писал комментарий - ее закидали помидорами и убрали. Тем не менее, по сути статья полезная: я взял и попробовал.
И оно, оказывается, работает, и даже неплохо. Просто автор не дописал, как "дорисовать остальную сову".

Автор, если ты это видишь - сделай людям доброе дело, распиши подробнее.
Я б сам написал - но получится, типа украл чужую статью, а это не очень красиво.
Но тема-то интересная...

Теги:
Всего голосов 7: ↑7 и ↓0+9
Комментарии20