Реальные потери: почему CI «тормозит» ещё до предела канала
Когда GitHub Actions выгружает артефакты на удалённый Mac, команды чаще всего увеличивают тариф или меняют провайдера. Между тем каждый запуск rsync поднимает полный стек: DNS, TCP, обмен ключами SSH, аутентификацию и канал, а при использовании SFTP — ещё и согласование подсистемы. Короткие задачи с высокой частотой превращают фиксированные задержки в основной бюджет времени, особенно на трансокеанских линках, где RTT доминирует над полосой.
ControlMaster удерживает мастер-сокет и подключает последующие сессии к уже готовому туннелю, резко снижая повторные рукопожатия. Это бесценно для тысяч мелких файлов. Но все процессы с одним ControlPath делят одну очередь на уровне SSH: два параллельных job из матрицы могут ждать друг друга, хотя диск и CPU шифрования простаивают.
Параллелизм нужно проектировать: отдельные учётные записи, порты или каталоги ControlPath для команд, окружений или типов сборок. Это пересекается с MaxSessions в sshd на Mac: агрессивный multiplex может дать отказ по лимиту каналов, который выглядит как нехватка дисковой подсистемы.
Stateful NAT и балансировщики добавляют тишину: пока job локально архивирует гигабайты, прикладные байты не идут, и промежуточное устройство сбрасывает состояние TCP без явной ошибки в rsync. ServerAliveInterval на клиенте и ClientAliveInterval на сервере должны укладываться в самое короткое «окно тишины» на пути, а не в привычки внутренней команды.
Каталог с сокетами ControlPath — часть периметра безопасности: слишком открытые права раскрывают метаданные сессии, а агрессивный cron-очиститель может снести активный сокет. Если в путях артефактов встречаются персональные идентификаторы, журналы нужно проектировать с учётом требований к обработке данных.
У GitHub-hosted runner и self-hosted runner разная география исходящих адресов: публичные IP могут меняться между job, что влияет на политику pinning и на частоту «странных» обрывов multiplex без явного кода ошибки в rsync. Зафиксируйте эту особенность рядом с выбранной схемой multiplex, иначе оптимизация, проверенная в лаборатории, рассыплется при первой смене egress-пула.
На удалённом Mac полезно смотреть троттлинг при нескольких одновременных зашифрованных потоках: с точки зрения CI это похоже на сетевую деградацию, хотя узкое место — частота CPU и политика охлаждения, а не полоса канала. Сопоставление графиков загрузки с метриками TCP избавляет от ложных выводов о «плохом провайдере».
Наблюдаемость: три слоя без смешивания сигналов
Разделите L1 (DNS, маршрут, MTU, сырое TCP), L2 (доля попаданий в multiplex, возраст мастера, глубина очереди) и L3 (скорость rsync, коды выхода checksum-шлюзов, задержка записи на APFS или внешний том). Оптимизировать L3, пока L1 и L2 «плавают», почти бесполезно.
Экспортируйте счётчики hit/miss multiplex в ту же систему метрик, что и CI: резкое падение после минорного обновления OpenSSH на runner или на Mac — сигнал тревоги надёжнее субъективных жалоб. Сопоставляйте временные ряды с хэшем вывода ssh -G, чтобы отличить регрессию бинарника от ошибки в шаблоне ssh_config в образе.
Каждому алиасу Host нужна карточка: окружение, удалённый пользователь, политика pinning, длительность ControlPersist. В ночном инциденте это спасает от путаницы между прямым входом и цепочкой ProxyJump, где мастер-сокеты легко перепутать, если имена файлов не кодируют маршрут.
Снимайте агрегированную статистику hit/miss повторного использования мастер-сокета в ту же временную базу, что и длительность job: резкое падение доли попаданий после минорного обновления OpenSSH на runner или на стороне macOS — более надёжный индикатор регрессии, чем субъективные жалобы в чате.
При dual-stack фиксируйте отдельно ошибки первого коннекта и стабильность уже поднятого мастера: смешение симптомов затягивает RCA и подталкивает к «лечению» keepalive там, где проблема в выборе AAAA/чёрных дыр у провайдера.
Если выгрузка идёт через корпоративный forward-proxy, добавьте в карточку Host признак «через прокси» и отдельный набор метрик: multiplex может маскировать повторные рукопожатия до прокси, но не уберёт его лимиты на одновременные туннели.
Цифры и ловушки измерений
Типичное рукопожатие через океан часто 120–400 мс; десять коротких синхронизаций в минуту съедают минуты только на установление соединений, даже если мгновенный throughput высокий. После multiplex повторные сессии стартуют быстрее, но потолок полезной скорости задаёт окно TCP, контроль перегрузки и стоимость AEAD на Apple Silicon.
Корпоративные NAT часто обрывают простой через 300, 600 или 900 секунд без прикладных байт. Если этап подписи или сжатия длится дольше, зафиксируйте выбранные интервалы keepalive в runbook вместе с обоснованием: аудиторы просят трассу решения, а не «магическое число из гайда».
Крупные tarball меняют узкие места: последовательная запись, внешние диски, конфликт rsync --inplace с атомарной выкладкой. Здесь multiplex почти не помогает — смотрите материал о целостности и разнесении staging/production каталогов, чтобы шлюзы не ложно срабатывали при пересоздании мастера.
Любое изменение keepalive сопровождайте тикетом и коротким нагрузочным тестом: пять минут A/B часто показывают регрессию, когда runner завершается раньше, чем SSH успевает сбросить буферы.
Перед критичными передачами добавьте явную проверку DNS, если у runner агрессивный кеш и в окне миграции меняется адрес цели: короткий ControlPersist снижает риск «прилипнуть» к устаревшему peer, пока резолвер ещё отдаёт старый RR.
В журналах префиксируйте строки идентификатором job и именем Host из ssh_config: при аудите проще доказать, какой сетевой путь довёл артефакт, не раскрывая полную структуру каталогов на удалённой машине.
После каждого инцидента фиксируйте не только корневую причину, но и время, ушедшее на различение multiplex, NAT и диска: эти минуты — фактическая стоимость владения и аргумент при обсуждении перехода на управляемый Mac с заранее описанными политиками.
Асимметрия маршрутов вверх/вниз иногда проявляется только на длинных сессиях: короткий health-check проходит, а залив артефакта утыкается в другой MTU или политику shaping на обратном пути. Держите в runbook пару диагностических команд на обе стороны линка, чтобы не списывать всё на «битый» мастер-сокет.
Если в артефактах встречаются персональные данные, проектируйте журналы с возможностью выборочного редактирования под 152-ФЗ и внутренние регламенты: «удобный» verbose-лог часто оказывается дороже, чем кажется на этапе настройки.
Матрица решений
| Сценарий | Multiplex | Плюс | Минус |
|---|---|---|---|
| Много мелких инкрементов | ControlMaster auto + короткий ControlPersist | Меньше хвостовой задержки | Риск битого мастер-сокета |
| Плотная матрица на одном runner | Разделить ControlPath или отключить | Нет очереди в SSH | Больше рукопожатий |
| Долгие загрузки с шлюзами | Отдельный CI-пользователь | Меньше реконнектов | NAT требует активных keepalive |
| Люди и роботы в одной учётке | Разные Host | Меньше операционных ошибок | Больше веток конфигурации |
| Жёсткий compliance | Короткий persist или off | Уже окно экспозиции | Выше CPU на handshakes |
Практическая последовательность
# Фрагмент ~/.ssh/config для CI
# Host rm-ci
# HostName remote.mac.example
# User ciupload
# IdentityFile ~/.ssh/id_ed25519_ci
# ControlMaster auto
# ControlPath ~/.ssh/cm/%r@%h:%p
# ControlPersist 8m
# ServerAliveInterval 25
# ServerAliveCountMax 5
# ConnectTimeout 12
# rsync -av --partial -e "ssh -F ~/.ssh/config" ./dist/ rm-ci:~/artifacts/
Шаг 1 — честная база. Три одинаковых rsync без multiplex, с замером фазы подключения (фильтрованный ssh -vvv или обёртка времени). Зафиксируйте CPU и IO, чтобы не оптимизировать не тот уровень.
Шаг 2 — жёсткий каталог. Создайте ControlPath с правами 0700 только для пользователя runner; логируйте метаданные без лишних путей, если в именах есть чувствительные идентификаторы.
Шаг 3 — стресс параллельности. Запустите два job матрицы одновременно: если второй ждёт первый на уровне SSH, делите алиасы или отключайте multiplex для этого профиля.
Шаг 4 — согласование keepalive. Выровняйте клиентский ServerAliveInterval и серверный ClientAliveInterval по самому жёсткому NAT; отметьте, есть ли балансировщик L7 на пути.
Шаг 5 — крипто-якорь. Зашейте StrictHostKeyChecking и отпечатки в образ runner: multiplex не должен маскировать интерактивный запрос из-за внезапной ротации ключа.
Шаг 6 — идемпотентность шлюзов. Скрипты checksum должны переживать пересоздание мастера: файловые блокировки, отдельные временные каталоги на job, критерий успеха по итоговой сумме, а не по длительности сессии.
Шаг 7 — аварийный алиас. Держите Host без multiplex, проверяйте его в квартальном учении с обрывом мастера во время шлюза.
Замечание про rsync -z. Сжатие может съесть CPU на быстром канале; измерьте, прежде чем включать его вместе с multiplex, иначе выигрыш по сессиям съест стоимость упаковки.
ProxyJump. Кодируйте в имени ControlPath наличие bastion, иначе прямой заход может схватить чужой сокет — классический источник «не воспроизводится у меня».
Conntrack и stateful-фильтры. Проверяйте лимиты таблицы отслеживания на шлюзе: «тихие» обрывы часто совпадают с исчерпанием conntrack, а не с дефектом rsync. Keepalive здесь лишь симптоматическое лекарство, если таблица переполнена.
Канареечное обновление sshd. При минорном bump на Mac держите параллельный runner с отключённым multiplex одну ночь: регрессии MaxStartups, лимитов каналов или политик macOS проявятся изолированно и не смешаются с очередью SSH.
Сглаживание пиков. Флаг rsync --bwlimit полезен для снижения пика на внешнем SSD и одновременно уменьшает вероятность, что балансировщик воспримет длительный залив как простой и обрежет сессию в самый неудачный момент.
Игры на отказ. Раз в квартал прогоняйте учение: убить мастер-сокет во время checksum-шлюза и убедиться, что скрипт завершился предсказуемо, артефакт помечен корректно, а повторный job не заливает мусор поверх частично записанного дерева.
Согласование с бизнесом. Командам контента и продакшена достаточно таблицы «окно обслуживания, ожидаемая скорость, порядок отката»; детали ControlPath оставьте в инженерной wiki. Multiplex — инструмент надёжности, а не тема для еженедельного статуса, если его ценность не переведена на язык SLA.
Версии на концах. Зафиксируйте в образе runner хэш пакета OpenSSH и снимок ssh -V с удалённого Mac: расхождение patch-уровня иногда меняет поведение keepalive и согласования шифров без заметного changelog в вашем приложении.
Очереди на стороне GitHub. Помните, что задержка старта job не равна задержке SSH: сравнивайте метрики очереди Actions с метриками multiplex, иначе оптимизация сокетов не сдвинет пользовательский перцентиль, если узкое место — пул runner.
Ротация ключей. Спланируйте ротацию host key и пользовательских ключей так, чтобы на период окна существовал алиас без multiplex или с укороченным persist: иначе старый мастер продолжит жить с устаревшим контекстом доверия и даст загадочные отказы на строгом StrictHostKeyChecking.
Мониторинг диска. Добавьте алерт на свободное место в каталоге ControlPath и в целевом томе артефактов одновременно: нехватка inodes на APFS выглядит как «зависший» rsync, хотя сеть и multiplex здоровы.
IPv6 и брандмауэр. Если включили AAAA, проверьте, что правила на промежуточных узлах симметричны для TCP/22 или нестандартного порта: асимметрия даёт джиттер первого подключения, который ошибочно списывают на «плохой» multiplex.
Документация изменений. Любой тюнинг ServerAliveInterval фиксируйте не только в git, но и в runbook с привязкой к измеренному окну тишины NAT: через полгода никто не вспомнит, откуда взялась цифра 25.
Связанные материалы и runbook
Сначала закрепите идентичность хоста по known_hosts, затем согласуйте лимиты сессий и keepalive с параллельным SFTP. Для джиттера первого подключения читайте IPv6, а целостность артефактов связывайте с контрольными суммами. Вернитесь на главную, чтобы сравнить управляемые Mac.
Встройте эти ссылки в внутреннюю wiki линейно: ночной дежурный тратит меньше минут на поиск «той статьи про known_hosts».
Добавьте в runbook чек-лист перед крупным релизом: сверка версий OpenSSH, ревизия алиасов, пробный заход по аварийному Host без multiplex, проверка квот и прав на каталог сокетов. Эта рутина занимает меньше часа и экономит ночи на хаотичных откатах.
Если используете внешнее хранилище для артефактов, опишите порядок размонтирования: неаккуратный unmount во время активного мастера может оставить полузакрытые дескрипторы, которые CI воспринимает как сетевой сбой.
FAQ и вывод
Как долго держать ControlPersist?
Сопоставьте с реальным ритмом job и политикой ИБ; фиксируйте в runbook, а не в локальном ~/.ssh.
Работает ли с ProxyJump?
Да, но имена ControlPath должны явно отличать прямой путь и bastion; тестируйте обе ветки при обновлении OpenSSH.
Стоит ли включать rsync -z вместе с multiplex?
Измеряйте: на быстром канале сжатие может съесть CPU сильнее, чем сэкономит время; на медленном uplink выигрыш может быть ощутимым, но тогда следите за троттлингом на Mac.
Как отличить проблему multiplex от лимита MaxSessions?
Multiplex даёт очередь на уровне клиента; лимит sshd — отказ или задержка при открытии новых каналов даже при здоровом мастере. Снимите sshd -T и сравните с фактической веерностью job.
Нужен ли отдельный пользователь CI?
Да, если люди и роботы делят учётку: иначе ручной вход может снести или перезаписать сокет, а отладка займёт часы.
Итог. Multiplex — мощный рычаг против налога на рукопожатие, но не замена зрелой политики NAT и идемпотентных шлюзов. Мастер-сокет — stateful-компонент: владелец, срок жизни, метрики и запасной путь без multiplex должны быть описаны так же подробно, как прикладной код деплоя.
Ограничение. Если DNS, dual-stack или корпоративный прокси нестабильны, multiplex лишь ускорит появление сбоев — сначала стабилизируйте L1.
Про SFTPMAC. Аренда постоянно доступного удалённого Mac упаковывает вход, значения keepalive и границы прав: команды тратят меньше ночей на охоту за «зомби»-сокетами и больше времени на релизы.
Сведите multiplex, отпечатки и NAT-проверки в один квартальный регресс.