КЕЙС 01
ERP на Odoo
Второй разработчик на корпоративной ERP: свои модули, интеграции, доступы и надёжность сервера, на котором всё это живёт.
Задача
План безопасности выполнили наполовину: доступ закрыли, а бэкапов не было. Месяц единственными копиями боевой базы — зарплаты, договоры, 36 пользователей — были два ручных дампа на том же диске. Мониторинга не было вообще, поэтому о проблемах узнавали от людей, а не от системы.
Что я вёл
Отвечаю за надёжность инфраструктуры, модель доступа и поток входящих заявок. Работаю в паре со вторым разработчиком, решения по инфраструктуре принимаю и защищаю сам. Разработка идёт в связке с AI-агентом: задачу ставлю и принимаю я, каждый выкат — после прогона тестов на копии боевой базы.
Система
- 01Внешние зашифрованные бэкапы каждые 4 часа, у другого провайдера, восстановление проверено
- 02Мониторинг с нуля: сбор метрик, правила тревог, оповещения в мессенджер
- 03Страница состояния в двух местах — внутри ERP и отдельно в nginx, живёт даже когда ERP лежит
- 04Перевод прода в многопроцессный режим скриптом с проверками и откатом одной командой
- 05Каталог ролей вместо персональных назначений: 116 → 55 без изменения чьих-либо прав
- 06Входящие заявки из четырёх каналов сведены в одну воронку CRM
- 07Проверка секретов в конвейере поставки до пуша и в CI
- 08Деплой падает, если обновление модуля молча не применилось
Результат
Главный эпизод: восемь дней подряд один из процессов Odoo падал по кругу — около 1150 перезапусков в минуту, 80% ядра, — и этого никто не видел, потому что страница входа всё это время отвечала «200». Чат и живые уведомления были мертвы. Нашёл причину в способе запуска процесса, починил и поставил отдельного сторожа на этот порт: нагрузка упала с ~80% до ~6%, падений ноль. Вывод, который теперь применяю везде: проверять живость по главной странице недостаточно, сторож нужен на каждый процесс, от которого зависит пользователь.