Mettre en production le vendredi

L’idée de base c’est que s’il se passe quelque chose d’imprévu, les veilles de jours chômés sont les moins bons jours pour cela.

Au pire on ne le détecte pas et on a une catastrophe à gérer au retour. Au mieux on le détecte et on fait intervenir les personnes d’astreinte. Dans les cas intermédiaires il faut faire déranger l’équipe opérationnelle pendant les jours de repos, ce qui n’est pas idéal non plus. Rien de très attirant.

Et s’il y a des centaines de mini-déploiements réussis par jour ? des tests unitaires, un déploiement automatisé, un triple environnement iso dev / test / prod, une capacité de revenir à la version antérieure sur simple requête, et un monitoring complet … ?

Génial. C’est un bon objectif qui améliore sacrément le niveau de confiance.

Maintenant on ne parle pas niveau de risques, on parle équilibre de risques. Si le risque d’emmerdement est faible mais que le bénéfice d’une livraison le vendredi soir plutôt que le lundi matin est encore plus faible… autant attendre.

Cet équilibre seul vous pouvez le connaitre, mais ne vous leurrez pas quant à votre couverture de test. Elle ne couvre que ce que vous avez pensé à couvrir. La question n’est pas de savoir si vous aurez des problèmes mais de quand vous les aurez, et dans quelles conditions.

Du coup oui, j’ai tendance à conseiller par défaut d’éviter de livrer dans les périodes qui arrangent le moins. Les fins de journée les veilles d’opérations techniques planifiées importantes, vendredis après midi, veilles de jours chômés, et quelques dates très spécifiques genre autour de Noël pour le e-commerce.

Ça ne veut pas dire « on ne bosse pas » (on peut même livrer en pré-production), ça ne veut même pas dire « on ne livre pas » (parfois le rapport bénéfice/risque est assez haut, par exemple pour des correctifs), ça veut juste dire « ne pas faire comme si rien ne pouvait se passer » et garder une vision objective de la situation – impact d’un imprévu compris.

Publié

13 mars 2015

dans

Vie professionnelle

par

Éric

Étiquettes :

Commentaires

9 réponses à “Mettre en production le vendredi”

Nico

13 mars 2015

+1000 pour tout cela.

Et même si ça se passe bien : il y a toujours un syndrome qui fait que le client voit un truc qui ne peut pas attendre après la mise en prod.

Tu peux lui faire relire 600 fois le même truc, y a une barrière métaphysicosinusoïdale qui pète dès que le site est en prod.

Même si cela ne m’empêche pas de faire des méga-interventions le vendredi et que cela se passe comme un charme (y a que les peureux qui ont peur), clairement pour le côté humain, je préfère l’éviter, surtout quand rien ne le justifie (le syndrome de « je pars en week-end, tout doit être expédié » => très violent à la fin de l’année, à croire que la survie de l’humanité en dépend).

Répondre
r4is3

13 mars 2015

« pour le côté humain, je préfère l’éviter »
Voila EXACTEMENT pourquoi personne ne devrait mettre en prod un vendredi!

Répondre
Sebus

13 mars 2015

Tout à fait d’accord. C’est d’ailleurs très bien compris par les clients…

Répondre
nicoschwartz

13 mars 2015

« Au pire on ne le détecte pas et on a une catastrophe à gérer au retour »
ça doit dépendre des situations mais si tu as un monitoring et tous les bons éléments que tu as listés, on n’arrive pas le lundi matin avec une situation qualifiable de catastrophique à corriger.

« Au mieux on le détecte et on fait intervenir les personnes d’astreinte. »
Au mieux on a envoyé un bug en prod qui est détecté mais dont la correction peut attendre lundi matin.

L’équilibre des risques est un élément parmi d’autres à prendre en compte pour décider si on accepte de mettre en prod à tel ou tel moment.

D’autres éléments sont:
– à quel point est-ce que ça ralentit les gens qui bossent (en effet ne pas mettre en prod, ça ne veut pas dire ne pas bosser), mais ça veut dire passer à autre chose par exemple et donc plus de contexte switching car on ne finit pas une tache complètement tant qu’on ne l’a pas mise en prod et vérifié si tout est ok. ça veut dire des « bouchons » le lundi matin pour mettre en prod ou alors des mises en prod groupées … ce qui est un autre risque.
– le signal qu’on envoie. Je préfère dire mettez en prod par défaut et si vous manquez de confiance, attendez lundi. La confiance est super importante.

Je ne dis pas que c’est la bonne solution dans tous les cas, ça me paraît important de laisser le choix au dev et qu’il fasse son choix en sachant ce que ça implique.

Répondre
1. Éric
  
  14 mars 2015
  
  Tu as trop confiance dans tes outils.
  Les tests ne sont pas parfaits, pas complets. Le monitoring l’est très certainement encore moins ; il ne permet de tester que ce qui a été prévu à l’avance.
  
  Petit exemple perso : Livraison le vendredi. Le vendredi en soirée, après que tout le monde soit parti, quelqu’un se rend compte (de visu, en passant sur le site) que les prix ne sont pas les bons. L’analyse des données sources a déraillé et pris des prix qui auraient du être appliqués à un autre pays. Le monitoring automatique ne voit rien, les tests avant déploiement n’ont rien vu non plus. Logique en fait : tout se passe techniquement très bien. Par contre on va perdre de l’argent, et miner notre crédibilité publique à un moment extrêmement critique.
  
  Tu peux dire que les tests unitaires à la base étaient incomplets. C’est vrai (et je le dis d’autant plus facilement que ce code était responsabilité d’une autre boite), mais tes tests seront *toujours* incomplets, même avec une couverture de 100% (ce que tu n’as probablement pas).
  
  Tu peux dire que le monitoring était incomplet aussi. C’est vrai, mais encore plus discutable. Le monitoring ne test que ce qu’on a prévu à la base. Avait-on prévu que les prix pouvaient venir de données corrompues ? non. On aurait peut être du, et lever une alerte si le prix du panier moyen changeait d’un coup. Combien d’équipes ecommerce ont une telle alerte de monitoring ? sur un site de moins d’un an ? D’autant que c’est le genre de trucs sioux à régler pour ne pas avoir trop de faux positifs.
  
  Le fait de passer tests et monitoring ne nous apprend rien sur les conséquences. Elles peuvent être ridicules comme monstrueuses. Ca dit juste que si tu as une couverture correcte, ce n’est probablement pas un problème d’infra ou un problème technique grave. Sauf que les problèmes les plus graves ne sont pas techniques, ils sont métier. Et ça, les détecter c’est bien plus couteux et difficile.
  
  Pour la petite histoire en question, j’avais justement un bouton rouge qui me permettait de retirer arbitrairement de la vente toute la série de produits concernés. J’ai pris la décision, j’aurais bien aimé ne pas avoir gérer le stress en question mais c’était peanuts finalement. Combien d’équipes ecommerce ont ce bouton type de produit par type de produit, source de produit par source de produit, et savent qui a le droit de prendre la décision ?
  
  L’équilibre des risques est un élément parmi d’autres à prendre en compte pour décider si on accepte de mettre en prod à tel ou tel moment.
  
  C’est à ma connaissance le seul :) tu ne fais qu’expliciter ce qui selon toi pèse dans les risques ou bénéfices, d’un côté ou de l’autre.
  
  à quel point est-ce que ça ralentit les gens qui bossent (en effet ne pas mettre en prod, ça ne veut pas dire ne pas bosser), mais ça veut dire passer à autre chose par exemple et donc plus de contexte switching car on ne finit pas une tache complètement tant qu’on ne l’a pas mise en prod et vérifié si tout est ok. ça veut dire des « bouchons » le lundi matin pour mettre en prod ou alors des mises en prod groupées … ce qui est un autre risque.
  
  Bullshit!
  Tu as de super tests, un bon monitoring, un processus de déploiement rapide (sinon on ne parle pas de reporter plusieurs mises en production ou de les faire au jour le jour), et tu as besoin de faire du context switching pour la mise en prod, la vérifier (manuellement ?), avec un risque de bouchon ? Rien que la notion de bouchon implique que tu ne peux pas relivrer la version la plus récente et que tu es obligé de faire du pas à pas dans le même ordre que prévu ?
  
  Je trouve que tu n’es pas cohérent avec toi même. Si ta plateforme en est là (pas de honte, c’est encore au dessus de la plupart, et on commence tous avec un historique ou une situation qui est parfois loin d’être parfaite, j’en sais quelque chose), tu n’es pas crédible en disant que tes procédures, tes tests et ton monitoring sont suffisamment de confiance. Simplifier la mise en prod, faire en sorte qu’elle soit pousse-bouton, qu’elle soit suffisamment rapide et unitaire pour ne pas faire de « bouchon », c’est un peu le minimum avant d’envisager de déployer une veille de fête hein…
  
  le signal qu’on envoie. Je préfère dire mettez en prod par défaut et si vous manquez de confiance, attendez lundi. La confiance est super importante. Je ne dis pas que c’est la bonne solution dans tous les cas, ça me paraît important de laisser le choix au dev et qu’il fasse son choix en sachant ce que ça implique.
  
  Je ne comprends pas la remarque. Jusqu’à présent je n’ai absolument pas discuté de qui prend la décision. Ca dépend trop de l’organisation. Je n’imagine pas que la décision se prenne sans le dev, voire qu’il n’en soit pas à l’origine, tout simplement parce que c’est lui qui maitrise le mieux l’impact prévu. Après attention, il n’est pas seul non plus et c’est le management qui est responsable in-fine, et qui peut donc forcer une décision après avoir entendu la reco du dev. Parce qu’il y a un risque ou un bénéfice particulier pour la boite par exemple.
  
  Pour la petite histoire là aussi : Quand c’est le dev qui veut livrer en prod qui est d’astreinte le week-end, la phrase « c’est toi qui voit de toutes façons » a tendance a faire retarder la livraison au samedi. Déduisez-en ce que vous voulez :)
2. Florian Strzelecki
  
  15 mars 2015
  
  > tout simplement parce que c’est lui qui maitrise le mieux l’impact prévu
  
  Hm. Oui et non, cela dépend aussi de son expérience, de son niveau de compétence, et l’un des facteurs les plus importants à mon avis : la dépendance de son travail à l’environnement et au système sur lequel son code va être exécuté.
  
  À la louche je dirais que c’est le problème que j’ai le plus souvent rencontré : un collègue pense bien faire, il est confiant, mais il n’a pas une compréhension suffisante du système (que ce soit l’OS, les outils, les packages, les dépendances, l’impact sur les I/O, la RAM ou le CPU) pour ne serait-ce que penser au problème.
  
  Et ça, c’est une lacune qui ne se comble pas si facilement :
  
  * Tests « boîte noire » automatisées,
  * Tests de performance et de stress,
  * Connaissances mixte (dev & sys),
  * Une bonne équipe d’admin
  
  Dans tous les cas cela demande du temps, de l’expérience, et un investissement au départ.
padawan

15 mars 2015

Je pensais jusqu’ici que seuls les non-informaticiens croyaient que l’informatique était une science exacte. Je m’aperçois qu’il faut y ajouter les informaticiens sans expérience de la vraie vie.

(Éric, je ne dis pas ça pour toi ;-)

Répondre
padawan

15 mars 2015

Pour illustrer : https://twitter.com/mariofusco/status/577125201529450496

Répondre
Didier Sampaolo

6 novembre 2019

Salut Eric,

Des années plus tard, ce post est encore cruellement d’actualité. Les outils se sont bien démocratisés depuis (autant en tests qu’en déploiements), mais ton argument massue reste entièrement valable : ne serait-ce que pour le côté humain, je préfère reporter toutes les mises en prod « non-critiques » (hotfix par exemple) au lundi.

Répondre