je parle ici de mon expérience. Le métier est vaste, et je suis sûr que ma définition ne s’applique pas partout. Je pense néanmoins qu’elle peut s’appliquer pour un grand nombre d’entreprises "classiques" (produits SaaS par exemple) ayant des équipes de développeurs et d’ops.

L’intérêt d’un blog est aussi de pouvoir "revenir dans le passé". Je me demande si ma définition sera toujours la même dans 5 ans par exemple. Chaque nouvelle expérience nous fait réfléchir et c’est ça aussi qui est intéressant dans nos métiers.

Pourquoi faisons-nous de l’ops ? A quoi sert les infrastructures et outils que nous mettons en place ?

On pourrait dire par exemple que notre travail est de faire en sorte que l’infrastructure soit tolérance aux pannes, qu’elle soit sécurisée, correctement monitorée…​ mais c’est une vision très centrée "ops".

Le métier de notre entreprise n’est généralement pas de maintenir une infrastructure pour la beauté du geste. Un produit est généralement développé en interne. Chaque amélioration du produit permet de satisfaire plus de clients, de gagner des marchés, de corriger des problèmes…​ Bref, de créer de la valeur.

Je pense que l’ops en 2022 doit être un accélérateur pour la création de cette valeur.

On est (bientôt) en 2022, donc je ne vais pas me lancer dans une dissertation sur le DevOps. Mais pour moi un ops est un rôle où l’accompagnement des développeurs est essentiel.

je pense que les développeurs doivent aujourd’hui avoir un maximum d’autonomie dans la gestion de leurs applications en production. L’époque où tout ce qui touchait à l’exploitation et où la production était la chasse gardée des ops est révolue, et tant mieux.

Ce n’est pourtant pas selon moi aux développeurs de maintenir l’infrastructure. Est ce que ce n’est pas contradictoire avec ce que j’ai dit avant ? Je ne pense pas.

Les ops doivent travailler avec les développeurs pour que ces derniers puissent développer, tester, déployer, et exploiter leurs applications de manière autonome, fiable et efficace.

Voici par exemple quelques sujets où selon moi les développeurs doivent être autonome:

Cela peut sembler beaucoup mais soyons clair: les développeurs sont autonomes mais sont consommateurs de services mis en place par les ops.

Je ne demande pas par exemple à un développeur de connaître tout le fonctionnement interne de Kubernetes (est ce que quelqu’un connaît vraiment tout ça de toute façon ?). Je peux par contre fournir Kubernetes en tant que service, avec un certain nombre d’outils autour pour qu’il ou elle puisse travailler efficacement avec. je lui garantirai également qu’en cas de perte du noeud hébergeant l’application, cette dernière redémarrera ailleurs grâce à Kubernetes.

De la même manière, les ops peuvent mettre à la disposition des développeurs une plateforme de métrique et d’alerting prête à être utilisée en totale autonomie par ces derniers.

On voit dans ce que j’ai décrit précédemment que le développeur est en quelque sorte client des services mis en place par l’ops.

Alors que côté développeur il est devenu commun de travailler sur les produits en étant en contact permanent avec le client et des product owners, c’est quelque chose qui n’est pas je trouve si courant que ça côté ops.

Prenons un exemple fictif: l’équipe ops décide de déployer une nouvelle plateforme de monitoring pour l’entreprise. C’est parti ! Brainstorming, tests de produits, choix d’une solution, déploiement…​ Avec 4 mois de travail acharné tout est prêt.
On annonce aux développeurs que ça y est, ils peuvent migrer dessus ! Ces derniers testent, et là c’est l’ascenseur émotionnel: "Cela ne répond pas à nos besoins", "C’est trop difficile à utiliser", "Le langage trucmuche n’a pas de librairie pour cet outil"…​ en conclusion: le produit n’est pas ce qui était attendu.

Cela est généralement dû à une non intégration des développeurs dans la construction de la nouvelle solution. Rappelez vous, vous mettez en place des produits qui doivent satisfaire vos utilisateurs. C’est seulement en travaillant étroitement avec ces derniers que vous aller répondre de manière pertinente à leurs besoins. Je me méfierai toujours des choses imposées par une équipe quelconque sans consultation.

Expliquer comment travailler ensemble n’est pas vraiment le but de cet article. Certaines entreprises vont par exemple embarquer des profils "ops" directement dans les équipes de développeurs.
Cela peut très bien marcher si cet ops ne devient pas la personne sur laquelle se décharge le reste de l’équipe pour tout ce qui touche à la production. Vous mettez un ops dans une équipe de dev pour casser les silos et l’équipe crée de façon autonome son propre silo au sien de l’équipe. Dommage non ?
L’autonomie de l’ensemble des membres de l’équipe sur la production doit être l’objectif, non juste une compétence d’une personne identifiée.

De plus, la frontière entre le développeur et l’ops est poreuse. Il y a des bonnes idées sur ces sujets (dev et ops) des deux côtés. Il ne faut pas croire que seul l’ops aura de bonne idées sur comment gérer des services en production, ou que seulement lui peut "détecter" un besoin chez une équipe de développeur. Attention à ne pas tomber dans le paternalisme.

C’est un vrai travail en commun et je m’attends également personnellement à ce que les développeurs soient critiques sur ce qui est mis en place côté ops. De nombreux sujets autour de l’architecture ou des performances par exemple sont également communs aux deux mondes et demandent de toute façon de travailler ensemble.

le métier d’ops est un métier en constante évolution. Sur quoi s’appuient aujourd’hui les ops pour construire de l’infrastructure ? On va trouver par exemple:

Les outils d’infrastructure se configurent généralement via des fichiers de configurations (GitOps blablabla…​). Est ce qu’on peut parler de code ici ? Dur de trancher pour ma part, mais pourquoi pas.

Par contre ces outils sont généralement open source, peuvent être améliorés, étendus…​ et là il faut par contre mettre les mains dans le cambouis. Ecrire un opérateur Kubernetes ou des modules Ansible sont par exemple des travaux de développement.

Ces outils répondent à des besoins généraux mais on se retrouve régulièrement à devoir écrire du code pour faire par exemple de la glue entre produits. Les entreprises ont souvent des besoins métiers spécifiques donc du code est souvent nécessaire pour réaliser de manière automatisée et fiable un certain nombre de tâches en lien avec la plateforme.

Ecrire du tooling, des CLI, exposer des services d’infrastructures via une API maison…​ sont des choses que l’on voit de plus en plus dans les équipes ops.

Bref, on voit que négliger l’aspect développement côté ops n’est peut être pas une bonne idée (et ne me parlez pas de scripts shell s’il vous plaît :D).
Pouvoir en tant qu’ops se dire "ce problème là je vais le régler via un programme" ou "ce truc là, je le mets en self service pour les équipe grâce à une API" est je pense très intéressant. Il est également important que ces programmes soient de qualité: tests, CI, métriques, logs, alertes…​

Et pourquoi pas ? Rappelez vous la citation du fameux livre SRE de Google:

C’est bien sur à tempếrer.
Quand on lit ça en tant que sysadmin on peut avoir tendance à se sentir obsolète mais ce n’est pas le but: les compétences "classiques" d’un sysadmin sont toujours nécessaires. L’évolution se fait selon moi beaucoup plus sur la façon de travailler, de communiquer, et d’exposer les services au reste de l’entreprise.

Mais appliquer les méthodes de l’ingeniérie à l’infrastructure devient aussi obligatoire.

J’espère que cet article est clair. En tant que sysadmin ayant travaillé ensuite presque 4 ans comme développeur (appliqué à de l’infrastructure mais quand même du développement) et qui repasse côté ops, il est même parfois pour moi difficile de me situer.

Comme dit en début d’article, les multiples définitions des postes (SRE, DevOps, ingénieur Cloud…​ chaque entreprise ayant ensuite sa définition interne) n’aide pas non plus à trouver sa place.

Mais une bonne cohabitation entre les devs et les ops est cruciale et est pour moi obligatoire si l’on veut qu’un produit soit un succès.