De l'administrateur système à la personne

DevOps a au moins deux vues bien établies - du côté des administrateurs système et du côté des développeurs. Les premiers se vantent généralement d'utiliser Chef / Puppet / Ansible / Docker depuis 200X, les seconds pensent que DevOps a survécu et mène à NoOps, ou que «j'ai tout emballé dans un conteneur, puis comment ça se passe.»

Dans le même temps, l'entreprise lit sur DevOps dans des articles et espère que les gars ci-dessous sauront quoi en faire. Dans le même temps, DevOps lui-même ne se produit pas, l'entreprise ne ressemble pas à Google, l'entreprise ne devient pas turquoise, les gens ne créent pas de nouvelles approches pour tester des hypothèses dans le monde.

Cet article concerne DevOps en tant que système. Comment cela aide-t-il l'entreprise, quelles compétences des ingénieurs devraient apparaître pour DevOps, quelles tâches commerciales peuvent être résolues par la méthode DevOps de production de logiciels, et quelles erreurs sont possibles sur le chemin de la production DevOps et comment les éviter ou les arrêter. Comment, en fin de compte, comment un ingénieur peut-il devenir un homme et être un créateur dans ce monde, comment construire un cheminement de carrière pour cela et comment commencer à regarder la technologie humainement.

Le matériel est basé sur la transcription du rapport d' Alexander osminog Titov de notre conférence d'octobre DevOops 2017.



Pour ceux qui sont habitués à regarder des reportages de conférences dans des enregistrements, nous attachons une vidéo.



Je travaille pour Express 42. Mon histoire concerne mon cheminement de carrière, mais je vais lui fournir des conseils et des conclusions intéressants. Il a un nom accrocheur "De l'administrateur système à la personne". Je sépare le rôle de l'administrateur système d'une certaine condition humaine. DevOps nous pousse à être non seulement des artistes, mais des créateurs de nouveaux produits numériques et plus encore.

Puisque mon histoire est basée sur mon expérience, je vais vous parler un peu de moi. J'ai commencé en tant qu'administrateur système lorsque j'étais à l'université. Il a travaillé sur le quart de nuit, puis a commencé à travailler sur le quart de jour, puis est passé au poste d'administrateur principal du système. J'ai ensuite travaillé dans les réseaux sociaux connectect.ua et fakultet.ru, puis en tant que directeur technique dans la société Oversan-Skalaksi. Ce fut l'une des premières tentatives de lancement d'hébergement cloud en Russie, comme il s'est avéré, une tentative très précoce. Le besoin d'hébergement cloud en Russie ne s'est fait sentir que maintenant. Nous venons de comprendre comment les utiliser, nous avons réalisé qu'il s'agit de ressources flexibles, qu'elles ont besoin d'écrire les applications différemment, etc. À cette époque, personne ne comprenait cela du tout, il était donc très difficile de le vendre.

J'ai ensuite travaillé dans une startup Qik de la Silicon Valley, dont le bureau de développement était ici en Russie. Chez Qik, j'ai vraiment ressenti les avantages du concept DevOps, car en deux mois, nous avons créé un produit qui est passé de 0 à 5 millions d'utilisateurs. Si à Oversan-Skalaxi, du point de vue du service, je pensais que DevOps était nécessaire et que les gens devaient comprendre ce que DevOps utilisait pour l'hébergement cloud, alors à Qik, je le ressentais en tant qu'administrateur système et en tant que chef du département des administrateurs système. Ensuite, nous avons été rachetés par Skype, et nous avons commencé à nous y intégrer, et également à y intégrer les développements dans le domaine du DevOps, car ce n'était pas dans Skype. Et puis Skype a acheté Microsoft. Il semble qu'il soit venu dans une entreprise où environ 40 personnes, et après quelques années, vous travaillez dans une grande entreprise avec 100 000 employés. Ce fut une expérience très intéressante.

En conséquence, je n'ai pas trouvé où aller plus loin dans ces entreprises, et mes collègues et moi avons ouvert Express 42, qui transporte DevOps vers les masses. Cette idée est née à Oversan-Skalaksi, et elle me motive. Entre autres choses, je suis très enraciné pour la communauté DevOps en Russie. Je suis l'organisateur des réunions DevOpsDays Moscou et Moscou DevOps.

Je crains depuis longtemps que l'utilisation d'Ansible puisse être mauvaise ou bonne. L'outil dans son ensemble ne résout rien. Vous pouvez utiliser Docker, Kubernetes, installer la dernière version de Prometheus, mais en même temps ce que vous faites ne sera pas différent de ce que les utilisateurs de scripts bash ont. Je vais essayer de vous expliquer pourquoi cela se produit. À bien des égards, cette réponse réside en nous, donc l'article s'appelle ainsi. L'administrateur système pense comment écrire des scripts bash pour lui, et la personne pense un peu différemment.

Comment DevOps apparaît-il dans l'entreprise?

Développeur DevOps

Il existe plusieurs façons d'apparaître DevOps dans une entreprise. L'une de ces façons est lorsque les développeurs, fatigués de demander aux administrateurs système de faire quelque chose et après avoir entendu parler de DevOps, essaient de l'implémenter. Mais en même temps, ils ont une compréhension particulière de DevOps. Ils pensent qu'ils peuvent utiliser n'importe quelle technologie, tout envelopper dans un conteneur Docker et l'envoyer aux administrateurs système, mais ils ne pensent pas du tout au fonctionnement de leur code en production. Ils n'ont rien changé dans leur tête pour passer à DevOps, mais en même temps ils commencent à utiliser de nouvelles technologies.

J'ai vu beaucoup de ces entreprises. Vous venez à eux - ils ont quatre départements de développement. Chaque département écrit son propre microservice, chaque département a sa propre base de données. Quelqu'un Redis, quelqu'un PostgreSQL, quelqu'un PostgreSQL et MySQL en même temps. Et ils accompagnent cela, jusqu'à ce que les bases de données atteignent des tailles telles qu'elles ne peuvent plus.

À ce stade, tout commence à s'effondrer et à s'effondrer, et des conséquences terrifiantes surviennent. Il s'agit d'un zoo technologique avec lequel on ne sait pas quoi faire. De plus, la particularité du développeur est qu'il résout le problème en faisant glisser une nouvelle bibliothèque. Je pense que ceux qui travaillent avec les développeurs de Node.js le savent. Lorsque les développeurs de Node.js constatent que la base de données ne fonctionne pas correctement, ils peuvent passer de PostgreSQL à une version, ajouter une extension ou commencer à utiliser du JSONB. En conséquence, un état d'architecture terrible se pose, mais dans l'ensemble, ils sont satisfaits de tout. L'application est difficile à gérer, vous ne pouvez pas comprendre ce qui s'y passe, sa stabilité est faible, elle se bloque constamment. En réponse à l'application bloquée, les développeurs y collent autre chose, et cela continue de baisser, et en conséquence, rien n'est compris du tout.

Sysadmin DevOps

Il existe une chose telle que DevOps-sysadmin. Ce sont généralement des gars très puissants qui ont fait leurs preuves. Ils viennent et disent: "Les gars, vous ne pouvez pas vivre comme ça, nous sommes fatigués de tirer ce fluide, nous automatisons maintenant tout, nous allons faire le pipeline de livraison, si doux, merveilleux et qui fonctionne bien. Nous savons très bien comment l'application devrait fonctionner en production. Beaucoup mieux que ces fous qui écrivent sur Node.js. Et nous savons ce qui doit être utilisé pour que tout soit parfait. »

Plusieurs fois, je suis tombé sur le fait que ces personnes ont construit DevOps sur FreeBSD. Le résultat a été un système fermé, qu'ils ont eux-mêmes écrit, et seulement ils ont compris comment cela fonctionne. Malgré mon expérience d'administrateur système, je ne pouvais pas le comprendre, mais si je ne le pouvais pas, comment le développeur devrait-il comprendre comment déployer via ce système CI? En conséquence, j'ai interdit administrativement l'utilisation de FreeBSD dans l'entreprise, malgré le fait que j'aime et respecte sincèrement le système lui-même, en particulier j'aime OpenBSD. Mais une semaine plus tard, parmi les serveurs Linux, les serveurs FreeBSD ont recommencé à apparaître, comme des agarics volants.

Les administrateurs système DevOps, ainsi que les développeurs, pensent que la technologie est la chose la plus importante, rien ne peut être fait sans eux. S'ils aiment la technologie, ils essaient de la coller partout.
Chez Oversan-Skalaxi, nous avons inventé le terme configurations et scripts en écriture seule. C'est quand une personne pouvait écrire, mais personne ne pouvait lire.

Dans le même temps, les administrateurs système continuent de réparer quelque chose dans le savon. Vous venez à lui et offrez de l'aide, et il vous donne quelque chose avec un tapis à trois étages. Vous ne comprenez rien, car vous devez comprendre ce qu'il a fait. Eh bien, si le développeur vient et dit, par exemple, qu'il a besoin d'une base de données tolérante aux pannes? On lui donnera quelque chose avec ce tapis de trois étages, il s'assiéra et ne comprendra pas quoi en faire. Tous partis, les développeurs et les administrateurs système ne communiquent pas. Bien qu'à l'intérieur on utilise tous les plus modernes, sophistiqués.

De là est venue l'idée traditionnelle des administrateurs système: c'est une personne à plusieurs bras qui fait quelque chose, mais vous ne comprendrez pas quoi exactement. Soit dit en passant, la plupart des RH en recherchent actuellement. Je peux vous dire que trouver une telle personne dans l'entreprise ne vous évitera pas à 100% de problèmes.

DevOps pour les entreprises

Un autre moyen pour l'émergence de DevOps est du côté des entreprises. Certains de vos cadres supérieurs sont allés à une conférence d'affaires, par exemple, dans la vallée, où ils lui ont dit que si vous n'avez pas Docker, une intégration continue (CI) et autre chose, alors vous ne pouvez pas être considéré société de technologie. Le gestionnaire revient, recueille les employés et lit les mots d'un cahier: DevOps, Docker, Concourse CI. Les gars commencent à comprendre, puis les scénarios mixtes mentionnés ci-dessus se produisent: DevOps-développeur, DevOps-sysadmin, et tout cela conduit à un gâchis que vous ne pouvez pas discerner.

En fait, je vois constamment de telles situations. Pourquoi cela se produit-il: vous venez à la conférence, tout le monde a une vision rationnelle et normale - puis vous allez dans les tranchées, dans la production, et puis il y a des ordures et des fumées? Autrement dit, tout le monde comprend tout, mais pour une raison quelconque, ils ne fonctionnent pas. J'ai l'hypothèse que tout le monde comprend une partie, pas tous. Et maintenant, je vais essayer de parler globalement de DevOps.

De l'entreprise à l'agile

Premièrement, du point de vue des affaires, nous vivons un tournant: nous nous éloignons d'une entreprise qui met en œuvre des projets monumentaux pour transférer l'entreprise elle-même du point A au point B (par exemple, une stratégie sur cinq ans pour capter 70% du marché) ...

... et venez dans le monde d'Agile. Le point d'Agile n'est pas d'être flexible, mais ce point A est connu et B ne l'est pas. Et c'est le plus profond qui puisse arriver. Parce que ni nous ni les entreprises ne sommes habitués à travailler avec cela. Imaginez que vous ne savez pas ce qui se passera dans une semaine ou deux semaines, que le chef est venu vers vous et a dit: "Alors, essayez de me faire quelque chose qui ne peut pas être, notez votre nom afin de ne pas oublier à la hâte . " Et vous ne savez pas quoi faire, mais le monde et les affaires deviennent de cette façon, et vous devez vous y habituer. Et toutes ces pratiques, comme Agile, Scrum, Kanban, ne visent pas à vivre avec.


Nous passons de la voie des entreprises-sociétés et des sociétés à la voie de la technologie. Certains logiciels commencent à interagir avec nous sur le marché. Si des personnes plus anciennes, des entreprises interagissaient avec nous, des vendeurs téléphonaient et ainsi de suite, maintenant pour appeler un taxi, commander une pizza, écouter de la musique, nous passons à l'application. Et une application est un logiciel que quelqu'un doit écrire et adapter en permanence au marché. Et nous, les ingénieurs et ceux qui sont engagés dans les affaires, devons comprendre à partir de l'application ce qui se passe sur le marché. Et au final, cela nous fait évoluer vers DevOps.

DevOps n'apparaît pas parce que l'un de vous devrait être à l'aise et non parce que vous devez utiliser des technologies plus cool. NoSQL n'est pas plus cool que SQL; de plus, il est bien pire que SQL par l'état il y a 3-4 ans. Les bases de données SQL sont développées depuis 20 ans et les bases de données NoSQL depuis 1 an. Et nous nous souvenons de l'état déplorable de MongoDB il y a 4 ans, quand ce n'était pas du tout une base de données.


DevOps est le même qu'avant, seulement maintenant nous faisons tout en même temps. Si vous êtes développeur, vous écrivez du code et écrivez immédiatement des tests, un wrapper pour Kubernetes, ou simplement un conteneur Docker, comment cela devrait fonctionner en production. Et ce faisant, vous devez remplir une condition minimale - exécutez ce code. Parce que de nombreux développeurs de l'ère précédente ne l'ont pas fait: le compilateur a compilé et ce qui a commencé et a commencé à fonctionner dans le conteneur d'application est déjà la dixième chose. Dans le même temps, écrivez des métriques, des journaux à collecter. Et puis vous perdez tout dans Delivery Pipeline, Jenkins, TeamCity ou autre chose. Il s'agit d'une différence fondamentale entre un développeur dans une entreprise et un développeur dans une entreprise technologique. Ici, le développeur commence à écrire non seulement des algorithmes, mais l'ensemble du produit.

Histoire de DevOps

Voici le moment de vous tourner vers l'histoire de DevOps. Comment tout cela s'est-il produit? J'ai vécu cela, j'ai constamment lu les nouvelles, suivi la chaîne historique, comment tout cela est apparu. Et maintenant, différentes personnes de différentes années me disent différentes versions de ce qu'est DevOps et comment cela s'est produit. Et il me semble important de revenir aux racines.

En 2003, Ben Trainor de Google a créé l'équipe SRE. Google est la première grande entreprise numérique au monde. Déjà en 2003, ils étaient confrontés au problème selon lequel, de la manière classique à laquelle tous les développeurs de logiciels sont habitués, ils ne peuvent pas faire ce qu'ils veulent. Et ils ont innové en présentant l'équipe SRE, et ont depuis développé cette pratique.

En 2009, John Alspaw et Paul Hammond ont parlé de travailler ensemble au sein de Flickr et comment ils partagent 10 fois par jour. À ce moment-là, c'était une sensation et une explosion. Et Patrick Deboit a espionné ce rapport et a inventé le terme DevOps, organisé la communauté mondiale afin de développer davantage cette pratique.

Les entreprises technologiques ont émergé qui devaient partager rapidement. Les anciennes approches ne convenaient pas et elles ont commencé à en proposer de nouvelles. Et en douceur, naturellement, ils ont été réorganisés afin qu'ils aient une nouvelle pratique de création de logiciels.

Nous sommes dans une situation très difficile, car nous n'avons pas connu ce changement naturel. Ces technologies nous parviennent lorsque quelque chose s'est déjà produit là-bas, mais nous ne savons toujours pas comment les utiliser. Là, les gens ont évolué vers cela, et nous devons faire une révolution, repenser tout cela et le déplacer d'une manière ou d'une autre sur leur propre sol.

Comment appliquer DevOps?

Lorsque vous utilisez DevOps, il est très important de vraiment réaliser que vous créez un produit numérique et que le délai de commercialisation (TTM) est important pour les entreprises.

Il est important de transformer toutes les équipes en équipes de développement. Il n'y a plus d'administrateur système distinct, un développeur distinct. Parce que ceux que nous appelons les administrateurs système écrivent ce qu'on appelle une plate-forme d'infrastructure, et les développeurs écrivent ce qu'on appelle un produit, et ainsi ils se fournissent mutuellement un service.

Une autre chose non évidente et très importante que nous oublions tous est l'organisation de l'accumulation et de l'échange de connaissances au sein de l'équipe et entre les équipes. Nous avons de gros problèmes avec cela. Nous n'aimons pas partager quelque chose qui, par exemple, n'est pas encore prêt, et c'est la clé pour que DevOps existe. Il faut parler de ce qui n'est pas prêt, tester des hypothèses, il faut être ouvert à quelqu'un qui nous dit qu'il n'est pas prêt. Parce que nous sommes habitués, par exemple, si les administrateurs système ont testé quelque chose de cool, sont venus, ont dit, ils ont répondu: "Non, mais comment ça marche en production, qu'avez-vous testé?"

Les administrateurs système, se rendant compte que quelque part ils n'ont pas compris, quelque part ils n'ont pas testé, quitté, fermé, et cette connaissance disparaît, et nous ne faisons pas un pas en avant. Et il est juste de dire: "Les gars, regardez! Vous avez fait un travail vraiment cool, un excellent travail, mais il y a une question que je veux vraiment vous poser: comment cela fonctionnera-t-il en production? Avez-vous pensé à ça? "La prochaine fois que vous nous montrez comment implémenter cette fonction en production, ce sera très cool!"
Ils partent déjà avec la tâche. Et dans le cas de notre approche russe classique "oui non non, toutes les ordures", ils partent avec la pensée "pourquoi devrions-nous faire cela si nous étions tous refusés" . Et c'est un gros problème au sein de la communauté DevOps. Nous ne partageons pas les uns avec les autres, car nous ne sommes pas sûrs que cela ne sera pas reconnu comme évident ou pas aussi hardcore qu'il y paraît, et ainsi de suite.

Les organisateurs de la conférence m'ont déjà dit que tout le monde avait besoin d'un méga-hardcore. Eh bien, peut-être que vous ne pouvez pas faire un méga-hardcore, mais pour qu'une personne partage une expérience réelle et que vous puissiez en parler, c'est aussi cool.

Développeur chez DevOps

Le développeur de DevOps n'écrit pas le code, mais le produit. Et ce n'est pas une chose évidente, car dans les instituts, les cours, les livres, nous, les programmeurs, apprenons à écrire des algorithmes, pas des produits, ils apprennent à résoudre non pas un problème commercial, mais un problème algorithmique. C'est un énorme problème. Il est très important dans votre tête de savoir à quel moment vous résolvez un problème algorithmique et à quel moment est un vrai problème commercial.

Dans une entreprise pratiquant DevOps, le développeur pense immédiatement comment son code s'intégrera avec d'autres composants. Commence immédiatement à communiquer à ce sujet. Par exemple, pour clarifier dans un chat une feuille de route d'un changement d'API qu'il utilise pour vérifier. C'est le début de la coopération.

Le développeur a une idée de l'architecture de l'application - c'est très important, car sans comprendre comment l'architecture fonctionne, quelles sont les couches technologiques et comment elles interagissent entre elles, il est impossible de penser à l'intégration.

Le développeur sait comment le code fonctionne au combat et comprend ce qui se passe avec cette application. Dans mon exemple, lorsqu'un développeur écrit immédiatement le code, le conteneur Docker et la surveillance, il doit avoir une idée du fonctionnement de l'architecture, du fonctionnement du code en production et de son intégration dans l'application. Ceux d'entre vous qui travaillent en tant qu'administrateurs système ou ingénieurs d'infrastructure, réfléchissent à la manière de transmettre ces connaissances aux développeurs. Votre tâche consiste à leur en parler. Vous pouvez embaucher des consultants, mais mieux par vous-même.

Ingénieur Infrastructure

Le rôle suivant de DevOps est l'ingénieur en infrastructure, anciennement appelé administrateur système. Je n'aime pas du tout le terme «ingénieur DevOps» car DevOps est une pratique courante qui couvre le développement, les tests et l'exploitation. Comme je l'ai dit plus tôt, vous pouvez avoir un ingénieur DevOps, une équipe DevOps, la meilleure technologie, et vous n'avez pas DevOps.

Un ingénieur en infrastructure crée une plate-forme principalement pour le développement de produits, mais cela devrait être pratique pour les développeurs. Cet équilibre doit être essayé pour se conformer.
Un ingénieur en infrastructure utilise plusieurs couches d'abstraction pour fournir des services. Par exemple, il y avait un bon rapport de Nikolai Ryzhikov sur Kubernetes, il y a montré comment sélectionner et utiliser plusieurs couches d'abstraction. Il avait là un modèle idéal, qui est mis en pratique. Un tel modèle peut être découpé en différents niveaux d'abstraction. Ceci est fait pour réduire la complexité de la résolution de problèmes et de l'intégration. Lorsque vous avez des niveaux d'abstraction compréhensibles, vous pouvez basculer entre eux et voir où se trouvent les écarts. Vous n'avez pas à faire confiance aux couches d'abstraction, mais elles sont très utiles pour en parler. Autrement dit, ils ne devraient pas être un outil absolu, mais utile.

L'ingénieur en infrastructure conçoit la plate-forme en tant que produit, sait comment être propriétaire d'un produit, ce qu'est la pensée de conception, sait comment collecter les exigences des développeurs. Mais c'est un niveau élevé, et je ne suis pas sûr que de tels ingénieurs soient présents sur le marché sous la forme d'ingénieurs en infrastructure.

Technologue de test

Le testeur change également un peu et devient un technologue qui améliore la qualité des logiciels et transforme ce processus en code.

Release Manager / Service Station

, , . , , , .

, : , , .


, , , — . , delivery pipeline, , , .

, , , — ( ), . , — , , , , continuous delivery pipeline.

, . (- CTO) — . , — , , , .


Dans Express 42, nous appelons cette mise à niveau le concept de base-service-app. Il existe un certain niveau de base - le niveau d'orchestration (allocation) des ressources et des divers services d'infrastructure de bas niveau. Les ingénieurs d'infrastructure ont ici plus de connaissances et d'expérience. Il existe un niveau de service: différentes bases de données, équilibreurs de charge, surveillance, journalisation, moteurs CI (TeamCity comme moteur ou Jenkins comme moteur). Il existe un niveau d'application qui collecte ces niveaux ensemble à travers toutes sortes d'API, de fonctions, etc. Encore une fois, je me réfère au rapport de Nikolai Ryzhikov, il a parfaitement montré comment tout cela fonctionne ensemble et comment mettre en œuvre CI sur Kubernetes.


Les processus et les technologies sont cruciaux. Les technologies que vous utilisez, autres qu'eux-mêmes, ont un moyen de l'utiliser. Par exemple, vous pouvez couper du pain avec un couteau ou tuer une personne. Donc c'est ici, seulement dans notre cas c'est encore plus compliqué, encore plus de niveaux d'abstraction. Les processus que vous créez autour de cela sont très importants. Et ces processus, en principe, personne ne peut les créer sauf pour vous au sein de l'entreprise, car ils sont hautement adaptés à des applications spécifiques. Maintenant, en principe, il est impossible que, comme auparavant, vous ayez engagé un consultant ITIL, et il ait mis en place tous les processus pour vous. L'application Internet Banking et Yandex.Music sont différentes comme le ciel et la terre. Il existe des principes généraux, mais le processus lui-même est complètement différent.

, . , - : « , — » .
, , , ( , , ). C'est très important.

, DevOps, , , , , (Kubernetes, Prometheus, Docker . .), , .

, DevOps- . , , , . , continuous delivery, — , , . , , , . , , , « ». , .

- , , . 3-4 , , .

, DevOops 2018 : , . 14 , .