Rebrand de nom d'équipe en DevOps

Hello,

J’ai besoin d’un peu d’aide pour faire comprendre le devops dans ma boite (comprendre pour mon manager).
Le contexte pourrait être idéal, il en est loin. Il s’agit :

  • d’une PME, environ 30 personnes
  • 10 dans l’équipe technique (il ne reste qu’un ops (moi), 5 dev et ensuite c’est r&d, alternants et d’autres personnes moins tech)
  • migration dans le cloud en 2020. Ca s’est fait un peu dans la douleur, mais dans les temps. Certaines apps ont pu être un peu “cloudisées” mais pas tout. On se retrouve avec des VM bichonnées et un cluster k8s à côté (X2 car 2 environnements).
  • malgré les formations dispensées (formation sur aws (ça s’est pas très bien passé entre l’équipe dev et le formateur, c’est mort dans l’oeuf mais ils ont eu une petite couche quand meme avec un accès pour jouer sur AWS)). On a aussi mis en place une formation sur git/gitlab pour renforcer les points faibles mais là encore, on peut pas dire que ça a été un succès, pour les dev git ça va, mais gitlab, ils y touchent pas
  • y a très peu de motivation à prendre une nouvelle techno (on a une code base assez large, avec déjà pas mal de technos mais ça explique pas tout)
  • organisation en rateau (aucun lead), y a le manager (CTO)

Bref, l’équipe a été rebrandé “Equipe DevOps” et mon manager a fini de me tuer lors d’une réunion sur l’organisation où il a indiqué: “DevOps, c’est le fait faire du Dev puis de l’Ops, DevOps Quoi !”
Je me plains depuis déjà 2 ans d’avoir trop de boulot, de passer beaucoup de temps à faire de la MCO (AWS, y a que moi qui touche, pas par choix, k8s idem, et je gère la trentaine de serveurs avec ansible). Et encore, j’écris les manifests k8s pour les dev… Ca va un peu mieux ces derniers temps mais pendant longtemps je tapais les yum update sur les serveurs (le passe plat). Je m’occupe aussi du monitoring (que je délaisse un peu par manque de temps)…

Bref, dernière chose en date, le dernier dev embauché m’épaule parfois pour des migrations (le fameux devops du coup).

Je leur ai proposé de regarder une présentation de @mcorbin (que j’apprécie bien, tant la vidéo que le personnage, on te voit plus dans le podcast ;)).

Mais je pense faire encore chou blanc, faut cliquer, regarder 45 min de présentation…

J’avais mis en place une doc sous forme de projet gitlab, qui génère un site statique. Y a une CI/CD, faut faire du git et du markdown, c’est pas la mort. Même ça, ça prend pas, je m’occupe de 99.99% des commits. (Et j’ai aps proposé de passer par des merge requests, on commit dans main direct). Je voulais en faire le projet bac à sable, tu le casses, ben c’est pas grave, on prend le temps de le réparer, c’est pas une application pour un client.

Dernier ex, j’ai proposé qu’on teste github copilot. 1 seul dev a été ok. Sur 10 personnes, on est 2 à utiliser.

Bref, je ne suis même pas sûr qu’un accompagnement serait bénéfique. MAis je epux toujours proposer.

Qu’en pensez-vous ?

Hello

Situation pas simple que tu exposes.
D’après tes dires il semble y avoir un problème bien plus profond qu’un simple rebrand d’une équipe de dev en devops.

A la lecture, je me dis qu’il y a un problème de culture et de mentalité dans l’équipe de dev. Ils ont visiblement la possibilité d’utiliser des outils modernes et qui leurs simplifierai la vie mais refusent de le faire. C’est problématique.

Hélas dans ce genre de cas, il n’y a pas 50 solutions :

  • soit c’est imposé par la direction / manager car il y a prise de conscience de la perte d’efficacité (probable) du fonctionnement actuel
  • soit en te faisant des alliers dans l’équipe qui vont aller se faire les relais de tes propositions, démontrer aux autres devs que c’est utile…
  • soit par le renouvellement de l’équipe. Il faut profiter de la fraîcheur des gens (qui vont arriver avec des pratiques qui ne sont pas les vôtres) pour qu’ils fassent passer des messages.

Après dans tous les cas je crains qu’un big bang ne soit pas réalisable, ni souhaitable.

Quelques idées pour essayer de changer petit a petit les mentalités en place :

  • appliquer une nouvelle méthodo sur un nouveau projet
  • mettre en place des communautés de pratiques
  • faire des demo/rex de votre utilisation d’outils (github copilot par exemple)
  • proposer au CTO de lire des rapports type Accelerate ou DevOps state of arts (j’ai plus les noms exacts en tête) ou leurs synthèses pour mettrez en avant les pratiques des autres entreprises et leurs apports

En tout cas, bon courage car faire changer les pratiques quand les personnes y sont réfractaires (d’autant plus si elles se pensent intouchables) c’est très compliqué.

3 « J'aime »

Salut,
nulle part dans ta description de ton enfer :slight_smile: je ne lis “agile”. Ton équipe de DEV fonctionne en SCRUM, en kanban ? En V ? :face_vomiting:
Le fait de travailler en méthodo agile est le premier pas vers le devops et cela va te donner l’opportunité de “rentrer” dans l’équipe et je pense que c’est ça qui te manque, tu me sembles très extérieur à l’équipe.
En plus cela “obligera” à faire du gitflow, des MR, … Je plussois jygastaud, il faut faire ça dans le cadre d’un nouveau projet et surtout il faut un vrai PO qui gère les priorités et les US et donne une direction.
Une question : ta migration vers AWS te coute combien par rapport à ton ancienne infra (on premise a priori). Un ordre de grandeur, j’en ai suivi 2/3 et cela a toujours couté très cher pour des avantages pas à la hauteur, je suis curieux …

P.S. : et avant le burn out, va voir ailleurs …

3 « J'aime »

On est en scrum, sprint de deux semaines. Assez peu d’infos dans les daily qu’on a fini par rendre bi hebdomadaire (c’était censé être au profit d’une autre réu mais ça n’a pas tenu très longtemps :D)
Le PO s’est transformé en 2 POs, un pour la partie très tech, l’autre pour la vision produit.

J’ai des alliés dans l’équipe de DEV mais on a un pilier réfractaire qui sape un peu tout.

J’y travaille un peu mais c’est pas simple. En tout cas, je prospecte depuis un moment, j’ai passé des entretiens sans que ça n’ait abouti (je pourrai faire un autre post à ce sujet, pour un des jobs, j’ai trouvé ça pas top du tout)

1 « J'aime »

Ya pas un pb au niveau du découpage des US ? Une US dans 99% des cas c’est max 2 jours de taf avec un descriptif précis, objectif, résultat attendu, test à faire,… PO c’est un boulot.
Si vous êtes 4-6 à faire le daily il doit y avoir toujours pas mal d’info. Ton lead tech a bouffé ton PO pour les US tech, mais si ton PO tiens toujours le lead sur le projet pas de pb. Tu as des US ? Tu pourrais montrer l’exemple avec celles-ci… Et tu dois en avoir ! Des US tech d’amélioration de la CI, d’intégration de test,…

Pour le taf, soit tu cherches le boulot parfait, soit tu habites le désert, dans les 2 cas tu trouveras pas. :grin:

Les US, parfois, il peut y en avoir. Yep, on est à la ramasse complet…

Je plaide coupable, je suis exigeant et j’habite pas une grande ville… Du coup, je zieute principalement en full remote actuellement.

Beaucoup de choses à dire.

Il y a clairement un manque d’organisation et c’est normalement à votre CTO de prendre les choses en main.

Pour ce qui est de l’organisation de votre équipe et de l’approche DevOps, une ressource assez simple à consulter est : https://web.devopstopologies.com/
Cela met en exergue les topologies d’équipes qui ne fonctionnent pas et celles qui fonctionnent bien.

En ce qui concerne l’usage de git et gitlab, il faut adopter une stratégie de gestion de branche qui serait adaptée à vos besoins. Personnellement, le passage par des PR me semble indispensable, tu peux protéger la branche “main” pour leur forcer la main.

Pour réduire ta charge de travail je pense qu’il faut essayer de standardiser le plus possible vos approches, ça peut passer par :

  • La mise en place de templates CI/CD Gitlab.
  • Standardisation du packaging des app (container).
  • Automatisation de la gestion des VMs (Ansible, Terraform, …).
  • Automatisation de la gestion de l’infra (IaC).

Au début cela va te consommer du temps de mettre ça en place mais cela finira par t’en faire gagner au quotidien.

2 « J'aime »

Sympa ce lien, je vais le partager en interne je pense, Merci

  • template CI/CD c’est en cours, je peine à finir mais la partie technique est faite (pour les conteneurs et k8s, pour le packaging RPM… nop mais c’est pas censé trop durer)
  • packaging en conteneur, ça a été réalisé sur une bonne partie du backend lors de la migration cloud, reste toute la partie frontend et encore certains services backend. En fait, faut tout le temps pousser…
  • Gestion des VMs, j’ai pas mal oeuvré avec ansible, je fais plus de la maintenance mais ca reste assez chronophage
  • Gestion infra, c’est ok aussi, ça me prend peu de temps cette partie
1 « J'aime »

Salut,

Y a t il un besoin pour la boite a “comprendre le devops” ? Si ça se trouve ta boite fonctionne dans un mode non-devops qui va très bien a tout le monde. Aussi, tu serait le seul a voir un changement de mode de travail comme une amélioration.

Est-ce qu’adopter une méthodologie devops apporte de la facilité dans le quotidien de tout le monde ou juste de la contrainte, sauf pour toi ? Par exemple, qui voudra se faire chier à faire des containers si un “cp” du code sur la prod fonctionne bien depuis longtemps ?

Bref, est-ce pertinent de proposer du devops ?

Lorsque je lis ton post, je comprends que tu déplore que l’équipe ne souhaite pas adopter un mode de collaboration devops, mais ce n’est pas argumenté. Tout ce que je trouve de factuel et non discutable c’est:

  • “J’ai trop de boulot”
  • “Marre de faire de la MCO”
  • “Je suis le seul à connaitre le cloud”

Dans tous ces points, je ne vois rien qui concerne ton équipe, il semble que tu soit le seul à souffrir du fait que ton équipe se foute complètement de l’exploitation de la solution et du fonctionnement du cloud provider. De part la nature humaine, tu as peu de chances de trouver quelqu’un qui acceptera de faire une action que la personne n’a pas envie de faire juste dans le but de te faciliter la vie.

Donc, je dirais qu’il faut tout d’abord identifier précisément ce qui bloque et qui pose problème. Etant dans une société, les seuls problèmes qui comptes sont ceux qui impactent la société. Une fois que tu a identifié les problèmes de ta société, tu peux réfléchir à des pistes d’amélioration ou de proposition.

Par exemple:

  1. La société perds des contrats car elle a un problème de time-to-market
  2. La société perds des client a cause de livraisons ratées
  3. La société dépense trop d’argent dans l’hébergement

Tu peux ensuite proposer des solutions:

  1. Pour livrer plus vite, il faut soulager le tache des developpeur en mettant en place une CI/CD
  2. Pour arrêter de rater des livraisons, il faut uniformiser le parc et automatiser les livraisons
  3. Pour économiser sur le hosting, ils faut sortir du cloud et passer on-prem

Une fois que tu as le problème et une solution potentielle, si ton chef n’est pas un demeuré, il devrait écouter un discours argumenté.

Bonjour chef vénéré, j’ai remarqué que nous perdions beaucoup de crédit auprès des client a cause de ce problème précis. J’ai une solution à proposer pour régler ce problème. Il s’agit de ceci-cela. Pour mettre cette solution en oeuvre il faudrait tant de temps et cela couterait environs XX a la boite, pour faire gagner en retour YY.

Si le discours est sensé et convenablement argumenté, un chef sensé doit écouter. Si ce n’est pas le cas, tu est face a un problème humain insolvable: casse toi.

Si je reste sur ce que j’ai lu dans ton post, tu peux orienter ceci de cette manière (bien sur je suis peut être a coté de la plaque):

Bonjour, il y a un problème assez grave dans la pérénité de la société : je suis le seul a savoir faire fonctionner la production et à assurer le MCO. Si je me casse une jambe, la société est dans la panade. Par ailleur, cela pose probleme pour que je pose mes congés. Je propose d’identifier une personnes dans l’équipe intéressée par le sujet avec qui je puisse partager mon activité ou bien d’ouvrir un poste pour avoir une personne en mesure de me remplacer.

Par ailleurs, ma charge de travail ne cesse d’augmenter et je ne suis pas sur de pouvoir l’assurer. Cela commence a empiéter sur la vie privée et je ne peux pas l’accepter. aussi je propose d’investir du temps pour automatiser ceci / cela qui le libèrera du temps pour travailler sur des sujet a valeur ajoutée, tout en faisant baisser ma charge. On peut aussi ouvrir un poste pour m’épauler.

Si rien de positif sort de ce discours, alors il n’y a rien de positif a chercher.

3 « J'aime »

Merci pour ton point de vue trés intéressant. Je n’ai pas le temps de répondre point par point, j’essaierai de la faire plus tard, là, les congés débutent :smiley:

1 « J'aime »