Accès à la production dès le premier jour

J’avais publié il y a quelques temps une liste de contrôle pour l’intégration des nouveaux développeurs. Dans la liste le nouveau venu reçoit et installe son poste de travail, se connecte aux outils de communication, mais voit aussi configurés ses accès au code source, à la plateforme d’intégration continue, et à la production.

Oui, à la production. Dès le premier jour. Et je veux qu’il l’utilise dans la semaine.

Idéalement tout le monde n’en a pas besoin (*). Toutefois, 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 malversation volontaire :

* L’ancienneté dans l’entreprise n’influe pas tant que ça dans la probabilité de boulettes. C’est plutôt l’ancienneté dans l’usage des accès qui compte, et il faut bien commencer pour l’acquérir.

La boulette elle s’évite par des outils et des pratiques. On prépare, on teste, on fait des revues croisées puis on automatise. Dans tous les cas on dissocie totalement le contexte de production de celui de développement. Les processus ne doivent pas permettre d’intervenir en production par erreur ou par inadvertance.

* L’ancienneté n’influe pas non plus tant que ça dans le risque de malversation volontaire. On ne sait si quelqu’un souhaite abuser de ces accès qu’une fois qu’il les a, et même généralement bien après.

Tout ce que je peux faire c’est ajouter des journaux pour chaque action, faire des backups, et limiter qui a accès aux données sensibles. Parti de là, soit je donne l’accès en production soit je ne le donne pas. Quitte à enfoncer les portes ouvertes et paraitre naïf : Vu les responsabilités que porte un développeur, si je n’ai pas confiance en lui je ne le recrute pas à la base.

* * *

Tout le monde semble d’accord pour dire que le problème est du côté de l’entreprise, et que ça ne mérite donc pas licenciement (**).

Cependant, pour moi l’erreur est au niveau des processus et des outils, pas sur le fait d’avoir donné des accès de production à un nouveau venu. Une erreur de copier/coller dans la configuration de poste aurait pu arriver à n’importe qui, indépendamment de l’ancienneté dans la boite.

Que font les mots de passe de prod dans un document d’installation, plus en évidence que ceux de test ? Que fait la base de données de production accessible en écriture directement depuis les postes de développement ?

* * *

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

L’isolement de la production se fait au fur et à mesure de besoins et de la croissance des équipes. En pratique il y a généralement une plateforme d’intégration continue et des déploiements automatisés (c’est le minimum). Maintenant ces déploiements demandent encore souvent les accès SSH de production pour celui qui les lance. La plupart du temps les batch, scripts et évolutions de base de données se font encore en ligne de commande. Quand à opérer suite à un problème constaté en production, là c’est l’artisanal total pour la grande partie des équipes.

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

Même quand toutes les actions sensibles sont réservées aux lead ou que l’automatisation est bien poussée, il faut encore des gens pour gérer la production. Ça veut dire une rotation des astreintes sur suffisamment 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.

Difficile 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éveloppeurs de l’équipe.

* * *

Seconde aparté : (**) Virer un développeur parce qu’il a fait une erreur de bonne foi, ça me parait incompréhensible, 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 processus. De deux, tout ce qu’on obtient c’est la peur : Pas de prise de risque et éventuellement des gens qui vont cacher les erreurs ou chercher des excuses.

Ce que j’attends c’est au contraire qu’on les expose pour qu’elles ne soient pas reproduites et qu’on trouve des solutions de sécurisation. Pour ça il faut un climat de confiance, qu’on se focalise sur « comment éviter » plutôt que « qui a fait ».

On licencie quand la personne pour incompétence, pour malveillance, pour non suivi conscient des règles et procédures ou pour négligence grave. Il faut vraiment des erreurs répétées et ce malgré des processus assez sécurisés pour considérer qu’on ne peut pas garder un collaborateur.

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 OVH SAS, joignable par téléphone au +33 (0)9 72 10 10 07 et dont le siège social est au 2 rue Kellermann, 59100 Roubaix, France.