Automation

Когда проект выходит за рамки локальной разработки и начинает использовать CI/CD, возникает фундаментальный вопрос: каким образом безопасно передавать конфигурационные параметры в пайплайны сборки и деплоя. Речь идет не только о паролях к базам данных, но и о токенах контейнерных реестров, SSH-ключах, ключах подписи JWT, строках подключения к очередям сообщений и любых других параметрах, которые нельзя хранить в открытом виде.

Попадание чувствительных данных в Git-репозиторий — это не просто плохая практика. История коммитов сохраняется навсегда. Даже если секрет был удален в следующем коммите, он уже стал частью истории и может быть извлечен через git log, git show или при клонировании форка. В корпоративной среде это превращается в реальный риск при аудитах, расширении команды или при утечке доступа к репозиторию.

При работе с реальными проектами (смена CDN, миграция, рефакторинг) часто нужно массово заменить один URL на другой.

На первый взгляд задача кажется тривиальной: sed -i 's|old|new|g' **/* — и готово.

В реальности такой подход — это русская рулетка.

Неосторожная замена приводит к:

• 💀 Повреждению бинарных файлов (images, pdf, archives);
• 📉 Мусору в git-истории (бинарники помечаются как изменённые);
• 🚫 Невозможности чистого отката, если бэкап не был сделан.

В этой заметке разберём production-grade алгоритм: меняем только текст, не трогаем бинарники, делаем точечный бэкап.

Jitsi Meet из коробки отлично решает задачу видеоконференций. Связка Jitsi Meet + Jibri позволяет записывать встречи — и на этом многие установки останавливаются.

Но как только Jitsi начинает использоваться не эпизодически, а в рабочем процессе, очень быстро появляются вопросы:

• Где централизованно хранить записи?
• Как автоматически публиковать ссылки для команды?
• Как избавиться от тяжёлых MP4 и перейти к потоковому просмотру?
• Как раздавать записи по HTTPS, не раскрывая структуру каталогов?
• Как сделать всё это автоматически, без ручного участия администратора?

Ниже — полноценный продакшн-конвейер с кодом: от финализации записи Jibri до публикации в Notion и асинхронного транскодинга MP4→HLS с раздачей через Caddy.

n8n — это мощный open-source инструмент для автоматизации рабочих процессов, который позволяет создавать сложные workflow без глубокого программирования. Один из ключевых механизмов масштабирования в n8n — это queue mode (режим очереди), где основной процесс (main instance) делегирует выполнение задач отдельным процессам, называемым workers. Workers позволяют распределять нагрузку, обеспечивая параллельное выполнение workflow и повышая производительность системы.

В сообществе n8n и практических гайдах часто выделяют два типа workers: light workers (легкие) и heavy workers (тяжелые). Хотя официальная документация не использует эти термины напрямую, они отражают различия в типах задач и конфигурации. Light workers ориентированы на быстрые, частые операции, а heavy — на ресурсоемкие задачи. В этой статье разберем, в чем их отличия, как они работают и почему они необходимы для эффективного масштабирования.

Я разработал AI-помощника, который звонит клиентам вместо бухгалтера.

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

Моя система автоматизирует этот процесс.
AI-робот совершает обзвон клиентов, сообщает о задолженности, слушает ответы, распознаёт речь и фиксирует результаты.

Как это работает:

1. Бухгалтерия готовит таблицу в 1С, Excel, Google Sheets или Яндекс.Таблицах с суммой задолженности и телефоном клиента.
2. Система запускается вручную или по расписанию.
3. Робот звонит клиентам, зачитывает сообщение, распознаёт ответы и записывает результат.

Система поддерживает: