Devops, ce four à micro-ondes

On ouvre des portes blindées à la thermite aujourd’hui 😏 Je veux vous parler de l’escroquerie devops.

Comme tous les buzzword on met du devops partout, dans les postes, sur les gens, sur les outils 🤷

Mais au fait à la fin comment on se retrouve dans cette putain de jungle ? 🤔

Les origines du mots

Bataille plus vieille que la rancunes des français envers les anglais. à la base sysadmin et développeur sont en guerre perpétuelle pour la défense de leur territoire respectif.

(Admin == prod stable) != ( Dev == nouvelle fonctionnalitée, parfois instable)

L’un à pour objectif l’immobilisme, l’autre est poussé à au mouvement et au changement .

Donc bon, ça génère de la friction entre les équipes.

Mais putain on traîne une version de DB qui contient pas ma feature dont j’ai besoin pour avancer mon dev .

Ouh le petit con de dev qui m’a introduit un bug le vendredi soir et qui me flingue mon weekend 🙄

Mais au fond c’est juste des gens qui savent pas parler de leurs problèmes et trouver une synergie d’équipe.

Parceque le mot traduit un concept, il est embarqué à tort et à travers et galvaudé dans tout les sens.

Et comme les mots s’adaptent aux usage et non l’inverse, on a commencé à chercher des gens devops, des outils devops, des méthodes devops 😏

pourquoi on cherche des gens devops ?

T’a compris ? au final on détourne l’usage du mot pour coller à un effet de mode et essayer de répondre à des besoins qui pourraient correspondre au concept.

Donc du coup, comme on n’a pas compris le sens philosophique du mot et qu’on essaye de s’accrocher à un concept abstrait, on a fini par utiliser le même mot pour définir tout ce qui pourrait représenter concrètement un concept abstrait, du coup c’est la baise .

Chacun y va de sa petite interprétation du sujet, essaye de raccrocher des wagons et l’orienter pour que ça rentre dans ce qu’il connait 🤷

Du coup on colle du devops en décoration, et en redondance à toutes les soupes.

les titres de poste qui n’en sont pas vraiment

Avec de magnifiques dev {techno} devops. (Dit plutôt que tu veux quelqu’un qui fait du code, mais qui connaît un peu les services managés cloud ) 🤷

Ingénieur devops, celui-ci j’aime bien, on pourrait le traduire en ingénieur philosophe. (T’as compris il veut absolument rien dire)

Le fameux sysops, mais un peu dev quand même, ouais enfin tu cherche un sysadmin qui script un peu quoi 🤷

Devops cloud ( quelqu’un qui sait utiliser un cloud provider et automatiser deux trois trucs)

Architect Cloud devops (pareil qu’en haut, mais qui sais faire de beau schéma et réfléchir sur les bonnes pratiques d’architecture cloud)

Devops data analyste (tu cherche un datascientiste qui met son truc en prod tout seul)

LE DEVOPS

LE DEVOPS mon préféré.

Cette personne n’existe pas, tu cherches éventuellement une personne un peu pluridisciplinaire, ramasse merde, qui automatise des sujets que personne ne veut prendre.

pas de mal à ça, je fais un peu ça 🤷

Il faut juste comprendre que ce poste vas complètement à l’encontre de la philosophie du mouvement qui porte ce nom et pourtant c’est ce que retiennent les décideurs. Ah oui c’est bien, il nous faut quelqu’un qui automatise tout comme ça on livre plus vite 😅

Tout ça c’est du cinéma, ça n’a aucun sens, fermez la putain

Si tu penses qu’il te faut une personne à plein temps pour faire de l’infra as code de la cicd et des scripts de backup. Tu crées un nouveau botleneck humain, et tu mets en danger de nouveau le fonctionnement de ton orga.

Une personne qui automatise peut accélérer ton processus de livraison, mais ne saura jamais profondément comment ton appli fonctionne, ni en détail les flux réseau et les contraintes opérationnelles .

Si cette personne part, ça tiendra un temps et ensuite il faudra replonger dans le code pour réparer ou faire évoluer à la prochaine connerie 😏

C’est un poste de boostrap. La vraie organisation devops, c’est la responsabilité partagée, par toute l’équipe.

Attention à ne pas tomber dans le travers de faire des équipiers macdo . On ne veut pas que les devs fassent tout le boulot, seulement comprendre leurs scopes de responsabilité et communiquer correctement les informations .

On ne veut pas de sysadmin qui patch le code forcément, mais s’il est capable d’identifier que c’est bien un problème de code et d’orienter la résolution, c’est gagné 😏 +10 beau gosse s’il le fait sans bougonner dans son coin et maudissant les devs du monde entier 😏

On veux bien des devs qui détecte des problèmes d’infra et de flux, mais ce n’est pas vraiment normal dans une grande orga que les devs bypass le travail des ops et accède aux machines de prod en mode admin.(Dans une petite orga, si y’a juste pas d’admin, c’est best effort, c’est ok)

La finalité et ne l’oublie jamais, ce n’est pas de livrer plus vite, c’est de livrer dans de meilleures conditions et de façon plus flexible. La rapidité et la fiabilité c’est un peu d’outil et d’infra logiciel, mais c’est surtout un changement d’organisation et de culture qui va te permettre ça.

Et pour faire ça, pas besoin de beaucoup d’argent ou de ressources, il faut de la conduite du changement et des bonnes volontés.

Tu vas rester sur la touche si tu bouges trop lentement. C’est la course, on a tous du mal à suivre le changement

(Orelsan, Changement)

comment chercher des missions, comment en proposer

Une seule et unique règle d’or pour ce genre de poste.

Le projet définit la personne que tu cherches, la personne que tu cherches est définie par les projets qu’elle a accomplis.

Un poste de “devops”, un humain “devops”, encore une fois ça n’existe pas 😆 rentre-toi ça dans le crâne à coup de masse rouillée !

Le projet a des contraintes sur lesquelles reposent des technologies. Ces technologies sont des outils , utilisés parfois à bon escient et parfois de manière complètement conne.

Le job, c’est souvent de trouver une personne de transition qui connait des moyens techniques d’automatisation et d’adapter les bons outils et les bons réflexes pour que les gens communiquent les infos et s’approprie l’automatisation. Et une fois que les gens communiquent et s’approprient les outils et les méthodes de travail, la synergie peut s’installer et le boostrap est fini.

Si seule l’automatisation est présente, c’est que la moitié du job qui est fait 🤷 Si personne ne comprend ou ne touche à la cicd ou le code d’infra, ça n’évoluera plus 🤪 et on retourne sur des travers encore pire :

• on essaye dans le code de contourner la CI/CD
• on bypass l’Infra as code pour faire des opérations manuelles sans les répercuter dans le code
• on subit complètement les outils sans les comprendre et on casse des choses sans savoir vraiment les réparer

La perpétuelle guerre de religion

Certains aspects culturels à comprendre : Windows et Linux sont deux mondes qui se touchent peu de manière traditionnelle 😏

Il est compliqué de tabler sur les deux technos à la fois ( avec un effort du côté Windows pour faire revenir les dev avec le subsystem Linux dans Windows)

C’est chiant de manager les deux technos à la fois, et de faire l’un avec l’autre. Pas la même philosophie, et un inconfort permanent en switchant de l’un à l’autre.

Sans compter une bataille d’église encore très marquée.

Je suis du côté Linux extrémiste et je pense pas changer d’avis 😏

Si on me donnait un Windows serveur à administrer ça sera pour moi très compliqué et en plus ça m’intéresse pas.

Scoop, il existe la même chose sur les cloud providers public, le champ de bataille cloud privé vs cloud public, les technos de configuration de serveur, les langages de programmation et les cultures d’entreprises .

Donc pour caler une mission avec le bon candidat, toutes ces variables sont à prendre en compte:

• Les technos qu’il utilise
• Le type d’entreprise dans lequel il a travaillé ( leurs cultures, processus, secteur de métier )
• Le contexte du projet
• Les contraintes techniques et fonctionnelles
• L’état d’esprit et la culture technique et d’entreprise du candidat, il doit fit avec le reste de l’équipe
• L’autonomie, la prise de risques et la capacité à prendre des initiatives

Le budget et les attentes de la mission doivent être réalistes et le salaire doit correspondre aux responsabilités et tâches du poste. pas de Monnaie, pas de poney

Un candidat “qui fait tout” va probablement manquer de profondeur sur les aspects techniques experts du métier .

C’est bien beau de cocher AWS, GCP, Azure, Openstack, Linux Windows sur un CV, mais c’est une autre chose de vraiment comprendre et maîtriser ces outils .

Par contre des expériences dans des cultures d’entreprises et de domaine différent sont une force dans le métier.

Transformer une grande entreprise silotée au maximum où les gens ne se parlent pas et sur des technos matures et très classiques sont très différents des exigences d’une startup en pleine croissance qui ont des besoins de techno très moderne et de faire des itérations rapides et des livraisons très régulières.

Les technos renferment aussi les pratiques de déploiement et d’automatisation possibles, il est plus facile d’automatiser des applications qui ont été prévues pour être installées en ligne de commande par exemple. Les containers sont traditionnels du monde Linux, si tu pars sur du Windows c’est possible, mais tu pars avec un handicap majeur.

mon opinion sur le multicloud

Le multicloud dans une petite structure c’est seulement quand on n’a pas le choix 😏 il est important de comprendre qu’une bonne infracloud native est un objectif complexe quand on à une équipe très réduite . Il est important de stabiliser au maximum l’existant et d’éviter au maximum l’éparpillement.

Travailler en multicloud quand on n’a pas les compétences en interne et peu de temps c’est seulement en cas d’extrême nécessité. Ton infrademande des services présents dans 2 clouds différents. Ou alors tu es dans une étape transitionnelle et ton cloud provider actuel ne suffit plus .

Travailler en cloud hybride quand on est un grand acteur et qu’on a pas mal de legacy et de matériel, c’est une bonne idée si tu as des objectifs de modernisation et d’évolution possible seulement avec des services managés publics. Où que tu downscales tes machines parce que ton parc arrive en fin de vie.

Multiplier les cloud providers sans stratégie ni concertation, est le pire scénario possible.

Plus le temps passe et plus on perd la maîtrise de l’existant. Ça devient un cauchemar opérationnel pour rationaliser et unifier tout ça et quand on sait plus où la carte bleu est enregistrée et comment accéder aux machines, c’est la merde totale.

mon métier, la science de la démerde

Je considère mon métier comme un concentrateur de ce qui se fait de pire des deux mondes. Faire de l’automatisation avec des langages de scripts peu flexibles et un peu relou, jongler avec les technos, faire du contexte switching en permanence. scripter des trucs pas sexy, provisionner des services managés, faire des scripts de déploiement, faire des backups de base de données.

On peut penser en lisant tout ça que je déteste profondément ce que je fais, mais c’est plus compliqué que ça 😏

Oui je rage en permanence, oui je crache sur les technos, mais au fond la vraie puissance de mon métier c’est de faciliter tous les trucs infernaux et chronophages et laisser les devs et les exploitants apporter de la valeur business.

Tous les trucs laissés de côté, parcequ’on n’a pas le temps, parce que c’est trop pénible, parcequ’on ne sait pas faire et bien si personne ne le prend ça ne bougera jamais.

Je suis en quelque sorte le bousier de l’informatique, je fais des boules et je déplace la merde.

Mais je suis OK avec ça, parce qu’à la fin de la journée, cette boulette est automatisée, et elle dégage du paysage.

Mais attention, ne te méprends pas, je roule la merde oui, mais pas n’importe laquelle, je choisis mon caca avec soin, et je vais toujours privilégier les technos qui sont les plus simples à bouger, les orgas qui me plaisent et les projets qui me font plaisir. Je te vois venir toi et ton infra on prem de 10 ans sur du centos 5 , dégage 🤪

Et au final, bien sûr que je vais les prendre tes missions d’automatisation, mais là où je te tannerai la tronche à coup de barre de fer, C’est que si tu ne changes pas profondément tes processus et ton organisation, mon travail n’a aucun sens, mange tes genoux et avale tes dents.

conclusion

Du coup, la vraie connerie dans tout ça, c’est qu’il existe un paquet de métiers et de situations variées regroupées derrière le mot devops.

Chacun avec des objectifs et des besoins parfois radicalement opposés

Ça ne veut rien dire 🤷, mais comme les gens s’approprient le mot, il est inclus en ponctuation partout dans les fiches de poste.

Donc la seule chose raisonnable à faire c’est de matcher les postes par techno dans un premier temps et ensuite de tenter de matcher les cultures d’entreprises 🙂

Les expériences, les entreprises et les techno définissent les profils de mission et les types de profils qui pourraient matcher la mission.

À titre purement personnel, quand je fais de la prospection, j’ai besoin de toutes ces infos pour comprendre les enjeux du projet, court et moyen terme.

Le type de techno et la forme du projet sont primordiaux, car ça profile forcément les types de solutions que je peux proposer à mon client.

Un budget me permet tout de suite de savoir si j’entame une procédure ou pas, à un moment faut respecter le travail et l’expertise des gens 🤷

Et encore une fois, démerde-toi avec ça, c’est la jungle, soit tu es le tigre, sois tu es le singe, choisi bien 🤪