Casser la production

culture générale informatique devops 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.