Лекция «Документирование и передача сценариев — семь записей, которые переживут автора и платформу»

Около 55 минут на 15 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 38 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Пятнадцать тем об одном разрыве: автоматизация работает, а прочитать её нечего. Лекция начинается с аварии, у которой есть официальное имя в документации вендора: осиротевший поток (orphaned flow) — поток без действительного владельца, который может отказать, если использует подключения, привязанные к учётной записи ушедшего. Удаление учётной записи сценарии не удаляет, а делает безымянными, и чинится это назначением совладельца вручную. Дальше — измеримая сторона вопроса: Truck Factor и порог, при котором проект считается осиротевшим (более 50% файлов без единого автора), выборка из 1 932 проектов GitHub, где 16% в какой-то момент были брошены всеми ключевыми авторами, а 41% выжили, притянув новых, — выжили по коду, которого у no-code-сценария нет. Ядро лекции фактическое: окно памяти платформы конечно и у всех разное (до 60 дней в Make, пять дней на n8n Cloud Pro, 24 часа остальным, полная история на Enterprise), восстановленная версия в Make не сохраняется сама, а изменения настроек рабочего процесса новую версию не создают вовсе. Экспорт разобран с двух сторон: чертёж Make содержит модули, их настройки, сопоставленные значения и расписание, но не содержит подключений, и ограничен 2 МБ; при этом выгруженный JSON n8n включает имена учётных данных, а узлы HTTP Request могут содержать заголовки аутентификации — поэтому непочищенный экспорт хранится там же, где доступы. Семь инструментов читатель уносит целиком: паспорт сценария из восьми полей, правило имени «что делает → над чем → когда», схема из 7–15 строк текстом, строка журнала изменений с шестью типами по Keep a Changelog, сжатая запись решения в четыре строки вместо пяти разделов Nygard, реестр с квартальной ревизией и чек-лист передачи, где права идут раньше знаний, а приёмкой служит попытка преемника править сценарий молча. Отдельно — правовая рамка: две недели по статье 80 Трудового кодекса, обязанности работодателя по статье 84.1 и отсутствие в кодексе самой процедуры передачи дел. Завершают лекцию десять красных линий: чего документация не заменяет и чего обещать нельзя.

По двум независимым причинам, и обе проверяются по документации самих платформ. Первая — окно конечно: Make отдаёт версии до 60 дней и прямо объясняет причину регулярной архивацией, у n8n полная история только на Enterprise, пять дней на Cloud Pro и 24 часа всем остальным. Вторая причина серьёзнее: даже внутри окна история неполна. n8n предупреждает, что изменения настроек рабочего процесса новую версию не создают, — а настройки это расписание, таймауты и поведение при ошибке. Человек меняет расписание, сценарий начинает вести себя иначе, и в истории версий этого нет. Плюс жанровая разница: список версий отвечает на вопрос «что стало другим», а журнал — на вопрос «зачем это сделали и что теперь нельзя ломать». Если файл заводить пока не готовы, начните с малого: именованные версии в n8n не удаляются автоматически, а у версии чертежа Make есть поле описания. Это уже журнал, просто со сроком годности.

Нет. «Подключения не выгружаются» — верное утверждение о подключениях и неверное обо всём файле. n8n предупреждает прямым текстом: выгруженный JSON содержит имена и идентификаторы учётных данных, и если идентификаторы не чувствительны, то имена могут быть — смотря как вы их назвали; а узлы HTTP Request могут содержать заголовки аутентификации, если создавались импортом из cURL. Отдельно про Make: народное правило «в чертеже нет секретов» верно для подключений и неверно как общее утверждение — у HTTP-модуля логин и пароль лежат прямо в настройках модуля, а настройки модулей входят в чертёж наряду с сопоставленными значениями. Практический вывод: непочищенный экспорт приравнивается к документу с ограниченным доступом. Хранится он там же, где рабочие доступы, а в паспорте сценария стоит ссылка на это место и запись о том, каким именно способом выгрузка сделана.