Casser la production
May 20, 2022"J'ai peur de mal faire en DevOPS"
Peur légitime de Dev Junior
Cassons cette croyance
C'est l'argument que j'entends :
"Non mais je ne suis pas expert et j'ai peur de casser la production"
Ou
"Si ce que je mets en place nous fait perdre du temps ?"
And so what ? ("Et si quoi ?")
La peur de mal faire vient de deux facteurs :
-
L'impression de ne pas en savoir assez
-
Croire que ce que l'on fait est irrécupérable, irréversible ("inéluctable")
L'impression de ne pas en savoir assez
Ça se travaille
Avec de l'entrainement : oui au début, on perd en efficacité
Plus le temps passe, plus tu deviens rapide
Tout ça avec une méthode efficace (j'en ai parlé dans d'autres articles et dans la formation que je lance la semaine prochaine)
Mais c'est comme dans toutes nouvelles activités.
Croire que ce que l'on fait est irrécupérable
Petit secret : j'ai cassé des serveurs de clients en production
Et ça a été récupérable !
Il y a quelques années, un client me demande de supprimer un site web sur son serveur
J'ai la gestion de son Linux qui héberge plus d'une centaine de sites web
Tout est bien organisé en dossier, chaque site à le sien
Je me connecte en SSH, je vais dans le dossier parent qui contient tous les dossiers des sites
Je repère le dossier à supprimer
Et je lance mon "rm -rf" machinalement
Et là catastrophe ...
Je vois que ça prend des plombes alors que ça doit prendre 5 sec max
Paniqué, j'annule (ctrl+c) et je relis ma commande
J'ai fait "rm -rf *"
Alors que dans ma tête j'avais dit "rm -rf nomdudossier"
Je refais un ls -lh et là, sur la centaine de sites, il n'en reste que 7
J'avertis mon manageur
Je réussis à restaurer le tout, car on a des sauvegardes
Je contacte le client pour lui expliquer, on check ensemble que tout est ok
Ça tombe bien, il avait pas fait de mise en prod depuis plusieurs jours, donc la sauvegarde contient toutes les données à jour
Ça se termine avec plus de peur que de mal
Qu'est-ce que j'en retiens :
J'avais déjà de l'expérience
Linux je maitrise, ça fait des années que j'utilise
L'action que j'allais faire je l'ai faite des dizaines de fois
Et malgré tout j'ai merdé
Donc croire qu'avec plus de temps, plus de formations, plus d'expertises, plus de sénior qui t'entourent, tu ne vas jamais te planter ...
C'est illusoire
Si on revient à ton cas, comment faire si tu as peur de tout casser en faisant du DevOPS ?
Voilà la procédure que je m'impose d'écrire avant toute action
Le Mode Opératoire
-
But du doc :
-
Qu'est-ce que ce doc permet de réaliser comme tâche précisément
-
Ça doit tenir en une phrase compréhensible par l'ensemble de l'équipe
-
-
Pré requis :
-
De quoi a-t-on besoin avant de commencer à faire les actions listées dans ce doc
-
Les login/mdp, les versions d'app sur le poste, les ip des serveurs, les vérifications de sauvegarde ...
-
-
Sauvegarde
-
Quelles actions sont à prendre JUSTE avant de commencer pour sauvegarder l'état actuel du système ?
-
Cette sauvegarde doit me permettre de tout remettre à cet état initial en cas de pépin
-
-
Rollback
-
En partant de la sauvegarde, comment je fais concrètement pour la restaurer
-
Et ça doit marcher, quelle que soit l'étape à laquelle je suis dans les instructions (plus bas)
-
Exemple : que je sois au début, au milieu ou à la fin de mes manip, si ça merde je dois pouvoir restaurer l'état initial
-
Comme si je n'avais jamais rien fait
-
-
-
Les instructions
-
Là on décrit étape par étape (avec les lignes de commandes si nécessaire) de TOUT ce qu'il y a faire
-
On inclut des "if then else" si besoin
-
Ça doit être comme du code : on exécute sans se poser de questions
-
Ça doit gérer les cas d'erreurs et les cas d'exceptions
-
-
Les améliorations futures
-
Je note des idées qui me viennent pour rendre ce ModOP plus efficace plus tard
-
J'écris ce modop en même temps que je fais les tests sur un environnement de Dev
Un environnement qui peut être cassé sans impact
Quand c'est fini, je crée un nouvel environnement de Dev et je descends le ModOP de zéro
Je dois arriver au même résultat
Si tu en as la possibilité, tu fais exécuter ton modop par un collègue sur un autre environnement de Dev
Une fois que c'est fait, tu peux te permettre de faire sur la production
Donc si on revient à la peur de faire du DevOPS et à la peur de casser des trucs,
avec cette méthode, tu peux à tout moment être rassuré, car tu as un filet
Tu peux travailler en autonomie et faire intervenir des collègues que pour de la vérification (sans leur prendre leur temps et leur énergie)
Tu ne pourras plus invoquer l'excuse "J'ai peur de mal faire"
Voilà, voilà
Imrane 🏖
La newsletter pour ne rien louper
Rejoins les 2500 lecteurs de la newsletter pour obtenir des conseils, des stratégies et des ressources pour développer et monétiser tes compétences Tech.