Mise en production

Mise en production, ou le mythe du vendredi.

Nous sommes vendredi, c'est le moment de troller^Wécrire un article sérieux

Je vois souvent revenir la même phrase, répétée partout, sans explication logique : « On ne met pas en production le vendredi ».

Pourquoi c'est absurde ? C'est simple :

• on ne met pas en production le vendredi sinon ça gâche le samedi, parce qu'on va passer toute la soirée, nuit pour tenter de réparer (enfin, agraver la situation) ;
• il y a toujours des problèmes le vendredi ;
• le vendredi, c'est trolldi ;
• les équipes en astreinte détestent devoir intervenir le week-end suite à une mise à jour cassée ;
• tester, c'est douter ;
• il faut corriger les erreurs de mise en production.

Si on pousse le raisonnement :

• on ne doit pas mettre en prod le vendredi parce que cela gâche le week-end ;
• on ne doit pas mettre en prod le lundi parce qu'on rentre le week-end (et on a fait la fête jusqu'à tard dimanche soir) ;
• on ne doit pas mettre en prod le mercredi, parce que l'après-midi, il faut amener les enfants à leurs clubs, activités sportives et ou culturelles ;
• on ne met pas en prod le week-end.

Du coup, on ne peut faire une mise en prod que le mardi ou le jeudi.

Faut arrêter les conneries.

Les raisons qui font qu'une mise en prod échoue sont diverses :

• cas non documenté ;
• pas de test en recette/environnement de test dédié (ou pas de recette ou recette ne correspondant pas à la production) ;
• pas de procédure de mise à jour écrite et fonctionnelle ;
• procédure de mise à jour non respectée, ou * prestataire (chargé d'appliquer les mises à jour) ne respectant pas la documentation de mise à jour ;
• DBA du prestataire qui surveille sa montre et éteint son laptop en plein milieu de l'exécution d'un script SQL de mise à jour et part « parce qu'il est 17h30 et j'ai fini ma journée ».

Toute ressemblance avec des faits réels ne sont pas du tout fortuits.

Pour les cas non documentés, c'est rare, mais cela arrive (GPO/WSUS en environnement Windows qui bloque). En général, l'adminsys (ou la DSI) arrive à s'en sortir. Un document de retour d'expérience est alors écrit et la documentation avec ce cas est mise à jour.

Pas de test en recette ou environnement de test dédié. C'est comme sauter en parachute sans vérifier que le parachute est bon, ou que l'on ait pas de parachute. Ça peut passer, mais en cas d'échec…

Pas de procédure écrite et fonctionnelle.

– On fait quoi pour appliquer la mise à jour ?
– Je sais pas.
– Il est où le serveur ?
– Je sais pas.
– Ça veut dire quoi “Production” ?
– Je sais pas.

Procédure de mise à jour non respectée, ou comment ne pas faire confiance à un prestataire qui fait la mise à jour sans tenir compte de la documentation, en mode “nan mais je fais comme d'habitude”. Et PAF ! Le serveur de production tombe. Client : pas content. Moi : pas content.

– Je comprends pas, c'est marqué dans la doc qu'il faut supprimer des fichiers. Bon, c'est pas grave, on va juste renommer en fichier-old.ext. Qu'est-ce qu'il peut se passer de mal ?
– Tiens, le service ne fonctionne plus. Bon, c'est la faute du fournisseur, hein. Bon, pause café.

Ici, c'est rigolo quand les extensions sont en .so ou .dll Conflit de .so ou .dll >.<

– Bon, il est 17h30. J'ai fini ma journée.

DBA du prestataire qui coupe son PC en plein milieu d'une mise à jour et part (en mode rien à battre!). Prod pdantée. Le lendemain, grosse enguelade, blame, facturation d'une demi-journée supplémentaire en support, application du PRA et reprise de la mise à jour.

(la boîte en question n'existe plus...)