I. Почему «на моём ноутбуке работает» всё ещё блокирует первую продакшен-подпись
Фрагменты из сообществ оптимизированы под быстрый дофамин: вставил команду, увидел баннер — и кажется, что сложное уже позади. Продакшен редко падает с явной ошибкой компиляции. Чаще он приходит тишиной: процесс gateway жив, метрики ровные, но первое видимое клиенту сообщение так и не попадает в обещанный канал. Типичная причина — порядок шагов, а не «плохая модель». Каналы подключают до того, как openclaw doctor подтвердит согласованность ключей провайдера, адресов прослушивания и путей reverse-proxy. Канальный слой проглатывает расхождения вместо чёткого стека. Второй сценарий — расхождение «истории каталогов»: то, что создал openclaw init, и то, что реально исполняет launchd (WorkingDirectory, логи, скрипты обновления), расходятся до тех пор, пока один перезапуск не превратит разбор в археологию. Третий — безопасность как фольклор: без openclaw security audit поверхности bind, права на токены и происхождение навыков ClawHub живут в личном чате одного инженера. Когда он в отпуске, система откатывается от «работает» к «никто не смеет трогать». Поэтому здесь намеренно мало крупных разделов: каждый блок достаточно длинный, чтобы его можно было целиком вставить во внутреннюю wiki, а не распиливать на дюжину микропостов.
В языке управления это означает отсутствие критериев подписи: ревьюеры не понимают, что значит «зелёный», дежурный не знает, на каком слое остановить откат. Без явных вложений каждая эскалация превращается в устную передачу эстафеты, где теряются версии CLI, флаги запуска и даже ответ на вопрос, какой именно канал считался «боевым» в момент инцидента. Нить статьи — официальная цепочка install.sh → init → doctor → channels probe → security audit, плюс паритет OPENCLAW_* на удалённом Mac в том же пакете доказательств. Цель — отвечать аудиторам вложениями, а не скриншотами, собранными накануне. Одна страница с тремя вложениями doctor/probe/audit стоит десяти страниц переписки, потому что её можно сравнить между релизами и увидеть дрейф за неделю, а не за ночь перед аудитом; это практически бесплатная страховка против «у нас вчера работало», и её можно проверить за считанные минуты и без ночных сюрпризов.
II. Выбрать путь установки, не устроив религиозную войну
Вопрос не в том, какой стек красивее на слайде, а какой ваше «я через год» воспроизведет с теми же digest и теми же вложениями. Официальный install.sh кодирует порядок и ограничения в самом скрипте, снижая риск, что новичок подключит каналы до появления workspace. Глобальный npm или pnpm подходит командам, которые уже считают мажор Node инфраструктурным контрактом, но правила PATH, границы прав и заметки о rollback должны жить на одной странице runbook; иначе мышечная память тихо становится продакшен-конфигурацией. Docker Compose часто выигрывает в аудите и изоляции, но заставляет проектировать приёмочные тесты для томов, bridge-сетей и прохода канала на хост до того, как команда понимает поведение gateway; контейнеры поверх путаницы только удлиняют triage.
Какой бы путь ни выбрали, зафиксируйте мажор Node, менеджер пакетов и запрет недокументированных флагов curl в README. Перечитайте материал npm/Docker/pnpm на этом сайте и оформите единое командное решение о каноническом пути поставки, а не позволяйте трём ноутбукам изобрести три «религии». Отдельной строкой запретите «ночной curl без чек-суммы»: это самый дешёвый способ получить в проде чужой скрипт с тем же именем файла.
При переносе с ноутбука на удалённый узел копируйте одинаковые lockfile, шаблоны конфигурации и ту же командную строку probe; проведите пятнадцатиминутный soak до навешивания ночных заданий. Если задержка внезапно улучшилась, потребуйте объяснения по I/O и термолимитам; если ухудшилась, проверьте сетевые тома и отладочные логи, оставленные по SSH.
После выбора пути потратьте час и опишите отказы, которые не хотите открывать заново: ротация TLS-корней у провайдера, коллега, поднявший Node в CI без выравнивания с prod, reverse-proxy с дефолтным idle, убивающим долгие websocket, нехватка диска на удалённом Mac, замедлившая ротацию логов до того, как заметят клиенты. Эти абзацы живут рядом с таблицей: так фиксируется тихий риск senior-инженерии. Из них вырастает первый tabletop: отозвать тестовый токен, перезапустить probes, убедиться, что пейджинг сработал, восстановить доступ, приложить временные метки к runbook, чтобы аудиторы видели практику, а не только чтение PDF.
| Ось | Официальный install.sh | Глобальный npm / pnpm | Docker Compose |
|---|---|---|---|
| Порядок и ограничения | Высоко; последовательность в скрипте | Средне; вы добавляете ворота | Низко; сначала хранилище и сеть |
| Аудит | Digest скрипта | Lockfile и пути | Digest образа |
| Совместимость с launchd | Сильная | Сильная | Средняя; больше эксплуатации |
III. Пять шагов от пустого каталога до первого защищаемого сообщения
Список ниже — чеклист вложений к тикету, а не мотивационный плакат. Если шаг не породил сохраняемый лог или текстовый артефакт, шаг не завершён. Дисциплина окупается при первом переносе с личного ноутбука на общий удалённый Mac или передаче пейджера человеку, который не сидел в вашем приватном чате при рождении кластера.
- Заморозить границы Node и каталога
- Выполнить официальный install.sh с записанным digest
- openclaw init с проверкой workspace, конфигурации и памяти
- openclaw doctor как жёсткий шлюз с сырым логом в артефакте
- channels probe и шаблонное первое сообщение до приглашения людей
После пяти шагов вы должны ответить на три прямых вопроса: какая версия установлена, какой каталог авторитетен, и были ли рукопожатия канала проверены независимо от оптимизма. Если нет — было движение без доказательств: остановите фичи и почините цепочку.
IV. Слоистый разбор, когда каналы молчат
Тишина провоцирует крутить модель или наращивать параллелизм. Спокойнее идти так: здоровье провайдера, затем маршрутизация gateway и bind, затем адаптеры каналов и callback URL. Логи channels probe должны говорить, истекли ли учётные данные, достижимы ли webhooks, нужен ли туннель в socket-режиме, и не ошиблись ли вы интерфейсом bind. Читайте материал про 429 и логи параллельно, чтобы отделить лимиты от «мёртвого» рукопожатия: у лимитов часто явные HTTP или ошибки провайдера, у DNS/часов/idle — маскирующаяся рваная тишина.
Когда перед OpenClaw стоит n8n или другой HTTP-оркестратор, идемпотентность и подписи не заменяют gateway-probe. Держите вложения по слоям тикета, а не смешивайте несвязанные логи в один файл; иначе следующий postmortem потратит часы, доказывая, залили ли ретраи внутреннюю очередь или gateway сам потерял события.
Нагрузка и стоимость — та же история: burst в изолированных проектах провайдера и синтетических каналах, фиксируя CPU, память и открытые дескрипторы. Заливать продакшен-каналы синтетикой — заказать шторм пейджеров. На Apple Silicon с другими ИИ-сервисами сверяйтесь с материалом про конкурентность и unified memory, чтобы не принять троттлинг за логический баг. Потолки токенов и rpm на дашборде рядом с долей падений probe; алерты, когда одновременно рвутся и стоимость, и ошибки — иначе усталость от шума скрывает реальные регрессии.
Юридические и retention-аспекты тоже стоит вписать в короткий абзац runbook: какие данные через какие каналы в какие юрисдикции могут уходить и сколько живут логи. Ссылка на эту политику в summary audit экономит часы на «внезапном» compliance-запросе. Маркетинговый бейдж «beta» держите отдельно от GA: GA — это, например, семь дней подряд зелёных probe на фикстурах, чистый audit или подписанные отклонения, обученный заместитель и успешный месячный restore-drill; иначе это просто громкая техническая задолженность.
| Симптом | Гипотеза | Действие |
|---|---|---|
| doctor зелёный, канал нем | Учётка или callback URL | probe; сверить консоль провайдера |
| Часто ошибка, редко успех | DNS, время, idle proxy | NTP; настроить idle reverse-proxy |
| После апгрейда всё мертво | Состояние или миграция env | Runbook апгрейда; diff plist до кода |
V. security audit, права workspace и «вакуум» провайдера
openclaw security audit должен покрыть listen, права на токены, происхождение ClawHub с pin и diff, согласованность reverse-proxy, Tailscale или SSH-туннелей с нарисованной архитектурой. Перечитайте материал про поверхность атаки gateway и повесьте владельца и срок на каждый finding, а не превращайте аудит в уборку выходных. На удалённом Mac включите обмен экраном и файлами в ту же дискуссию, что и порт gateway. Workspace после init часто содержит заготовки секретов и память: задокументируйте Unix-права, групповую политику, какие сервисные аккаунты читают, CI только для чтения, могут ли девелоперские ноутбуки писать в prod-пути. Секреты, читаемые несколькими пользователями, — блокеры релиза, не «warning». В multi-tenant — отдельный пользователь ОС на инстанс gateway вместо общего sudo.
Между doctor и probe — вакуум провайдера: биллинг, организационная политика, allow-list IP, регистрация egress IP, даты ротации ключей. Egress удалёнки отличается от ноутбука разработчика; заранее занесите в консоль, иначе погоня за «иногда зелёным» в prod. Изменения egress IP — в тот же класс изменений, что и правки plist, чтобы ops и приложение смотрели на обе стороны границы. Ротация заслуживает абзаца в runbook: второй токен, side-by-side, переключение консоли, двойной probe, отзыв старого, повторный audit, тикет у merge plist. Команды, правящие живой plist без второй копии, уже написали сценарий инцидента.
VI. Удалённый launchd, пороги, наблюдаемость, MACGPU
На общем удалённом Mac явно укажите, приходят ли OPENCLAW_* и секреты модели из EnvironmentVariables, EnvironmentFiles или секрет-хранилища. После апгрейда сначала diff plist, потом код приложения. Разделите админский SSH и публичный вход webhook по гайду SSH/VNC. Окно обновления: снимок plist и редактируемого манифеста workspace, doctor, затем каналы. Не смешивайте смену маршрутизации провайдера и апгрейд gateway в одном тикете.
- Три несогласованных сбоя probe за час — заморозить новые каналы до сетевой и учётной базовой линии.
- Больше двух world-readable секретов или опасных bind — стоп публичных демо до исправления и повторного теста.
- Нет подтверждения первого сообщения за пятнадцать минут — откат к baseline только doctor.
Наблюдаемость: пять вложений — doctor, сырой probe, краткий audit, маскированный plist, идентификаторы событий провайдера. Внешние демо — минимум первые три. Квартальные холодные прогоны только по публичному runbook и внутреннему зеркалу. Ночной CI: одноразовый каталог, установка с фиксированным digest, doctor как артефакт; выровняйте мажор Node CI и prod; метрики смысла (доля успешных probe, медиана до первого токена после входящего, счётчик findings audit), а не пустые uptime-плитки; сопоставляйте метрики gateway с квотами провайдера.
Ноутбуки хороши для проверки и экспериментов, но плохи как единственные витрины для клиента: сон, PATH, прокси браузера искажают поведение. Удалённые Mac дают выделенный launchd, закреплённые версии и общие вложения. Если нужен постоянно включённый Apple Silicon для gateway и регрессий, а не шкаф из личного железа, у MACGPU есть публичные тарифы и вход справки без стены логина. Финальная самопроверка перед внешней демо: вместе doctor, probe и audit; пропустить один — вернуть тихие регрессии на сцену.
Версионируйте каталог на окружение, ссылку из шапки дежурства, чтобы postmortem не гнили в Slack. После инцидента цепляйте ссылку на postmortem рядом с сработавшими порогами, чтобы следующий читатель получил контекст, а не фольклор. Добавьте к шапке дежурства ссылку на версионированную папку окружения, чтобы артефакты не расползались по личным чатам. Раз в квартал кто-то вне ядра должен пройти пять шагов только по публичному runbook и внутреннему зеркалу; дыры — мёртвые ссылки, отсутствующие креды, размытые апрувы — идут в бэклог выше новых фич. Так папка инцидентов остаётся аудируемой, а не собирается из скриншотов.
Бэкапы должны восстанавливаться, а не просто существовать: ежемесячно разверните tarball workspace и plist на запасном хосте, прогоните doctor и шаблонное сообщение, зафиксируйте checksum и версию OpenClaw, чтобы видеть границы несовместимых апгрейдов. Цепочка поставки самого install.sh — с той же серьёзностью, что и код приложения: внутренний артефакт-репозиторий, ревью digest, хеш в том же абзаце, что и URL загрузки, чтобы при копировании в wiki не потерять проверку.
Выровняйте CI и хост gateway: JSON-lint без doctor почти ничего не доказывает. Ночной job с установкой по фиксированному digest и архивом логов ловит дрейф до клиента. Документируйте часовые пояса и триггеры cron/launchd рядом с результатами probe, чтобы саппорт коррелировал всплески. Раз в год пусть security понаблюдает учение — стабилизируется словарь рисков; общий глоссарий спасает от того, чтобы «критично» то значило блокер аудита, то маркетинговый лозунг.
Считайте видимый док-долг: сколько страниц дежурства без pin digest, сколько plist без комментария OWNER, сколько каналов без ID шаблона. Когда счётчики для среды обнулились, объявляйте её runbook-ready, а не потому что демо-GIF один раз проиграл гладко. Если два инженера независимо больше четырёх часов щёлкают флаги без новых вложений — остановитесь и допишите строку runbook; героический дебаг без доказательств создаёт невоспроизводимую магию, за которую заплатит следующая смена. Раз в год пригласите security понаблюдать учение — выровняется лексика рисков и перестанет путаться «критично» для аудита и для маркетинга. Назначьте владельца и заместителя на pin digest, шаблоны plist и корпус шаблонов, с квартальной ротацией заместителя, чтобы знание не уезжало в отпуск.
Дополнительно зафиксируйте политику зеркала install.sh: каждое изменение digest проходит ревью с откатом, а URL и ожидаемый хеш лежат в одном абзаце runbook, чтобы новичок не потерял проверку при копировании во внутреннюю wiki. Отдельно опишите, что делать при смене egress IP арендованного Mac: тикет в тот же класс, что и правки plist, уведомление провайдера модели, двойной probe после регистрации, запись в журнале изменений с датой и ответственным.
Для связки с оркестраторами вроде n8n добавьте в тикет два вложения: цепочку webhook с идемпотентностью и сырые логи gateway-probe, чтобы postmortem не спорил, переполнена ли внутренняя очередь ретраями или шлюз теряет события. На дашборде рядом держите квоты провайдера и долю успешных probe: так вы отличите throttling от «немого» канала без лишних эскалаций.