Перейти к основному содержимому
megapromotingДавайте обсудим

Экспертиза · Инфраструктура и операционная деятельность

Мы размещаем приложение на сервере, который контролируем, с обратимым выпуском, проверенными резервными копиями и местом, где видно, когда что-то упало.

Хостинг, ввод в эксплуатацию, мониторинг и непрерывность для веб-приложений и платформ с базой данных. Мы работаем на инфраструктуре, на которую клиент может претендовать: виртуальные машины у европейских провайдеров, nginx, процессы под надзором, контейнеры, самохостимая база данных. Включает ответ на вопрос «где фактически находятся мои данные».

Уже построеноМы так эксплуатируем несколько собственных систем, и конфигурации находятся в репозиториях, а не только на серверах. Этот сайт работает на nginx с Next.js 16 под PM2, в OVHcloud București. Платформа ассистентов работает на Microsoft Azure, Poland Central, с MySQL, Redis и RabbitMQ в контейнерах, подключённых к локальному интерфейсу. Собственная civic-платформа использует systemd unit-ы с публикацией через атомарное переключение символической ссылки, проверенной ежедневной резервной копией и отдельной задачей retention, которая запускается только если эта копия удалась. Внутренняя board публикуется через собственный runner, с GitHub actions, закреплёнными по полному fingerprint, и автоматическим возвратом к предыдущей версии, если health check падает после публикации. Оговорка, которую нужно сказать: степень автоматизации различается от системы к системе. Публикация этого сайта всё ещё делается вручную, а миграции базы данных применяются вручную, намеренно. Мы не продаём автоматизированную цепочку, которой у нас нет везде.

Приложение, которое работает на ноутбуке, и приложение, которое работает в production, отличаются вещами, которых не видно в интерфейсе: что происходит, когда процесс умирает в три ночи, что происходит, когда выпуск проходит плохо, куда попадают журналы, кто первым узнаёт, что что-то упало, и откуда восстанавливается база данных, если диск исчезает. Этот сервис занимается именно этой частью.

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

На вопрос о суверенитете данных есть только один честный ответ: проверенный. Местоположение подтверждают, опрашивая сервис метаданных виртуальной машины и регистр адреса, а не читая маркетинговую страницу провайдера. Разница не теоретическая — для передачи внутри Европейского экономического пространства глава о передаче в Legea 195/2024 просто не применяется. Выполненная нами миграция перевела платформу с базы данных, размещённой в Соединённых Штатах, на самохостируемый стек в Европейском союзе, именно по этой причине.

Что мы не обещаем: что всё автоматизировано. Миграции схемы мы применяем вручную, сознательно, потому что миграция, автоматически применённая в production цепочкой, которая не знает, что находится в таблице, — это обычный способ потерять данные. Публикация кода автоматизируется; изменение структуры базы остаётся человеческим решением, со свежей резервной копией на фоне.

Что входит

Работа, по составляющим

Обратимая публикация, с проверкой после, а не только до

Публикация не заканчивается, когда файлы дошли до сервера, а когда реальный запрос доказывает, что новая версия действительно отдается. В одной из реализаций скрипт синхронизирует каталог, сохраняет предыдущую версию рядом, затем извлекает имя пакета из отданной страницы и проверяет по публичному адресу, что отдается именно этот файл; если нет, он сам откатывается к предыдущей версии. Это не теория: механизм поймал пакет, оставшийся старым в каталоге runnerului, и отменил публикацию, которая иначе выглядела бы успешной.

Атомарное переключение версии с процессом под systemd

Альтернатива «останавливаем, копируем поверх, запускаем» — каталог версий плюс символическая ссылка, переключаемая одной операцией. Устройство systemd всегда указывает на стабильный путь, а возврат означает переключение ссылки обратно. Устройство имеет политику перезапуска при сбое с короткой паузой, максимальное время останова и системные ограничения: без повышения привилегий, защищенная файловая система, недоступные личные каталоги, с явным списком путей, куда ему разрешено писать.

nginx впереди, с ограничениями, записанными для реального случая

Завершение TLS с автоматическим продлением сертификата, HSTS сроком на один год и включением поддоменов, сжатие с минимальным порогом размера, статические ресурсы с длинным сроком истечения и неизменяемой меткой, а приложение привязано к локальному интерфейсу, чтобы к нему нельзя было обратиться напрямую из интернета. Ограничения по скорости задаются по типу трафика, а не глобально. Оплаченный урок стоит упомянуть: под HTTP/2 лимит соединений считает потоки, а не соединения — при малом значении одна загрузка страницы сама отвергает свои шрифты и скрипты с 429.

Резервная копия, которая проверяется, а не просто запускается

Ежедневная запланированная задача, с запуском при следующем boot, если машина была выключена в назначенное время, и со случайной задержкой, чтобы все не стартовало в одну секунду. Экспорт базы сжимается, а если получившийся файл пуст, выполнение считается сбоем — экспорт, который завершается «успешно» и дает ноль байт, это обычный способ через шесть месяцев обнаружить, что копии нет. Файлы из объектного хранилища синхронизируются отдельно. Копия, находящаяся на 100% локально, не переживает потерю диска, поэтому копия уходит и за пределы машины, в учетную запись хранения в Европейском союзе с географической репликацией, версионированием, обратимым удалением и автоматическим истечением срока — с доступом через управляемую идентичность, чтобы на диске не было ни одного ключа хранения.

Запланированное удаление выполняется только после успешной копии

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

Оповещения, которые не лгут и не спамят

Запланированная задача, которая возвращает 200, не означает, что задача сработала. Наша оболочка выполнения читает тело ответа и ищет в нем частичные сбои, затем отправляет оповещение с ограничением частоты, чтобы упавший весь день сервис не породил девяносто шесть одинаковых сообщений. Причина, почему это существует: ежедневный отчет был мертв одиннадцать дней подряд, а единственным следом была пустота в таблице, на которую никто не смотрел. Запланированная задача срабатывала все одиннадцать раз.

Цепочка публикации, которую нельзя перехватить сверху

Действия в потоке интеграции фиксируются на полном отпечатке commit, а не на теге. В марте 2026 года популярное действие было перенаправлено с тегов `v1`…`v45` на вредоносный код и затронуло более 23.000 репозиториев за 24 часа; отпечаток не смещается. Поток не хранит креденциалы в рабочей копии, а публикация не идет через token: она проходит через собственный runner, на целевой машине, с правами, выданными точечно. Так ни один ключ доступа к серверу не находится на платформе кода.

Контейнеры с ограничениями, проверками здоровья и журналами, которые не заполняют диск

Каждый сервис имеет политику перезапуска, собственную проверку здоровья (подготовка базы данных, точка состояния приложения), ограничения по процессору и памяти там, где нагрузка этого требует, и ротацию журналов на уровне движка контейнеров, с максимальным размером и количеством файлов. Порты баз данных привязываются к локальному интерфейсу, никогда не публикуются. Обязательные переменные объявляются так, чтобы контейнер отказывался запускаться, если они отсутствуют, вместо запуска с опасным значением по умолчанию.

Самостоятельно размещаемая база данных, когда независимость важна

Полный стек в контейнерах — база данных, аутентификация, REST-интерфейс, канал в реальном времени, хранение файлов, шлюз доступа — с расширениями, включенными явно, и с параметрами памяти и соединений, подходящими машине, а не оставленными на значениях по умолчанию. Миграции — это версионированные файлы в репозитории, и они применяются вручную, с перезапуском компонента, который держит свою схему в памяти. Причина этого выбора проста: платформа, управляемая из-за пределов Европейского союза, может быть технически отличной и все же юридически неподходящей.

Как это выглядит

Путь, шаг за шагом.

01

Инвентаризируем, что существует и что может быть потеряно

Что фактически работает на машине, под каким супервизором, с какими версиями, с какими открытыми портами; какие резервные копии существуют и была ли какая-либо из них когда-либо восстановлена; какие секреты попали в репозитории; в чем разница между конфигурацией в репозитории и файлом на сервере. Последний пункт почти всегда вызывает сюрпризы — у нас самих задокументирован случай, когда файл на сервере был отредактирован напрямую, вне репозитория, и рядом с ним осталась резервная копия с отметкой времени. Мы поставляем инвентарь и список единых точек отказа.

02

Создаем основу: сервер, nginx, процессы, hardening

Firewall, который по умолчанию отклоняет входящие соединения и открывает только необходимое, защита от повторных попыток аутентификации, настроенное пространство swap, nginx с TLS и автоматическим обновлением, приложение, привязанное к локальному интерфейсу, супервизор процессов, настроенный на запуск при загрузке. Мы поставляем конфигурации в репозитории, а не только на машине, чтобы следующий человек не восстанавливал их по памяти.

03

Делаем публикацию повторяемой и обратимой

Скрипт публикации с сохранением предыдущей версии, проверка работоспособности после публикации и автоматический откат при сбое. Там, где есть команда и непрерывная интеграция, добавляется собственный runner на целевой машине, с действиями, зафиксированными по отпечатку, и без credentials в рабочей копии. Мы поставляем письменную процедуру и откат, выполненный в присутствии клиента — непроверенный откат не является откатом.

04

Настраиваем копии, retention и оповещения

Ежедневная копия с проверкой, что файл не пустой, внешняя копия в регионе Европейского союза, задача retention, которая запускается только после успешной копии и оставляет след, а также оповещения с ограничением частоты, которые читают содержимое ответа, а не только код состояния. Мы поставляем фактически выполненное тестовое восстановление и его журнал.

05

Передаем ключи и пишем, что осталось не сделано

Доступ в собственный аккаунт, документация по эксплуатации, список запланированных задач и — обязательно — честный список того, что не было автоматизировано, и почему. У нас в нем почти всегда остаются две позиции: миграции схемы, которые сознательно применяются вручную, и публикация этого сайта, которая все еще выполняется вручную.

Ce vede utilizatorulПриложениеСеть и безопасностьХостинг и данныеКАЖДЫЙ СЛОЙ, ВЫБРАННЫЙ И ОБЪЯСНЕННЫЙ
Слои установки, снизу вверх: виртуальная машина в подтверждённом европейском регионе, контейнерный движок с ротацией журналов, база данных с проверенной ежедневной копией и копией вне машины, процессы под супервизором с перезапуском при сбое, nginx с TLS и лимитами скорости — а сбоку цепочка публикации с сохранением предыдущей версии и автоматическим откатом.

Данные

К чему прикасаемся, где оно лежит и сколько остаётся

Вопросы, которые задаёт всякий, у кого есть ответственный за защиту данных, — заданы здесь раньше, чем их задаст он.

Где фактически находятся данные и как это проверяется
Местоположение подтверждается с машины, а не из документации: сервис метаданных провайдера сообщает реальный регион, а регистр адреса говорит о стране. Наши системы находятся на OVHcloud, București, România и на Microsoft Azure, Poland Central — обе в Европейском экономическом пространстве. Резервные копии гражданской платформы находятся в северном регионе Союза, с репликацией во второй регион также из Союза. Эти строки заменили более длинный список местоположений, которые мы не смогли подтвердить.
Что мы видим в ходе работы
Конфигурация, журналы, схема базы и состояние процессов. Содержимое персональных данных не является частью работы; если для отладки все же нужен пример, используется случай, созданный для этого. Административный доступ предоставляется на время вмешательства, поименно, и отзывается в конце — и отзыв проверяется, а не предполагается.
Журналы и срок их жизни
Веб-журналы этого сайта ротируются ежедневно, с четырнадцатью сохраняемыми экземплярами, с правами чтения, ограниченными группой администрирования. На уровне контейнеров ротация выполняется движком контейнеров, с фиксированным размером и количеством файлов, чтобы слишком разговорчивый сервис не заполнил диск и не остановил базу данных — самый банальный способ вывести production из строя.
Секреты не хранятся в репозитории
Чувствительные значения поступают из файлов окружения с ограниченными правами, читаемых системным юнитом, а не записываются в юнит — потому что определение юнита и системный журнал читаемы большим числом людей, чем принято думать. В цепочке публикации файл окружения для production не проходит через платформу кода: он копируется локально на машину и сразу удаляется после сборки. Когда мы берем на обслуживание уже существующую инфраструктуру, первый проход всегда представляет собой инвентаризацию секретов, попавших в хранилища, с планом ротации.
Непрерывность: что происходит, когда мы уходим
Передача означает доступ в собственный аккаунт у поставщика инфраструктуры, хранилище со всеми конфигурациями серверов, процедуру публикации и отката, процедуру восстановления резервной копии — протестированную, а не только записанную — и список запланированных задач с тем, что делает каждая. Защита от случайного удаления ставится на группу ресурсов production с самого начала.

Случай

Ежедневный отчет, который не запускался уже одиннадцать дней, в системе, где все отвечало 200

Ситуация

Во внутренней собственной платформе несколько автоматических процедур ежедневно создают отчеты и очищают данные. Задачи запускались изнутри приложения, с счетчиками в процессе. Ничто не указывало на проблему: сервис был запущен, адрес отвечал, журналы не содержали ошибок.

Что мы построили

Ежедневный отчет отсутствовал одиннадцать дней, и единственным следом была пустота в таблице, на которую никто не смотрел. Выявились два отдельных дефекта. Первый: счетчик, запущенный внутри приложения, сбрасывается при каждом перезапуске сервиса, поэтому процедура с интервалом больше, чем интервал между публикациями, никогда не срабатывает. Второй, более коварный: процедура корректно запускалась все одиннадцать раз и каждый раз возвращала код 200 — но тело ответа содержало частичные сбои, которые никто не читал.

Что получилось

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

Чего этот случай не говорит

Ничто из этого не было проблемой инфраструктуры в классическом смысле: сервер работал, на диске было место, процесс был жив. Именно поэтому это длилось одиннадцать дней. Самые дорогие эксплуатационные дефекты — не падения, их видно, — а вещи, которые сообщают об успехе, ничего не делая. Проверка здоровья, которая имеет значение, не спрашивает «вы запущены?», а «вы сделали то, что должны были, столько раз, сколько должны были?».

Вопросы

О чём нас спрашивают перед тем, как позвонить

Где фактически будут храниться наши данные?

Где выберете вы, и мы проверяем, что они действительно там. Наши системы размещены в OVHcloud, București, и на Microsoft Azure, Poland Central, обе в Европейском экономическом пространстве, а местоположение было подтверждено путем запроса к службе метаданных виртуальной машины и реестру адреса — а не чтением документации поставщика. Проверка важна: для передачи внутри Европейского экономического пространства глава о передачах из Legea 195/2024 не применяется, и специальные разрешения не требуются. Вне его появляется досье гарантий.

Почему собственный сервер, а не управляемая платформа?

Не всегда. Управляемая платформа — правильный выбор, когда команда маленькая, трафик нерегулярный и ничто в стеке не имеет требований к резидентности. Собственный сервер становится более сильным аргументом в трех ситуациях: когда данные должны оставаться в определенной юрисдикции, когда стоимость становится непредсказуемой в масштабе и когда вы хотите иметь возможность забрать все и уйти. Мы делали и обратную миграцию для собственной системы: с базы данных, размещенной в Соединенных Штатах, на самохостинговый стек в Европейском союзе, с восемью контейнерами — база данных, аутентификация, REST-интерфейс, real-time, хранилище, метаданные, панель и шлюз доступа.

Что происходит, если публикация выходит плохо?

Осуществляется откат, и желательно автоматически. Предыдущая версия остается на диске рядом с новой, а после публикации проверка запрашивает реальную страницу и подтверждает, что обслуживаемый файл — это только что собранный; если нет, скрипт откатывает автоматически. Там, где мы используем атомарное переключение символической ссылки, откат — одна операция. Это не описание из брошюры — механизм уже поймал публикацию со старым пакетом, оставшимся в рабочем каталоге runner-а, и отменил ее.

Вы делаете резервные копии? Как часто и проверяете ли их?

Ежедневно там, где мы это построили — и подчеркиваем это, потому что автоматическая копия сама по себе не появляется, когда переносите приложение на сервер. Копия запускается в фиксированное время, восстанавливается при следующем boot, если машина была выключена, а если экспорт оказывается пустым, выполнение считается сбоем. Копия уходит и за пределы машины, в регион Европейского союза, с репликацией, versioning, обратимым удалением и автоматическим истечением срока. Тест восстановления является частью поставки: копия, которую никогда не восстанавливали, — это предположение, а не копия.

Кто узнает первым, когда что-то падает?

Это зависит от того, что мы построили, и стоит сказать это без украшений. Проверки здоровья на уровне контейнера и точки состояния приложений существуют; оповещение в канал сообщений, с ограничением частоты, существует там, где мы его построили. Точка проверки состояния, которую никто не запрашивает, — это не мониторинг, а страница. Если вам нужен настоящий мониторинг, это отдельный этап, с внешним наблюдателем, который периодически опрашивает, и с получателем оповещения, которого разрешено будить.

Применяете ли вы автоматически миграции базы данных при каждой публикации?

Нет, и это осознанное решение, а не упущение. Цепочка публикации строит и копирует код; и только. Изменения схемы — это версионированные файлы в репозитории, применяемые вручную, со свежей резервной копией за спиной, а компоненты, которые держат свою схему в памяти, после этого перезапускаются. Миграция, автоматически применённая в продакшене процессом, который не знает, что в таблице, — обычный способ безвозвратно потерять данные.

Как вы избегаете того, чтобы ваша цепочка публикации стала путём атаки?

Через три правила. Внешние действия закрепляются за полным отпечатком коммита, а не за тегом — в марте 2026 широко используемое действие было перенаправлено с его тегов на вредоносный код и за 24 часа затронуло более 23.000 репозиториев. Рабочая копия не хранит учётные данные. Публикация выполняется не с ключом доступа, хранящимся на платформе кода, а через собственный исполнитель, который работает на целевой машине, с правами, выданными точечно. Мы признаём, что не все наши более старые проекты ещё соблюдают все три; их миграция — отдельная работа.

Вы принимаете инфраструктуру, сделанную кем-то другим?

Да, и первый проход всегда является инвентаризацией, а не изменением. Что реально работает, под каким надзирателем, с какими версиями, какие порты открыты, какие резервные копии существуют, была ли хоть одна восстановлена когда-либо, какие секреты попали в репозитории и насколько конфигурация в репозитории ещё похожа на файл на сервере. Последняя проверка почти всегда что-то даёт: у нас задокументирован, в собственном проекте, файл конфигурации, отредактированный напрямую на продакшене, который оставил рядом резервную копию с временной меткой.

Что происходит, если мы хотим работать с кем-то другим?

Вы уходите полностью. Инфраструктура с самого начала находится на ваших аккаунтах у поставщика, а передача включает репозиторий со всеми конфигурациями серверов, процедуру публикации и отката, процедуру проверенного восстановления и список запланированных задач с тем, что делает каждая. Блокировка от случайного удаления группы ресурсов продакшена ставится с установки. Если поставщик ставит ваш уход в зависимость от переписывания инфраструктуры, проблема была в этом, а не в технологии.

На чём основаны утверждения выше (30 источников)
  1. https://www.megapromoting.com отвечает 200 на nginx + Next.jshttps://www.megapromoting.com/servicii · 2026-09-06

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

Что вы хотели бы наладить?

Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.

Давайте обсудим