Используйте этот чек-лист передачи приложения в production, чтобы упаковать окружения, секреты, мониторинг, бекапы и runbook — так ops смогут развернуть и поддерживать приложение самостоятельно.
Production-ready handoff означает, что ops может управлять приложением без догадок. Они могут развернуть известную версию, подтвердить её работоспособность, реагировать на оповещения и восстановиться после плохого релиза или простоя. Если что-то из этого зависит от памяти одного разработчика, передача не завершена.
Рассматривайте передачу как пакет, отвечающий на один вопрос: если оригинальные разработчики исчезнут на неделю, сможет ли ops сохранить систему в безопасности и доступной?
Хороший пакет обычно описывает, что делает приложение, что значит «здорово», как работают релизы (деплой, проверка, откат), где хранится конфигурация, как обращаются с секретами и как настроен мониторинг, бекапы и реагирование на инциденты.
Не менее важно описать, что пакет не включает. Передача — это не обещание добавлять фичи, рефакторить, переделывать экраны или «починить потом». Это отдельные проекты с собственным scope.
Прежде чем считать задачу завершённой, согласуйте владение и сроки реакции. Например: ops отвечает за uptime и деплой; продукт — за roadmap; команда разработки предоставляет оговоренное окно пост-передачи для фиксов и вопросов.
Ops может владеть только тем, что видно. Простая одностраничная сводка избегает догадок при деплоях, инцидентах и аудитах. Пишите простым языком и конкретно.
Перечислите каждую работающую часть системы и где она живёт: backend API, web-приложение, фоновые воркеры, планировщик задач и как подключаются мобильные клиенты. Даже если iOS/Android распространяются через магазины, они всё ещё зависят от того же бэкенда.
Включите внешние сервисы, без которых приложение не работает. Если вы используете PostgreSQL, очередь, объектное хранилище или сторонние API (платежи вроде Stripe, messaging, email/SMS, Telegram), запишите точное имя сервиса и для чего он нужен.
Зафиксируйте сетевые требования, чтобы хостинг не стал методом проб и ошибок: требуемые домены (app, api, admin), порты и протоколы, кто обновляет TLS-сертификаты, где управляется DNS и любые allowlist для входящих/исходящих соединений.
Наконец, запишите ожидаемую нагрузку в реальных числах: пиковые запросы в минуту, активные пользователи, типичные размеры payload, текущий размер БД и ожидаемый рост. Даже грубые диапазоны помогают ops настроить лимиты и оповещения.
Если вы строили приложение с AppMaster, опишите сгенерированный бэкенд, web-приложение и интеграции, чтобы ops знали, что нужно разворачивать вместе.
Production-окружения обычно ломаются на скучных вещах: конфиг, который живёт только в чьей-то голове. Отнеситесь к конфигурации как к артефакту. Ops должны видеть, какие настройки есть, что отличается между окружениями и как безопасно их менять.
Начните с перечня всех окружений, которые существуют сегодня, даже если вы думаете, что одно временное. У большинства команд есть dev, staging и production, а также копии вроде “production-eu” или “staging-us”. Отметьте, какое окружение используется для тестирования релизов, миграций данных и тренировок инцидентов.
Дайте единый справочник конфигурации, где перечислены имена переменных и безопасные примерные значения (ни в коем случае не реальные креды). Делайте плейсхолдеры очевидными.
В ваш handoff-пакет должны входить:
Добавьте простой процесс изменений. Например: запрос через тикет, ревью владельцем сервиса, применение сначала в staging, затем продвижение в production в окно деплоя с планом отката, если растёт уровень ошибок.
Если вы экспортируете и самостоятельно хостите приложение из AppMaster, соблюдайте то же правило: отправляйте чистый, документированный набор ключей конфигурации вместе с сгенерированным исходным кодом, чтобы ops могли запускать его последовательно в разных окружениях.
Секреты — самый быстрый путь, как аккуратная передача превращается в инцидент безопасности. Цель простая: ops должны знать все секреты, которые нужны приложению, где они хранятся, кто может их читать и как менять их без даунтайма.
Начните с короткого списка секретов, который ops может просканировать за минуту. Для каждого пункта укажите, что он открывает (БД, SMTP, Stripe, ключ подписи JWT), где хранится (vault, облачный secret store, Kubernetes Secret, зашифрованный файл) и кто отвечает за ротацию.
Пишите шаги ротации как рецепт, а не как политику. Включите точный порядок, как долго старый секрет должен оставаться валидным и одну проверку, которая доказывает успешность.
Используйте этот шаблон для каждого секрета:
Будьте точны в ожиданиях по шифрованию. Секреты должны храниться зашифрованными в хранилище и защищаться в транзите (TLS) между приложением и зависимостями. Никогда не храните секреты в исходниках, артефактах сборки или общих документах.
Определите процедуру экстренного доступа. Если аутентификация блокируется во время аутсейджа, укажите, кто может одобрить экстренный доступ, на какой срок и что нужно задокументировать и проаудировать после этого.
Ops может владеть только тем, что они могут воспроизвести. Хороший пакет деплоя отвечает на три вопроса: что именно запускается, как это снова задеплоить и как быстро вернуться назад, если что-то сломается?
Включите ясный «билль материалов» для сборки. Указывайте тип артефакта и как его проверить, а не только где он хранится:
Добавьте небольшой конкретный пример. Например: «Задеплойте v1.8.2, обновив тег образа, запустив миграции, затем перезапустив web-воркеры. Если health checks падают в течение 10 минут, вернуться на v1.8.1 и остановить задачу миграции.»
План отката должен читаться как инструкция, которой можно следовать в 2 часа ночи. В нём должно быть указано:
Если приложение создано в AppMaster и экспортировано как исходники для самостоятельного хостинга, включите версию сгенерированного кода, инструкции сборки и ожидания runtime, чтобы ops могли пересобрать тот же релиз позже.
Передача не завершена, пока ops не видят, что делает приложение, и не получают предупреждений до того, как начнут жаловаться пользователи.
Договоритесь, какие логи должны существовать и куда они попадают (файл, syslog, log-платформа). Убедитесь, что логи синхронизированы по времени и содержат request or correlation ID, чтобы инциденты можно было трассировать насквозь.
Обычно нужны application logs (ключевые события и ошибки), error logs (stack traces и упавшие задания), access logs (запросы и коды статусов), audit logs (админ-действия и выгрузки) и инфраструктурные логи (рестарты, давление на узлы, проблемы с диском).
Далее определите небольшой набор метрик, отражающих пользовательский опыт и здоровье системы. Если выбирать только пять: latency (p95/p99), error rate, saturation (CPU/память/диск), глубина очередей и внешние проверки доступности.
Правила алертов должны быть однозначными: что триггерит, серьёзность (page vs ticket), кто на дежурстве и когда эскалировать. Добавьте снимок «известно рабочей» dashboard и короткую заметку, что такое норма (типичный диапазон latency, ожидаемый error rate, обычная глубина очередей). Этот контекст предотвращает шум и помогает новым ответчикам быстро действовать.
Бекапы — это не то, что «у нас есть». Это то, из чего вы можете восстановиться по требованию.
Опишите точный объём: база данных, файловое хранилище (загрузки, отчёты, счета) и те элементы, о которых часто забывают, например конфигурацию вне кода и ключи шифрования для защищённых полей.
Укажите цели в простых терминах. RPO — сколько данных вы можете потерять (например, 15 минут). RTO — сколько вы можете быть недоступны (например, 1 час). Выбирайте числа, согласованные с бизнесом, потому что они определяют стоимость и усилия.
Включите:
Если вы экспортируете и самостоятельно хостите приложение, созданное в AppMaster, включите шаги восстановления PostgreSQL и любые внешние бакеты и ключи, используемые для зашифрованных полей.
Запланируйте drill по восстановлению. Зафиксируйте время, что сломалось и что вы поменяли, чтобы следующий рестор прошёл быстрее и спокойнее.
Передача не считается настоящей, пока кто-то не сможет получить пейдж в 2 часа ночи и решить проблему без догадок. Runbooks превращают племенные знания в шаги, которые может выполнить дежурный.
Начните с инцидентов, которые скорее всего произойдут: полный аут, медленные ответы и кривой деплой. Держите каждый runbook коротким. Ставьте самые быстрые проверки в начало, чтобы ответчик получил сигнал за минуты.
Соблюдайте единообразную структуру, чтобы было легко читать под давлением:
Если приложение экспортировано или self-hosted из AppMaster, включите, где сгенерированные сервисы работают, как их безопасно перезапускать и какие значения конфигурации ожидаются для каждого окружения.
Держите короткий пост-инцидент чеклист. Запишите таймлайн, что менялось последним, точные сообщения об ошибке, затронутых пользователей и действие, которое исправило ситуацию. Затем обновите runbook, пока детали не забыты.
Ops может владеть системой, только если ясно, кто и что может менять, и как это отслеживается.
Опишите роли, которые вы реально используете. Для многих команд хватает:
Задокументируйте «политику двери» простыми шагами: кто даёт доступ, где он выдается (SSO, cloud IAM, БД-пользователи, CI/CD, админ-панели), кто может отозвать и как подтверждается удаление при офбординге.
Не забудьте про нечеловеческий доступ. Перечислите каждый сервисный аккаунт и токен, используемые заданиями, интеграциями и мониторингом, с пометкой принципа наименьших привилегий (например, «может читать только из бакета X»). Если вы экспортируете исходники AppMaster для self-hosting, укажите, какие env vars или конфигурационные файлы задают эти идентичности, но никогда не вставляйте секреты в документ передачи.
Также укажите ожидания по аудит-логам: что должно логироваться (логин, деплой, изменение конфигурации, действия DBA), кто может читать логи, период хранения, где они хранятся и как запросить логи во время инцидента или ревью.
Заметки по безопасности должны быть понятны неспециалистам, но достаточно конкретны, чтобы ops могли действовать. Добавьте одностраничное резюме: какие данные мы храним, где они живут и кто имеет к ним доступ.
Начните с типов данных: профили клиентов, тикеты поддержки, метаданные платежей, файлы. Отметьте чувствительные категории: PII (имена, email, телефоны), учётные данные и любые регламентированные данные, важные для вашей компании. Если вы экспортировали исходники для self-hosting (включая из AppMaster), укажите, где эти данные находятся в базе и какие сервисы могут их читать.
Потом опишите правила хранения и удаления на практике. Скажите, что хранится, как долго и как работает удаление (soft delete vs hard delete, отложенная очистка, бекапы). Если есть юридические удержания или требования аудита, отметьте, кто даёт исключения.
Логи часто выдают больше, чем базы. Будьте конкретны, где может появляться PII (access logs, error logs, аналитика) и как вы сводите это к минимуму или маскируете. Если поле нельзя логировать, запишите это явно.
Сделайте утверждения явными:
Если можно добавить только одну вещь — добавьте заметку, где хранятся доказательства: audit-логи и как их экспортировать, когда потребуется подтверждение.
Ops берёт на себя customer portal, сделанный небольшой продуктовой командой, и переносит его на новое self-hosted окружение. Цель не просто «чтобы работало», а «ops могут управлять без звонков разработчикам».
Day 1: Ops делает чистый первый деплой в новом окружении, используя только handoff-пакет. Приложение поднимается, но логин падает из‑за отсутствующей переменной окружения для почтового провайдера. Это добавляют в шаблон env, и деплой повторяют, пока всё не работает «с нуля».
Day 2: Специально симулируют первый алерт. Ops вызывает контролируемый фол (останавливает сервис или блокирует исходящую почту) и подтверждает: метрики показывают проблему, оповещения доходят до нужного канала, и сообщение подсказывает дальнейшие действия.
Day 3: В sandbox платежей истёк токен. Поскольку место хранения и шаги ротации задокументированы, ops меняет его без догадок и утечек секретов.
Day 4: Переключение DNS. Неправильная запись указывает на старый IP, и портал недоступен для части пользователей. Ops использует runbook для проверки DNS, TLS и health checks в правильном порядке.
Day 5: Тест восстановления из бекапа. Ops восстанавливает в новую БД и подтверждает, что портал загружает реальные данные.
Приложение проработало 7 дней без загадочных фиксов, один успешный рестор проведён, оповещения настроены и повторяемый деплой, который ops может выполнять самостоятельно.
Самый быстрый путь превратить спокойную передачу в пожар в 2 часа ночи — думать, что «мы всё рассказали ops» равнозначно «ops могут управлять без нас».
Типичные паттерны провалов при self-hosting передаче: секреты в таблицах или чатах, откаты зависят от разработчика, бекапы есть, но ресторы никогда не тестировались, алерты срабатывают постоянно из‑за неотстроенных порогов и детали окружения только в голове у кого-то (порты, DNS, cron, права облака).
Пример: вы экспортировали исходники из AppMaster для self-hosting, первый деплой прошёл. Через две недели изменение конфигурации ломает логины. Если секреты передавались через чат, а откат требует оригинального разработчика, ops теряют часы, чтобы вернуть состояние «как вчера".
Перед закрытием тикета проведите короткий fresh-start drill. Дайте handoff-пакет одному инженеру ops и чистое окружение (новая VM, новый namespace в Kubernetes или пустой облачный проект). Если он может задеплоить, наблюдать и восстановить приложение в установленное время (например, 2 часа), вы близки к завершению.
Проверьте:
Если вы экспортируете сгенерированные исходники для самостоятельного хостинга, также убедитесь, что ops знает, где записаны входные данные сборки, версии и релиз-тэги, чтобы будущие релизы были воспроизводимы.
Проведите финальный walkthrough с людьми, которые будут нести пейдж. Отрепетируйте деплой, откат, рестор и алерты с тем же пакетом, который передаёте.
Финальный walkthrough обычно включает: деплой в тест, затем в production теми же шагами; откат на предыдущую версию и проверку работы; восстановление из бекапа в чистое окружение и валидацию простой проверки (войти, создать запись, отправить сообщение); триггер одного безопасного алерта; и подтверждение, где искать логи и дашборды при инциденте.
Сделайте владение явным. Назначьте ответственного за каждый runbook (деплой, инцидент, рестор) и за каждый маршрут оповещений (первичный on-call, бэкап, поведение в нерабочее время). Если за алерт никто не отвечает, он либо будет игнорироваться, либо разбужен не тот человек.
Напишите короткий план Day 2, чтобы ops знали, что улучшить после первой недели: отстроить пороги, проверить расходы, почистить старые артефакты и пересмотреть доступы. Держите это небольшим и в пределах времени.
Если вы строили в AppMaster (appmaster.io), включите экспорт исходного кода или точные детали целевого развертывания (облако, регионы, настройки сборки, требуемые сервисы), чтобы ops могли воспроизвести приложение без зависимости от исходного проекта. Установите простой ритм обновления пакета при изменениях, чтобы runbooks не расходились с реальностью.
Что на практике означает «production-ready handoff»?A production-ready handoff означает, что ops может развернуть известную версию, подтвердить её здоровье, реагировать на оповещения и восстанавливать систему после сбоев без опоры на память конкретного разработчика. Если неделя без авторов поставит аптайм под угрозу, передача не завершена.
Что должно быть в базовом инвентаре системы?Начните с одностраничного инвентаря системы, в котором перечислены все работающие компоненты и где они находятся: API, web-приложение, воркеры, планировщик задач, база данных, хранилище и внешние сервисы. Добавьте домены, порты, кто отвечает за DNS/TLS и грубую оценку нагрузки, чтобы ops не гадали в критический момент.
Как передать конфигурацию окружений, не сливая секреты?Предоставьте единый справочник конфигурации, где перечислены все ключи конфигурации, их тип и безопасные примерные значения, а также что отличается между dev/staging/prod. Не включайте реальные учётные данные, и опишите, где хранится конфигурация и как она применяется при деплое, чтобы изменения были воспроизводимы.
Что минимально документировать по секретам и их ротации?Составьте короткий список секретов, где указано, для чего нужен каждый секрет, где он хранится, кто может его читать и кто отвечает за ротацию. Описывайте шаги ротации как чеклист с одной понятной проверкой в конце, и опишите процедуру экстренного доступа (break-glass) с требованиями к аудиту.
Что делает пакет деплоя воспроизводимым для ops?Ops должно точно знать, что запущено и как это восстановить: имя/тег артефакта, версия, дата сборки, контрольная сумма и ссылка на исходники/тэг/коммит. Укажите рекомендуемую цель деплоя, порядок шагов, ожидаемое время деплоя и как запускаются и проверяются миграции базы данных.
Что должно быть в плане отката, чтобы им можно было воспользоваться в 2:00 утра?Определите сигналы-триггеры (например, падение health check или рост ошибки), последнюю заведомо рабочую версию и точные шаги для быстрого отката. Укажите, обратимы ли изменения в базе, и что делать, если они не обратимы, чтобы откат не превратился в импровизацию в 2 часа ночи.
Какие сигналы мониторинга приоритетнее всего при передаче?Выберите небольшой набор метрик, отражающих влияние на пользователей: задержки (p95/p99), уровень ошибок, загрузка ресурсов, глубина очередей и внешний чек доступности. Сделайте правила алертов однозначными: что триггерит, уровень серьёзности, кто на дежурстве и как эскалировать. Убедитесь, что логи синхронизированы по времени и содержат correlation ID для трассировки.
Как сделать бекапы и восстановление действительно надёжными?Документируйте, что бекапится, где хранится, период хранения и кто может запускать восстановления. Включите пошаговую процедуру восстановления с проверкой и регулярно проводите drills: бекапы важны только тогда, когда можно быстро и предсказуемо восстановиться в чистом окружении.
Как должен выглядеть on-call runbook для типичных инцидентов?Держите runbooks короткими и однообразными: симптомы, первые проверки, следующие шаги, точки принятия решений и эскалация. Сфокусируйтесь на ожидаемых инцидентах (полный аут, медленные ответы, кривой деплой) и обновляйте runbook сразу после инцидента, пока детали не забыты.
Как документировать контроль доступа и права для ops-владения?Опишите роли, которые вы реально используете (deployer, DBA, read-only, incident commander), как предоставляется и отзывается доступ, и что обязательно логируется для аудита. Не забудьте про сервисные аккаунты и токены: перечислите, к чему они дают доступ и где их идентификаторы настраиваются, но не включайте секретные значения.
27 янв. 2026 г.
1 мин
26 янв. 2026 г.1 мин
21 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
