Accès à la produc­tion dès le premier jour

J’avais publié il y a quelques temps une liste de contrôle pour l’in­té­gra­tion des nouveaux déve­lop­peurs. Dans la liste le nouveau venu reçoit et installe son poste de travail, se connecte aux outils de commu­ni­ca­tion, mais voit aussi confi­gu­rés ses accès au code source, à la plate­forme d’in­té­gra­tion conti­nue, et à la produc­tion.

Oui, à la produc­tion. Dès le premier jour. Et je veux qu’il l’uti­lise dans la semaine.

Idéa­le­ment tout le monde n’en a pas besoin (*). Toute­fois, si la personne est amenée à en avoir besoin dans le cadre de son travail, c’est dès le premier jour qu’on donne tout ça.

Il y a deux risques. Le premier risque c’est celui de la boulette. Le second c’est celui de la malver­sa­tion volon­taire :

* L’an­cien­neté dans l’en­tre­prise n’in­flue pas tant que ça dans la proba­bi­lité de boulettes. C’est plutôt l’an­cien­neté dans l’usage des accès qui compte, et il faut bien commen­cer pour l’ac­qué­rir.

La boulette elle s’évite par des outils et des pratiques. On prépare, on teste, on fait des revues croi­sées puis on auto­ma­tise. Dans tous les cas on disso­cie tota­le­ment le contexte de produc­tion de celui de déve­lop­pe­ment. Les proces­sus ne doivent pas permettre d’in­ter­ve­nir en produc­tion par erreur ou par inad­ver­tance.

* L’an­cien­neté n’in­flue pas non plus tant que ça dans le risque de malver­sa­tion volon­taire. On ne sait si quelqu’un souhaite abuser de ces accès qu’une fois qu’il les a, et même géné­ra­le­ment bien après.

Tout ce que je peux faire c’est ajou­ter des jour­naux pour chaque action, faire des backups, et limi­ter qui a accès aux données sensibles. Parti de là, soit je donne l’ac­cès en produc­tion soit je ne le donne pas. Quitte à enfon­cer les portes ouvertes et paraitre naïf : Vu les respon­sa­bi­li­tés que porte un déve­lop­peur, si je n’ai pas confiance en lui je ne le recrute pas à la base.

* * *

If a junior deve­lo­per acci­den­tally destroys produc­tion on their first day, it’s *your compa­ny’s* fault, not theirs. pic.twit­ter.com/GCYWwBdRIy

— John Femi­nella ✈️OSL (@jxxf) 3 juin 2017

Tout le monde semble d’ac­cord pour dire que le problème est du côté de l’en­tre­prise, et que ça ne mérite donc pas licen­cie­ment (**).

Cepen­dant, pour moi l’er­reur est au niveau des proces­sus et des outils, pas sur le fait d’avoir donné des accès de produc­tion à un nouveau venu. Une erreur de copier/coller dans la confi­gu­ra­tion de poste aurait pu arri­ver à n’im­porte qui, indé­pen­dam­ment de l’an­cien­neté dans la boite.

Que font les mots de passe de prod dans un docu­ment d’ins­tal­la­tion, plus en évidence que ceux de test ? Que fait la base de données de produc­tion acces­sible en écri­ture direc­te­ment depuis les postes de déve­lop­pe­ment ?

* * *

Aparté : (*) En théo­rie tout le monde n’en a pas besoin.

L’iso­le­ment de la produc­tion se fait au fur et à mesure de besoins et de la crois­sance des équipes. En pratique il y a géné­ra­le­ment une plate­forme d’in­té­gra­tion conti­nue et des déploie­ments auto­ma­ti­sés (c’est le mini­mum). Main­te­nant ces déploie­ments demandent encore souvent les accès SSH de produc­tion pour celui qui les lance. La plupart du temps les batch, scripts et évolu­tions de base de données se font encore en ligne de commande. Quand à opérer suite à un problème constaté en produc­tion, là c’est l’ar­ti­sa­nal total pour la grande partie des équipes.

Bref, surtout dans des petites équipes auto­nomes qui gèrent elles-mêmes leur produc­tion – ce que je tente de mettre en place, – il est fréquent que tout le monde soit amené à utili­ser les accès en produc­tion. C’est encore plus vrai quand on ne souhaite pas mettre une hiérar­chie forte où tous les déploie­ments sont forcé­ment faits par le lead.

Même quand toutes les actions sensibles sont réser­vées aux lead ou que l’au­to­ma­ti­sa­tion est bien pous­sée, il faut encore des gens pour gérer la produc­tion. Ça veut dire une rota­tion des astreintes sur suffi­sam­ment de personnes pour palier aux congés et absences des uns et des autres, mais aussi au départ d’un ou deux membres de l’équipe.

Diffi­cile de donner les clefs à moins de quatre personnes. Selon moi ce serait une erreur plus grave que de donner les clefs à la huitaine de déve­lop­peurs de l’équipe.

* * *

Seconde aparté : (**) Virer un déve­lop­peur parce qu’il a fait une erreur de bonne foi, ça me parait incom­pré­hen­sible, et ça quelle que soit la gravité des consé­quences.

D’une, si des erreurs sont faciles, c’est d’abord un problème de proces­sus. De deux, tout ce qu’on obtient c’est la peur : Pas de prise de risque et éven­tuel­le­ment des gens qui vont cacher les erreurs ou cher­cher des excuses.

Ce que j’at­tends c’est au contraire qu’on les expose pour qu’elles ne soient pas repro­duites et qu’on trouve des solu­tions de sécu­ri­sa­tion. Pour ça il faut un climat de confiance, qu’on se foca­lise sur « comment éviter » plutôt que « qui a fait ».

On licen­cie quand la personne pour incom­pé­tence, pour malveillance, pour non suivi conscient des règles et procé­dures ou pour négli­gence grave. Il faut vrai­ment des erreurs répé­tées et ce malgré des proces­sus assez sécu­ri­sés pour consi­dé­rer qu’on ne peut pas garder un colla­bo­ra­teur.