Система, которая принимает заказы, плохо переезжает в ночь с субботы на понедельник. Пока её гасят, заявки оседают в чатах. Потом их дописывают руками, и отчёт за эту неделю расходится с кассой.
Ниже разбираю, когда миграция внутренней системы вообще нужна, как устроен перенос в одном контуре и какие три числа по нему уже стоят на сайте. К следующему переносу эти числа относятся только после разбора.
Коротко
- Перенос нужен, когда старая система падает в пик и через неё идут заказы. Если ломается один отчёт, сначала чинят его.
- Выключение «на выходные» останавливает приём заказов, даже если в календаре это называется техническим окном.
- Работу начали с нового backend. Сам переход: сначала данные, затем новый backend, затем поэтапное переключение. Промежуточной версии не было.
- По этому контуру на сайте три числа: простой 0 часов, скорость отчётов ×3, инцидентов в месяц на 70% меньше.
- Срок и простой следующего переноса называю после разбора. Ноль часов из карточки на другие системы не переносится.
Когда перенос нужен?
Перенос нужен, когда в пике встаёт сам приём работы: заказы, отгрузки, статусы, без которых день не закрывается. Тогда имеют смысл новый backend и поэтапное переключение. Пока падает один экран или один отчёт, дешевле найти узкое место и починить его.
| Что происходит | Куда это ведёт |
|---|---|
| Врёт один отчёт, приём заказов жив | Сначала узкое место, перенос не начинать |
| Пик роняет заказ, отгрузку или статус, который уже обещали клиенту | Перенос частями, день продаж не ставить на паузу |
| Система давно написана, простоев нет | Возраст кода сам по себе перенос не обосновывает |
Разбор как раз для этой развилки. Сначала код и процесс, потом план: лечить или переносить. Если узкое место лечится на месте, перенос не предлагаю. Услуга так и названа: аудит и миграция.
Старый контур, который в пик принимает заказы, трогать ради смены стека незачем. Трогают тот, на котором уже теряется день.
Почему системе нельзя устроить выходной?
В таком контуре старая система и есть операционка. Окно «никого не пускаем» в плане работ занимает вечер. В продажах оно длиннее: менеджер не создаёт заявку, склад не видит остаток, клиент повторяет заказ в мессенджере.
Дальше эти заявки дописывают задним числом. Утренний отчёт за понедельник расходится с тем, что команда обещала в субботу. Перенос планируют так, чтобы день на пределе нагрузки шёл дальше.
Перед окном полезно ответить на три вопроса. Они не заменяют разбор:
- Кто принимает заказ, пока система недоступна, и куда он его записывает?
- Какой остаток или статус в это время смотрят наугад?
- Какой отчёт в понедельник руководитель откроет первым?
Если на все три есть спокойный ответ, окно, скорее всего, переживёте. Если хотя бы на один ответа нет, перенос собирают без этого окна.
Как прошёл один перенос?
Карточка миграция без паузы говорит прямо. Старая система падала в пики. Были новый backend, перенос данных и поэтапное переключение. Операционка при этом не останавливалась.
Работу начали с кода: новый backend писали, пока старая система ещё принимала заказы.
Сам переход шёл в другом порядке. Сначала данные: бэкап, перелив в новую базу, сверка скриптом в момент перехода. Затем новый backend. Затем поэтапное переключение. Пользователей не переводили одним днём, когда всё выключено. Промежуточной версии системы не было. Для перелива стоял отдельный вспомогательный сервис.
Стек того контура на той же странице: PostgreSQL, Docker, CI/CD, Nuxt.
Продажи не стояли ни дня. Ноль часов простоя относится к этому контуру. На следующий перенос это число заранее не переношу.
Что изменилось в том переносе?
Три числа с той же карточки, без добавлений:
| На карточке | Как читается |
|---|---|
| 0 ч простоя | Простой этого переноса был 0 часов |
| ×3 скорость отчётов | Отчёты этого контура стали быстрее в 3 раза |
| −70% инцидентов в месяц | Инцидентов в месяц стало на 70% меньше |
Рядом на карточке результат словами: стабильная платформа, предсказуемые отчёты, заметно меньше инцидентов, продажи не стояли ни дня. Какие именно отчёты стали быстрее, карточка не называет. В статье остаётся её формула: скорость отчётов ×3.
Это один контур. Ноль часов простоя, тройная скорость отчётов и минус 70% инцидентов описывают его. Следующему проекту эти числа заранее не назначаю. Срок, простой и состав работ появляются после разбора: где система падает и какие операции нельзя остановить.
Окупаемость в месяцах по этой карточке не считается. Такой цифры там нет.
Что происходит после запуска?
Перенос заканчивается на работающем дне. Дальше мониторинг и правки, когда системой уже пользуются. Сопровождение обговаривается отдельно. Шаги от диагностики до запуска, и вилка бюджета до кода, лежат на странице процесса.
Если пики уже мешают продажам
В первое сообщение хватает трёх вещей. Где встаёт день: приём заказа, склад, отчёт, обмен с другой системой. Было ли уже окно, когда систему гасили. Какой отчёт утром открывают первым.
Опишите задачу. Отвечу в рабочий день: чинить это, переносить или пока не трогать.