ovh - incident pCC

Bonjour,

Cette nuit nous avons eu un incident sur l’une de
baies de stockage du pCC. Le switch qui gère les
masters de 19 NAS-HA s’est mis en défaut suite à
un défaut simultané de 2 ventilateurs du switch.
Ce n’est pas grave, ça peut arriver. Le problème
est que les 19 têtes slaves n’ont pas su détecter
ce défaut et n’ont pas repris immédiatement le
service. C’est un cas de figure qui (bizarrement)
n’a pas été prévu et n’a pas été codé. Faute.

Nous avons mis 1h45 pour remettre le service en
place. Faute encore. Et ceci malgré le fait que
4 équipes indépendantes qui ont eu de remontés
du problème. Même si nous n’avons pas eu de
pertes de données, la panne n’est pas acceptable.
Voici, en toute transparence, notre analyse.

On est à 22h30. Le switch se coupe électriquement.

D’abord l’équipe d’astreinte, qui a reçu les
alertes de suite après le défaut du service,
ne s’est pas inquiété de suite. Pourquoi ? Parce
que les travaux de mises à jour de l’infrastructure
de réseau a été prévue et l’astreinte a pensé
qu’il s’agissait tout simplement de travaux de
maintenance et donc que c’est normal. Il n’y a
pas eu de vérification au près de l’équipe
réseau. Ça aurait aidé car les travaux n’ont
pas été prévus pour cette nuit précise mais
pour "une" nuit. C’est seulement au bout d’1
heure de panne que l’astreinte a commencé à
chercher l’origine du problème et alerter les
autres équipes. Une faute fatale.

L’équipe de pCC a son propre système de monitoring.
On monitore tout et pour chaque client. Mais le
système s’est retrouvé bloqué (on ne sait pas encore
pourquoi) et n’a pas enregistré de défaut. Et donc
le monitoring n’a pas déclenché les équipes de pCC.
Les alertes ont été déclenché au bout de 1h45.

La 3ème équipe c’est le support qui s’est retrouvé
avec le PABX en panne au moment de la panne (!?).
L’astreinte a réparé le serveur PABX sans penser
qu’il y avait un rapport avec le problème sur le
pCC. Une fois que le PABX a été réparé, le support
a reçu des appels des clients et a déclenché l’équipe
VIP ainsi que son responsable. Ici on a mis 1 heure
aussi.

Puis la 4ème équipe dans le datacentre qui a reçu
les alertes mais n’est pas intervenu sur la panne
en urgence totale. "tout est redondé donc pas de
panique"(c). Au bout de 40 minutes d’investigation,
le datacentre a déclenché les équipes de réseau qui
ont commencé à regarder le problème au bout de
20 minutes. Toujours sans urgence. "tout est redondé
donc pas de panique"(c).

On est à 23h30.

Au bout d’1 heure, les 4 équipes ont été au même
point et ont trouvé l’origine du problème. A ce
moment, la décision a été prise de réparer le
switch et ne pas basculer manuellement sur les
slaves. Grosse faute. L’équipe réseau a réparé
le switch en 45 minutes et le service est revenu.
Mais un basculement sur le slave prend entre 15
secondes à 30 secondes. Et on aurait eu 1h00 de
panne au lieu de 1h45.

0h15 le service est à nouveau UP.

Voilà.

Il n’y a pas d’excuses. On a été très mauvais
sur ce coup là. On ne peut que s’excuser et faire
déclencher les SLA en espérant que la confiance
va revenir rapidement grâce aux améliorations
que nous allons effectuer dans les prochaines
heures/jours.

Et, donc ce matin, nous avons déterminé tout ce
qu’il faut faire pour améliorer les processes
interne liés au pCC mais pas seulement. On s’est
rendu compte de pas mal de petits problèmes qui
empêchent les équipes d’être en état d’urgence
quand c’est réellement le cas. Mais globalement
une meilleure communication aurait énormément
accéléré la résolution du problème. Le système
de monitoring n’est pas parfait. Il faut le
faire évoluer.

Voici la liste des améliorations que nous avons
déjà commencé à faire :

- mieux nommer les équipements réseaux par métier,
ne pas utiliser les noms commun.

- préparer et valider une configuration standard
pour les serveurs de monitoring qui est indépendante
de tous. vérifier l’indépendance des emails,
des SMS et de PABX.

- ajouter une IP fake de service NAS-HA accessible
de l’extérieur et la monitorer

- rendre le monitoring pCC indépendant de pCC dans
un autre datacentre pour monitorer les hosts et
les NAS de chaque client.
- monitorer le système de monitoring de pCC.

- ajouter une VM de monitoring par host en IPv6
pour monitorer le fonctionnement de chaque
host de client en fonctionnement de l’extérieur

- sur les NAS-HA fixer le code de basculement
master/slave en prenant en compte "eth0 down"

- sur les NAS-HA ajouter un OCO sur le test de
la route par défaut sur le master et le slave
puis fixer le code de basculement master/slave
avec le cas "le slave ne ping pas le master &&
OCO master GW down && OCO slave GW up".

- nous allons officiellement créer une équipe
niveau 2 dans le datacentre qui sera être
présente 24/24 7/7, au lieu de 10/24 5/7

- les alertes de l’ensemble des équipements de
pCC, FEX, N5, N7 sont ajoutés sur l’équipe
de réseau

- travailler sur les fausses alertes qui diminuent
la réactivité des équipes

- le support déclenchera les équipes VIP par
téléphone (pas de SMS) et on diminue le nombre
des alertes de même genre pour déclencher le
responsable du support.

- le stock de spare de N5 doit être doublé dans
chaque datacentre où il y a le N5. le but est
de diminuer le temps de changement d’un spare.

- le monitoring de "tasks de pCC qui tombent en
erreur" déclenche l’équipe pCC 24/24

En tout 64 services NAS-HA ont été en panne
impactant 60 clients pCC. En terme de SLA c’est
très simple : Ovh assure le 100% de SLA sur le
stockage. C’est à dire qu’en cas de panne, les
pénalités démarrent dés la 1ère seconde de panne
détectée par le vSphere. Le ratio sur le stockage
est de "-5% par 10 minutes de panne". Il n’y a
pas de pertes de données. Les temps sont calculés
par le vSphere. Nous allons les appliquer
automatiquement.

Nous sommes sincèrement désolé pour l’incident
et la gestion de l’incident. On va faire le
nécessaire pour que ceci ne se reproduise pas.

Amicalement
Octave

Envie de recevoir nos dernières nouvelles? Inscrivez-vous à notre newsletter