Pourquoi un développeur ne doit pas avoir d'accès «root» sur un serveur de production ?

Lorsqu'une entreprise passe du mode petite entreprise à moyenne ou grande entreprise, assez souvent les tâches d'administrateur système qu'un développeur effectuait, sont déplacer vers une personne dédiée administrateur système. Cet ajout de personnel peut parfois amener des visions différentes, d'une part le développeur prend trop de place au niveau dans sa gestion du serveur tandis que l'administrateur système ne s'occupera pas de la stabilisation du serveur et cherchera un bouquet missaire auprès des développeurs. Pour que le rôle de chacun fonctionne bien, il faut donc que les tâches sont bien définies et s'entendre sur des règles cruciales. Une des règles les plus importantes c'est qu'un développeur ne doit pas avoir d'accès «root» sur un serveur de production. Voici les raisons pourquoi cela est si important :

1. Aucune trace écrite des modifications par rapport à la version précédente ou de correctif de certains bogues cruciaux.

Lorsqu'un développeur effectue les changements lui-même, il ne sera pas porté et répertorier tous les changements, d'une part parce que les petites entreprises sont beaucoup moins patientes en terme de temps accordé à un développeur pour résoudre un problème et d'autre part, bien des développeurs trouveront qu'il peut paraitre inutile de faire un suivi sur l'absence d'un "s" sur un mot au pluriel, qu'ils ont auront a corriger rapidement.

2. C'est une porte d'entrée pour le développeur «live» en production.

Lorsqu'on donne un accès en production, un patron impatient viendra parfois talonner jusqu'à son bureau un développeur afin qu'il corrige la situation devant lui et rapidement sur un problème léger. L'humain étant ce qu'il est, il finit nécessairement par faire le %1 d'erreur de la nature humaine. Souvent, le nombre de temps nécessaire au début, aurait été beaucoup plus court sur un serveur de développement, mais parce qu'on a brûlé les étapes, à cause qu'on avait un accès direct en production, le pire est arrivé. Ainsi, si on n'a pas d'accès en production, cette situation ne peut pas se produire.

3. Les supérieurs lui demanderont des tâches d'administrateur système plutôt que de développement.

Pour bien des gestionnaires, un informaticien, vaut bien un autre informaticien, ainsi si une personne est absente cette journée, on en prendra au hasard, et ça tombe sur vous !

4. L'administrateur système ne peut pas blâmer le développeur sur des problèmes du serveur.

Lorsqu'un administrateur système n'est pas le seul à travailler sur une machine, il a tendance à se plaindre que les autres sabots sont travail. C'est le cas tout particulièrement des administrateurs systèmes inexpérimentés.

5. Le programmeur s'oblige a être plus discipliné.

Lorsqu'il n'a pas possibilité pour le développeur d'accéder au serveur, celui ce voit obligé de passer par un mécanisme de déploiement, parfois automatiquement, un simple déploiement d'un «tronc», d'une «branche» ou d'un «tag» ou parfois effectuer par un administrateur système, lorsqu'il faut mettre à jour des dossiers, envoyer des requêtes SQL,... On arrive donc, dans le deuxième cas, à une procédure de déploiement. Et à partir de ce point, on se doit d'être discipliné pour que l'administrateur système effectue toutes les étapes de la procédure sans omissions et dans l'ordre indiqué.

Conclusion

En résumé, donné un droit «root» ou «Administrator» à un programmeur sur un serveur de production se révèle dans les faits essentiellement une mauvaise pratique.