Basé sur une discussion par chat
Récemment, de véritables batailles ont éclaté sur la définition du DevOps et du SRE.
Malgré le fait qu'à bien des égards, les discussions sur ce sujet m'ont déjà fait grincer des dents, y compris moi-même, j'ai décidé de présenter mon point de vue sur ce sujet au tribunal de la communauté Habra. Pour ceux que ça intéresse, bienvenue chez cat. Et que tout recommence !
Préhistoire
Ainsi, dans les temps anciens, une équipe de développeurs de logiciels et d'administrateurs de serveurs vivait séparément. Le premier a écrit avec succès le code, le second, en utilisant divers mots chaleureux et affectueux adressés au premier, a configuré les serveurs, s'adressant périodiquement aux développeurs et recevant en réponse un message complet "tout fonctionne sur ma machine". L'entreprise attendait le logiciel, tout était inactif, il tombait en panne périodiquement, tout le monde était nerveux. Surtout celui qui a payé pour tout ce gâchis. Glorieuse époque des lampes. Eh bien, vous savez déjà d'où vient le DevOps.
La naissance des pratiques DevOps
Puis des gars sérieux sont venus et ont dit : ce n’est pas une industrie, vous ne pouvez pas travailler comme ça. Et ils ont introduit des modèles de cycle de vie. Voici par exemple le modèle V.
Alors que voit-on ? Une entreprise vient avec un concept, les architectes conçoivent des solutions, les développeurs écrivent du code, puis elle échoue. Quelqu'un teste le produit d'une manière ou d'une autre, quelqu'un le livre à l'utilisateur final, et quelque part à la sortie de ce modèle miracle se trouve un client professionnel solitaire qui attend le temps promis au bord de la mer. Nous sommes arrivés à la conclusion que nous avons besoin de méthodes qui nous permettront d'établir ce processus. Et nous avons décidé de créer des pratiques qui permettraient de les mettre en œuvre.
Une digression lyrique sur ce qu'est la pratique
Par pratique, j’entends une combinaison de technologie et de discipline. Un exemple est la pratique consistant à décrire l’infrastructure à l’aide du code Terraform. La discipline consiste à décrire l'infrastructure avec du code, elle est dans la tête du développeur et la technologie est la terraformation elle-même.
Et ils ont décidé de les appeler pratiques DevOps – je pense qu’ils voulaient dire du développement aux opérations. Nous avons trouvé diverses choses intelligentes - des pratiques CI/CD, des pratiques basées sur le principe IaC, des milliers d'entre elles. Et c'est parti, les développeurs écrivent du code, les ingénieurs DevOps transforment la description du système sous forme de code en systèmes fonctionnels (oui, le code n'est malheureusement qu'une description, mais pas l'incarnation du système), la livraison continue, et ainsi de suite. Les administrateurs d'hier, maîtrisant les nouvelles pratiques, se sont fièrement reconvertis en ingénieurs DevOps, et tout est parti de là. Et il y avait un soir, et il y avait un matin... désolé, pas à partir de là.
Tout n'est pas encore bien, Dieu merci
Dès que tout s'est calmé et que divers « méthodologues » rusés ont commencé à écrire des livres épais sur les pratiques DevOps, des disputes ont éclaté tranquillement sur l'identité du célèbre ingénieur DevOps et sur le fait que DevOps est une culture de production, le mécontentement est à nouveau apparu. Soudain, il s'est avéré que la livraison de logiciels est une tâche absolument non triviale. Chaque infrastructure de développement a sa propre pile, quelque part vous devez l'assembler, quelque part vous devez déployer l'environnement, ici vous avez besoin de Tomcat, ici vous avez besoin d'un moyen astucieux et compliqué de le lancer - en général, vous avez la tête qui bat. Et le problème, assez curieusement, s'est avéré être principalement l'organisation des processus - cette fonction de livraison, comme un goulot d'étranglement, a commencé à bloquer les processus. De plus, personne n'a annulé les opérations. Il n'est pas visible dans le modèle en V, mais il y a toujours le cycle de vie complet à droite. En conséquence, il est nécessaire d'entretenir l'infrastructure, de surveiller la surveillance, de résoudre les incidents et également de gérer la livraison. Ceux. asseyez-vous avec un pied dans le développement et l'exploitation - et tout à coup, il s'est avéré qu'il s'agissait du développement et des opérations. Et puis il y a eu un battage médiatique général autour des microservices. Et avec eux, le développement à partir de machines locales a commencé à migrer vers le cloud - essayez de déboguer quelque chose localement, s'il existe des dizaines et des centaines de microservices, alors la livraison constante devient un moyen de survie. Pour une « petite entreprise modeste », tout allait bien, mais quand même ? Et Google ?
SRE par Google
Google est venu, a mangé les plus gros cactus et a décidé : nous n'avons pas besoin de cela, nous avons besoin de fiabilité. Et la fiabilité doit être gérée. Et j'ai décidé que nous avions besoin de spécialistes qui géreraient la fiabilité. Je les ai appelés ingénieurs SR et leur ai dit, c'est tout pour vous, faites-le bien comme d'habitude. Voici SLI, voici SLO, voici la surveillance. Et il a mis son nez dans les opérations. Et il a appelé son SRE « DevOps fiable ». Tout semble aller bien, mais il y a un sale hack que Google pourrait se permettre : pour le poste d'ingénieurs SR, embaucher des personnes qui étaient des développeurs qualifiés et qui ont également fait quelques devoirs et compris le fonctionnement des systèmes de travail. De plus, Google lui-même a du mal à embaucher de telles personnes - principalement parce qu'ici il est en concurrence avec lui-même - il est nécessaire de décrire la logique métier à quelqu'un. La livraison a été confiée aux ingénieurs de publication, SR - les ingénieurs gèrent la fiabilité (bien sûr, pas directement, mais en influençant l'infrastructure, en modifiant l'architecture, en suivant les changements et les indicateurs, en traitant les incidents). Bien, tu peux . Mais que se passe-t-il si vous n'êtes pas Google et que la fiabilité reste, d'une manière ou d'une autre, un sujet de préoccupation ?
Développement d'idées DevOps
C'est à ce moment-là qu'est arrivé Docker, issu de lxc, puis divers systèmes d'orchestration tels que Docker Swarm et Kubernetes, et les ingénieurs DevOps ont expiré - l'unification des pratiques a simplifié la livraison. Cela l'a tellement simplifié qu'il est devenu possible même d'externaliser la livraison aux développeurs - qu'est-ce que le déploiement.yaml. La conteneurisation résout le problème. Et la maturité des systèmes CI/CD est déjà au niveau de l'écriture d'un fichier et c'est parti - les développeurs peuvent le gérer eux-mêmes. Et puis nous commençons à parler de la façon dont nous pouvons créer notre propre SRE, avec... ou du moins avec quelqu'un.
SRE n'est pas sur Google
Bon, ok, nous avons livré la livraison, il semble que nous puissions expirer, revenir au bon vieux temps, quand les administrateurs surveillaient le chargement du processeur, ajustaient les systèmes et sirotaient tranquillement quelque chose d'incompréhensible dans des tasses en toute tranquillité... Arrêtez. Ce n’est pas pour ça qu’on a tout commencé (ce qui est dommage !). Soudain, il s'avère que dans l'approche de Google, nous pouvons facilement adopter d'excellentes pratiques - ce n'est pas la charge du processeur qui est importante, ni la fréquence à laquelle nous changeons les disques ou optimisons les coûts dans le cloud, mais les mesures commerciales sont les mêmes notoires SLx. Et personne ne leur a supprimé la gestion de l'infrastructure, et ils doivent résoudre les incidents, être en service périodiquement et, de manière générale, rester au courant des processus métier. Et les gars, commencez à programmer petit à petit à un bon niveau, Google vous attend déjà.
Résumer. Du coup, mais vous en avez déjà marre de lire et vous avez hâte de cracher et d'écrire à l'auteur en commentaire de l'article. DevOps en tant que pratique de livraison a toujours été et sera. Et ça ne mène nulle part. Le SRE en tant qu’ensemble de pratiques opérationnelles contribue au succès de cette prestation.
Source: habr.com