Les ingénieurs DevOps n'existent pas. Qui existe alors et que faire avec ça ?

Récemment, de telles annonces ont envahi Internet. Malgré un salaire attractif, il est difficile de ne pas être troublé par le fait qu'elles contiennent des absurdités flagrantes. Au départ, on suppose qu'il est possible de combiner « DevOps » et « ingénieur » en un seul mot, et ensuite vient une liste aléatoire d'exigences, dont une partie semble clairement copiée depuis une annonce pour administrateur système.

Dans ce post, nous souhaitons discuter de la manière dont nous en sommes arrivés à cette situation, ce qu'est réellement DevOps et comment procéder désormais.

Ces annonces de travail peuvent être critiquées sous toutes les coutures, mais le fait est qu'il y en a beaucoup, et c'est ainsi que le marché fonctionne actuellement. Nous avons organisé une conférence DevOps et déclarons ouvertement : «DevOops — ce n'est pas pour les ingénieurs DevOps ». Beaucoup trouveront cela étrange et absurde : pourquoi des personnes organisant un événement commercial s'opposent-elles au marché ? Nous allons tout expliquer maintenant.

Sur la culture et les processus

Commencez par comprendre que DevOps n'est pas une discipline d'ingénierie. Tout a commencé par le fait que la division historique des rôles ne fonctionne pas pour la qualité des produits. Lorsque les programmeurs se contentent de coder sans vouloir entendre parler de tests, le logiciel est bourré de bogues. Lorsque les administrateurs se moquent de la façon et des raisons pour lesquelles le logiciel est écrit, le support devient un véritable enfer.

Par exemple, la différence entre l'approche d'administration système et celle de SRE en matière de gestion de service commence avec le célèbre livre Google SRE. Des recherches intéressantes ont été menées dans le cadre de l'enquête DORA — il est évident que les meilleurs développeurs parviennent d'une manière ou d'une autre à déployer de nouveaux changements en production plus d'une fois par heure. Ils effectuent également des tests manuels pas plus de 10% du temps (comme on le voit dans le DORA de l'année dernière). Comment y parviennent-ils ? « Excel or die » – dit l'un des titres du rapport. Pour une discussion plus détaillée de ces statistiques en matière de tests, vous pouvez vous référer au keynote de Baruch Sadogursky « Nous avons DevOps. Licencions tous les testeurs » lors d'une autre de nos conférences, Heisenbug.

« Quand il n'y a pas d'accord entre les camarades,
Leurs affaires ne progresseront pas,
Et il ne sortira de là rien de bon, juste de la souffrance.
Un jour, le Cygne, le Crabe et le Brochet… »

Que pensez-vous, quelle partie des développeurs web comprend vraiment dans quelles conditions leurs applications fonctionnent en production ? Combien d'entre eux iront voir les administrateurs pour essayer de comprendre ce qui se passera en cas de chute de la base de données ? Qui d'entre eux se rendra chez les testeurs et demandera à apprendre à écrire des tests correctement ? Et il y a aussi des spécialistes de la sécurité, des chefs de produits, et une foule d'autres personnes.

L'idée générale de DevOps est d'établir une interaction entre les rôles et les départements. Cela se réalise principalement non pas avec un logiciel réglé de manière astucieuse, mais par la pratique de la communication. DevOps concerne la culture, la pratique, la méthodologie et les processus. Il n'existe pas de spécialité d'ingénieur qui réponde à ces questions.

Cercle vicieux

D'où vient alors la discipline « ingénierie DevOps » ? Nous avons une théorie ! Les idées de DevOps se sont révélées si bonnes qu'elles sont devenues victimes de leur succès. Autour de ce sujet, des recruteurs douteux et des marchands de personnes se sont regroupés, créant une atmosphère bien à eux.

Imaginez : hier, vous faisiez des shawarmas à Khimki, et aujourd'hui — vous êtes déjà une personne importante, un recruteur senior. Il y a tout un processus de recherche et de sélection des candidats, tout cela n'est pas simple, il faut comprendre. Supposons que le chef de département dit : trouve un spécialiste en X. On ajoute au mot X le mot « ingénieur », et le tour est joué. Besoin de Linux ? Eh bien, c'est certainement un ingénieur Linux, si vous voulez DevOps — un ingénieur DevOps. Une offre d'emploi ne se compose pas seulement d'un titre, mais à l'intérieur, il faut inscrire un certain texte. Le plus simple est d'inscrire un ensemble de mots-clés de Google, selon l'imagination de chacun. DevOps se compose de deux mots — « Dev » et « Ops », donc, il faut rassembler des mots-clés liés aux développeurs et aux administrateurs, tous ensemble. Ainsi apparaissent des offres d'emploi mentionnant la maîtrise de 42 langages de programmation et 20 ans d'utilisation de Kubernetes et Swarm simultanément. C'est une approche habituelle.

Ainsi, dans l'esprit des gens s'est enracinée l'image absurde et impitoyable d'un super-héros DevOps, qui configurera tous les déploiements sur Jenkins, et ce sera le bonheur. Ah, si tout était si simple. « Et en plus, on peut chasser des admins systèmes, pense le recruteur, c'est à la mode, les mots-clés sont les mêmes, ils devraient mordre. »

La demande crée l'offre, et toutes ces offres douteuses ont attiré un nombre fou d'administrateurs système qui ont compris qu'ils pouvaient faire exactement la même chose qu'auparavant, mais en étant payés plusieurs fois plus, sous le nom de « devops ». Comme tu configurais des serveurs via SSH un par un, tu continueras à le faire, mais cela s'appelle apparemment maintenant une pratique devops. C'est un phénomène complexe, en partie lié à la sous-estimation des admins classiques et au phénomène entourant DevOps, mais au final — ce qui est fait, est fait.

Nous avons donc la demande et l'offre. Un cercle vicieux qui se nourrit de lui-même. C'est ce avec quoi nous luttons (y compris en créant la conférence DevOops).

Bien sûr, en plus des administrateurs système qui se sont rebaptisés en « devops », il y a d'autres participants — par exemple, des SRE professionnels ou des développeurs d'Infrastructure-as-Code.

Que font les gens en DevOps (réellement)

Alors, vous voulez progresser dans l'apprentissage et l'application des pratiques DevOps. Mais comment faire, dans quelle direction regarder ? Évidemment, il ne faut pas se fier aveuglément aux mots-clés populaires.

S'il y a du travail, quelqu'un doit s'en occuper. Nous avons déjà établi que ce ne sont pas des « ingénieurs devops », alors qui ? Il semble plus approprié de le formuler non pas en termes de postes, mais en termes de domaines de travail spécifiques.

Tout d'abord, vous pouvez vous occuper du cœur même de DevOps — les processus et la culture. La culture est une affaire de longue haleine et difficile, et bien que cela soit traditionnellement de la responsabilité des dirigeants, d'une manière ou d'une autre, tout le monde participe à cela, des programmeurs aux admins. Il y a quelques mois, Tim Lister a déclaré dans une interview:

« La culture est déterminée par les valeurs fondamentales de l'organisation. Les gens ne s'en rendent généralement pas compte, mais nous, travaillant en consulting depuis de nombreuses années, avons appris à le remarquer. Vous entrez dans une entreprise et littéralement au bout de quelques minutes, vous commencez à ressentir ce qui se passe. Nous appelons cela l'« arôme ». Parfois, cet arôme est vraiment bon. Parfois, il provoque des nausées. (…) Vous ne pouvez pas changer la culture tant que les valeurs et les croyances qui sous-tendent des actions spécifiques n'ont pas été prises en compte. Le comportement est facile à observer, mais trouver les croyances est difficile. DevOps est justement un excellent exemple de la manière dont tout devient de plus en plus compliqué. »

Il y a forcément un aspect technique à la question. Si ton nouveau code arrive en test dans un mois et n’est publié que dans un an, et qu'il est physiquement impossible d’accélérer tout cela, tu risques de ne jamais atteindre de bonnes pratiques. Les bonnes pratiques sont soutenues par de bons outils. Par exemple, en gardant à l’esprit l’idée d’Infrastructure-as-Code, on peut utiliser n’importe quoi, d’AWS CloudFormation et Terraform à Chef-Ansible-Puppet. Il faut tout cela connaître et maîtriser, et cela constitue déjà une véritable discipline d’ingénierie. Il est important de ne pas confondre la cause et les conséquences : d'abord, vous travaillez selon les principes SRE et ensuite seulement vous incarnez ces principes sous forme de solutions techniques concrètes. Par ailleurs, le SRE est une méthodologie très complexe qui ne parle pas de comment configurer Jenkins, mais de cinq principes fondamentaux :

• Améliorer la collaboration entre les rôles et les départements
• Accepter les erreurs comme une partie intégrante du travail
• Mettre en œuvre des changements progressivement
• Utiliser des outils et d'autres formes d'automatisation
• Mesurer tout ce qui peut être mesuré

Ce n’est pas simplement un ensemble d'énoncés, mais un guide d'action. Par exemple, sur le chemin de l'acceptation des erreurs, il faudra comprendre les risques, mesurer la disponibilité et l'indisponibilité des services grâce à quelque chose comme l’SLI (indicateurs de niveau de service) et SLO (objectifs de niveau de service), apprendre à rédiger des post-mortems et faire en sorte qu’il ne soit pas effrayant de les rédiger.

Dans la discipline SRE, l'utilisation d'outils n'est qu'une partie du succès, bien que non négligeable. Nous devons continuellement nous développer sur le plan technique, surveiller ce qui se passe dans le monde et comment cela peut être appliqué à notre travail.

D'autre part, les solutions Cloud Native sont devenues très populaires récemment. Selon la compréhension moderne de la Cloud Native Computing Foundation, les technologies Cloud Native permettent aux organisations de développer et de déployer des applications évolutives dans des environnements dynamiques modernes, tels que les nuages publics, privés et hybrides. Parmi les exemples, on peut citer les conteneurs, les maillages de services, les microservices, l'infrastructure immuable et les API déclaratives. Toutes ces techniques permettent aux systèmes faiblement couplés de rester flexibles, gérables et bien observables. Une bonne automatisation permet aux ingénieurs d'apporter de grands changements fréquemment, avec des résultats prévisibles, sans que cela ne devienne un travail infernal. Tout cela est soutenu par un ensemble d'outils bien connus, tels que Docker et Kubernetes.

Cette définition est assez complexe et dense, car le domaine l'est également. D'une part, il est affirmé que de nouveaux changements dans ce système devraient être ajoutés assez simplement. D'autre part, pour comprendre comment créer un environnement conteneurisé où des services faiblement couplés résident sur une infrastructure définie par logiciel et sont fournis par l'intermédiaire d'une CI/CD continue, ainsi que pour établir des pratiques DevOps autour de cela, il faut en avoir vu d'autres.

Que faire avec tout cela

Chacun résout ces problèmes à sa manière : par exemple, on peut publier des offres d'emploi normales pour rompre le cercle vicieux. On peut comprendre la signification des termes tels que DevOps et Cloud Native et les utiliser correctement et à bon escient. On peut progresser en DevOps et démontrer par l'exemple des approches appropriées.

Nous organisons une conférence DevOops 2020 Moscou, qui offre l'opportunité d'explorer en profondeur les sujets que nous venons d'aborder. Pour cela, il y a plusieurs groupes de présentations :

• Processus et culture;
• Ingénierie de la fiabilité des sites;
• Cloud Native;

Comment choisir où aller ? Il y a un point délicat. D'une part, DevOps, c'est une question d'interaction, et nous espérons vraiment que vous assisterez à des présentations de différentes sessions. D'autre part, si vous êtes un responsable du développement venu à la conférence pour se concentrer sur une tâche spécifique, rien ne vous en empêche — il est clair que ce sera la session sur les processus et la culture. N'oubliez pas qu'après la conférence, vous aurez accès aux enregistrements (après avoir rempli le formulaire de retour), donc vous pourrez toujours visionner des présentations moins essentielles plus tard.

Évidemment, lors de la conférence, vous ne pouvez pas assister à trois sessions en même temps, c'est pourquoi nous avons conçu le programme pour que chaque créneau horaire propose des sujets variés.

Il ne reste plus qu'à comprendre quoi faire si vous êtes ingénieur DevOps ! Tout d'abord, essayez de déterminer ce que vous faites réellement. Ce terme est souvent utilisé pour désigner :

• Les développeurs qui s'occupent de l'infrastructure. Les sessions sur l'SRE et le Cloud Native vous conviendront le mieux.
• Les administrateurs systèmes. C'est plus compliqué. DevOps ne concerne pas l'administration système. Heureusement, il existe de nombreuses excellentes conférences, livres, articles, vidéos en ligne, etc. sur le sujet de l'administration système. D'un autre côté, si vous êtes intéressé par le développement de votre compréhension de la culture et des processus, l'étude des technologies cloud et les détails de la vie avec le Cloud Native, nous serons ravis de vous accueillir ! Réfléchissez à ceci : si vous vous occupez de l'administration, que ferez-vous ensuite ? Pour éviter de vous retrouver dans une situation compliquée, il est prudent d'apprendre dès maintenant.

Il y a une autre option : vous persistez et continuez à affirmer que vous êtes exactement un ingénieur DevOps et rien d'autre, quoi que cela puisse signifier. Dans ce cas, nous devons vous décevoir, DevOps n'est pas une conférence destinée aux ingénieurs DevOps !

Diapositive de la présentation de Konstantin Diener à Munich

DevOops 2020 Moscou se déroulera les 29 et 30 avril à Moscou, les billets sont déjà en vente achetés sur le site officiel.

De plus, vous pouvez soumettre votre présentation jusqu'au 8 février. Notez que lors de la soumission du formulaire, vous devez choisir le public cible qui bénéficiera le plus de votre présentation (un surprise est enfouie dans la liste).

Source : habr.com