ovh - Un bug dans l’UpdateContact pour les .fr

Bonjour,
Afin d’être totalement transparent avec nos clients, on se doit, aussi,
de communiquer sur ce qui n’a pas été. Ça nous arrive aussi. Dans le
cas là du bug dans l’UpdateContact, c’est une erreur humaine d’un
développeur qui est à l’origine du problème. Voici les détails et le
contexte.

Contexte :
Depuis quelques mois l’AFNIC a passé sur le protocole EPP ce qui permet
aux registrars, comme Ovh, de fournir l’ensemble se services que le
client peut attendre d’un registrar pour son nom de domaine. En effet,
jusque là nos robots communiquaient avec AFNIC via des emails
preformatés ce qui posait un certain nombre de problèmes. L’un de ces
problèmes était l’impossibilité de mettre à jour les contacts de noms
de domaines de manière automatique. Et donc depuis qu’AFNIC est passée
en EPP, nous avons beaucoup avancé sur l’ajout des fonctions simples
mais essentielles. Et donc aussi sur UpdateContact.

Le 2009-09-14 à 14:58:52 nous avons introduit une nouvelle fonction
dans notre code qui permet de mettre à jour les contacts dans la base
d’AFNIC. Enfin ! Le robot de synchronisation de notre base avec celle d’AFNIC
a été lancé en priorité basse dans la soirée du 15 et a mis un peu moins
de 1 journée pour réaliser la mise à jour de contacts qui étaient en
attente là depuis des mois ou des années. En tout, nous avons mis à
jour environ 12’000 contacts (en tout genre : les entreprises, les
particuliers, les associations etc). Changement d’adresse, changement
d’email de contact, changement de n° de téléphone etc. Dans la base
d’AFNIC 1 contact est unique et donc il est utilisé dans un ou plusieurs
noms de domaines. Et donc, en modifiant 1 contact, nous avons modifié le
whois de tous les noms de domaines qui avaient ce contact. Jusque
là rien d’anormal.

Un bug s’est glissé dans cette fonction. En plus de changement de
informations sur le contact, la fonction modifiait l’information sur le
"restrictedPublication" du contact. Il s’agit d’une option qui permet
de rendre le whois d’AFNIC privé et donc ne pas fournir les informations
sur les contacts d’un nom de domaine. Or, la fonction UpdateContact est une
fonction bas niveau et donc, par définition, elle ne peut pas savoir si oui
ou non, un contact est en "restrictedPublication". Un paramètre par
défaut s’est retrouvé par erreur dans cette fonction qui a forcé le
passage de l’option "restrictedPublication" à "false". Certains contacts
étaient déjà en "false" (les entreprises, les associations) donc il n’y a
pas de problème à ce niveau là. Mais d’autres comme les particuliers
ont été en "true" et sont passés en "false". En tout environ sur les
12000 contacts corrigés le vendredi 16, les 7700 contacts particuliers
ont ainsi changé l’état et ont été rendu public dans la base whois d’AFNIC.

Normalement, cette erreur n’aurait pas dû se glisser dans cette fonction.
C’est un point de base indiscutable. Mais en plus, comme nous développons
en mode "parano", s’il y avait une erreur, elle aurait dû activer l’option
"restrictedPublication" et pas l’enlever. Le développeur en question a
pensé justement "activer" le "restrictedPublication" en faisant dans le
code un "remove" de l’activation de "restrictedPublication". Mais à travers
une double négation dans un if, il l’a activé. Il a activé le passage de
"true" en "false". Donc il a désactivé l’option en l’activant dans le code.
Voilà. Une erreur humaine on ne peut plus explicite.

Voici le code en question :

# $params->rem =
# list => "restrictedPublication",
#
 ;

3 lignes de code qui ne devaient pas être là. rem = remove

Donc, chrologiquement, tous les contacts ont été mis à jour le vendredi 16.
Vendredi dans l’après midi, nous avons eu un cas isolé d’un client qui a créé un
ticket d’incident. Nous avons corrigé son problème à lui le vendredi à 19h34 en
forçant l’activation de la "restrictedPublication". Rien à ce moment là ne pouvait
nous prédire qu’il y a un bug plus générale. D’autres clients nous ont remonté
le problème durant la soirée et le week-end (2 tickets), mais c’est seulement
Mardi 20 que nous avons eu un feedback plus importants (5 tickets) qui pouvaient
faire penser à un bug. Le problème a été corrigé 2009-10-20 à 15:14:00 ensuite
un robot de corrction a rectifié les contacts en 30 minutes.

Voilà. On ne peut pas être plus transparent sur le problème, son
origine et sur le déroulement chronologique du problème jusqu’à sa résolution.

Les bugs ça peut arriver. A moins de ne plus rien développer, on ne peut pas
éviter les bugs dans le futur. On peut réduire le nombre mais on ne les
évitera pas.

Par contre ce qu’il faut, c’est une communication client/ovh nettement plus
réactive lors des incidents. Un thread sur le forum d’Ovh a été ouvert par un client
dans la soirée du 16 octobre et seulement quelques posts ont été ajoutés dans
ce thread tard dans la soirée du 16. Rien de dramatique à première vue. 2 clients ont
ouvert les tickets d’incidents durant le week-end seulement (ça tombe toujours au
mauvais moment les week-end). Malgré les équipes sur le support-incident 24/24, y
compris le week-end, nous n’avons pas pu déduire de ces 2 tickets un fonctionnement
générale anormal car pas assez de tickets ouverts (2 seulement). Quand nous avons
eu 5 tickets nous avons vu le problème et nous l’avons corrigé. Nous allons donc
renforcer les procédures internes, mais aussi les discussions et les échanges avec
nos clients sur les forums ou les mailing list. Même si on sait que le forum et
la mailing list n’est pas le support d’Ovh (ce n’est qu’un forum comme les autres
avec ses plus et ses moins).

Nous sommes sincèrement désolés pour ce problème (qu’on estime comme grave).

Amicalement
Octave

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