Comment perdre 2 ans de confiance en 2 heures
15/04/2017
Les faits
08:44
Un client de l'EURL Barme signale l'indisponibilité d'un service.
08:55 Création d'un ticket incident :
Bonjour,
Que ce soit depuis l'extérieur (ping barme.fr 195.154.60.32) ou par le RPN (ping 10.x.x.x), le serveur ne répond pas.
Est-ce un problème réseau ?
Merci.
08:58 réponse du support :
Bonjour,
Je fais quelque vérifications et reviens vers vous dans les plus brefs délais.
Cordialement,
09:01 (support) :
Bonjour,
Je vois des logs sur le kvm qui peuvent indiquer une Kernel Panic.
M'autorisez-vous à passer le serveur en mode secours afin de faire quelques tests? Je reviendrai vers vous dès les tests finis.
Cordialement,
09:08 (EURL Barme) :
Oui, passez en mode rescue.
A noter, j'ai basculé mon IP failover sur mon serveur de secours.
09:36 (support) :
Bonjour,
Après les tests que j'ai effectué, il apparaît que le serveur est fonctionnel et n'a pas de souci matériel.
Je vous invite à regarder du côté Software/OS et installation ou configuration.
Je reste à votre disposition pour toute autre demande.
Cordialement,
09:40 (EURL Barme) :
ping x.x.x.x: 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
Vous appelez ça fonctionnel ?
09:43 (support) :
Bonjour,
J'ai fait les tests en mode secours et cela n'utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l'OS que vous avez installé et les réglages que vous avez fait.
Je reste à votre disposition pour toute autre demande.
Cordialement,
09:45 (EURL Barme) :
Merci, je sais ce que c'est le mode secours.
Ne touchez donc plus à rien ; je vais investiguer par moi-même.
09:47 (EURL Barme) :
A noter le "Monitoring" :
Monitoring
Service Statut
Ping du serveur Disponible il y a 1 année historique
!!
09:54 (support) :
Bonjour,
Très bien.
Cordialement,
10:00 (EURL Barme) :
Mon serveur sd-x est à nouveau opérationnel, directement sans _aucune_ modification de sa configuration...
Un simple reboot aura donc suffit à le remettre en service ; c'est habituel de mettre en cause la configuration du client mais comment pouvez-vous le justifier ?
10:16 (support) :
Bonjour,
Je vois que le souci sur ce serveur est résolu après un simple reboot.
Je vous invite à clore le ticket et à le noter en laissant un commentaire.
Bonne journée,
10:20 (EURL Barme) :
Dans syslog, j'ai :
...
Apr 11 21:17:01 ol1 /USR/SBIN/CRON[46128]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Apr 12 09:40:42 ol1 kernel: imklog 5.8.11, log source = /proc/kmsg started.
...
Donc mon serveur est down depuis hier 21:17:01 et à nouveau opérationnel depuis 09:40:42 ce matin.
Et pourtant votre monitoring ne m'a pas alerté et prétend qu'il est disponible depuis 30/09/2015 09:52:18 ! ?
N'y aurait-il pas un problème de votre coté ?
10:44 (support) :
Bonjour,
Je transmet votre demande au service concerné et nous reviendrons vers vous dans les plus brefs délais.
Cordialement,
10:53 (EURL Barme) :
Cela vous amuse de passez mon serveur en mode rescue sans prévenir ?
11:03 (EURL Barme) :
Vos techniciens mettent mon site HS alors que je leur ai demandé de ne plus y toucher à 12/04/2017 09:45:53.
C'est pourtant pas un jouet ce serveur !
11:09 (support) :
J'ai prévenu mes collègues en charge
-- --
Cordialement,
11:30 (support) :
Bonjour,
je reprends la suite du ticket au vu du signalement de celui-ci.
Un quiproquo et un échange trop rapide lors de la remonté a en effet entraîné un autre passage en secours.
Je confirme que le serveur est bien opérationnel de mon côté
Il ping bien en mode normal.
J'ai remis à jour le monitoring sur le serveur en espérant que vous soyez allertez la prochaine fois.
Rien ne vous empêche de mettre en place votre propre monitoring.
Cordialement - Technicien Premium
Commentaires
C'est toujours dans un contexte défavorable qu'un incident survient, en l'occurrence lors d'un déplacement, avec un contexte technique d'intervention et une disponibilité réduits.
Evidemment, c'est un client qui découvre et indique le problème ; en temps normal il aurait été découvert bien plus tôt et l'investigation de l'EURL Barme aurait été faite directement par une connexion sur la console du serveur, avant de faire intervenir le support.
Le support a été très réactif : réponse au ticket en 3 minutes. Son diagnostique initial (Kernel Panic) a été confirmé par le technicien Premium intervenu après escalade du problème.
Erreur du support : retour sans vérifier que le serveur est opérationnel après sortie du mode rescue. Il aurait été préférable d'attendre la fin du redémarrage.
Dérapage du support : mise en cause arbitraire du client ("J'ai fait les tests en mode secours et cela n'utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l'OS que vous avez installé et les réglages que vous avez fait.")
C'est un grand classique de tous les supports de mettre systématiquement le client en cause. C'est évident que la plupart des remontées faites aux supports le sont par des personnes aux compétences informatiques modestes et de surcroît sans doute agressives car le problème pour lequel elles appellent est mal vécu. Mais ce n'est pas une raison pour mettre tout le monde dans le même panier et considérer, a priori, que l'origine du problème est du coté du client. La bonne approche devrait être de vérifier en premier s'il n'y a pas un souci du coté du prestataire et rien n'empêche, ensuite, de mettre le client face à ses responsabilités.
Erreur gravissime du support : passer un serveur de production (qui fonctionne !) en mode rescue sans autorisation du client. Là c'est le summum de l'inconséquence et totalement inadmissible de la part d'un service professionnel.
Ensuite c'est l'escalade et le problème atterri sur le dos d'un technicien "Premium" qui n'y est pour rien et ne peut plus rien y faire. Le terme "Premium" fait sourire avec sa connotation de "compétence supérieure". Techniquement c'est sans doute vrai mais dans le contexte, ce sont davantage des compétences en communication qui sont requises.
Ce technicien "Premium" prendra la peine d'appeler pour signaler le retour au mode normal du serveur, ce qui est très bien et courageux de sa part mais son ton condescendant face à un interlocuteur avec 36 années d'expériences en informatique dans un tel contexte sera la cerise sur le gâteaux… Une formation de base à la communication lui serait bien utile.
Et pour la suite…
Les serveurs sous linux sont très fiables mais pas infaillibles. C'est justement la raison pour laquelle un serveur dédié utilisé pour un service critique ou non doit être doublé par un clone synchronisé automatiquement et en permanence avec le serveur en fonction. Un kernel panic isolé est un aléa potentiel qui ne remet pas en cause le serveur ni sa configuration.
De même un incident isolé mal géré ne remet pas en cause un prestataire ni son professionnalisme.
L'EURL Barme ne changera donc pas ses serveurs impliqués dans cet incident et ne souhaite finalement qu'une chose : que cesse cette habitude des supports de mettre systématiquement en cause le client.
Epilogue
A l’occasion d’un autre souci technique (mineur celui-là) sur mes serveurs chez Online, j’ai eu affaire à un service de qualité, tant en compétences techniques qu’en communication.
Comme quoi cela dépend beaucoup des interlocuteurs ; il y en a des décevant mais aussi des très bons.
Ouf, mes serveurs sont décidément bien gérés et mes fournisseurs bien choisis :-)