VPS managé ou non managé : lequel choisir ?

VPS managé ou non managé : réponse courte

Choisir entre un VPS managé et un VPS non managé relève de la charge de travail, pas du produit. Avec un VPS non managé, vous devez gérer les correctifs, le firewall, les sauvegardes, la supervision et le redémarrage à 2am. Avec un VPS managé, le fournisseur prend en charge une partie de ces tâches. L’étendue de cette prise en charge varie fortement d’un hébergeur à l’autre. La seule comparaison utile consiste à lister les tâches que chaque offre vous retire, puis à comparer ce périmètre au coût de vos propres heures.

Le terme managé n’a pas de définition standard. Pour un hébergeur, cela signifie que le système d’exploitation reçoit ses correctifs et qu’un technicien répond aux tickets. Pour un autre, cela signifie qu’un panneau de contrôle a été installé et que tout ce qui se trouve au-dessus reste à votre charge. Pour un troisième, il s’agit d’un contrat de service écrit avec un délai de réponse défini. Deux offres utilisant le même terme peuvent différer sur tous les points importants. Lisez donc le document qui définit le périmètre avant de consulter le prix. Si vous ne savez pas encore à quoi servira la machine, commencez plutôt par déterminer ce que vous pouvez réellement faire avec un VPS.

Les tâches dont quelqu’un doit être responsable

Chaque serveur en production implique la même liste de tâches. Avec une offre non administrée, cette liste vous revient. Avec une offre administrée, vous payez pour en retirer certaines tâches. Parcourez la liste et indiquez le responsable de chacune.

• Mise à jour du système d’exploitation et redémarrages requis par les mises à jour du kernel.
• Règles du firewall, maintenues à jour lors de l’ajout et de la suppression de services. Les bases du firewall ufw pour un VPS présentent le jeu de règles initial.
• Accès SSH : gestion des clés, désactivation de l’authentification par mot de passe, révocation d’une clé lorsqu’une personne quitte l’équipe et méthode de récupération lorsque vous vous verrouillez vous-même l’accès.
• Sauvegardes, copie hors site et restauration réellement effectuée.
• Monitoring : vérifier que le serveur est joignable, que le disque dispose d’espace libre, que le service fonctionne toujours et que le certificat n’a pas expiré.
• Consultation des logs et intervention lorsqu’un élément semble anormal dans ces logs.
• Configuration des services pour le serveur web, la base de données, le reverse proxy et la file d’attente si vous en utilisez une.
• Renouvellement du certificat et réparation lorsque le renouvellement automatique ne fonctionne plus.
• Capacité : détecter que la mémoire est épuisée avant que le tueur out of memory (OOM) ne le fasse à votre place.
• Réponse aux incidents : rester éveillé et joignable à une heure que vous ne choisissez pas.

La plupart de ces tâches sont routinières et peuvent être confiées à un script. La réponse aux incidents fait exception, car elle nécessite une personne capable de prendre une décision. C’est le véritable service vendu par une offre administrée. C’est pourquoi la checklist plus bas consacre la plupart de ses questions au périmètre du support plutôt qu’aux mises à jour.

Ce que la gestion inclut généralement pas

C’est à ce stade que les acheteurs ont de mauvaises surprises. Soyez précis sur ce point. Un contrat de gestion couvre normalement le système d’exploitation et les logiciels installés par le fournisseur. Il s’arrête à la limite de votre application.

Votre propre code vous incombe. Une erreur 500 générée par votre application n’est pas un problème de serveur. Le fournisseur vérifiera que le processus du serveur web fonctionne, puis vous renverra le ticket. Cette limite est normale. Elle représente aussi le principal écart entre ce que les acheteurs attendent et ce qu’ils ont acheté.

Les problèmes au niveau de l’application sont généralement hors périmètre. Une requête de base de données lente, un plugin cassé après une mise à jour, un cache mal configuré ou une file d’attente de mails qui ne se vide plus : ces problèmes se situent au-dessus de cette limite, même si le fournisseur a installé les logiciels sous-jacents.

La plupart des récupérations de données sont hors périmètre. Les sauvegardes du fournisseur protègent l’image du serveur telle qu’il la gère et servent en cas de panne du matériel hôte. Elles sont rarement conçues pour le cas où vous avez supprimé une ligne, exécuté une migration incorrecte ou corrompu un fichier il y a six semaines sans vous en rendre compte avant aujourd’hui. Demandez quelle est la durée de rétention, s’il est possible de récupérer un seul fichier et qui effectue la restauration.

Les logiciels que vous installez vous incombent. Si vous installez Docker, le fournisseur est généralement responsable de l’hôte, tandis que tout ce qui se trouve dans les conteneurs relève de votre responsabilité.

Les modifications manuelles peuvent annuler le support. Certains contrats excluent un composant du périmètre dès lors qu’un client a modifié directement sa configuration. Demandez des précisions si vous prévoyez d’ajuster un élément.

Évaluez votre temps par rapport à l’écart mensuel

Prenez les deux offres devant vous et notez la différence mensuelle. Ce montant correspond à ce que le fournisseur facture pour supprimer les tâches de la liste ci-dessus. Évaluez maintenant votre propre coût dans cette comparaison.

• Combien vaut une heure de votre temps, et combien d’heures par mois cette liste nécessite-t-elle une fois l’automatisation en place ?
• Que coûte une heure d’indisponibilité pour ce qui fonctionne sur ce serveur ?

Un serveur Ubuntu stable, avec des mises à jour automatiques et une supervision externe, nécessite très peu d’intervention courante. La plupart des mois, aucune intervention n’est nécessaire. Le travail courant coûte peu une fois qu’un script s’en charge. Ce sont les interruptions qui coûtent cher, et c’est précisément ce que vend une offre managed. Si le serveur héberge un projet personnel, une indisponibilité ne coûte rien : l’option unmanaged s’impose donc naturellement. S’il permet de recevoir des commandes, vérifiez attentivement si un contrat de support réduit réellement la durée d’une panne. Un fournisseur managed doit malgré tout lire votre ticket, reproduire le problème et intervenir.

L’écart augmente également avec le nombre de serveurs. Les frais managed sont généralement facturés par serveur, tandis que l’automatisation est écrite une seule fois puis copiée. Le deuxième serveur réduit de moitié le coût effectif du script écrit pour le premier. Consultez donc comment gérer plusieurs serveurs Linux avant de vous engager sur des frais par serveur. Pour les montants de base des deux options, combien coûte réellement un VPS par mois fixe le seuil minimal. Le comparatif entre VPS et serveur dédié devient pertinent lorsque la charge est suffisamment importante pour que le surcoût managed soit négligeable.

Questions à poser à un hébergeur avant de payer l’offre premium managée

Posez ces questions avant de payer et demandez des réponses écrites. Une page commerciale ne définit pas le périmètre des prestations.

1. Que comprend exactement la prestation, tâche par tâche ? Demandez la liste, pas la brochure.
2. Le support couvre-t-il les logiciels que j’installe, ou uniquement ceux que vous avez installés ?
3. Appliquez-vous automatiquement les correctifs ? Redémarrez-vous le serveur pour les mises à jour du kernel sans me demander mon accord ?
4. Qui est responsable si un correctif que vous avez appliqué casse mon application ?
5. Effectuez-vous des sauvegardes ? Où sont-elles stockées, combien de temps sont-elles conservées et qui effectue une restauration ?
6. Avez-vous récemment restauré le serveur d’un client ? Combien de temps l’opération a-t-elle pris ?
7. Quel est le délai de réponse aux tickets ? Est-il différent à 03:00 un dimanche ?
8. Est-ce que je conserve l’accès root ? Son utilisation réduit-elle le périmètre du support ?
9. La facturation s’effectue-t-elle par serveur ou par compte ?
10. Si je pars, qu’est-ce que je peux récupérer ? Une configuration qui dépend d’un control panel propriétaire peut être difficile à exporter.

La question 5 détermine la plupart des autres. Un hébergeur qui y répond précisément vous montre qu’il a déjà effectué cette opération. Une réponse vague signifie que la restauration n’a jamais été testée. Une sauvegarde non testée n’est qu’une copie. La question 5 comporte aussi un volet géographique : l’emplacement physique des copies relève autant du droit que de la technique, et ce qui compte réellement lors du choix d’un pays d’hébergement l’examine en détail.

Le juste milieu : infogéré sans automatisation

La plupart des lecteurs techniques ne veulent aucun des deux extrêmes. Ils veulent un plan non infogéré, avec les tâches courantes confiées à la machine, afin de garder leur attention pour ce qu’une machine ne peut pas évaluer. Mettez cela en place dès le premier jour. Les dix premières minutes sur un nouveau VPS constituent le point de départ pratique pour toute personne qui choisit un serveur non infogéré, et sécuriser l’accès SSH fait partie de cette même première session.

Mises à jour de sécurité automatiques

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Ce fichier doit maintenant contenir APT::Periodic::Update-Package-Lists "1"; et APT::Periodic::Unattended-Upgrade "1";. Un fichier absent, ou un 0 sur l’une des deux lignes, signifie que rien ne s’exécute et que vous ne serez pas averti.

Testez-le sans modifier le système. Notez que le paquet est unattended-upgrades, tandis que la commande est au singulier :

sudo unattended-upgrade --dry-run --debug

La sortie liste tous les paquets pris en compte et se termine par une ligne telle que No packages found that can be upgraded unattended lorsqu’aucune mise à jour n’est en attente. Les exécutions réelles sont écrites dans /var/log/unattended-upgrades/unattended-upgrades.log. Consultez donc ce fichier au lieu de supposer que tout s’est bien passé.

Une mise à jour du kernel ne produit aucun effet tant que la machine n’a pas redémarré, car le kernel en cours d’exécution est celui chargé au démarrage. Le fichier /var/run/reboot-required apparaît lorsqu’un redémarrage est requis. Surveillez ce fichier ou laissez la machine gérer ce redémarrage dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" retarde le redémarrage lorsqu’une personne est connectée. C’est plus sûr sur une machine utilisée de manière interactive, mais inutile sur une machine à laquelle personne ne se connecte. Configuration complète des mises à niveau automatiques sur Ubuntu décrit la syntaxe de la blocklist et les options d’envoi d’e-mails.

Supervision exécutée ailleurs

Un monitor exécuté sur le serveur ne peut pas vous informer que le serveur est hors service, puisqu’il l’est aussi. Effectuez le contrôle depuis un deuxième hôte ou un service externe. Uptime Kuma pour la supervision de disponibilité est généralement la solution self-hosted, et doit être installé sur une autre machine que celle qu’il surveille.

Surveillez au minimum quatre éléments : l’accessibilité, l’espace disque utilisé, la réponse de l’application sur son véritable port et l’expiration du certificat. Le disque est l’élément qui prend le plus souvent les utilisateurs au dépourvu. Un fichier de log ou une base de données qui grossit un peu chaque jour peut arrêter la machine à un moment qu’aucun autre indicateur ne permet de prévoir. Le premier symptôme est souvent un service qui ne peut plus écrire et qui s’arrête.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Ajoutez également un heartbeat. Un timer sur le serveur appelle une URL après chaque sauvegarde ou contrôle d’intégrité réussi, et le monitor déclenche une alerte lorsque cet appel n’arrive plus. Un serveur silencieux génère alors lui-même une alerte, ce qu’un contrôle reposant uniquement sur des requêtes sortantes ne peut pas faire lorsque le problème vient du chemin réseau.

Sauvegardes restaurées au moins une fois

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init affiche created restic repository <id> at sftp:... une seule fois. Son exécution sur un repository existant échoue au lieu de l’écraser, ce qui est le comportement recherché. Conservez une copie de cette passphrase hors du serveur : le repository est illisible sans elle et il n’existe aucun moyen de récupération.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots doit lister l’exécution que vous venez de lancer, avec la date du jour. restic check vérifie la structure du repository et affiche no errors were found. Effectuez maintenant l’étape que la plupart des utilisateurs ignorent :

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

Le fichier attendu est présent ou absent, et le vérifier maintenant ne prend que dix minutes. Programmez ensuite l’exécution avec un timer afin qu’elle ne dépende pas de vous. Écrivez /etc/systemd/system/restic-backup.service :

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Puis /etc/systemd/system/restic-backup.timer :

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers affiche la prochaine exécution et le temps restant. Un résultat vide signifie que vous avez activé le service au lieu du timer, ce qui est l’erreur la plus fréquente ici. Persistent=true exécute une tâche manquée après le prochain démarrage. Une machine éteinte pendant la nuit effectue donc tout de même sa sauvegarde. Sauvegardes Restic sur un VPS décrit plus en détail l’organisation du repository et la rétention, et Services et timers systemd explique les fichiers d’unité ligne par ligne.

Ce que l’automatisation ne vous apporte pas

Elle ne vous apporte pas le jugement nécessaire. Un redémarrage automatique à 02:00 a lieu, que votre application redémarre correctement ou non. Vérifiez donc que chaque service démarre seul, puis redémarrez volontairement la machine pendant que vous êtes éveillé :

systemctl is-enabled nginx docker
sudo reboot

Une mise à niveau automatique peut également installer un paquet qui casse votre application, sans qu’aucun élément de la chaîne ne le détecte. C’est votre monitor qui le signalera. C’est pourquoi il devient indispensable dès que les mises à jour sont automatiques. La machine prend en charge les tâches courantes. La gestion de l’incident reste votre responsabilité.

Ce qui justifie le prix d’une offre managed

Il faut aussi considérer sérieusement les offres managed. Dans quatre situations, elles constituent le bon choix.

• Personne dans l’équipe n’administre Linux et il n’est pas prévu de recruter quelqu’un.
• Une exigence de conformité désigne un responsable pour l’application des patches, et ce responsable ne peut pas être vous.
• La stack est spécialisée chez l’hébergeur, qui a donc déjà rencontré le problème que vous rencontrez.
• La personne qui effectuerait autrement ces tâches est votre salarié le plus coûteux, et une heure de son temps coûte plus cher qu’un mois de l’option premium.

Une offre managed n’est pas automatiquement plus sécurisée. Elle applique effectivement les patches plus rapidement qu’un propriétaire inattentif, ce qui constitue un gain réel. Elle installe aussi souvent un control panel : il s’agit d’une application importante exposée au réseau, avec une page de connexion et son propre historique de vulnérabilités. Ce compromis peut être raisonnable, mais cela reste un compromis.

La décision repose toujours sur la même liste. Notez les dix tâches, indiquez qui est responsable de chacune d’elles dans chaque offre, puis comparez l’écart avec la valeur d’une heure de votre temps. La plupart des lecteurs techniques qui procèdent ainsi choisissent finalement une solution unmanaged et confient les tâches récurrentes à un timer. C’est une décision défendable, pas simplement une décision économique.

FAQ

Quelle est la différence entre un VPS administré et un VPS non administré ?

Un VPS non administré fournit uniquement la machine. Vous devez donc gérer les correctifs, le firewall, les sauvegardes, la supervision et le redémarrage après une mise à jour du kernel. Avec un VPS administré, une partie de ce travail est confiée au fournisseur, généralement la couche du système d’exploitation et les logiciels qu’il a installés pour vous. La limite exacte dépend de chaque fournisseur, et non du terme employé. Demandez donc par écrit le périmètre détaillé, tâche par tâche, avant de comparer deux tarifs.

Un VPS administré signifie-t-il que je n’ai pas besoin de mes propres sauvegardes ?

Non. Les sauvegardes du fournisseur protègent généralement son image de l’ensemble du serveur et servent surtout en cas de panne de l’hôte. Elles vous aident rarement si vous avez supprimé un fichier, exécuté une migration incorrecte ou corrompu des données plusieurs semaines auparavant sans vous en apercevoir avant aujourd’hui. Demandez combien de temps les snapshots sont conservés, si un seul fichier peut être restauré et qui réalise la restauration. Conservez ensuite votre propre copie hors site avec un outil tel que restic, puis testez-la avec restic restore latest --target /tmp/restore-check pour vérifier qu’elle fonctionne.

Un VPS administré est-il plus sécurisé qu’un VPS non administré ?

Pas en soi. Une offre administrée installe les correctifs plus rapidement qu’un serveur dont le propriétaire ne se connecte jamais, ce qui réduit réellement le risque. De nombreuses offres administrées installent également un panneau de contrôle. Or un panneau est une application réseau importante, exposée sur Internet, avec sa propre page de connexion et son propre historique de vulnérabilités. Un serveur non administré avec les mises à jour de sécurité automatiques, un firewall restrictif, un accès SSH par clé uniquement et aucun service supplémentaire en écoute constitue une cible plus réduite qu’un serveur administré exécutant un panneau.

Puis-je commencer avec un VPS non administré, puis passer à une offre administrée ?

Généralement oui, mais il ne suffit que rarement de cocher une option. Les fournisseurs auditent ou réinstallent souvent le serveur avant d’en prendre la responsabilité, car ils ne prennent pas en charge une configuration qu’ils ne peuvent pas contrôler. Demandez ce que comprend l’intégration, si une réinstallation est nécessaire et si les éléments que vous avez configurés vous-même resteront ensuite hors périmètre.

Est-ce que je conserve l’accès root sur un VPS administré ?

Sur la plupart des offres de VPS administrés, oui. Toutefois, l’accès root et le périmètre du support sont liés. Certains fournisseurs réduisent ou annulent leur support pour un composant que vous avez modifié manuellement. D’autres réinstallent le serveur à partir de leur propre template si un ticket nécessite une intervention approfondie. Obtenez cette règle par écrit avant de modifier quoi que ce soit et conservez vos fichiers de configuration dans un système de gestion de versions. Ainsi, une réinstallation prend une heure plutôt qu’un week-end.