Je me suis abonné à un serveur privé virtuel (VPS) qui promet une garantie de 99,99% de la disponibilité. Mais je rencontre souvent des temps d'arrêt, des temps d'accès lents et je réfléchis à la façon de les "obtenir".
Existe-t-il de toute façon un service/service qui me permette de prouver que le fournisseur d’hébergement Web ne fournit pas la garantie de disponibilité de 99,99%?
La réponse rapide est qu’il existe des sociétés qui surveillent les sites Web, pindom étant le plus connu. pour un seul site, de nombreux services sont gratuits. J'utilise http://mon.itor.us Ils ont une interface utilisateur vraiment sympa.
Si votre site Web ne répond pas, il existe de nombreuses autres causes plus probables que les problèmes de connectivité de votre fournisseur d'hébergement. Idéalement, vous devriez voir s’ils vous donneront l’adresse d’un autre site situé sur le même nœud. Si les deux sites sont hors service, vous avez alors de bonnes raisons de blâmer l’hôte. Si seul votre site ne répond pas, vous devrez résoudre vous-même les problèmes en supposant que le VPS n'est pas géré.
Il est probable que la garantie de disponibilité se rapporte à la connectivité réseau. Normalement, cela est testé en recherchant une réponse ping de votre serveur. Même si vous pouvez prouver que le serveur est inaccessible à partir de plusieurs emplacements et que c'est le nœud entier, pas seulement votre VPS, il n'en vaudra probablement pas la peine. Un SLA typique pourrait offrir un crédit de service jours par heure d'indisponibilité. Vos efforts seront mieux dépensés pour migrer vers un hôte plus fiable que pour "récupérer" votre hôte actuel.
Comme le SLA est normalement référencé au temps de disponibilité du serveur, le meilleur moyen de le vérifier est au niveau du système d'exploitation.
Avec la commande tuptime , vous pouvez vérifier le comportement des 365 derniers jours. Passez à l'option --tsince
les secondes annuelles en négatif.
# tuptime --tsince -31536000
System startups: 5 since 02:26:54 PM 01/10/2017
System shutdowns: 3 ok - 1 bad
System uptime: 100.0 % - 364 days, 23 hours, 51 minutes and 39 seconds
System downtime: 0.0 % - 8 minutes and 21 seconds
System life: 1 year, 0 days, 0 hours, 0 minutes and 0 seconds
...
Même l'option -t
vous fournit le rapport de table historique depuis un an. Notez la colonne "Fin" qui enregistre comment était l’arrêt du système:
# tuptime --tsince -31536000 -t
No. Startup Date Uptime Shutdown Date End Downtime
7 56 days, 18 hours, 25 minutes and 22 seconds 08:52:17 AM 03/08/2017 OK 23 seconds
8 08:52:40 AM 03/08/2017 2 days, 2 hours, 5 minutes and 10 seconds 10:57:50 AM 03/10/2017 OK 32 seconds
9 10:58:22 AM 03/10/2017 56 days, 1 hour, 59 minutes and 38 seconds 01:58:00 PM 05/05/2017 OK 9 seconds
10 01:58:09 PM 05/05/2017 213 days, 11 hours, 28 minutes and 13 seconds 12:26:22 AM 12/05/2017 BAD 7 minutes and 17 seconds
11 12:33:39 AM 12/05/2017 36 days, 13 hours, 53 minutes and 16 seconds
Si vous voulez la plus haute précision possible, ajustez dans "/etc/cron.d/tuptime" leur exécution toutes les cinq minutes */5
à chaque minute *
.
Plus d'informations sur le site Web du référentiel: https://github.com/rfrail3/tuptime/
Je dirais que votre meilleur pari serait d'obtenir un service de surveillance par une tierce partie - semblable à Pingdom - pour les y tenir. Idéalement, il serait assez difficile pour une personne de contester de disposer de deux services de disponibilité définis de manière indépendante pour vérifier les temps d'arrêt.
Certes, même si vous pouvez prouver que leur promesse de disponibilité de 99,99% a été brisée, cela ne signifie pas que vous pouvez obtenir quelque chose de la société elle-même. Je suis d'accord avec le commentaire de @ Metalshark: commencez avec un hôte fiable, ce qui devrait, espérons-le, en faire une question discutable.
En plus des suggestions ci-dessus ...
En supposant que vous gériez vous-même le VPS, assurez-vous que les problèmes ne vous appartiennent pas ou qu'ils résultent d'un VPS fourni avec des ressources insuffisantes pour gérer le travail que vous lui demandez de faire, en particulier en période de pointe.
Une fois que vous êtes certain que le problème se situe en amont de votre VPS, si les temps d'arrêt sont fréquents, je vous conseillerais d'effectuer un déménagement bien planifié et bien exécuté ailleurs, plutôt que de vous battre pour que votre fournisseur actuel respecte son contrat de niveau de service. . Le SLA a probablement plus de lacunes que la réunion d'un vieux club de crochet pour dames, en tout cas.
En bref, si vous êtes absolument certain que votre temps d'indisponibilité et vos performances faibles sont la faute de l'hôte, je vous suggère d'arrêter d'essayer de les obtenir et de vous en passer.