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.

* * *

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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.