Как минимум, сразу после выхода обновлений безопасности, и за этим надо внимательно следить...
Если автоматизировать резервное копирование перед обновлением, и тестирование после, можно и автоматически обновлять. Но для нескольких сайтиков, обычно, такая автоматизация просто избыточна.

Расценки для России вполне ничего, на самом деле, я бы даже сказал очень даже.
Ну и с качеством, вроде пока всё ок - у меня есть на ihor VPS, в целом доволен.

Техподержка могла бы отвечать несколько оперативнее, но опять же, для хостинга в России и тут всё более-менее.

Как говорится, всё познаётся в сравнении, и если необходим Российский хостинг, ihor весьма неплохой выбор.

Важность пинга в случае среднестатистического сайта сильно переоценена. К тому же разница будет 5-10мс.
Также, как и скорость в регионах, кстати, если вы не показываете потоковое видео.

Использую Redmine.

Посмотрите:
https://www.drupal.org/project/imageapi_optimize
https://www.drupal.org/project/advagg

При правильной настройке, вы получите нужный результат.
И не гоняйтесь за 100 - это почти всегда не оправдано. 85-90 вполне нормально.

Бред откровенный!

«Advanced CSS/JS Aggregation тормозит работу сервера - у него долгие sql-запросы.»
Приведите примеры таких запросов.

«удалите лишние js, в частнсти languages/бногобукв.js, drupal.js»
И получите большую проблему, т.к. используются они почти наверняка.

«картинки он всегда будет требовать сжать, может быть только, если размеры width и height больше реальных размеров картинки»
Это совсем не так - снижаться счёт будет тогда, когда картинку можно при том же разрешении, без потерь качества уменьшить, а не уменьшить её разрешение.

Это не совсем так. Страница "сайт на тех-обслуживание" тоже темизируется вполне себе. Ключевые слова: maintenance-page.tpl.php, $conf['maintenance_theme'] = 'themename';

Кстати, не во всех темах оформления, особенно в разделе mobile.

Далеко не всегда разумно на лету оптимизировать на каждый запрос то, что может быть оптимизировано однократно настройками CMS. Это может дать весьма немалый оверхед на каждый запрос. И, в итоге, вместо оптимизаций картинок и скриптов, гугл будет просить оптимизировать время отклика.
Указанный вами инструмент, на самом деле, просто большой костыль на крайний случай, когда ничего не изменить уже, или менять дороже, чем тратить постоянно дополнительные ресурсы.

Хороший адаптивный шаблон, ImageAPI optimize, Advanced CSS/JS Aggregation, Отсутствие внешних JS (всякие счётчики, виджеты, и.т.п.). Правильная настройка веб сервера (сжатие, expires и.т.п.).

Но на самом деле, 100 просто не нужно. Обычно цена такого достижения не оправдано высока, а толку от него просто нет. 85-90 уже вполне не плохой результат, 95+ отличный.

В вашем случае, вероятно, таких цифр поможет добиться правильно настроенный модуль Advanced CSS/JS Aggregation.

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

Это чуть более чем бесполезно - быстродействие зависит от того, как что и где кешируется, какие пользователи приходят на сайт и что они там делают и.т.п.
Где-то использование определённых видов и настроек кеширования даст хороший результат, где-то нет.

А при чём тут postgresql или ACPu? Спитч о том, что расширение php-memcached для php7, есть в dotdeb репозитории - зачем его собирать отдельно?
А выше, просто цитата из новости dotdeb, со списком имеющихся в их репозитории расширений для php7.

Во-первых зачем если задача иметь именно php7, как я понимаю?
Во-вторых это хорошо при разработке/тестировании в разных условиях, и крайне плохо в продакшене - любые подобные примочки, вместо использования пакетного менеджера системы, и проверенных майнтейнерами и пользователями дистрибутива пакетов, крайне негативно влияют а поддержку - никогда так не делайте.

Добавлю, что надо было тогда и php-memcached не собирать, а установить из того же репозитория:
«Packages of the following PECL extensions are now available : APCu, APCu_bc, igbinary, imagick, memcached, mongodb, msgpack, redis and xdebug»

Так а чего удивляться, если php < 5.6 и сервер "настроен" установкой панельки, его очень часто нет. Проверено многолетней практикой.
Одна из самых распространённых проблем. Вторая после не настроенного innodb, наверное.

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

Собственно главный вопрос, на который стоит ответить - что вы хотите кешировать в redis? Для каких пользователей? Почему как бекэнд этого кеша выбран именно redis(например, тот же memcached в целом быстрее и проще)?

На самом деле, далеко не только в настройках сервера. Наибольшая проблема была в огромном количестве записей в таблице queue, из-за прерванных batch задач. И, соответственно, резкое замедление последующего выполнения batch, из-за долгих к ней запросов...
Но конфиг mysql тоже был не подходящий, да и кешера опкода, почему-то, на сервере не водилось.

Защита от DDOS там примерно такая же как на хетзнере - чуть что серьёзное, нульроут или отключение виртуалки.
Что не патчится на DO, или любой другой виртуалке? Если речь о ядре, а это единственное что не везде можно сменить, то огромный вопрос - зачем?
У меня есть виртуалка на vultr, большой разницы в производительности нет, я бы сказал, что чуть быстрее проц и чуть медленнее диски по ощущениям, что подтверждается, кстати, и ссылкой на сравнение выше.
Снепшоты на лету это да, это +, но для тех, кому они вообще нужны.

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

«Скажу больше, у нас еще и софт патченный. Сами собираем ряд пакетов для улучшения производительности с нашими внутренними патчами. Включая ядро линукса.»
Что обычно даёт совсем не большой профит в реальности.

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

Защита - прокомментируйте чем лучше?
Свобода? Интересное понятие. В чём она выражается?

«+ перформанс (opcache, redis, nginx, самих сайтов) + тестинг (newrelic)»
Это не зависит от хостера виртуалки - на любой можно настроить.

«вультр он тоже, как патрол типа "для своих"»
А это вообще очень странное высказывание - патрол хорош только тем, что они разбираются в Drupal. На vultr же, никакой техподдержки связанной с какой-либо CMS вообще не существует.

Нет-ли проблем в отчёте о состоянии?
Используется-ли какое-нибудь кеширование, если да какое?

Шаред хостинг законченная услуга - вы оплачиваете весь комплекс, и администрирование и ресурсы. Причём за счёт массовости и стандартизации окружения, администрирование имеет довольно небольшую долю в этой цене.
Арендуя VPS вы оплачиваете только ресурсы, и сравнивая по цене VPS с шаред хостингом, вам надо к его цене прибавить стоимость администрирования, как начальной установки, так и последующего обслуживания, при чём администрирование тут уже имеет куда больший процент окончательной цене. И тут становится понятно, что только кажется, что VPS дешевле.