Провели аудит production-сервера торгово-сервисной компании. На одном физическом узле одновременно работали корпоративная почта, CRM, около 20 основных сайтов и служебных доменов. Во время периодических зависаний сотрудники теряли доступ сразу ко всем системам, но обычная проверка после перезапуска не показывала причину. Собрали baseline-снимок инфраструктуры и отдельный incident-снимок непосредственно во время деградации. Сопоставили Docker, Mailcow, MySQL/MariaDB, Apache, PHP-FPM, системные логи, Iostat, iotop, mpstat, загрузку CPU, RAM, swap и дисков. Выявили механизм отказа: дисковая подсистема достигала 100% утилизации, средний `iowait` рос примерно до 62%, а load average — до 26,6. Основной поток чтения создавал процесс базы данных почтового контура. Из-за перегрузки диска почтовые сервисы теряли соединение с БД, а общая инфраструктура на одном сервере создавала каскадную деградацию CRM и сайтов. Подготовили план действий: безопасно увеличить лимиты памяти критичных контейнеров, включить сбор slow query log, настроить мониторинг и алерты, разгрузить системный диск, ограничить PHP-FPM и поэтапно вынести почту и новую CRM на отдельные узлы. Для каждого шага зафиксировали проверку результата и rollback.