rustelekom

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

Без обращения никак, так уж устроена cPanel...

awbs.com - был такой биллинг в своё время. Вроде и сейчас живой. Мы его использовали до 2013 года. Он конечно совсем не заточен под РФ, но зная код (раскодированные файлы ходили одно время в сети, так же как и whmcs)  допилить можно. Но проблемы всё те же - нужны кодеры свои. К тому же перепиливать неизвестно какой надёжности код зачастую куда хуже чем написать своё с нуля.

Вариант, который вам предложили в DigitalOcean  вполне разумный - текущий сервер оставить как есть для изучения того, как он был взломан, а тем временем создать новый сервер и на него развернуть ваши сайты из бэкапов. Сэкономите время на том, что не нужно будет ждать восстановления работы, а можно будет сразу запустить сайты. А старый сервер после изучения можно будет удалить - это вопрос одного, двух дней или даже нескольких часов.

Как найти почему и как сервер был взломан? Ну вот примерно как описано ниже.

На 99.9% один из ваших сайтов был взломан и на ваш сервер закачали скрипт для произведения атаки. 0.1% что украли или подобрали ваш пароль для доступа на сервер с правами администратора или даже суперпользователя (root). Но обычно после разбора выясняется взлом сайта - это куда проще и это автоматизированный процесс. Хакеры запускают автоматический процесс по поиску уязвимостей на сайте и при нахождении таковых запускается скрипт взлома. После получения доступа, жертва включается в сеть ботнета и используется в разных злокозненных целях хозяином этой сети.
 Так как сервер отключен от сети, по ssh или через панель вы до него добраться не сможете. Однако у вас есть наверняка консоль (обычно это VNC доступ) которая позволяет зайти на сервер даже при отключенном доступе к сети интернет. Зайдите на сервер через консоль (либо через панель управления DigitalOcean, либо с VNC клиента) и проверьте логи доступа к аккаунтам администратора сервера. Если с ними всё чисто и в логах показаны только ваши айпи адреса, можно перейти к проверке сайтов на взлом. Для начала можно прогнать файлы антивирусом, а также можно посмотреть какие файлы изменялись недавно. После нахождения вредоносных файлов, нужно будет проверить как они оказались у вас на сервере и затем удалить или переместить в не доступную из сети интернет папочку для дальнейшего изучения. Если обнаружатся старые версии движков сайтов, их шаблонов или плагинов - все их нужно будет запланировать к  обновлению на новом сервере. Затем сменить пароли для сайтов и их баз данных на новом сервере.

Так через Coremanager всё можно решить, но это тогда без биллменеджера. Пишешь свой биллинг и всё. А в биллменеджере из функционала для доменов есть только: изменение контактных данных (работает так себе), смена/регистрация днс серверов, включение/выключение приватного хуиза.

Здравствуйте!

Возможно, подойдут наши новые тарифы на KVM SSD VPS в Германии:

Neptune 5 vCPU, 6 Гб памяти, порт 200 Мбит/сек, трафик не учитывается

или

Uranus

6 vCPU, 8 ГБ памяти, порт 250 Мбит/сек, трафик не учитывается.
Лицензия на Windows Standard 2012/2016/2019 - 499 ₽
По бюджету проходим в обоих случаях.

Нет, так проекты не делают. Так можно деньги собирать (краудфандинг), вечеринки мутить, экскурсии/путешествия, даже на акциях нажиться (robinhood + reddit). Но софт приличный так не сделать и тем более не получится его поддерживать в течение многих лет.

Billmanager почти приблизился - основные задачи решать может с большей/меньшей результативностью. Но, писать к нему даже модули не так просто, а кое-что и вовсе нереализуемо (например элементарное управление доменами) просто из-за того, что функции отсутствуют и их никак не расширить. 

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

Да, с Яндексом всё хорошо, проверил, данные поступают. А вот с гуглем - увы.