Collaboration entre un ops et des devs externalisés : Comment se comprendre ?

jl-m · Janvier 16, 2022, 2:50

J’ai des questions liées au travail en collaboration avec des devs externes par un ops.

Je le poste dans le forum général, mais si vous préférez que ce soit dans la partie devops, pas de soucis pour le déplacer.

But : Comprendre comment présenter les choses aux devs d’une société dans le cadre d’un projet dont le développement est externalisé.

Contexte : Au boulot on a des serveurs physiques performants et une infrastructure d’hébergement on premise à disposition. Nous n’utilisons aucun services cloud.
Un chercheur a besoin d’un outil web destiné à modifier des documents spécifiques lié a ses recherches. Le projet n’étant pas public, je n’en dirais pas vraiment plus sur la finalité. On a le serveur physique qui va héberger l’application.

Il a externalisé le développement de cet outil a une société externe. Il m’a demandé de présenter notre infrastructure et de répondre aux questions réseaux spécifiques sur ce projet. Je ne suis pas chef de projet, je suis juste « consultant infra », rien de plus, et je tiens à rester dans ce rôle. Une réunion avec le prestataire externe était prévue pour présenter un peu le cadre de part et d’autre.

Le fait de collaborer avec une société pour un développement externalisé est quelque chose de nouveau pour moi.

Avant la réunion, j’ai fait un petit schéma partiel notre infrastructure, ultra basique, 2 serveurs isolés par des pare-feu, un proxy web isolé des serveurs par un pare-feu et les postes de travail isolé par des pare-feu. Je ne savais pas à quoi m’attendre donc j’ai fait large et ai inclut des parties qui ne me semblent pas du tout nécessaire après coup.

La réunion c’est moyennement passé, rien de dramatique, juste un agacement de part et d’autre de ne pas réussir à se comprendre.

J’essayais de mon côté de faire comprendre que le développement devait tourner sur un unique serveur en localhost et de l’autre on me parlait de mise en place d’apis pour communiquer entre le front, le back et la data, de devoir recoder un IAM puisqu’on en avait pas, de sécuriser les transferts avec la mise en place d’un VPN, d’un stockage S3 pour les datas.

Bref, je n’ai pas du tout l’habitude de parler avec des devs de boites externes et clairement on ne s’est pas du tout compris. Je ne suis pas partie prenante dans ce projet, mais c’est pour moi une expérience intéressante qui touche concrètement à l’organisation devops.

Quels conseils simples auriez-vous pour pouvoir présenter clairement l’infra on premise sur laquelle des devs externes (très orienté cloud AWS) vont bosser.
Quels outils ou informations leur fournir ?
Que leur demander de leur côté ?

Je reprécise, ceci m’intéresse à titre personnel et sur mon temps libre d’avoir une idée simple des attendus concrets orientés devops dans le cadre d’une interaction avec des devs externes.
Je ne compte pas m’impliquer plus que ça dans ce projet, ni ne viens demander une solution tout faite. Juste quelques grandes lignes pour comprendre par quel bout prendre cette histoire.

bat79a · Janvier 17, 2022, 8:09

Salut @jl-m.

Pour moi il “suffit” de leur faire comprendre qu’étant sur un serveur uniquement, l’application front et back peuvent très bien être sur la même machine et donc communiquer facilement entre les deux, la data ne sera pas sur du S3 mais sur la machine aussi.
Il faut a mon avis savoir sur quoi ils avaient prévu (ou au moins l’habitude) de faire tourner tout ça : kubernetes, serverless ou autre.
Et maintenant que vous en êtes là, essayé de trouver des solutions pour résoudre le probleme et que le projet puisse aboutir.

Car peut etre qu’il sont habitué a docker et donc par exemple, leur proposer d’avoir le deamon docker sur la machine et du coup ils lanceront le back et front sous docker comme si ils étaient sur du cloud kubernetes par exemple ?
Pour l’iam effectivement c’est un probleme mais si le chef de projet savait que c’était sur un serveur isolé, il fallait prévoir dans le développement une alternative. Ou si le serveur n’est pas isolé et peut accéder à l’exterieur utiliser un outil externe ?

Bref j’ai l’impression que le chef de projet a passé commande sans trop de détails sur l’infrastructure cible et que du coup le prestataire n’a pas prévu des briques du system ou parties à ajouter dans le devis.
Donc pour moi le chef de projet aurait du définir l’infra cible dans son devis et le prestataire avant de se lancer aurait aussi pu/du se renseigner un peu sur cette cible de mise en place.

Dans tous les cas pour moi tu exposes l’infra cible qui existe et si ça pose un probleme au moment de déploiement c’est qu’il fallait venir te voir avant ;p
Reste comme je le disais, à comprendre ce qui n’a pas fonctionné pour ne pas reproduire cette situation dans le futur et pour ce projet essayer de contenter tout le monde au mieux (déploiement sur une autre cible et/ou ajout dans le devis des parties restantes à faire.

Bon courage.
Baptiste.

thierry.f.78 · Janvier 18, 2022, 4:02

Salut,

Note: je relis ma réponse et je me rends compte que c’est très pessimiste. C’est lié au manque d’information dans ta question, il y a beaucoup de point que je ne peut qu’imaginer. C’est certainement aussi lié a mon expérience perso avec des développeur incompetent et/ou je-m-en-foutiste. J’ai plein de bonne experiences avec des développeurs motivé et très pro avec qui tout s’est bien passé. Bref, ma réponse est à prendre avec des pincettes.

Dans ce que tu décris, je ne note pas de problème de présentation, mais un problème protocolaire, peut-être lié à l’absence de personnes compétentes pour t’écouter: normalement, un boite de développement engage pour chaque projet un architecte qui doit comprendre et prendre en compte les besoins du client. Si les deux développeurs que tu évoques font office d’architecte, tu est face a un problème de compétences, il n’ont manifestement pas le niveau requis pour appréhender ton projet dans son intégralité. Si ce n’est pas le cas, il manque une compétence dans le projet.

La situation que tu décris me fait penser à des situations que j’ai vécu plusieurs fois, ou la communication entre les dev et les ops est cassée. Cela m’évoque des tas de warning:

Il n’y a pas d’architecte, ou bien l’architecte est un junior: le livrable et son exploitation en seront impacté
La société de prestation fait des économies: pas d’architecte, mais des programmeurs qui manque de recul et qui répondent a toutes les problématique avec:
un “framework”,
des modèles à la mode (microservice, …) plutôt que des modèles adaptés,
des service prêt a être consommés (cloud, base de données spécialisées…) sans réfléchir à l’exploitabilité et la pérennité
…

Quels conseils simples auriez-vous …

Il n’y a rien de simple dans ce que tu décris, car il semble que tu soit face à un problème humain. Si le développeur ne comprends pas le langage de l’ops (et vice-versa) tu est dans une impasse. Le conseil simple est de fuir cette situation toxique

Quels outils ou informations leur fournir ?

Les outils ne resolvent pas des problèmes de communication. Enfin, si, mais mal. Docker est clairement fait pour mal répondre à ton problème. Tu ne comprends rien aux dev, et eux ne comprennent rien à l’ops. Pas de problème: le développeur met tout dans un container et voila, ça marche.

Docker c’est génial, le développeur se moque de ton environnement, il met tout dans son container et l’ops se moque de ce qu’a fait le dev, son boulot est juste de démarrer un container.

En revanche:

c’est inexploitable
c’est galère a livrer
c’est extrêment difficile à débugguer
la maintenance sécu est difficile (appliquer les updates)
c’est moralement pas satisfaisant (avis personnel qui n’engage que moi)

Une piste de solution plus complexe

A ta place (et en fonction du contexte) je lèverai rapidement un warning auprès de “qui-de-droit” (le chercheur, un chef de projet, un responsable quelconque, etc.), en précisant que ce projet sera:

certainement plus couteux que prévu car probablement livré en retard a cause de problèmes de communication
demandera probablement des resources (humaines) supplémentaire en exploitation, car non exploitable.
risque que ca fonctionne mal, ou que des fonctionnalités soient baclées
[si c’est de développement forfait]: certitude que des fonctionnalités soient baclées.

Je proposerai un plan d’action qui ressemble plus ou moins à ça:

Fournir tes contraintes d’hébergement,
Demander ce dont tu as besoin
Donner les conditions de validation du livrable.

Je ne peux que te donner des exemples qu’il convient de moduler en fonction de la nature de l’application et de ta manière d’héberger. J’évoque beaucoup le web car tu a écrit que c’est un outil web:

Les contraintes d’hebergement

Le service doit intégralement fonctionner sur un unique server de ce modele: (CPU, RAM). Tu risques de tomber sur des dev débutant qui vont installer des tas de framework tous plus mal configurés les uns que les autres, et l’application risque de ne pas fonctionner sur un serveur. Ce point est complexe à défendre car la position du développeur sera de t’expliquer que la demande “est tellement complexe” que l’application nécessite plusieurs serveurs. Parfois c’est vrai, parfois c’est du bullshit pour défendre du code pourri. Donc: à toi d’évaluer l’application et sa capacité à fonctionner sur un seul serveur. Si tu pense qu’un seul serveur est nécessaire, tu l’impose (si tu peux le prouver c’est mieux). Sinon, il faut suivre les recommendations des développeurs.
Donner les performance attendues. C’est très important de fixer des limites. J’ai déjà vu un développeur qui avait un temps de réponse de 2 minutes (oui, deux minutes pour une page web) pour générer un tableau de 9x9. Il se satisfaisait de ce temps en argumentant que les calculs sont complexes. Apres avoir gueulé, il a trouvé le bug, et il a fallu 100ms pour générer ce même tableau. Il faut imposer des temps de réponses maximum pour l’affichage des pages. Ce point est peut être le problème du gars qui a commandé le site. Impose également le nombre de connexions simultanées dont tu as besoin. Ceci est généralement lié à la quantité de RAM (j’ai vu une application qui consomme 16Go (oui 16Go!!) de RAM par session utilisateur. Si tu utilise des disques non SSD, precise le (en fonction de l’application), si par exemple il y a du tri massif fait sur disque, il est bien de préciser si les disques sont lent. La tendance actuelle est de supposer que rien ne fonctionne sans SSD et donc le SSD est la norme.
Si le service doit devenir disponible, il faut preciser qu’il doit pouvoir fonctionner dans une architecture en haute disponibilité. A toi de voir les outils et méthodes en fonction de la nature du développement. Si c’est web pense aux health-check: demande un url qui te donne l’état de santé de l’application afin de piloter tes load balancer, ou un cluster, un vip, …
Coté métrologie/supervision, demande une url (ou autre méthode) qui va exporter des métrique au format de ton application de supervision (prometheus, collectd, nagios, etc.). Demande la doc pour savoir à quoi correspond chaque métrique. Demande a partir de quelle valeur il faut s’inquiété, et ce qu’il faut faire. Ce point n’est pas pertinent si l’application n’est pas un daemon.
Tu doit préciser les format de logs. Les logs sont fait pour l’administrateur. L’administrateur doit comprendre ce qu’il se passe dans l’application quand elle n’applique pas le comportement attendu. Attention, aujourd’hui la “mode” (fénéantise ?) est a la backtrace. Tu te retrouve vite avec des erreurs de plusieurs centaines de lignes ou tu ne comprends rien, juste pour signaler qu’un fichier est manquant. En fonction de tes besoins, tu doit specifier ce que tu veux voir dans les logs, Mais également la méthode d’envoie des logs (le syslog du système, un fichier simple, …). Je te recommande de rejeter les logs multiligne et demande tout dans une ligne. Imposer des informations qui doivent être toujours présentes dans un log (un identifiant unique de requête, la méthode, le path, le user concerné, …).
En fonction de ton hébergement, precise les versions des softs avec lesquels l’application doit fonctionner. En mode “traditionnel”, ton OS t’impose des versions de JVM, ruby, python, php, etc. Alors que le développeur va presque toujours prendre la dernière version de l’interpréteur. Si tu est dans ce cas et que tu ne veux pas de surprises, tu précise la version de ton interpréteur (sinon, bonjour les emmerdes). Si tu utilise des containers tu n’est pas concerné. Attention, si tu n’utilise pas de containers (ce qui est normal, même si ces technos sont à la mode) ne te laisse pas séduire par l’argument “mon livrable est une image docker” ! Précise également les versions de certaines lib importantes comme OpenSSL. Pour simplifier: tu peux demander à ce que l’application fonctionne sur RHEL8, sans installation de composants qui ne sont pas standard à l’OS. (en fonction de tes habitudes d’exploitation)
Coté protocolaire, si ton application utilise des protocoles standard, précise que ces protocole doivent respecter les RFC. On voit des tas développeurs web qui ne comprennent rien à HTTP et font des horreurs immondes. Si par la suite tu doit mettre un reverse proxy, ou un load balancer, tu va te retrouver ennuyé avec un application incompatible. Avec cette demande tu te reserve le droit de rejeter l’application si elle ne respecte pas les protocoles.
Coté sécu je te recommande de préciser les droits de l’application. Un cas classique est de faire en sorte que le user qui execute l’application n’a pas les droits d’écriture sur l’application elle même. Seul le user qui déploie à ces droits. J’ai deja vu des application ou le runtime doit pouvoir modifier le code pour générer des “trucs”, c’est un grave faille de sécurité. Il faut également être strict sur les droits des fichiers de secret (password, clé RSA, …).
Coté sécu demande a ce que l’application soit chrootable. Au delà de l’aspect sécurité, cette fonctionnalité force le développeur à bien réfléchir à ce qu’il fait. Ceci n’est pas toujours applicable.
Demande à ce que les port, ip et interface d’écoute soient paramétrables. On oublie souvent l’interface et l’ip, mais c’est important. Il veut mieux que cela ne serve pas plutôt que cela soit manquant. Tu peux également imposer un fichier conf unique dont le chemin est specifiable en ligne de commande. Une application java (par exemple) va repartir de la conf dans 50 fichier “properties” en XML et donc difficiles à lire et à trouver. Pour livrer ton application avec du ansible (ou autre) ca va devenir compliqué. Tu peux éventuellement être plus souple en précisant que la configuration doit être dans un répertoire dédié dont l’emplacement est indépendant de l’application.
Je lit dans ton explication que tu utilise des proxy, il faut donc précise que si l’application va hors du réseau elle puisse utiliser un proxy.
Je lit “nous n’utilisons aucun service cloud”, pense à le préciser car tu reporte la proposition d’utiliser du S3.
En fonction de la politique de droits de ton application, tu peux expliquer que le terme IAM est peut être un peu fort pour designer deux fonctionnalités : valider un login/password et verifier un cookie de session ! (je reconnait dans cet argument, un développeur qui commence à t’expliquer pourquoi le délais va être dépassé)
Si le stockage est dans ton périmètre tu doit specifier les méthodes de stockage car c’est ton role. tu précise que ce ne sera pas du S3, mais plutôt du filesystem, ou du webdav, ou de la base de donnée, etc. Si le stockage n’est pas dans ton role, tu doit voir avec qui-de-droit. En revanche tu ne peux pas demander à une boite de développeur de mettre en place un stockage car ce n’est pas leur role (à priori), ni leur compétences. Idem pour le VPN, ce n’est pas le role d’un boite de dev de sécuriser des flux, c’est ton problème (à priori).

Deuxième point, tu as besoin d’information sur l’application:

Tu peux demander une matrice de flux sortant: savoir ou l’application va se connecter, sans oublier le DNS. Cela te permet de détecter des anomalies de communication. Tu ouvre uniquement les flux listés, et tu voit si l’application fonctionne ou si il y a de la “magie”. On n’est jamais a l’abri d’une dependance foireuse qui va communiquer sur le web.

L’acceptation du livrable:

Dernier point, tu explique que tu refuse de valider la recette si l’application ne réponds aux critères que tu donne. Tu te dégage de toute responsabilité si on t’impose une MEP dans un état pas satisfaisant.

mcorbin · Janvier 18, 2022, 8:00

C’est vrai qu’on manque d’information, notamment la taille/archi du projet.
Pour moi les dev ne sont pas toujours coupables.

Les devs sont maintenant habitués à travailler avec des abstractions de l’infrastructure et à déployer plusieurs services (rien que le pattern api gateway qui cache d’autres services backend est super commun).
Donc des choses comme S3, de l’infra à la demande, du load balancer intelligent… est devenu “commun” et quand on a touché à ça c’est dur de revenir en arrière.
Je comprends également que côté ops gérant une infra on prem ce ne soit pas possible de monter l’équivalent d’un cloud facilement et rapidement, et qu’on se demande pourquoi les dev ont besoin de tout ça.

Ce qui me gêne un peu dans ce que tu décris @thierry.f.78 c’est le fait que l’ops sera vu comme le dictateur qui va limiter les devs (en gros: l’ops dit “on vous donnera tel infra, les soft dans tel version, débrouillez vous”). Pour avoir travaillé côté dev dans ce genre de contexte je trouvais ça également pénible (en fait j’ai quitté une boîte en partie à cause de ça).

Mon conseil c’est de rediscuter avec eux, de comprendre vraiment ce qu’ils veulent et de discuter ensemble des contraintes des deux côtés.

J’ai un article sur le sujet de l’ops en 2022 d’ailleurs: (mcorbin.fr): Le métier d'ops en 2022

jl-m · Janvier 18, 2022, 9:04

Déjà Merci pour vos réponses, elles me donnent plein de pistes.

Pour le chef de projet: Ben y’en a pas et c’est là que ça va clairement coincer d’après vos retours. Personne chez nous n’a les compétences ni le temps de faire ce job. Mais bon on va essayer de s’y coller au mieux selon vos recommandations.

En fait, il ne s’agit pas de chercher des coupables (dev ou ops), juste de réussir à bosser ensemble, c’est une expérience qui m’intéresse à titre personnel, car je n’ai aucun rôle officiel dans ce projet, hormis de filer des specs

Le développement, désiré, de ce que j’en sais, c’est une plateforme web d’annotation de jeux de données, (pour ensuite faire de l’IA, mais cette seconde partie ne rentre pas du tout dans le développement demandé). La taille c’est petit, je crois me rappeler que c’est pas vraiment plus de 20 sessions en parallèle. Et l’archi, c’est super simple tout en standalone sur un unique serveur physique ou se trouvent les données. Pour “sortir” ils nous filent un ou des ports (voire des urls) sur le localhost du serveur, le reste c’est notre job.
Pour justifier ce choix, ben d’une part le serveur physique on l’a, il est racké, câblé, installé et supervisé, garanti 7 ans sur site, l’hébergement pour nous est totalement gratuit ainsi que toute l’infrastructure du datacentre auquel on a accès en permanence. Enfin les données sont confidentielles et ne peuvent pas sortir du serveur, donc évidement on va pas autoriser des accès tiers vers des api sur le cloud.

C’est effectivement une possibilité. Bien que je partage tout à fait tes points de vue sur la maintenabilité, la sécurité et la pérennité, d’un développement docker en one shot. Néanmoins ce projet n’a pas forcément une grande durée de vie, une a 2 années au blair, donc pourquoi pas

Là ça m’aide vraiment, j’ai commencé a faire les specs techniques du serveur à la main. Il me servira de modèle pour formaliser les développements internes
Vu que j’ai du facter sur tous nos serveurs, je peux créer le fichier de spec à la volée sur tous nos serveurs. On a des tonnes de stagiaires internes qui nous demandes des machines virtuelles pour des projets d’études. Fournir automatiquement un fichier de specs spécifique avec des recommandations de développement lié au serveur une fois celui ci déployé, ça serait cool et au moins même si ce projet externalisé ne mène a rien au moins, il aura servi à ça.

PS: On a pas l’habitude d’externaliser, en général, les projets sont faits par des stagiaires… (oui je sais ). Les appels à projets comportent en général des fonds pour un ou des devs en CDD. Seulement voila, le dev en CDD de 6 mois ou 1 an qui accepte d’être payé sur une grille fonction publique ou les années d’expérience dans le privé comptent pour moitié, ils ne se bousculent pas au portillon, surtout en ce moment. Ce qui se comprend. D’où l’externalisation, pour laquelle on est à mon avis absolument pas prêt.

jl-m · Janvier 18, 2022, 9:17

En tout cas merci pour tes recommandations. Je vais faire au mieux en suivant tout ce que tu as préconisé. Ca fera peut être trop pour la boite externe, mais au moins, ça pourra ouvrir une base de discussion moins floue.

D’ailleurs, je trouve que plus généralement cette réponse donne plein de piste pour tous ceux qui comme moi commence à devoir bosser avec des prestataires et qui chercherait un mémo pour savoir quoi faire et comment

bat79a · Janvier 19, 2022, 7:56

Re.

Pour moi y’a quand même quelqu’un qui a passé une commande, il me semble que c’est le chercheur, et qu’il aurait du spécifier la cible du déploiement, et que de son côté le prestataire aurait du demander ou sera héberger son développement.

Reste comme je le disais a essayer de trouver des solutions et éviter maintenant que des personnes passent commandes sans fournir un minimum d’informations.

PS : je suis développeur et sur chaque projet je demande un peu de context, dont l’archi cible ;p

Bon courage.

thierry.f.78 · Janvier 19, 2022, 9:31

Je ne fourni que des exemples de contraintes à poser. Ce sont des contraintes qui existent dans la vrai vie, mais ils ne sont pas exhaustifs.

Il ne faut pas oublier qu’en tant que client, tu n’est pas dictateur mais commanditaire. Tu fixe donc tes besoins. Si ton infra s’exploite d’un certaine manière, tu ne va pas tout changer pour faire plaisir au prestataire. C’est un peu comme si tu fait construire un chalet en montagne et que le constructeur pose une caravane en t’expliquant que c’est comme ça qu’il sait faire.

Si tu décide de revoir tes exigences a la baisse pour faire plaisir au prestataire, c’est gentil pour lui et tout le monde travaille dans la bonne humeur, sauf toi qui te retrouve avec une application inexploitable et des tas de verrues à maintenir.

Pour moi une application doit répondre a des contraintes d’exploitation, sans quoi elle n’est pas exploitable. Si le prestataire n’aime pas ces contraintes, il peut refuser le contrat. En revanche je doute que le client accepte de revoir ses procédure d’exploitation pour faire plaisir aux développeurs. A la fin, il reste toujours une marge de négociation.

Tout ceci est moins vrai avec des équipes de dev internes, car une équipe interne n’est pas sensé finir sa mission et disparaitre en te laissant le bébé. Il est plus simple de travailler en bonne intelligence avec les équipes internes qui sont impliqué dans les process de prod.

Tout ce qui suit n’engage que moi, ce ne sont pas des best practice

Pour ma part, les contraintes que j’impose au prestataires sont les suivantes. Ces contraintes sont vu en accord avec nos développeurs:

le programme doit fonctionner sur RHEL8 avec les soft dans leur versions RHEL. exception si il existe un repository “sérieux” (si possible officiel, qui est suivi et qui backporte les correctif de bug) qui fourni les soft nécessaires (ex: https://blog.remirepo.net/ pour PHP). - (facilitation des updates et de la maintenance de l’OS)
si pertinent: le programme doit fournir des métriques de supervision dans un format donné - (observa-bilité)
le programme doit fournir des logs simples, logué via syslog configurable (udp ou /dev/log, facility) - (observabilité)
une backtrace est considéré comme un bug à corriger, elle est remontée via un canal automatique dans une interface de suivi (sentry like).
les logs doivent relater chaque décision prise par le soft en debug, chaque consultation en info, chaque modification en notice, les anomalies en warning, les erreurs en erreur. (observabilité, tracabilité)
les logs doivent repondre à un format précis et contenir des données obligatoires (observabilité, facilité d’intégration siem)
un api rest speciale remonte les cas grave directement au support. (observabilité)
si le soft est un daemon lancé en root, il doit perdre ses droits. (sécu de base)
si c’est pertinent il doit pouvoir être chrooté (secu de base)
la configuration doit être localisé dans un seul répertoire / sous répertoire et doit pouvoir être déplaçable facilement. (c’est pour faciliter les déploiement Ansible)
le soft doit fonctionner avec son code en lecture seule, si il y a des phases de compilation, elle doivent être faite par la CI et pas sur la machine destination. (sécurité)
respect des protocoles (RFC)
architecture en haute disponibilité (quelque soit la méthode. actif/backup, actif/actif, qorum, …)
si possible architecture scalable.
si possible éviter l’utilisation du réseau de manière non conventionnelle (NAT, regles iptables locales, …) - (observabilité et debug reseau simplifie)
documentation d’exploitation. doc des métriques, liste des points d’attention.

Au final, j’affine les contrainte en fonction de la nature développement.

Avec ces contraintes:

l’exploitation est très simple car le soft est observable.
l’astreinte ne sonne jamais car la haute-dispo fait son boulot.
le soft est debugable.

Certains prestataire n’aiment pas ces regles, on ne bosse pas avec eux.