{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"Les ing\u00e9nieurs DevOps n'existent pas. Qui existe alors et que faire avec \u00e7a ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Les<\/p>\n

<\/p>\n

R\u00e9cemment, de telles annonces ont envahi Internet. Malgr\u00e9 un salaire attractif, il est difficile de ne pas \u00eatre troubl\u00e9 par le fait qu'elles contiennent des absurdit\u00e9s flagrantes. Au d\u00e9part, on suppose qu'il est possible de combiner \u00ab DevOps \u00bb et \u00ab ing\u00e9nieur \u00bb en un seul mot, et ensuite vient une liste al\u00e9atoire d'exigences, dont une partie semble clairement copi\u00e9e depuis une annonce pour administrateur syst\u00e8me.<\/p>\n

<\/p>\n

Dans ce post, nous souhaitons discuter de la mani\u00e8re dont nous en sommes arriv\u00e9s \u00e0 cette situation, ce qu'est r\u00e9ellement DevOps et comment proc\u00e9der d\u00e9sormais.<\/p>\n

<\/p>\n

Ces annonces de travail peuvent \u00eatre critiqu\u00e9es sous toutes les coutures, mais le fait est qu'il y en a beaucoup, et c'est ainsi que le march\u00e9 fonctionne actuellement. Nous avons organis\u00e9 une conf\u00e9rence DevOps et d\u00e9clarons ouvertement : \u00abDevOops<\/a><\/noindex> \u2014 ce n'est pas pour les ing\u00e9nieurs DevOps \u00bb. Beaucoup trouveront cela \u00e9trange et absurde : pourquoi des personnes organisant un \u00e9v\u00e9nement commercial s'opposent-elles au march\u00e9 ? Nous allons tout expliquer maintenant.<\/p>\n

<\/a><\/noindex><\/p>\n

Sur la culture et les processus<\/h2>\n

<\/p>\n

Commencez par comprendre que DevOps n'est pas une discipline d'ing\u00e9nierie. Tout a commenc\u00e9 par le fait que la division historique des r\u00f4les ne fonctionne pas pour la qualit\u00e9 des produits. Lorsque les programmeurs se contentent de coder sans vouloir entendre parler de tests, le logiciel est bourr\u00e9 de bogues. Lorsque les administrateurs se moquent de la fa\u00e7on et des raisons pour lesquelles le logiciel est \u00e9crit, le support devient un v\u00e9ritable enfer. <\/p>\n

<\/p>\n

Par exemple, la diff\u00e9rence entre l'approche d'administration syst\u00e8me et celle de SRE en mati\u00e8re de gestion de service commence avec le c\u00e9l\u00e8bre livre Google SRE<\/a><\/noindex>. Des recherches int\u00e9ressantes ont \u00e9t\u00e9 men\u00e9es dans le cadre de l'enqu\u00eate DORA<\/a><\/noindex> \u2014 il est \u00e9vident que les meilleurs d\u00e9veloppeurs parviennent d'une mani\u00e8re ou d'une autre \u00e0 d\u00e9ployer de nouveaux changements en production plus d'une fois par heure. Ils effectuent \u00e9galement des tests manuels pas plus de 10% du temps (comme on le voit dans le DORA de l'ann\u00e9e derni\u00e8re<\/a><\/noindex>). Comment y parviennent-ils ? \u00ab Excel or die \u00bb \u2013 dit l'un des titres du rapport. Pour une discussion plus d\u00e9taill\u00e9e de ces statistiques en mati\u00e8re de tests, vous pouvez vous r\u00e9f\u00e9rer au keynote de Baruch Sadogursky \u00ab Nous avons DevOps. Licencions tous les testeurs \u00bb<\/a><\/noindex> lors d'une autre de nos conf\u00e9rences, Heisenbug.<\/p>\n

<\/p>\n

\u00ab Quand il n'y a pas d'accord entre les camarades,
\nLeurs affaires ne progresseront pas,
\nEt il ne sortira de l\u00e0 rien de bon, juste de la souffrance.
\nUn jour, le Cygne, le Crabe et le Brochet\u2026 \u00bb<\/p><\/blockquote>\n

Que pensez-vous, quelle partie des d\u00e9veloppeurs web comprend vraiment dans quelles conditions leurs applications fonctionnent en production ? Combien d'entre eux iront voir les administrateurs pour essayer de comprendre ce qui se passera en cas de chute de la base de donn\u00e9es ? Qui d'entre eux se rendra chez les testeurs et demandera \u00e0 apprendre \u00e0 \u00e9crire des tests correctement ? Et il y a aussi des sp\u00e9cialistes de la s\u00e9curit\u00e9, des chefs de produits, et une foule d'autres personnes.<\/p>\n

<\/p>\n

L'id\u00e9e g\u00e9n\u00e9rale de DevOps est d'\u00e9tablir une interaction entre les r\u00f4les et les d\u00e9partements. Cela se r\u00e9alise principalement non pas avec un logiciel r\u00e9gl\u00e9 de mani\u00e8re astucieuse, mais par la pratique de la communication. DevOps concerne la culture, la pratique, la m\u00e9thodologie et les processus. Il n'existe pas de sp\u00e9cialit\u00e9 d'ing\u00e9nieur qui r\u00e9ponde \u00e0 ces questions.<\/p>\n

<\/p>\n

Cercle vicieux<\/h2>\n

<\/p>\n

D'o\u00f9 vient alors la discipline \u00ab ing\u00e9nierie DevOps \u00bb ? Nous avons une th\u00e9orie ! Les id\u00e9es de DevOps se sont r\u00e9v\u00e9l\u00e9es si bonnes qu'elles sont devenues victimes de leur succ\u00e8s. Autour de ce sujet, des recruteurs douteux et des marchands de personnes se sont regroup\u00e9s, cr\u00e9ant une atmosph\u00e8re bien \u00e0 eux.<\/p>\n

<\/p>\n

Imaginez : hier, vous faisiez des shawarmas \u00e0 Khimki, et aujourd'hui \u2014 vous \u00eates d\u00e9j\u00e0 une personne importante, un recruteur senior. Il y a tout un processus de recherche et de s\u00e9lection des candidats, tout cela n'est pas simple, il faut comprendre. Supposons que le chef de d\u00e9partement dit : trouve un sp\u00e9cialiste en X. On ajoute au mot X le mot \u00ab ing\u00e9nieur \u00bb, et le tour est jou\u00e9. Besoin de Linux ? Eh bien, c'est certainement un ing\u00e9nieur Linux, si vous voulez DevOps \u2014 un ing\u00e9nieur DevOps. Une offre d'emploi ne se compose pas seulement d'un titre, mais \u00e0 l'int\u00e9rieur, il faut inscrire un certain texte. Le plus simple est d'inscrire un ensemble de mots-cl\u00e9s de Google, selon l'imagination de chacun. DevOps se compose de deux mots \u2014 \u00ab Dev \u00bb et \u00ab Ops \u00bb, donc, il faut rassembler des mots-cl\u00e9s li\u00e9s aux d\u00e9veloppeurs et aux administrateurs, tous ensemble. Ainsi apparaissent des offres d'emploi mentionnant la ma\u00eetrise de 42 langages de programmation et 20 ans d'utilisation de Kubernetes et Swarm simultan\u00e9ment. C'est une approche habituelle.<\/p>\n

<\/p>\n

Ainsi, dans l'esprit des gens s'est enracin\u00e9e l'image absurde et impitoyable d'un super-h\u00e9ros DevOps, qui configurera tous les d\u00e9ploiements sur Jenkins, et ce sera le bonheur. Ah, si tout \u00e9tait si simple. \u00ab Et en plus, on peut chasser des admins syst\u00e8mes, pense le recruteur, c'est \u00e0 la mode, les mots-cl\u00e9s sont les m\u00eames, ils devraient mordre. \u00bb<\/p>\n

<\/p>\n

La demande cr\u00e9e l'offre, et toutes ces offres douteuses ont attir\u00e9 un nombre fou d'administrateurs syst\u00e8me qui ont compris qu'ils pouvaient faire exactement la m\u00eame chose qu'auparavant, mais en \u00e9tant pay\u00e9s plusieurs fois plus, sous le nom de \u00ab devops \u00bb. Comme tu configurais des serveurs via SSH un par un, tu continueras \u00e0 le faire, mais cela s'appelle apparemment maintenant une pratique devops. C'est un ph\u00e9nom\u00e8ne complexe, en partie li\u00e9 \u00e0 la sous-estimation des admins classiques et au ph\u00e9nom\u00e8ne entourant DevOps, mais au final \u2014 ce qui est fait, est fait.<\/p>\n

<\/p>\n

Nous avons donc la demande et l'offre. Un cercle vicieux qui se nourrit de lui-m\u00eame. C'est ce avec quoi nous luttons (y compris en cr\u00e9ant la conf\u00e9rence DevOops).<\/p>\n

<\/p>\n

Bien s\u00fbr, en plus des administrateurs syst\u00e8me qui se sont rebaptis\u00e9s en \u00ab devops \u00bb, il y a d'autres participants \u2014 par exemple, des SRE professionnels ou des d\u00e9veloppeurs d'Infrastructure-as-Code.<\/p>\n

<\/p>\n

Que font les gens en DevOps (r\u00e9ellement)<\/h2>\n

<\/p>\n

Alors, vous voulez progresser dans l'apprentissage et l'application des pratiques DevOps. Mais comment faire, dans quelle direction regarder ? \u00c9videmment, il ne faut pas se fier aveugl\u00e9ment aux mots-cl\u00e9s populaires.<\/p>\n

<\/p>\n

S'il y a du travail, quelqu'un doit s'en occuper. Nous avons d\u00e9j\u00e0 \u00e9tabli que ce ne sont pas des \u00ab ing\u00e9nieurs devops \u00bb, alors qui ? Il semble plus appropri\u00e9 de le formuler non pas en termes de postes, mais en termes de domaines de travail sp\u00e9cifiques.<\/p>\n

<\/p>\n

Tout d'abord, vous pouvez vous occuper du c\u0153ur m\u00eame de DevOps \u2014 les processus et la culture. La culture est une affaire de longue haleine et difficile, et bien que cela soit traditionnellement de la responsabilit\u00e9 des dirigeants, d'une mani\u00e8re ou d'une autre, tout le monde participe \u00e0 cela, des programmeurs aux admins. Il y a quelques mois, Tim Lister a d\u00e9clar\u00e9 dans une interview<\/a><\/noindex>:<\/p>\n

<\/p>\n

\u00ab La culture est d\u00e9termin\u00e9e par les valeurs fondamentales de l'organisation. Les gens ne s'en rendent g\u00e9n\u00e9ralement pas compte, mais nous, travaillant en consulting depuis de nombreuses ann\u00e9es, avons appris \u00e0 le remarquer. Vous entrez dans une entreprise et litt\u00e9ralement au bout de quelques minutes, vous commencez \u00e0 ressentir ce qui se passe. Nous appelons cela l'\u00ab ar\u00f4me \u00bb. Parfois, cet ar\u00f4me est vraiment bon. Parfois, il provoque des naus\u00e9es. (\u2026) Vous ne pouvez pas changer la culture tant que les valeurs et les croyances qui sous-tendent des actions sp\u00e9cifiques n'ont pas \u00e9t\u00e9 prises en compte. Le comportement est facile \u00e0 observer, mais trouver les croyances est difficile. DevOps est justement un excellent exemple de la mani\u00e8re dont tout devient de plus en plus compliqu\u00e9. \u00bb<\/p><\/blockquote>\n

Il y a forc\u00e9ment un aspect technique \u00e0 la question. Si ton nouveau code arrive en test dans un mois et n\u2019est publi\u00e9 que dans un an, et qu'il est physiquement impossible d\u2019acc\u00e9l\u00e9rer tout cela, tu risques de ne jamais atteindre de bonnes pratiques. Les bonnes pratiques sont soutenues par de bons outils. Par exemple, en gardant \u00e0 l\u2019esprit l\u2019id\u00e9e d\u2019Infrastructure-as-Code, on peut utiliser n\u2019importe quoi, d\u2019AWS CloudFormation et Terraform \u00e0 Chef-Ansible-Puppet. Il faut tout cela conna\u00eetre et ma\u00eetriser, et cela constitue d\u00e9j\u00e0 une v\u00e9ritable discipline d\u2019ing\u00e9nierie. Il est important de ne pas confondre la cause et les cons\u00e9quences : d'abord, vous travaillez selon les principes SRE et ensuite seulement vous incarnez ces principes sous forme de solutions techniques concr\u00e8tes. Par ailleurs, le SRE est une m\u00e9thodologie tr\u00e8s complexe qui ne parle pas de comment configurer Jenkins, mais de cinq principes fondamentaux :<\/p>\n

<\/p>\n