{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Qui sont les DevOps ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Actuellement, c'est sans doute la position la plus ch\u00e8re sur le march\u00e9. Le battage autour des ing\u00e9nieurs «DevOps» d\u00e9passe toutes les limites imaginables, et c'est encore plus vrai pour les ing\u00e9nieurs Senior DevOps.
\nJe suis responsable du d\u00e9partement d'int\u00e9gration et d'automatisation, devinez l'acronyme anglais \u2014 DevOps Manager. L'acronyme anglais refl\u00e8te-t-il vraiment notre activit\u00e9 quotidienne ? Probablement pas, tandis que la version russe est ici plus pr\u00e9cise. De par ma fonction, il est naturel que je doive interviewer les futurs membres de mon \u00e9quipe et, au cours de l'ann\u00e9e \u00e9coul\u00e9e, environ 50 personnes sont pass\u00e9es par mes soins, autant ont \u00e9t\u00e9 \u00e9cart\u00e9es lors de pr\u00e9s\u00e9lections avec mes employ\u00e9s.<\/p>\n

<\/p>\n

Nous sommes toujours \u00e0 la recherche de coll\u00e8gues, car derri\u00e8re le label DevOps se cache une tr\u00e8s grande diversit\u00e9 d'ing\u00e9nieurs.<\/a><\/noindex><\/p>\n

<\/p>\n

Tout ce qui est \u00e9crit ci-dessous est mon opinion personnelle, vous n'avez pas \u00e0 \u00eatre d'accord avec moi, mais je suppose que cela apportera une nuance \u00e0 votre perspective sur le sujet. En d\u00e9pit du risque de d\u00e9plaire, je publie mon opinion, car je pense qu'elle m\u00e9rite d'\u00eatre exprim\u00e9e.<\/p>\n

<\/p>\n

Les entreprises ont des compr\u00e9hensions diff\u00e9rentes de ce que sont les ing\u00e9nieurs DevOps et, pour embaucher rapidement des ressources, elles attribuent ce label \u00e0 tout le monde. La situation est assez \u00e9trange, car les entreprises sont pr\u00eates \u00e0 payer des sommes exorbitantes \u00e0 ces personnes, en obtenant dans la plupart des cas, un administrateur-outil.<\/p>\n

<\/p>\n

Alors, qui sont vraiment les ing\u00e9nieurs DevOps ?<\/h2>\n

<\/p>\n

Commen\u00e7ons par l'histoire de son apparition \u2014 les Operations de d\u00e9veloppement (DevOps) sont devenues une \u00e9tape suppl\u00e9mentaire pour optimiser la collaboration au sein des petites \u00e9quipes afin d'acc\u00e9l\u00e9rer la production de produits, comme en \u00e9tait l'attente. L'id\u00e9e \u00e9tait de renforcer l'\u00e9quipe de d\u00e9veloppement avec des connaissances sur les proc\u00e9dures et approches de gestion de l'environnement produit. En d'autres termes, un d\u00e9veloppeur doit comprendre et savoir comment son produit fonctionne dans diff\u00e9rentes conditions, savoir comment d\u00e9ployer son produit et quelles caract\u00e9ristiques de l'environnement ajuster pour am\u00e9liorer la performance. Ainsi, au fil du temps, des d\u00e9veloppeurs ayant une approche DevOps ont vu le jour. Les d\u00e9veloppeurs DevOps \u00e9crivaient des scripts de construction et de packaging pour simplifier leur travail et la fonctionnalit\u00e9 de l'environnement de production. Cependant, la complexit\u00e9 architecturale des solutions et l'interaction mutuelle des composants d'infrastructure ont commenc\u00e9 \u00e0 d\u00e9t\u00e9riorer les performances des environnements au fil du temps, n\u00e9cessitant une compr\u00e9hension de plus en plus approfondie de certains composants \u00e0 chaque it\u00e9ration, ce qui a diminu\u00e9 la productivit\u00e9 m\u00eame du d\u00e9veloppeur en raison des efforts suppl\u00e9mentaires requis pour comprendre les composants et peaufiner les syst\u00e8mes pour des t\u00e2ches sp\u00e9cifiques. Le co\u00fbt associ\u00e9 \u00e0 un d\u00e9veloppeur a augment\u00e9, le co\u00fbt du produit avec lui, et les exigences envers les nouveaux d\u00e9veloppeurs au sein de l'\u00e9quipe ont fortement augment\u00e9, \u00e9tant donn\u00e9 qu'ils devaient aussi couvrir les responsabilit\u00e9s de la \u00ab star \u00bb du d\u00e9veloppement, devenant de plus en plus rares et moins accessibles. Il convient \u00e9galement de noter que, d'apr\u00e8s mon exp\u00e9rience, peu de d\u00e9veloppeurs s'int\u00e9ressent \u00e0 la sp\u00e9cificit\u00e9 du traitement des paquets par le noyau du syst\u00e8me d'exploitation, aux r\u00e8gles de routage des paquets, ou aux aspects de s\u00e9curit\u00e9 de l'h\u00f4te. Il \u00e9tait donc logique de faire appel \u00e0 un administrateur, qui conna\u00eet bien ces sujets, et de lui assigner ces responsabilit\u00e9s, gr\u00e2ce \u00e0 son exp\u00e9rience permettant d'atteindre les m\u00eames r\u00e9sultats \u00e0 un co\u00fbt moindre par rapport \u00e0 celui d'une \u00ab star \u00bb du d\u00e9veloppement. Ces administrateurs \u00e9taient int\u00e9gr\u00e9s dans l'\u00e9quipe et leur t\u00e2che principale \u00e9tait de g\u00e9rer les environnements de test et de production, suivant les r\u00e8gles de l'\u00e9quipe sp\u00e9cifique, avec des ressources allou\u00e9es \u00e0 cette \u00e9quipe. C'est ainsi que les DevOps ont \u00e9t\u00e9 per\u00e7us par la majorit\u00e9.<\/p>\n

<\/p>\n

Partiellement ou totalement, au fil du temps, les administrateurs syst\u00e8mes ont commenc\u00e9 \u00e0 comprendre les besoins de cette \u00e9quipe sp\u00e9cifique en mati\u00e8re de d\u00e9veloppement, comment simplifier la vie des d\u00e9veloppeurs et des testeurs, comment d\u00e9ployer une mise \u00e0 jour sans passer la nuit au bureau \u00e0 corriger des erreurs de d\u00e9ploiement. Le temps a pass\u00e9, et maintenant, les \u00ab stars \u00bb sont devenus les administrateurs syst\u00e8mes qui comprennent ce que les d\u00e9veloppeurs d\u00e9sirent. Dans un souci de minimiser l'impact, des outils de gestion ont commenc\u00e9 \u00e0 appara\u00eetre, et tous se sont rappel\u00e9s de ces anciennes m\u00e9thodes fiables d'isolation au niveau du syst\u00e8me d'exploitation, permettant de minimiser les exigences en mati\u00e8re de s\u00e9curit\u00e9, de gestion r\u00e9seau et de configuration de l'h\u00f4te dans son ensemble, et par cons\u00e9quent, de r\u00e9duire les exigences pour les nouvelles \u00ab stars \u00bb. <\/p>\n

<\/p>\n

Une chose \u00ab merveilleuse \u00bb est apparue : Docker. Pourquoi merveilleuse ? Tout simplement parce que cr\u00e9er une isolation dans un chroot ou un jail, tout comme OpenVZ, n\u00e9cessitait des connaissances non triviales du syst\u00e8me d'exploitation, tandis que l'outil permettant de cr\u00e9er simplement un environnement isol\u00e9 d'application sur un h\u00f4te avec tout le n\u00e9cessaire \u00e0 l'int\u00e9rieur, et de transf\u00e9rer la direction aux d\u00e9veloppeurs, permettait \u00e0 l'administrateur syst\u00e8me de ne g\u00e9rer qu'un seul h\u00f4te, garantissant sa s\u00e9curit\u00e9 et sa haute disponibilit\u00e9 \u2014 une simplification logique. Mais le progr\u00e8s ne s'arr\u00eate pas, et les syst\u00e8mes deviennent de plus en plus complexes, avec de plus en plus de composants, un seul h\u00f4te ne satisfait plus les besoins du syst\u00e8me et il devient n\u00e9cessaire de construire des clusters, nous revenons alors aux administrateurs syst\u00e8mes capables de b\u00e2tir ces syst\u00e8mes.<\/p>\n

<\/p>\n

Cycle apr\u00e8s cycle, diverses syst\u00e8mes apparaissent pour simplifier le d\u00e9veloppement et\/ou l'administration, des syst\u00e8mes d'orchestration \u00e9mergent qui, tant que l'on reste dans le processus standard, sont simples \u00e0 utiliser. L'architecture microservices est \u00e9galement apparue pour simplifier tout ce qui a \u00e9t\u00e9 d\u00e9crit ci-dessus \u2014 moins d'interconnexions, plus facile \u00e0 g\u00e9rer. Dans mon exp\u00e9rience, je n'ai pas v\u00e9cu une architecture microservices compl\u00e8te, je dirais 50-50 : 50 % de microservices, des bo\u00eetes noires, ce qui est entr\u00e9, est sorti transform\u00e9, et les 50 % restants \u2014 un monolithe d\u00e9chir\u00e9, des services incapables de fonctionner ind\u00e9pendamment des autres composants. Tout cela a de nouveau impos\u00e9 des limites au niveau de connaissances tant pour les d\u00e9veloppeurs que pour les administrateurs.<\/p>\n

<\/p>\n

Ces \u00ab balancements \u00bb de niveau expert concernant telle ou telle ressource se poursuivent encore aujourd'hui. Mais nous nous sommes un peu \u00e9cart\u00e9s, il y a de nombreux points \u00e0 \u00e9claircir.<\/p>\n

<\/p>\n

Ing\u00e9nieur Build \/ Ing\u00e9nieur Release<\/h2>\n

<\/p>\n

Des ing\u00e9nieurs tr\u00e8s sp\u00e9cialis\u00e9s, apparus comme moyen de standardiser les processus de construction et de publication de logiciels. Avec l'av\u00e8nement g\u00e9n\u00e9ralis\u00e9 de l'Agile, on aurait pu penser qu'ils avaient perdu de leur pertinence, mais c'est tout le contraire. Cette sp\u00e9cialisation est n\u00e9e comme un moyen de standardiser la construction et la livraison de logiciels \u00e0 grande \u00e9chelle, c'est-\u00e0-dire en utilisant des techniques standards pour tous les produits de l'entreprise. Avec l'\u00e9mergence de DevOps, les d\u00e9veloppeurs ont partiellement perdu certaines fonctions, car ce sont maintenant eux qui pr\u00e9parent le produit pour la livraison. Consid\u00e9rant l'infrastructure en \u00e9volution et l'approche visant une livraison rapide sans se soucier de la qualit\u00e9, ils se sont finalement transform\u00e9s en un frein \u00e0 l'\u00e9volution, car le respect des normes de qualit\u00e9 ralentit in\u00e9vitablement les livraisons. Ainsi, progressivement, une partie des fonctions des ing\u00e9nieurs Build\/Release a \u00e9t\u00e9 transf\u00e9r\u00e9e aux administrateurs syst\u00e8me.<\/p>\n

<\/p>\n

Les Ops sont si diff\u00e9rents<\/h2>\n

<\/p>\n

Nous avan\u00e7ons et encore une fois, la multitude de responsabilit\u00e9s et le manque de personnel qualifi\u00e9 nous poussent vers une sp\u00e9cialisation stricte, comme des champignons apr\u00e8s la pluie, divers Operations \u00e9mergent :<\/p>\n

<\/p>\n