Casser la production
Hello,
"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")
Si ce n'est pas déjà fait, tu peux :
Découvrir notre formation sur le DevOps
Lire toutes les éditions précédentes de la newsletter
Au programme :
L'impression de ne pas en savoir assez
Croire que ce que l'on fait est irrécupérable
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à
Tes cadeaux pour te remercier de partager la newsletter
Pour rappel, si tu recommandes la newsletter à d’autres personnes, voici les récompenses que tu peux gagner :
25 recommandation → On met en avant ton profil dans un article
50 recommandations → Une visio de 20 min de mentoring DevSecOps avec nous
100 recommandations → Une de nos formations aux choix offertes
Il te suffit de cliquer sur le bouton juste en dessous pour obtenir ton lien personnalisé :
Voilà, c’est tout pour aujourd’hui.
On est curieux d’avoir tes retours.
Partage nous tes réactions en répondant à ce mail.
Si tu as aimé cet article, n’oublie pas de mettre un petit like ! Ça nous aide à comprendre quels sujets on dois creuser.
Passe une excellente journée et à la prochaine.