Les développeurs viennent de Mars, les administrateurs viennent de Vénus

Les coïncidences sont aléatoires, et effectivement c'était sur une autre planète...

J'aimerais partager trois histoires de réussite et d'échec sur la façon dont un développeur backend travaille en équipe avec des administrateurs.

La première histoire.
Studio Web, le nombre d'employés se compte d'une seule main. Aujourd'hui, vous êtes un maquettiste, demain vous êtes un backender, après-demain vous êtes un administrateur. D'une part, vous pouvez acquérir une expérience considérable. En revanche, il y a un manque de compétences dans tous les domaines. Je me souviens encore du premier jour de travail, je suis toujours vert, le patron dit : « Ouvrez le mastic », mais je ne sais pas ce que c'est. La communication avec les administrateurs est exclue, car vous êtes vous-même administrateur. Considérons les avantages et les inconvénients de cette situation.

+ Tout le pouvoir est entre vos mains.
+ Il n'est pas nécessaire de mendier qui que ce soit pour accéder au serveur.
+ Temps de réaction rapide dans toutes les directions.
+ Améliore bien les compétences.
+ Avoir une compréhension complète de l'architecture du produit.

— Haute responsabilité.
— Risque de rupture de production.
— Il est difficile d’être un bon spécialiste dans tous les domaines.

Pas intéressé, passons à autre chose

La deuxième histoire.
Grande entreprise, grand projet. Il existe un service administratif de 5 à 7 employés et plusieurs groupes de développement. Quand vous venez travailler dans une telle entreprise, chaque administrateur pense que vous n’êtes pas venu ici pour travailler sur un produit, mais pour casser quelque chose. Ni la NDA signée ni la sélection lors de l'entretien n'indiquent le contraire. Non, cet homme est venu ici avec ses petites mains sales pour ruiner notre production de baisers. Par conséquent, avec une telle personne, vous avez besoin d'un minimum de communication, vous pouvez au moins lancer un autocollant en réponse. Ne répondez pas aux questions sur l’architecture du projet. Il est conseillé de ne pas accorder l’accès jusqu’à ce que le chef d’équipe le demande. Et quand il le demandera, il le rendra avec encore moins de privilèges que ceux demandés. Presque toutes les communications avec ces administrateurs sont absorbées par le trou noir entre le service de développement et le service d'administration. Il est impossible de résoudre les problèmes rapidement. Mais vous ne pouvez pas venir en personne, les administrateurs sont trop occupés 24h/7 et XNUMXj/XNUMX. (Que faites-vous tout le temps ?) Quelques caractéristiques de performance :

• Le temps de déploiement moyen jusqu'à la production est de 4 à 5 heures
• Temps maximum de déploiement en production 9 heures
• Pour un développeur, une application en production est une boîte noire, au même titre que le serveur de production lui-même. Combien y en a-t-il au total ?
• Faible qualité des versions, erreurs fréquentes
• Le développeur ne participe pas au processus de publication

Eh bien, à quoi je m'attendais, bien sûr, les nouvelles personnes ne sont pas autorisées à entrer en production. Bon, d'accord, après avoir gagné en patience, nous commençons à gagner la confiance des autres. Mais pour une raison quelconque, les choses ne sont pas si simples avec les administrateurs.

Acte 1. L'administrateur est invisible.
Le jour de la sortie, le développeur et l'administrateur ne communiquent pas. L'administrateur n'a aucune question. Mais vous comprendrez pourquoi plus tard. L'administrateur est une personne de principe, n'a pas de messagers, ne communique son numéro de téléphone à personne et n'a pas de profil sur les réseaux sociaux. Il n’y a même pas de photo de lui nulle part, à quoi tu ressembles mec ? Nous restons assis avec le responsable responsable pendant environ 15 minutes, perplexes, essayant d'établir la communication avec ce Voyager 1, puis un message apparaît dans l'e-mail d'entreprise indiquant qu'il a terminé. Allons-nous correspondre par courrier ? Pourquoi pas? Pratique, n'est-ce pas ? Bon, d'accord, calmons-nous. Le processus est déjà en cours, il n’y a pas de retour en arrière possible. Relisez le message. "J'ai fini". Qu'as-tu fini ? Où? Où dois-je te chercher ? Ici vous comprenez pourquoi 4 heures pour la sortie sont normales. Nous subissons un choc de développement, mais nous terminons la sortie. Il n’y a plus aucune envie de se libérer.

Acte 2. Pas cette version.
La prochaine version. Ayant acquis de l'expérience, nous commençons à créer des listes des logiciels et bibliothèques nécessaires au serveur pour les administrateurs, en indiquant les versions pour certains. Comme toujours, nous recevons un faible signal radio indiquant que l'administrateur a terminé quelque chose. Le test de régression commence, qui lui-même dure environ une heure. Tout semble fonctionner, mais il y a un bug critique. Une fonctionnalité importante ne fonctionne pas. Les heures suivantes ont été consacrées à la danse avec des tambourins, à la bonne aventure sur le marc de café et à une révision détaillée de chaque morceau de code. L'administrateur dit qu'il a tout fait. L'application écrite par des développeurs véreux ne fonctionne pas, mais le serveur fonctionne. Des questions pour lui ? Au bout d'une heure, nous demandons à l'administrateur d'envoyer la version de la bibliothèque sur le serveur de production dans le chat et le bingo - ce n'est pas celle dont nous avons besoin. Nous demandons à l'administrateur d'installer la version requise, mais en réponse nous recevons qu'il ne peut pas le faire en raison de l'absence de cette version dans le gestionnaire de packages du système d'exploitation. Ici, du fond de sa mémoire, le manager se souvient qu'un autre administrateur avait déjà résolu ce problème en assemblant simplement à la main la version requise. Mais non, le nôtre ne fera pas ça. La réglementation l'interdit. Karl, nous sommes assis ici depuis plusieurs heures, quel est le délai ?! Nous recevons un autre choc et terminons d'une manière ou d'une autre la sortie.

Acte 3, court
Ticket urgent, fonctionnalité clé ne fonctionne pas pour l'un des utilisateurs en production. Nous passons quelques heures à fouiller et à vérifier. Dans un environnement de développement, tout fonctionne. Il est clairement entendu que ce serait une bonne idée de consulter les journaux php-fpm. Il n'y avait pas de systèmes de journalisation comme ELK ou Prometheus sur le projet à cette époque. Nous ouvrons un ticket au service administration afin qu'il donne accès aux logs php-fpm sur le serveur. Ici, vous devez comprendre que nous demandons l'accès pour une raison, vous ne vous souvenez pas du trou noir et des administrateurs occupés 24h/7 et XNUMXj/XNUMX ? Si vous leur demandez de consulter eux-mêmes les journaux, il s'agit alors d'une tâche avec une priorité « pas dans cette vie ». Le ticket a été créé, nous avons reçu une réponse instantanée du chef du service administratif : « Vous ne devriez pas avoir besoin d'accéder aux journaux de production, écrivez sans bugs. Un rideau.

Acte 4 et au-delà
Nous collectons encore des dizaines de problèmes en production, dus à différentes versions de bibliothèques, à des logiciels non configurés, à des charges de serveur non préparées et à d'autres problèmes. Bien sûr, il y a aussi des bugs de code, nous ne blâmerons pas les administrateurs pour tous les péchés, nous mentionnerons simplement une autre opération typique pour ce projet. Nous avions pas mal de travailleurs en arrière-plan qui étaient lancés via le superviseur, et certains scripts ont dû être ajoutés à cron. Parfois, ces mêmes travailleurs arrêtaient de travailler. La charge sur le serveur de file d'attente a augmenté à une vitesse fulgurante et les utilisateurs tristes ont regardé le chargeur en rotation. Pour réparer rapidement ces travailleurs, il suffisait simplement de les redémarrer, mais encore une fois, seul un administrateur pouvait le faire. Pendant qu’une opération aussi élémentaire était effectuée, une journée entière pouvait s’écouler. Ici, bien sûr, il convient de noter que les programmeurs véreux devraient écrire des travailleurs pour qu'ils ne plantent pas, mais lorsqu'ils tombent, il serait bien de comprendre pourquoi, ce qui est parfois impossible en raison du manque d'accès à la production, de bien sûr, et par conséquent, le manque de logs du développeur.

Transfiguration.
Après avoir enduré tout cela pendant assez longtemps, nous avons commencé, avec l'équipe, à nous diriger dans une direction qui nous convenait mieux. Pour résumer, à quels problèmes avons-nous été confrontés ?

• Manque de communication de qualité entre les développeurs et le service administratif
• Il s'avère que les administrateurs (!) ne comprennent pas du tout comment l'application est structurée, quelles dépendances elle possède et comment elle fonctionne.
• Les développeurs ne comprennent pas comment fonctionne l'environnement de production et, par conséquent, ne peuvent pas répondre efficacement aux problèmes.
• Le processus de déploiement prend trop de temps.
• Versions instables.

Qu'avons-nous fait?
Pour chaque version, une liste de notes de version a été générée, qui comprenait une liste des travaux à effectuer sur le serveur pour que la prochaine version fonctionne. La liste contenait plusieurs sections, un travail qui devait être effectué par l'administrateur, la personne responsable de la version et le développeur. Les développeurs bénéficiaient d'un accès non root à tous les serveurs de production, ce qui accélérait le développement en général et la résolution des problèmes en particulier. Les développeurs comprennent également comment fonctionne la production, en quels services elle est divisée, où et combien coûtent les répliques. Certaines charges de combat sont devenues plus claires, ce qui affecte sans aucun doute la qualité du code. La communication pendant le processus de publication a eu lieu dans le chat de l'une des messageries instantanées. Premièrement, nous avions un journal de toutes les actions et, deuxièmement, la communication s'effectuait dans un environnement plus proche. Avoir un historique d'actions a plus d'une fois permis aux nouveaux employés de résoudre les problèmes plus rapidement. C’est un paradoxe, mais cela a souvent aidé les administrateurs eux-mêmes. Je ne m'engage pas à le dire avec certitude, mais il me semble que les administrateurs ont commencé à mieux comprendre comment fonctionne le projet et comment il est écrit. Parfois, nous partagions même certains détails. Le temps moyen de sortie a été réduit à une heure. Parfois, nous avions terminé en 30 à 40 minutes. Le nombre de bugs a considérablement diminué, voire décuplé. Bien entendu, d’autres facteurs ont également influencé la réduction du temps de sortie, comme les autotests. Après chaque sortie, nous avons commencé à réaliser des rétrospectives. Pour que toute l’équipe ait une idée de ce qui est nouveau, de ce qui a changé et de ce qui a été supprimé. Malheureusement, les administrateurs ne sont pas toujours venus vers eux, eh bien, les administrateurs sont occupés... Ma satisfaction au travail en tant que développeur a sans aucun doute augmenté. Lorsque vous pouvez résoudre rapidement presque tous les problèmes qui relèvent de votre domaine de compétence, vous vous sentez au top. Plus tard, je comprendrai que dans une certaine mesure nous avons introduit une culture DevOps, pas complètement bien sûr, mais même ce début de transformation était impressionnant.

Troisième histoire
Démarrer. Un administrateur, petit département de développement. À mon arrivée, je suis un zéro complet, car... Je n'ai accès nulle part sauf par courrier. Nous écrivons à l'administrateur et demandons l'accès. De plus, il existe des informations selon lesquelles il connaît le nouvel employé et la nécessité de fournir des identifiants/mots de passe. Ils donnent accès depuis le référentiel et le VPN. Pourquoi donner accès à wiki, teamcity, rundesk ? Des choses inutiles pour une personne qui a été appelée pour écrire toute la partie backend. Ce n'est qu'avec le temps que nous avons accès à certains outils. Bien entendu, cette arrivée a suscité la méfiance. J’essaie lentement d’avoir une idée du fonctionnement de l’infrastructure du projet à travers des discussions et des questions suggestives. En gros, je ne reconnais rien. La production est la même boîte noire qu’avant. Mais plus encore, même les serveurs de scène utilisés pour les tests sont une boîte noire. Nous ne pouvons rien faire d’autre que d’y déployer une branche depuis Git. Nous ne pouvons pas non plus configurer notre application comme les fichiers .env. L'accès à de telles opérations n'est pas accordé. Vous devez mendier pour faire modifier une ligne dans la configuration de votre application sur le serveur de test. (Il existe une théorie selon laquelle il est vital que les administrateurs se sentent importants dans le projet ; si on ne leur demande pas de modifier les lignes dans les configurations, ils ne seront tout simplement pas nécessaires). Eh bien, comme toujours, n'est-ce pas pratique ? Cela devient vite ennuyeux, après une conversation directe avec l'administrateur, nous découvrons que les développeurs sont nés pour écrire du mauvais code, sont par nature des individus incompétents et qu'il vaut mieux les tenir à l'écart de la production. Mais ici aussi depuis des serveurs de test, juste au cas où. Le conflit s'intensifie rapidement. Il n'y a aucune communication avec l'administrateur. La situation est aggravée par le fait qu'il est seul. Ce qui suit est une image typique. Libérer. Certaines fonctionnalités ne fonctionnent pas. Il nous faut beaucoup de temps pour comprendre ce qui se passe, diverses idées des développeurs sont lancées dans le chat, mais l'administrateur dans une telle situation suppose généralement que les développeurs sont à blâmer. Puis il écrit dans le chat, attends, je l'ai corrigé. Lorsqu'on nous demande de laisser une histoire avec des informations sur l'origine du problème, nous recevons des excuses toxiques. Par exemple, ne mets pas ton nez là où il n'a pas sa place. Les développeurs doivent écrire du code. La situation où de nombreux mouvements du corps dans un projet passent par une seule personne et où elle seule a accès pour effectuer les opérations dont chacun a besoin est extrêmement triste. Une telle personne constitue un terrible goulot d’étranglement. Si les idées Devops s’efforcent de réduire les délais de mise sur le marché, alors ces personnes sont les pires ennemis des idées Devops. Malheureusement, le rideau se ferme ici.

PS Après avoir parlé un peu des développeurs et des administrateurs lors de discussions avec des gens, j'ai rencontré des personnes qui partageaient ma douleur. Mais il y avait aussi ceux qui disaient n’avoir jamais rencontré quelque chose de pareil. Lors d'une conférence Devops, j'ai demandé à Anton Isanin (Alfa Bank) comment ils géraient le problème du goulot d'étranglement lié aux administrateurs, ce à quoi il a répondu : « Nous les avons remplacés par des boutons ». D'ailleurs Podcast avec sa participation. J'aimerais croire qu'il y a beaucoup plus de bons administrateurs que d'ennemis. Et oui, la photo du début est une véritable correspondance.

Source : www.habr.com