Récemment, de telles publicités ont inondé Internet. Malgré le salaire agréable, on ne peut s'empêcher d'être gêné par le fait qu'une hérésie sauvage soit écrite à l'intérieur. Au début, on suppose que « DevOps » et « ingénieur » peuvent d'une manière ou d'une autre être regroupés en un seul mot, puis il existe une liste aléatoire d'exigences, dont certaines sont clairement copiées du poste vacant d'administrateur système.
Dans cet article, j'aimerais parler un peu de la façon dont nous sommes arrivés à ce point de la vie, de ce qu'est réellement DevOps et de ce qu'il faut en faire maintenant.
De telles offres d'emploi peuvent être condamnées de toutes les manières possibles, mais le fait demeure : elles sont nombreuses, et c'est ainsi que fonctionne actuellement le marché. Nous avons tenu une conférence Devops et déclarons ouvertement : « - pas pour les ingénieurs DevOps." Cela semblera étrange et fou à beaucoup : pourquoi les gens qui organisent un événement entièrement commercial vont à l'encontre du marché. Maintenant, nous allons tout expliquer.
À propos de la culture et des processus
Commençons par le fait que DevOps n'est pas une discipline d'ingénierie. Tout a commencé avec le fait que la répartition des rôles historiquement établie ne fonctionne pas pour la qualité des produits. Lorsque les programmeurs se contentent de programmer, mais ne veulent rien entendre sur les tests, le logiciel est rempli de bugs. Lorsque les administrateurs ne se soucient pas de savoir comment ou pourquoi le logiciel est écrit, le support se transforme en enfer.
Par exemple, décrire la différence entre un administrateur système et une approche SRE en matière de gestion des services. . Des études intéressantes ont été réalisées au sein — il est clair que les meilleurs développeurs parviennent d'une manière ou d'une autre à déployer de nouvelles modifications en production plus rapidement qu'une fois par heure. Ils testent avec leurs mains pas plus de 10 % (cela peut être vu sur ). comment font-ils ça? « Exceller ou mourir » dit l'un des titres du rapport. Pour une discussion détaillée de ces statistiques dans le cadre des tests, vous pouvez vous référer au discours de Baruch Sadogursky lors de notre autre conférence, Heisenbug.
« Quand il n’y a pas d’accord entre camarades,
Ils ne fonctionneront pas bien.
Et il n'en sortira pas, seulement de la farine.
Il était une fois un cygne, une écrevisse et un brochet..."
Selon vous, quelle partie des programmeurs Web comprend vraiment les conditions dans lesquelles leurs applications sont utilisées en production ? Combien d’entre eux s’adresseront aux administrateurs et tenteront de comprendre ce qui se passera si la base de données tombe en panne ? Et lequel d'entre eux ira voir les testeurs et leur demandera de leur apprendre à rédiger correctement les tests ? Et il y a aussi des agents de sécurité, des chefs de produit et bien d’autres personnes.
L'idée générale du DevOps est de créer une collaboration entre les rôles et les départements. Tout d’abord, cela n’est pas possible grâce à un logiciel intelligemment configuré, mais à la pratique de la communication. DevOps concerne la culture, les pratiques, la méthodologie et les processus. Aucune spécialité d’ingénierie ne peut répondre à ces questions.
Cercle vicieux
D’où vient alors la discipline de « l’ingénierie DevOps » ? Nous avons une version ! Les idées DevOps étaient bonnes, si bonnes qu'elles sont devenues victimes de leur propre succès. Certains recruteurs louches et trafiquants d’êtres humains, qui ont leur propre atmosphère, ont commencé à tourbillonner autour de tout ce sujet.
Imaginez : hier vous prépariez du shawarma à Khimki, et aujourd'hui vous êtes déjà un grand homme, un recruteur senior. Il y a tout un processus de recherche et de sélection des candidats, tout n'est pas facile, il faut comprendre. Disons que le chef d’un service dit : trouvez un spécialiste en X. On attribue le mot « ingénieur » à X, et c’est fini. Besoin de Linux ? Eh bien, c'est définitivement un ingénieur Linux, si vous voulez DevOps, alors un ingénieur DevOps. Le poste vacant se compose non seulement d'un titre, mais également d'un texte qui doit être saisi à l'intérieur. Le moyen le plus simple est de saisir un ensemble de mots-clés provenant de Google, en fonction de votre imagination. DevOps se compose de deux mots : « Dev » et « Ops », ce qui signifie que nous devons regrouper les mots-clés liés aux développeurs et aux administrateurs, le tout en une seule pile. C'est ainsi qu'apparaissent des postes vacants concernant la maîtrise de 42 langages de programmation et 20 ans d'utilisation simultanée de Kubernetes et Swarm. Schéma de travail.
C’est ainsi que s’est enracinée dans l’esprit des gens l’image dénuée de sens et impitoyable d’un certain super-héros « devops », qui configurera tout le monde pour se déployer sur Jenkins, et le bonheur viendra. Oh, si seulement tout était si simple. "Et c'est aussi comme ça qu'on peut traquer les administrateurs système", pense les RH, "c'est un mot à la mode, les mots-clés sont les mêmes, il faut qu'ils mordent à l'hameçon".
La demande crée l'offre, et tous ces postes vacants ont été pourvus par un nombre insensé d'administrateurs système qui ont réalisé : vous pouvez tout faire comme avant, mais en obtenez plusieurs fois plus en vous appelant « devops ». Tout comme vous avez configuré manuellement les serveurs via SSH un par un, vous continuerez à les configurer, mais c'est maintenant censé être une pratique devops. Il s'agit d'une sorte de phénomène complexe, en partie lié à la sous-estimation des administrateurs classiques et au battage médiatique autour du DevOps, mais en général, ce qui s'est passé s'est produit.
Nous avons donc une offre et une demande. Un cercle vicieux qui s'alimente tout seul. C’est contre cela que nous luttons (notamment en créant la conférence DevOops).
Bien entendu, outre les administrateurs système qui se sont rebaptisés « devops », il existe d'autres participants, par exemple des SRE professionnels ou des développeurs Infrastructure-as-Code.
Ce que font les gens dans DevOps (vraiment)
Vous souhaitez donc progresser dans l’apprentissage et l’application des pratiques DevOps. Mais comment faire, dans quelle direction regarder ? Évidemment, vous ne devez pas vous fier aveuglément aux mots-clés populaires.
S'il y a un travail, quelqu'un devrait le faire. Nous avons déjà découvert que ce ne sont pas des « ingénieurs DevOps », alors qui le sont ? Il semble plus correct de formuler cela non pas en termes de postes, mais en termes de domaines de travail spécifiques.
Tout d’abord, vous pouvez aborder le cœur du DevOps : les processus et la culture. La culture est une affaire lente et difficile, et même si elle relève traditionnellement de la responsabilité des managers, tout le monde est impliqué d'une manière ou d'une autre, des programmeurs aux administrateurs. Il y a quelques mois, Tim Lister :
« La culture est déterminée par les valeurs fondamentales de l’organisation. Habituellement, les gens ne le remarquent pas, mais ayant travaillé dans le conseil pendant de nombreuses années, nous avons l'habitude de le remarquer. Vous entrez dans une entreprise et, en quelques minutes, vous commencez à ressentir ce qui se passe. Nous appelons cela « saveur ». Parfois, ce parfum est vraiment bon. Parfois, cela provoque des nausées. (...) Vous ne pouvez pas changer une culture tant que les valeurs et les croyances qui sous-tendent des actions spécifiques ne sont pas comprises. Le comportement est facile à observer, mais la recherche de croyances est difficile. DevOps n’est qu’un excellent exemple de la façon dont les choses deviennent de plus en plus complexes.
Il y a bien sûr aussi un aspect technique à ce problème. Si votre nouveau code est testé dans un mois, mais n'est publié qu'un an plus tard, et qu'il est physiquement impossible de tout accélérer, vous risquez de ne pas respecter les bonnes pratiques. Les bonnes pratiques s'appuient sur de bons outils. Par exemple, avec l'idée d'Infrastructure-as-Code en tête, vous pouvez utiliser n'importe quoi, d'AWS CloudFormation et Terraform à Chef-Ansible-Puppet. Il faut savoir et être capable de faire tout cela, et c'est déjà une véritable discipline d'ingénierie. Il est important de ne pas confondre cause et effet : vous travaillez d’abord selon les principes du SRE et ensuite seulement vous mettez en œuvre ces principes sous la forme de solutions techniques spécifiques. En même temps, SRE est une méthodologie très complète qui ne vous explique pas comment configurer Jenkins, mais environ cinq principes de base :
- Communication améliorée entre les rôles et les départements
- Accepter les erreurs comme partie intégrante du travail
- Faire des changements progressivement
- Utiliser des outils et autres automatisations
- Mesurer tout ce qui peut être mesuré
Il ne s'agit pas simplement d'un ensemble de déclarations, mais d'un . Par exemple, pour accepter les erreurs, vous devrez comprendre les risques, mesurer la disponibilité et l'indisponibilité des services en utilisant quelque chose comme SLI () et SLO (), apprenez à rédiger des autopsies et faites en sorte que leur écriture ne soit pas effrayante.
Dans la discipline SRE, l’utilisation d’outils n’est qu’une partie de la réussite, bien qu’importante. Nous devons constamment nous développer techniquement, regarder ce qui se passe dans le monde et comment cela peut être appliqué dans notre travail.
À leur tour, les solutions Cloud Native sont désormais devenues très populaires. Telles que définies aujourd'hui par la Cloud Native Computing Foundation, les technologies Cloud Native permettent aux organisations de développer et d'exécuter des applications évolutives dans les environnements dynamiques d'aujourd'hui, tels que les cloud publics, privés et hybrides. Les exemples incluent 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 élastiques, gérables et hautement observables. Une bonne automatisation permet aux ingénieurs d’effectuer fréquemment des changements importants et avec des résultats prévisibles sans en faire une corvée. Tout cela est pris en charge par une pile d'outils bien connus tels que Docker et Kubernetes.
Cette définition assez complexe et large est due au fait que la zone est également assez complexe. D’une part, on avance que de nouvelles modifications à ce système devraient être apportées tout simplement. D'un autre côté, pour comprendre comment créer une sorte d'environnement conteneurisé dans lequel des services faiblement couplés vivent sur une infrastructure définie par logiciel et y sont fournis à l'aide de CI/CD continus, et construire des pratiques DevOps autour de tout cela - tout cela nécessite plus qu'on mange le chien.
Que faire de tout ça
Chacun résout ces problèmes à sa manière : par exemple, vous pouvez publier des offres d'emploi normales pour briser le cercle vicieux. Vous pouvez comprendre ce que signifient des mots comme DevOps et Cloud Native et les utiliser correctement et précisément. Vous pouvez développer en DevOps et démontrer les bonnes approches par votre exemple.
Nous faisons une conférence , ce qui donne l’occasion d’approfondir les choses dont nous venons de parler. Il existe plusieurs groupes de rapports pour cela :
- Processus et culture ;
- Ingénierie de la fiabilité du site ;
- Nuage natif ;
Comment choisir où aller ? Il y a ici un point subtil. D'une part, DevOps est une question d'interaction, et nous souhaitons vraiment que vous assistiez à des présentations de différents blocs. D'un autre côté, si vous êtes un responsable du développement venu à la conférence pour vous concentrer sur une tâche spécifique, personne ne vous limite - évidemment, ce sera un blocage concernant les processus et la culture. N'oubliez pas que vous disposerez d'enregistrements après la conférence (après avoir rempli le formulaire de commentaires), vous pourrez donc toujours regarder les présentations moins importantes plus tard.
Évidemment, lors de la conférence elle-même, vous ne pouvez pas aborder trois pistes à la fois, c'est pourquoi nous organisons le programme de manière à ce que chaque créneau horaire propose des sujets pour tous les goûts.
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. Habituellement, ils aiment appeler ce mot :
- Développeurs qui travaillent sur l'infrastructure. Les groupes de rapports sur SRE et Cloud Native vous conviennent le mieux.
- Administrateurs système. C'est plus compliqué ici. DevOops ne concerne pas l'administration système. Heureusement, il existe de nombreuses excellentes conférences, livres, articles, vidéos sur Internet, etc. sur le thème de l'administration système. D'un autre côté, si vous souhaitez vous développer en termes de compréhension de la culture et des processus, en apprendre davantage sur les technologies cloud et les détails de la vie avec Cloud Native, alors nous serions ravis de vous voir ! Pensez-y : vous faites de l’administration, et ensuite que ferez-vous ? Pour éviter de vous retrouver soudainement dans une situation désagréable, vous devez apprendre dès maintenant.
Il existe une autre option : vous persistez et continuez à prétendre que vous êtes spécifiquement un ingénieur DevOps et rien d'autre, quoi que cela signifie. Alors nous devons vous décevoir, DevOops n'est pas une conférence pour ingénieurs DevOps !
Glisser de à Munich
DevOops 2020 Moscou aura lieu les 29 et 30 avril à Moscou, les billets sont déjà disponibles .
Alternativement, vous pouvez jusqu'au 8 février. Veuillez noter qu'au moment de remplir le formulaire, vous devez sélectionner le public cible qui bénéficiera le plus de votre rapport (il y a une surprise enfouie dans la liste).
Source: habr.com