Pas si simple et il gère biiiiien plus de machines que moi.
J'ai eu un technicien au téléphone à l'instant. Je voulais joindre le service commercial en réalité mais visiblement on a conclu qu'il y a sans doute un problème de téléphonie partiel au service commercial, leur système de rappel téléphonique va dans le vide par moment.
Donc on a discuté un bon moment, j'ai expliqué le problème/besoin et j'ai posé des questions pourquoi un SLA 99,95% sur du matériel a une intervention qui démarre plus vite que un SLA 99,99% du Public Cloud.
Quand un problème est matériel, c'est détecté beaucoup plus facilement (pas de ping, incendie,...) donc l'équipe 24/7 intervient sans qu'on demande.
Mais pour un problème d'hyperviseur pas détecté (car le statut marquait "actif" alors que non), l'équipe admin a décidé que ça marchait, point. Et donc pas d'alerte, pas d'intervention.
Le ticket, lui est envoyé au support dont le seul but est d'appliquer la règle du SLA qui n'est pas technique. Ils m'avaient dit avoir envoyer à l'équipe d'admin mais comme il n'y avait pas d'alerte...
A un moment, j'ai lancé un "reset hard" en espérant que ça bloque et que potentiellement une alerte remonte. Je pense que ça s'est alors vu. Il y a eu une intervention mais pas dans la précipitation c'est clair 
Le technicien à qui j'ai parlé a créé un ticket interne pour suggérer d'étudier un GTI/GTR à la place d'un SLA pour le public cloud. (Mais pas sûr que ça règle complètement le problème que l'équipe d'admin n'a rien vu).
Et j'ai suggéré l'idée de prendre des prestataires pendant les congés car il y a peut-être eu des départs de congé ce week-end. J'ai suggéré 4 personnes en plus pour combler les trous et financés par un GTI à mettre dans la version 4 des instances en échange d'une augmentation de tarif si besoin.
Je lui ai dit qu'il y a un flou actuellement entre ce qu'on pense qu'on nous vend et la réalité : OVH est supposé faire l'effort d'intervenir en fonction du SLA indiqué et non d'attendre délibérément le lundi et rembourser partiellement l'instance en panne.
Si j'ai créé le ticket, c'est que j'avais des raisons de penser que l'hyperviseur était en panne et non un problème système de l'instance. Il faudrait qu'on soit un peu plus écouté même si le monitoring dit que tout va bien.
Prochaine étape, le service commercial si j'arrive à les joindre. Et non @Gaston, pas le matin entre 8h et 9h, je suis sur UTC-3 et pour le service commercial, c'est eux qui appellent en théorie.
Après il y-a bien du support 24/7 mais c'est 250€ /mois.
J'aimerai bien l'avoir mais encore un peu cher pour moi.
Génial, cet appel était nécessaire dans ton cas 
Merci de partager l'information avec nous. C’est vraiment éclairant sur plusieurs points.
Cordialement.
De nos jours, l'argent est le moins important 
et le bonheur de dormir en sachant qu'il y a toujours du personnel d'OVH à tes côtés, ça n'a pas de prix 
C'est vrai mais va dire ça aux clients quand il va falloir leur présenter l'augmentation 
C'est tt le problème, et c'est bien pour ça (en partie) que j'arrête l'IT (je viens d'être accepté dans mon centre de formation pour faire aide soignant !).
Les clients veulent du 99,99% mais avec la facture d'une instance mutualisée...
Qd on leur explique que pour un tel niveau de dispo, il faut déployer tout un cluster, que je facture en conséquence, là tt d'un coup ce n'est plus si important.
Malgré tt, en cas de panne sur une solution "simple" (du genre un baremetal en solo), ça ne les empêche pas de mettre la pression pour que ça "remonte au + vite"... Ouais, sauf que tu ne paies pas pour du HA mais sur une offre de base...
Surtout que la plupart des clients n'ont pas besoin de 99,99%... A part le "ouais mais tu comprends, Google pénalise le site s'il y a du downtime".... Bah monte toi une infra HA/LB sur aws en mode devops, et paie le prix qui va avec (parce que c'est pas donné aws !)...
Bref, pour en revenir au sujet de départ, comme cela a été soulevé, le gros problème, c'est qu'il faut que les admins détectent que l'instance est buggée... Et ça, ce n'est pas tjrs évident...
Et même là, pas dit qu'ils interviennent "en urgence" sur une instance PCI, comme dit dans le thread, c'est réservé aux pannes hardwares (car facile à détecter).
La solution, en effet, c'est le support à 250€ / mois, mais on en revient au problème de départ, ça commence à chiffrer pour un indé... Ce qui implique d'augmenter ses prix, ce qui revient à faire tousser les clients (je comprends pas, ça marche sans)...
Bref, les prix hardware se sont effondrés, mais le coût Humain de l'astreinte h24, lui, reste bien réel, et ça, les clients ont souvent du mal à l'entendre.
Aide-soignant et IT, ce n'est pas du tout le même domaine. J'espère que si une Mamie t'appelle un samedi matin, tu ne vas pas lui dire que tu passes le Lundi 
Le technicien m'a dit qu'ils voulaient éviter d'augmenter les tarifs.
Individuellement, une instance à 28 € a un coût très faible et ce coût ne permet pas d'envoyer une alerte un samedi alors que leur monitoring n'a rien vu. Il faudrait trouver un moyen intelligent d'y arriver, même pendant les vacances. Le truc est certainement de pouvoir filtrer le "bruit" des tickets qui ne sont pas des pannes de l'hyperviseur, par exemple au lieu d'essayer de détecter une panne, il faudrait que le ticket déclenche une série de test automatiques sur l'instance très poussés et si les tests sont en échec, ça remonte l'alerte, avec un suivi de l'intervention.
Et effectivement, il semble que pour le matériel, actuellement, c'est contre-intuitivement plus simple/rapide à obtenir une intervention.
Bonjour, j'ai eu le service "commercial" en ligne.
Je ne ferais aucun commentaire sur ce que j'en pense.
Mais j'en conclus qu'il y aurait bien un problème dans le cas où un service OVH tombe en panne et est non détecté par leur monitoring.
Le seul moyen de communication pour les alerter, lui est confiné aux heures ouvrées (support standard) alors que le problème, en lui-même peut recevoir une intervention pour essayer de respecter le SLA. Et la garantie d'intervention s'active seulement avec un support à 250 € / mois, ce qui fait exploser le tarif.
Leurs administrateurs semblent ne pas chercher à intervenir tant que tout est vert sur le monitoring.
C'est peu comme appeler les pompiers mais de leur caserne, ils ne sentent pas la fumée donc tout va bien.
Une panne sur serveur dédié étant plus facilement détectable, un SLA de 99,95% donne en réalité des pannes plus courtes que un SLA de 99,99% sur le Public Cloud...
À mes yeux, la SLA de 99,99% c'est purement un argument commercial, vu que de toute façon les indemnités sont ridicules en cas de non-respect de l'uptime.
Pour les gens motivés, en équipe, se monter son propre cluster est souvent + intéressant.
Que ce soit pour les finances, les performances ou la disponibilité.
Mais ça implique d'avoir des besoins suffisamment importants pour rentabiliser toute l'infra.
Et d'avoir une petite équipe pour gérer l'astreinte.
+1
Je suis avec toi
C'est plus ou moins ce que je comprends, la facilité du Public Cloud à monter des serveurs est gâchée par le risque de non intervention pendant 62 heures en cas de panne.
Alors que pour un dédié, c'est curieusement moins risqué, même avec un seul dédié.
Un seul dédié, il y a bcp bcp d'autres problèmes potentiels !
J'ai fait un article sur mon site à ce sujet, vais éviter de spammer ici
A minima, virtualiser le serveur + un serveur PBS pour sauvegarder la vm complète 1 ou plusieurs fois par jour. Ce qui permet de redéployer rapidement les services sur un autre serveur si nécessaire.
Perso, le baremetal tt seul (non virtualisé), je ne veux plus en entendre parler
Oui évidement, une VM sur du proxmox ou autre.
Bah si !
Plus ça va plus je virtualise aussi (mais avec kvm/qemu/virsh sans proxmox) c'est vrais que ça amène de la souplesse sans trop complexifier.
Le problème maintenant c'est cette brusque augmentation des tarifs sur le matos (RAM et SSD)
J'aime bien passer par Proxmox, ça simplifie énormément, une jolie GUI.
Pis les outils comme Proxmox Backup Server pour sauvegarder facilement la VM, la restaurer, etc...
Mais bon, le principe de base reste le même, virtualiser les services en prod, pour les rendre le - dépendant possible de la machine physique en dessous.
Je suis d’accord avec toi, le fait que nous puissions avoir une récupération ultra‑rapide, cloner, des snapshots… nous aide à réduire les coûts (et les maux de tête 
), allons, c’est un outil de survie aujourd’hui.
J'ai utilisé virssh et Proxmox, et sincèrement je reste également avec Proxmox ; quand on effectue une migration à chaud et un basculement automatique entre nœuds en quelques clics… Proxmox me semble plus pratique.
J'ai testé proxmox rapidement mais la courbe d’apprentissage me parait bien raide par rapport a une gestion simple en console.
Bon bien sur je suis certain que les fonctionnalités de Proxmox sont super il faut trouver le temps quoi.
Tout à fait d'accord. Proxmox est très puissant, mais il a sa courbe d'apprentissage et demande du temps pour le maîtriser. Pour une utilisation plus simple et directe, parfois la console et des outils comme Virtualmin ou Cockpit sont plus rapides à prendre en main. L'important, c’est que l’outil s’adapte à ton flux de travail, pas l’inverse. Quand tu auras un créneau, ça vaut le coup, mais ce n’est pas indispensable si ce que tu as fonctionne déjà 
Salut 