Récemment, de telles publicités ont inondé Internet. Malgré le salaire agréable, on ne peut qu'être gêné 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 collés ensemble en un seul mot, puis vient une liste aléatoire d'exigences, dont certaines sont clairement copiées à partir du poste vacant de l'administrateur système.
Dans cet article, je veux parler un peu de la façon dont nous en sommes arrivés à ce qu'est vraiment le DevOps et 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 fait une conférence devo et déclaré ouvertement: " DevOops - pas pour les ingénieurs DevOps." Ici, cela semblera étrange et sauvage à beaucoup: pourquoi les gens qui font un événement complètement commercial vont à l'encontre du marché. Nous allons tout expliquer maintenant.
À propos de la culture et des processus
Pour commencer, DevOps n'est pas une discipline d'ingénierie. Tout a commencé avec le fait que la division des rôles établie historiquement ne fonctionne pas sur la qualité des produits. Lorsque les programmeurs programment uniquement mais ne veulent rien entendre sur les tests, le logiciel est jonché de bogues. Lorsque les administrateurs ne se soucient pas de savoir comment et pourquoi les logiciels sont écrits, le support se transforme en enfer.
Par exemple, le célèbre livre Google SRE commence par une description de la différence entre l'approche sysadmin et SRE-shny de la gestion des services. Des études intéressantes ont été menées dans le cadre de l'enquête DORA - on peut voir que les meilleurs développeurs parviennent en quelque sorte à déployer de nouveaux changements en production plus rapidement qu'une fois par heure. Ils testent avec leurs mains pas plus de 10% (cela peut être vu dans le DORA de l'année dernière ). Comment font-ils? "Excel ou mourir", dit l'un des en-têtes du rapport. Pour une discussion détaillée de ces statistiques en termes de tests, vous pouvez vous tourner vers le discours-programme de Baruch Sadogursky «Nous avons DevOps. Tirons tous les testeurs » lors de notre autre conférence, Heisenbug.
«Quand il n'y a pas d'accord entre les camarades,
Ça ne marchera pas bien,
Et il n'en sortira pas, seulement de la farine.
Une fois un cygne, un cancer et un brochet ... "
Que pensez-vous, quelle partie des programmeurs Web comprend vraiment les conditions dans lesquelles leurs applications sont exploitées sur prod? Combien d'entre eux iront aux admins et essayeront de comprendre ce qui se passera lorsque la base tombera? Et qui d'entre eux ira aux testeurs et leur demandera d'enseigner comment écrire correctement les tests? Et il y a encore des agents de sécurité, des chefs de produit et un tas de gens.
L'idée générale de DevOps est d'établir une interaction entre les rôles et les départements. Tout d'abord, cela n'est pas réalisé par un logiciel astucieusement réglé, mais par la pratique de la communication. DevOps concerne la culture, la pratique, la méthodologie et les processus. Il n'y a pas une telle spécialité d'ingénierie qui répondrait à ces questions.
Cercle vicieux
D'où vient donc la discipline de «l'ingénierie des devops»? Nous avons une version! Les idées DevOps se sont avérées bonnes - si bonnes qu'elles sont devenues les victimes de leur succès. Autour de ce sujet, des recruteurs et des trafiquants boueux à l'atmosphère très particulière ont commencé à tourbillonner.
Imaginez: hier vous avez fait du shawarma à Khimki, et aujourd'hui vous êtes déjà un grand homme, recruteur senior. Il y a tout un processus de recherche et de sélection de candidats, tout n'est pas facile, il faut comprendre. Supposons que le chef du département dise: trouvez un spécialiste de X. Nous attribuons le mot "ingénieur" à X, et le point est dans le chapeau. Besoin de Linux? Eh bien, c'est définitivement un ingénieur Linux, vous voulez DevOps - DevOps engineer. Un travail ne se compose pas seulement d'un en-tête, mais du texte doit être saisi à l'intérieur. Le moyen le plus simple consiste à saisir un ensemble de mots clés de Google, pour lesquels il y a suffisamment d'imagination. DevOps se compose de deux mots - «Dev» et «Ops», ce qui signifie que vous devez coller les mots clés liés aux développeurs et aux administrateurs, le tout dans une pile. Il existe donc des postes vacants concernant la possession de 42 langages de programmation et 20 ans d'utilisation de Kubernetes et Swarm en même temps. Schéma de fonctionnement.
Ainsi, l'image aveugle et impitoyable d'un certain super-héros - les «devoops» ont pris racine dans l'esprit des gens, qui prépareront tout le monde pour Jenkins et le bonheur viendra. Ah, si seulement c'était aussi simple que cela. "Et vous pouvez également pirater les administrateurs système de cette manière", pense Eichar, "le mot est à la mode, les mots-clés sont les mêmes, ils doivent picorer".
La demande crée l'offre, et un nombre insensé d'administrateurs système sont tombés sur tous ces postes vacants. Comme vous avez configuré le serveur via SSH avec vos mains un par un, vous continuerez à configurer, mais maintenant c'est censé être une pratique de devops. Il s'agit d'une sorte de phénomène complexe, lié en partie à la fois à la sous-estimation des admins classiques et au battage médiatique autour de DevOps, mais en général, ce qui s'est passé s'est avéré.
Donc, nous avons l'offre et la demande. Un cercle vicieux qui se nourrit. C'est avec cela que nous nous battons (notamment en créant la conférence DevOops).
Bien sûr, en plus des administrateurs système, renommés «devops», il y a d'autres participants - par exemple, des SRE professionnels ou des développeurs d'Infrastructure-as-Code.
Que font les gens dans DevOps (en fait)
Vous souhaitez donc progresser dans l'apprentissage et l'application des pratiques DevOps. Mais comment faire, dans quel sens? Évidemment, guidé aveuglément par des mots clés populaires ne vaut pas la peine.
S'il y a du travail, quelqu'un devrait le faire. Nous avons déjà découvert que ce ne sont pas des «ingénieurs DevOps», alors qui? 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 faire le cœur même de DevOps - les processus et la culture. La culture n'est pas une question rapide et difficile, et bien que cela soit traditionnellement la responsabilité des gestionnaires, d'une manière ou d'une autre, tout le monde y participe, des programmeurs aux administrateurs. Il y a quelques mois, Tim Lister a déclaré dans une interview :
«La culture est définie par les valeurs fondamentales de l'organisation. Habituellement, les gens ne le remarquent pas, mais nous, travaillant dans le conseil depuis de nombreuses années, sommes habitués à le remarquer. Vous entrez dans l'entreprise et, en quelques minutes, vous commencez à ressentir ce qui se passe. Nous l'appelons «arôme». Parfois, cette saveur est vraiment bonne. Parfois, cela provoque des nausées. (...) Vous ne pouvez pas changer une culture avant que les valeurs et les croyances derrière des actions concrètes aient été réalisées. Le comportement est facile à observer et la recherche de croyances est difficile. DevOps est juste un excellent exemple de la façon dont les choses deviennent de plus en plus difficiles. »
Il y a aussi une partie technique à la question, bien sûr. Si vous obtenez un nouveau code à tester dans un mois, et dans la version, il n'apparaît que dans un an, et il est physiquement impossible d'accélérer tout cela, vous ne pouvez pas être à la hauteur des bonnes pratiques. Les bonnes pratiques sont soutenues par de bons outils. Par exemple, avec l'idée d'Infrastructure-as-Code à l'esprit, vous pouvez utiliser n'importe quoi, depuis AWS CloudFormation et Terraform jusqu'à Chef-Ansible-Puppet. Vous devez savoir et être capable de faire tout cela, et c'est une discipline entièrement d'ingénierie. Il est important de ne pas confondre la cause avec les conséquences: dans un premier temps, vous travaillez sur les principes du SRE et ce n'est qu'ensuite que vous appliquez ces principes sous la forme de solutions techniques spécifiques. Dans le même temps, SRE est une méthodologie très complète qui ne parle pas de la façon de configurer Jenkins, mais de cinq principes de base:
- Améliorer l'interaction entre les rôles et les départements
- Accepter les erreurs comme partie intégrante du travail
- Changement progressif
- Utilisation de l'optimisation et d'autres automatisations
- Mesurer tout ce qui peut être mesuré
Il ne s'agit pas seulement d'un ensemble de déclarations, mais d'un guide d'action spécifique. Par exemple, sur le chemin de l'erreur, vous devrez gérer les risques, mesurer la disponibilité et l'inaccessibilité des services à l'aide de quelque chose comme SLI ( indicateurs de niveau de service ) et SLO ( objectifs de niveau de service ), apprendre à écrire post-mortem et à faciliter l'écriture .
Dans la discipline SRE, l'utilisation d'outils n'est qu'une partie du succès, mais elle est 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 devenues très populaires maintenant. Selon la compréhension actuelle de 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 clouds publics, privés et hybrides. Les exemples incluent les conteneurs, les maillages de service, les microservices, l'infrastructure immuable et les API déclaratives. Toutes ces techniques permettent aux systèmes à couplage lâche de rester flexibles, gérables et bien observables. Une bonne automatisation permet aux ingénieurs de faire de grands changements souvent et avec des résultats prévisibles, sans en faire un travail infernal. Tout cela est pris en charge par une pile d'outils bien connus tels que Docker et Kubernetes.
Cette définition assez compliquée et lourde est liée au fait que la région est plutôt compliquée. D'une part, il est avancé que de nouveaux changements à ce système devraient être ajoutés 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 d'un CI / CD continu, et construisent autour de toute cette pratique DevOps - vous avez besoin de plus d'un manger un chien.
Que faire avec tout ça
Chacun résout ces problèmes à sa manière: par exemple, vous pouvez publier des travaux normaux 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 dans DevOps et démontrer les bonnes approches avec votre propre exemple.
Nous organisons la conférence DevOops 2020 à Moscou , qui offre l'occasion de mieux comprendre les choses dont nous venons de parler. Il existe plusieurs groupes de rapports pour cela:
- Processus et culture;
- Ingénierie de fiabilité du site;
- Cloud Native
Comment choisir où aller? Il y a un point subtil. D'une part, DevOps concerne l'interaction, et nous voulons vraiment que vous alliez aux rapports de différents blocs. D'un autre côté, si vous êtes un responsable du développement qui est venu à la conférence pour se concentrer sur une tâche spécifique, alors personne ne vous limite - évidemment, ce sera un bloc sur les processus et la culture. N'oubliez pas qu'après la conférence, vous aurez des notes (après avoir rempli le formulaire de rétroaction), afin que vous puissiez toujours voir les rapports moins importants plus tard.
De toute évidence, lors de la conférence elle-même, vous ne pouvez pas accéder immédiatement à trois pistes en même temps, nous créons donc le programme de telle sorte qu'il y ait des thèmes pour tous les goûts dans chaque créneau horaire.
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 traitent des infrastructures. Les groupes de discussion SRE et Cloud Native vous conviennent le mieux.
- Administrateurs système. C'est plus compliqué. 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 sujet de l'administration système. D'un autre côté, si vous êtes intéressé à développer en termes de compréhension de la culture et des processus, d'explorer les technologies cloud et les détails de la vie avec Cloud Native, alors nous serons heureux de vous voir! Pensez à ceci: vous êtes ici dans l'administration, et que ferez-vous? Afin de ne pas être soudainement dans une situation désagréable, cela vaut la peine d'étudier maintenant.
Il existe une autre option: vous persistez et continuez à prétendre que vous êtes un ingénieur DevOps et rien d'autre, quoi que cela signifie. Alors forcé de pleurer, DevOops n'est pas une conférence pour les ingénieurs DevOps!
Diapositive du rapport Konstantin Diener à Munich
DevOops 2020 Moscou se tiendra du 29 au 30 avril à Moscou, les billets peuvent déjà être achetés sur le site officiel .
De plus, vous pouvez soumettre votre rapport avant le 8 février. Veuillez noter qu'en remplissant le formulaire, vous devez choisir le public cible pour lequel votre rapport fera plus de bien ( une surprise est enfouie dans la liste ).