Mettre en produc­tion le vendredi


L’idée de base c’est que s’il se passe quelque chose d’im­pré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 catas­trophe à gérer au retour.  Au mieux on le détecte et on fait inter­ve­nir les personnes d’as­treinte. Dans les cas inter­mé­diaires il faut faire déran­ger l’équipe opéra­tion­nelle pendant les jours de repos, ce qui n’est pas idéal non plus. Rien de très atti­rant.

Mais j’ai des centaines de mini-déploie­ments réus­sis par jour, des tests unitaires, un déploie­ment auto­ma­tisé, un triple envi­ron­ne­ment iso dev / test / prod, une capa­cité de reve­nir à la version anté­rieure sur simple requête, et un moni­to­ring complet …

Génial, et ça doit sacré­ment amélio­rer le niveau de confiance.

Main­te­nant on ne parle pas niveau de risques, on parle équi­libre de risques. Si le risque d’em­mer­de­ment est faible mais que le béné­fice d’une livrai­son le vendredi soir plutôt que le lundi matin est encore plus faible… autant attendre.

Cet équi­libre seul vous pouvez le connaitre, mais ne vous leur­rez pas quant à votre couver­ture de test. Elle ne couvre que ce que vous avez pensé à couvrir. La ques­tion n’est pas de savoir si vous aurez des problèmes mais de quand vous les aurez, et dans quelles condi­tions.

Du coup oui, j’ai tendance à conseiller par défaut d’évi­ter de livrer dans les périodes qui arrangent le moins. Veilles d’opé­ra­tions tech­niques plani­fiées impor­tantes, vendre­dis après midi, veilles de jours chômés, et quelques dates très spéci­fiques 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é-produc­tion), ç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 correc­tifs), ça veut juste dire « ne pas faire comme si rien ne pouvait se passer » et garder une vision objec­tive de la situa­tion – impact d’un imprévu compris.


9 réponses à “Mettre en produc­tion le vendredi”

  1. +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).

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

  3. « 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.

    • 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 :)

    • > 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.

  4. 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 ;-)

  5. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.