Smashing Podcast Épisode 42 Avec Jeff Smith : Qu'est-ce que DevOps ?

Dans cet épisode, nous parlons de DevOps. Qu'est-ce que c'est, et est-ce une corde à ajouter à votre arc de développement web ? Drew McLellan parle à l'expert Jeff Smith pour le savoir.

Afficher les remarques

• Jeff sur Twitter
• Livre de Jeff Operations Anti-Patterns, DevOps Solutions
• DevOps accessible

Mise à jour hebdomadaire

• Combler le fossé entre les concepteurs et les développeurs écrit par Matthew Talebi
• API React utiles pour créer des composants flexibles avec TypeScript écrits par Gaurav Khanna
• Solutions CSS intelligentes pour les défis d'interface utilisateur courants écrits par Cosima Mielke
• Trucs et astuces pour évaluer les concepteurs UX/UI écrits par Nataliya Sambir
• Résoudre les problèmes CLS dans un site Web de commerce électronique alimenté par Next.js écrit par Arijit Mondal

Transcription

Drew McLellan : C'est un praticien DevOps qui se concentre sur les niveaux atteignables d'implémentations DevOps, peu importe où vous en êtes dans votre parcours. Il est directeur des opérations de production sur la plateforme de publicité numérique Centro, en plus d'être un conférencier public, partageant ses connaissances DevOps avec des publics du monde entier. Il est l'auteur du livre, Operations Anti-Patterns, DevOps Solutions for Manning Publishing, qui montre comment mettre en œuvre des techniques DevOps dans le type d'environnements imparfaits dans lesquels travaillent la plupart des développeurs. Nous savons donc qu'il est un expert en DevOps, mais saviez-vous que George Clooney le considère comme le meilleur fabricant d'avions en papier d'une génération ? Mes amis Smashing, veuillez accueillir Jeff Smith. Salut Jef. Comment vas-tu?

Jeff Smith : Je vais bien, Drew, comment ça va ?

Drew : Je vais bien. Merci. Ça fait plaisir à entendre. Je voulais donc vous parler aujourd'hui du sujet de DevOps, qui est l'un de vos principaux domaines clés. Beaucoup de nos auditeurs seront impliqués dans le développement Web et d'applications, mais n'auront peut-être qu'une vague connaissance de ce qui se passe du côté des opérations. Je sais que ceux d'entre nous qui pourraient travailler dans de grandes entreprises auront des équipes entières de collègues qui font des opérations. Nous sommes simplement reconnaissants que quoi qu'ils fassent, ils le font bien. Mais nous entendons de plus en plus parler de DevOps, et cela ressemble à l'une de ces choses qu'en tant que développeurs, nous devrions vraiment comprendre. Alors Jeff, qu'est-ce que DevOps ?

Jeff : Donc, si vous demandez à 20 personnes ce qu'est DevOps, vous pourriez obtenir 20 réponses différentes. Je vais donc vous donner mon point de vue, d'accord, et sachez que si vous êtes à une conférence et que vous mentionnez cela, vous pourriez vous battre avec quelqu'un. Mais pour moi, DevOps concerne vraiment cette relation entre, et nous nous concentrons sur le développement et les opérations, mais vraiment cette relation inter-équipes et la manière dont nous structurons notre travail et, plus important encore, structurons nos objectifs et nos incitations pour nous assurer qu'ils sont alignés afin que nous travaillions vers un objectif commun. Et beaucoup d'idées et de concepts fondamentaux de DevOps viennent de l'ancien monde où le développement et les opérations étaient toujours antagonistes, où il y avait ce conflit constant. Et quand on y pense, c'est à cause de la façon dont ces deux équipes sont incitées. Une équipe est incitée à pousser les changements. Une autre équipe est incitée à maintenir la stabilité, ce qui signifie moins de changements.

Jeff : Lorsque vous faites cela, vous créez ce conflit inhérent et tout se déverse à partir de là. Donc, DevOps consiste vraiment à aligner ces équipes et ces objectifs afin que nous travaillions vers une stratégie commune, mais aussi à adopter des pratiques des deux côtés, afin que les développeurs comprennent mieux les opérations et les opérations comprennent mieux les développeurs, comme un moyen de gagner et de partager empathie les uns avec les autres afin que nous comprenions la perspective d'où vient l'autre personne.

Jeff : Mais aussi pour valoriser notre travail. Parce qu'encore une fois, si je comprends votre point de vue et que j'en tiens compte dans mon travail, ce sera beaucoup plus bénéfique pour chacun de nous. Et les opérations peuvent apprendre beaucoup des développeurs en termes d'automatisation et de la façon dont nous abordons les choses pour qu'elles soient facilement reproductibles. C'est donc ce mélange et ces compétences. Et ce que vous voyez maintenant, c'est que cela s'applique à différentes combinaisons de groupes, vous entendez donc des choses comme DevSecOps, DevSecFinOps, DevSecFinHROps. Il va juste continuer à grandir et grandir et grandir. C'est donc vraiment une leçon que nous pouvons appliquer à toute l'organisation.

Drew : Il s'agit donc de prendre certains des concepts que nous comprenons en tant que développeurs et de diffuser nos idées plus loin dans l'organisation, et en même temps d'apprendre ce que nous pouvons des opérations pour essayer de faire avancer tout le monde.

Jeff : Absolument, oui. Et un autre aspect des opérations, et vous l'avez mentionné un peu dans l'intro, c'est que nous pensons que c'est juste pour ces grandes organisations avec des équipes d'opérations dédiées et des choses comme ça, mais une chose à laquelle il faut penser est que les opérations se déroulent dans votre organisation, quelle que soit la taille. C'est juste une question de savoir si c'est vous qui le faites, ou s'il y a une équipe distincte qui le fait, mais d'une manière ou d'une autre, vous déployez du code. D'une manière ou d'une autre, vous avez un serveur qui fonctionne quelque part. Les opérations existent donc quelque part dans votre organisation, quelle que soit leur taille. La question est, qui le fait ? Et s'il s'agit d'une seule personne ou d'un seul groupe, DevOps pourrait même être encore plus important pour vous, car vous devez comprendre les types de choses que font les ops.

Drew : En tant que développeurs professionnels, à quel point pensez-vous qu'il est important pour nous d'avoir une bonne compréhension de ce qu'est DevOps et de ce que cela signifie de mettre en œuvre ?

Jeff : Je pense que c'est super important, surtout à cette phase du parcours DevOps. Et la raison pour laquelle je pense que c'est important, c'est que je pense que nous sommes toujours plus efficaces, encore une fois, lorsque nous comprenons ce que font nos homologues. Mais l'autre chose est de pouvoir prendre en compte les préoccupations opérationnelles lors de votre développement de conception et de la mise en œuvre de toute technologie. Donc, une chose que j'ai apprise dans ma carrière, c'est que même si je pensais que les développeurs étaient les maîtres de l'univers et comprenaient tout ce qui concernait les ordinateurs, il s'avère que ce n'est pas le cas. Il s'avère qu'il y a beaucoup de choses qu'ils sous-traitent aux opérations en termes de compréhension, et cela se traduit parfois par des choix de conception ou des choix de mise en œuvre particuliers qui peuvent ne pas être optimaux pour un déploiement de production.

Jeff : Ils pourraient être bons dans le développement et les tests et des choses comme ça, mais une fois que vous arrivez à la production, c'est un peu un jeu de balle différent. Donc, cela ne veut pas dire qu'ils doivent posséder tout cet ensemble d'expertise, mais ils doivent au moins en savoir suffisamment pour savoir ce qu'ils ne savent pas. Ils savent donc quand engager les opérations tôt, car c'est un schéma courant que nous voyons, c'est que le développement fait un choix. Je ne dirai même pas faire un choix parce qu'ils ne savent même pas que c'est un choix, mais il se passe quelque chose qui conduit à une décision sous-optimale pour les opérations et le développement n'en était absolument pas conscient. Donc, avoir juste un peu plus de connaissances sur les opérations, même si c'est juste assez pour dire, peut-être devrions-nous faire participer les opérations à ce sujet pour avoir leur point de vue avant d'aller de l'avant. Cela pourrait économiser beaucoup de temps, d'énergie et de stabilité, évidemment, en ce qui concerne les produits que vous lancez.

Drew : Je vois tellement de parallèles avec la façon dont vous parlez de la relation entre le développement et les opérations comme nous l'avons entre la conception et le développement, où vous avez des concepteurs qui travaillent peut-être sur le fonctionnement et l'apparence d'une interface et qui ont une bonne compréhension de la façon dont cela va réellement être intégré dans le rôle de développement, et amener les développeurs à se consulter peut vraiment améliorer la solution globale simplement en ayant cette communication claire et une compréhension de ce que font les autres. On dirait que c'est le même principe qui s'est joué avec DevOps, ce qui est vraiment, vraiment bon à entendre.

Drew : Quand je pense à tout ce que j'entends à propos de DevOps, j'entends des termes comme Kubernetes, Docker, Jenkins, CircleCI. J'entends parler de Kubernetes depuis des années. Je n'ai toujours aucune idée de ce que c'est, mais d'après ce que vous dites, il semble que DevOps ne se limite pas à… Nous ne parlons pas seulement d'outils ici, n'est-ce pas ? Mais en savoir plus sur les processus et les moyens de communiquer sur les flux de travail, n'est-ce pas ?

Jef : Absolument. Donc, mon mantra des 20 dernières années a toujours été les outils de traitement des personnes. Vous amenez les gens à adhérer à la vision. À partir de là, vous définissez à quoi ressemblera votre processus pour réaliser cette vision. Et puis vous apportez des outils qui vont modéliser quel que soit votre processus. Donc, je place toujours les outils à la fin de la conversation DevOps, principalement parce que si vous n'avez pas cette adhésion, cela n'a pas d'importance. Je pourrais proposer le plus grand pipeline de déploiement continu de tous les temps, mais si les gens ne sont pas convaincus par l'idée d'envoyer chaque modification directement à la production, cela n'a pas d'importance, n'est-ce pas ? A quoi bon l'outil ? Donc, ces outils font définitivement partie de la conversation, uniquement parce qu'ils sont un moyen standardisé d'atteindre certains objectifs communs que nous avons définis.

Jeff : Mais vous devez vous assurer que les objectifs définis sont cohérents pour votre organisation. Peut-être que le déploiement continu n'a pas de sens pour vous. Peut-être que vous ne voulez pas expédier chaque changement à la minute où il sort. Et il y a beaucoup d'entreprises et d'organisations et de raisons pour lesquelles vous ne voudriez pas le faire. Alors peut-être que quelque chose comme un pipeline de déploiement continu n'a pas de sens pour vous. Ainsi, bien que les outils soient importants, il est plus important de se concentrer sur ce qui apportera de la valeur à votre organisation, puis de modéliser et de mettre en œuvre les outils nécessaires pour y parvenir.

Jeff : Mais n'allez pas en ligne et découvrez ce que tout le monde fait et dites, oh, eh bien, si nous allons faire du DevOps, nous devons passer à Docker et Kubernetes parce que c'est la chaîne d'outils. Non ce n'est pas ça. Vous n'aurez peut-être pas besoin de ces choses. Tout le monde n'est pas Google. Tout le monde n'est pas Netflix. Arrêtez de lire les messages de Netflix et Google. S'il vous plaît, arrêtez simplement de les lire. Parce que ça excite les gens et ils se disent, eh bien, c'est ce que nous devons faire. Et c'est comme, eh bien, ils résolvent des problèmes très différents des problèmes que vous avez.

Drew : Donc, si je démarre un nouveau projet, je suis peut-être une start-up, créant un logiciel en tant que produit de service. J'ai trois développeurs, j'ai un référentiel Git vide et j'ai des rêves d'introduction en bourse. Pour être entièrement dans une approche DevOps pour créer ce produit, quels sont les noms des éléments de base que je devrais avoir en place en termes de personnes et de processus et par où dois-je commencer ?

Jeff : Donc, dans votre exemple spécifique, le premier point par lequel je commencerais est de jouer le plus possible et d'utiliser quelque chose comme Heroku ou quelque chose à cet effet. Parce que vous êtes tellement enthousiasmé par tous ces trucs AWS, Docker, et en réalité, il est si difficile de créer un produit réussi. L'idée que vous vous concentrez sur la partie DevOps est comme, eh bien, je dirais externaliser autant de choses que possible jusqu'à ce que cela devienne réellement un point douloureux. Mais si vous êtes à ce point où vous dites d'accord, nous sommes prêts à prendre ce genre de choses en interne et nous sommes prêts à passer au niveau supérieur. Je dirais que le premier point de départ est, où sont vos points faibles ? quelles sont les choses qui vous causent des problèmes?

Jeff : Pour certaines personnes, c'est aussi simple que des tests automatisés. L'idée que nous devons exécuter des tests chaque fois que quelqu'un fait un commit, parce que parfois nous expédions des choses qui se font prendre par des tests unitaires que nous avons déjà écrits. Alors peut-être commencerez-vous par l'intégration continue. Peut-être que vos déploiements prennent des heures et qu'ils sont très manuels, alors c'est là que vous vous concentrez et vous dites, d'accord, de quelle automatisation avons-nous besoin pour pouvoir en faire une affaire d'un seul clic ? Mais je déteste prescrire un général, c'est par là que vous commencez, simplement parce que votre situation particulière et vos points douloureux particuliers vont être différents. Et le fait est que si c'est un point douloureux, il devrait vous crier dessus. Il devrait absolument vous crier dessus.

Jeff : Ça devrait être une de ces choses où quelqu'un dit, oh, qu'est-ce qui craint dans votre organisation ? Et ça devrait être comme, oh, je sais exactement ce que c'est. Donc, lorsque vous l'abordez de ce point de vue, je pense que les prochaines étapes deviennent assez évidentes pour vous en termes de ce que vous devez décompresser et commencer à travailler dans la boîte à outils DevOps. Et puis cela devient ces changements incrémentiels minimes qui ne cessent d'arriver et vous remarquez qu'à mesure que vous obtenez de nouvelles capacités, votre appétit pour les choses de qualité inférieure devient très faible. Donc vous partez du genre, oh ouais, les déploiements prennent trois heures et ça va. Vous y mettez des efforts et la prochaine chose que vous savez, dans trois semaines, vous vous dites, mec, je ne peux pas croire que le déploiement prend encore 30 minutes. Comment pouvons-nous réduire cela à partir de 30 minutes? Votre appétit devient insatiable pour l'amélioration. Donc, les choses sortent de là.

Drew : J'ai lu votre livre récent et il met en lumière ce que vous appelez les quatre piliers de DevOps. Et aucun d'entre eux n'est un outil, comme mentionné, mais il y a ces quatre principaux domaines d'intérêt, si vous voulez, pour DevOps. J'ai remarqué que le premier d'entre eux est la culture, j'ai été assez surpris par cela, d'abord, parce que je m'attendais à ce que vous parliez davantage d'outils et nous comprenons maintenant pourquoi, mais quand il s'agit de culture, cela semble tout simplement étrange chose à avoir au début. Il y a une base pour une approche technique. Comment la culture affecte-t-elle la réussite de la mise en œuvre de DevOps au sein d'une organisation ?

Drew : … à quel point la mise en œuvre de DevOps peut être réussie au sein d'une organisation.

Jeff : La culture est vraiment le fondement de tout quand on y pense. Et c'est important parce que la culture, et nous approfondissons cela un peu plus dans le livre, mais la culture prépare vraiment le terrain pour les normes au sein de l'organisation. Droit. Vous avez probablement été dans une entreprise où, si vous soumettez un PR sans test automatisé, ce n'est pas grave. Les gens l'acceptent et passent à autre chose.

Jeff : Mais il y a d'autres organisations où c'est un péché capital. Droit. Où si vous avez fait cela, c'est comme, « Whoa, es-tu fou ? Qu'est-ce que tu fais? Il n'y a pas de cas de test ici. Droit. C'est pourtant la culture. C'est la culture qui applique cette norme pour dire, "Ce n'est tout simplement pas ce que nous faisons."

Jeff : N'importe qui peut écrire un document qui dit que nous aurons des cas de test automatisés, mais la culture de l'organisation est ce qui applique ce mécanisme parmi les gens. Ce n'est qu'un petit exemple de la raison pour laquelle la culture est si importante. Si vous avez une organisation où la culture est une culture de peur, une culture de vengeance. C'est comme si vous faisiez une erreur, c'est un sacrilège. Droit. Cela équivaut à une trahison. Droit.

Jeff : Vous créez des comportements dans cette organisation qui sont défavorables à tout ce qui pourrait être risqué ou potentiellement échouer. Et cela finit par laisser beaucoup d'opportunités sur la table. Alors que si vous créez une culture qui embrasse l'apprentissage de l'échec, embrasse cette idée de sécurité psychologique, où les gens peuvent expérimenter. Et s'ils se trompent, ils peuvent trouver comment échouer en toute sécurité et réessayer. Vous obtenez une culture de l'expérimentation. Vous obtenez une organisation où les gens sont ouverts aux nouvelles idées.

Jeff : Je pense que nous avons tous été dans ces entreprises où c'est comme : « Eh bien, c'est comme ça que ça se passe. Et personne ne change cela. Droit. Vous ne voulez pas cela parce que le monde change constamment. C'est pourquoi nous plaçons la culture au premier plan, car bon nombre des comportements au sein d'une organisation existent à cause de la culture qui existe.

Jeff : Et le fait est que les acteurs culturels peuvent être bons ou mauvais. Droit. Ce qui est ironique, et nous en parlons aussi dans le livre, c'est qu'il ne faut pas autant de personnes que vous le pensez pour changer la culture organisationnelle. Droit. Parce que la plupart des gens, il y a des détracteurs, et puis il y a des partisans, et puis il y a des gardiens de clôture quand il s'agit de n'importe quel type de changement. Et la plupart des gens sont des gardiens de la clôture. Droit. Il suffit d'une poignée de supporters pour vraiment faire pencher la balance. Mais dans le même sens, il ne faut vraiment qu'une poignée de détracteurs pour faire pencher la balance non plus.

Jeff : C'est comme, il ne faut pas grand-chose pour changer la culture pour le mieux. Et si vous y mettez cette énergie, même sans être un cadre supérieur, vous pouvez vraiment influencer la culture de votre équipe, qui finit par influencer la culture de votre département, qui finit par influencer la culture de l'organisation.

Jeff : Vous pouvez effectuer ces changements culturels en tant que contributeur individuel, simplement en épousant ces idées et ces comportements à haute voix et en disant : "Ce sont les avantages que nous en retirons." C'est pourquoi je pense que la culture doit être à l'avant-plan, car il faut que tout le monde adhère à cette idée et ils doivent comprendre que, en tant qu'organisation, cela vaudra la peine et la soutiendra.

Drew : Ouais. Ça doit être un mode de vie, je suppose.

Jeff : Exactement.

Drew : Ouais. Je m'intéresse vraiment au domaine de l'automatisation car, tout au long de ma carrière, je n'ai jamais vu d'automatisation mise en place qui n'ait pas été bénéfique. Droit. Je veux dire, à part la chose étrange peut-être où quelque chose est automatisé et ça tourne mal. Généralement, lorsque vous prenez le temps de vous asseoir et d'automatiser quelque chose que vous avez fait manuellement, cela vous fait toujours gagner du temps et vous permet d'économiser de l'espace pour la tête, et c'est juste un poids sur vos épaules.

Drew : En adoptant une approche DevOps, quel genre de choses chercheriez-vous à automatiser dans vos flux de travail ? Et quels gains attendez-vous de cela plutôt que de terminer les choses manuellement ?

Jeff : En ce qui concerne l'automatisation, à votre avis, il y a très rarement un moment où l'automatisation n'a pas amélioré la vie. Droit. Le hic que les gens rencontrent est de trouver le temps de construire cette automatisation. Droit. Et généralement, dans mon travail actuel, pour nous, c'est en fait le but de la demande. Droit. Parce qu'à un moment donné, il faut se dire : « Je vais arrêter de faire ça manuellement et je vais l'automatiser.

Jeff : Et il se peut que ce soit le moment où vous recevez une demande où vous dites : « Vous savez quoi ? Cela va prendre deux semaines. Je sais que nous effectuons normalement le traitement en quelques heures, mais cela prendra deux semaines car c'est la demande qui est automatisée. » En termes d'identification de ce que vous automatisez. Chez Central, j'utilise le processus où, en gros, j'échantillonne tous les différents types de demandes reçues sur une période de quatre semaines, disons. Et je les classerais en travail planifié, travail non planifié, travail à valeur ajoutée, travail pénible. Labeur étant un travail qui n'est pas vraiment utile, mais pour une raison quelconque, mon organisation doit le faire.

Jeff : Et ensuite, identifier ces choses qui sont du genre : "D'accord, quel est le fruit à portée de main dont nous pouvons nous débarrasser si nous devions automatiser cela ? Que pouvons-nous faire pour simplement simplifier cela ? » Et certains des critères étaient le risque du processus. Droit. Les basculements de base de données automatisés sont un peu effrayants car vous ne les faites pas souvent. Et les infrastructures changent. Droit. Nous disons : « À quelle fréquence faisons-nous cette chose ? Si nous le faisons une fois par an, cela ne vaut peut-être pas la peine de l'automatiser car cela n'a que très peu de valeur. Mais si c'est une de ces choses que nous recevons deux, trois fois par mois, d'accord, jetons un coup d'œil à cela. D'accord.

Jeff : Maintenant, quelles sont les choses que nous pouvons faire pour accélérer cela ? Et le fait est que, lorsque nous parlons d'automatisation, nous nous sommes immédiatement dit : "Je vais cliquer sur un bouton et cette chose va se faire comme par magie." Droit. Mais il y a tellement d'étapes différentes que vous pouvez suivre dans l'automatisation si vous vous sentez mal à l'aise. Droit. Par exemple, disons que vous avez 10 étapes avec 10 commandes CLI différentes que vous exécuteriez normalement. Votre première étape d'automatisation pourrait être aussi simple que d'exécuter cette commande ou au moins d'afficher cette commande. Droit. Dites : « Hé, c'est ce que je vais exécuter. Tu penses que ça va ? "Oui." "D'accord. C'est le résultat que j'ai obtenu. Est-ce que je peux continuer ? » "Oui." "D'accord. C'est le résultat que j'ai obtenu. Droit.

Jeff : De cette façon, vous avez encore un peu de contrôle. Vous vous sentez à l'aise. Et puis après 20 exécutions, vous réalisez que vous ne faites que frapper, oui, oui, oui, oui, oui, oui. Vous dites : « D'accord. Enchaînons toutes ces choses ensemble et faisons en sorte que tout ne fasse qu'un. Ce n'est pas comme si vous deviez sauter dans les profondeurs de, cliquer dessus et l'oublier dès le départ. Vous pouvez y entrer jusqu'à ce que vous vous sentiez à l'aise.

Jeff : Ce sont les types de choses que nous avons faites dans le cadre de notre effort d'automatisation : comment pouvons-nous accélérer le délai d'exécution et réduire le niveau d'effort de notre part ? Ce n'est peut-être pas 100 % le premier jour, mais l'objectif est toujours d'atteindre 100 %. Nous commencerons par de petits morceaux dont nous automatiserons les parties avec lesquelles nous nous sentons à l'aise. Oui. Nous sommes très confiants que cela va fonctionner. Cette partie est un peu risquée, alors peut-être que nous aurons juste une vérification humaine avant de continuer.

Jeff : L'autre chose que nous avons examinée en termes d'automatisation, mais quelle valeur ajoutons-nous à un processus particulier ? Et cela est particulièrement important pour les ops. Parce que souvent, les opérations servent d'intermédiaire pour un processus. Ensuite, leur implication n'est rien de plus qu'une question d'accès. Droit. C'est comme, eh bien, les opérations doivent le faire parce que les opérations sont la seule personne qui a accès.

Jeff : Eh bien, c'est comme, eh bien, comment pouvons-nous externaliser cet accès pour que les gens puissent le faire ? Parce que la réalité est que nous ne nous inquiétons pas du fait que les développeurs aient accès à la production. Droit. Nous craignons que les développeurs aient un accès illimité à la production. Et c'est vraiment une question de sécurité. Droit. C'est comme si ma boîte à outils ne contenait que des couteaux tranchants, je ferai très attention à qui je les donnerai. Mais si je peux mélanger la boîte à outils avec une cuillère et un marteau pour que les gens puissent choisir le bon outil pour le travail, alors c'est beaucoup plus facile de le prêter.

Jeff : Par exemple, nous avions un processus où les gens devaient exécuter des scripts Ruby ad hoc en production, pour une raison quelconque. Droit. Besoin de nettoyer des données, besoin de corriger un mauvais enregistrement, peu importe. Et cela passait toujours par mon équipe. Et c'est comme, eh bien, nous n'ajoutons aucune valeur à cela parce que je ne peux pas approuver ce ticket. Droit. Je n'ai aucune idée. Vous avez écrit le logiciel, alors à quoi ça sert que je sois assis par-dessus votre épaule et que je dise : "Eh bien, je pense que c'est sûr" ? Droit. Je n'ai ajouté aucune valeur à sa saisie car je ne fais que taper exactement ce que vous m'avez dit de taper. Droit.

Jeff : Et dans le pire des cas, et à la fin, je ne suis vraiment qu'un obstacle pour vous parce que vous soumettez un ticket, puis vous attendez que je revienne du déjeuner. Je reviens du déjeuner, mais j'ai d'autres choses sur lesquelles travailler. Nous avons dit : "Comment pouvons-nous automatiser cela afin que nous puissions mettre cela entre les mains des développeurs tout en répondant à l'un de ces problèmes d'audit que nous pourrions avoir ?"

Jeff : Nous l'avons mis dans un flux de travail JIRA, où nous avions un bot qui automatiserait l'exécution des commandes spécifiées dans le ticket JIRA. Et puis nous pourrions spécifier dans le ticket JIRA qu'il nécessitait l'approbation de l'un des nombreux ingénieurs seniors. Droit.

Jeff : Il est plus logique qu'un ingénieur approuve le travail d'un autre ingénieur parce qu'il connaît le contexte. Droit. Ils n'ont pas à attendre les opérations. La pièce d'audit est répondue parce que nous avons un flux de travail clair qui a été défini dans JIRA et qui est documenté au fur et à mesure que quelqu'un approuve, comme quelqu'un l'a demandé. Et nous avons une automatisation qui extrait cette commande et l'exécute textuellement dans le terminal. Droit.

Jeff : Vous n'avez pas à vous soucier de ma faute de frappe. Vous n'avez pas à vous soucier que je prenne le mauvais billet. Cela a augmenté le délai d'exécution de ces billets, quelque chose comme dix fois. Droit. Les développeurs sont débloqués. Mon équipe n'est pas occupée à faire ça. Et tout ce qu'il a vraiment fallu, c'est un investissement d'une semaine ou deux semaines pour développer l'automatisation et les autorisations nécessaires pour leur permettre d'y accéder.

Jeff : Maintenant, nous sommes complètement éloignés de cela. Et le développement est en fait capable d'externaliser certaines de ces fonctionnalités vers des parties inférieures de l'organisation. Ils l'ont poussé au service à la clientèle. C'est comme maintenant, quand le service client sait que cet enregistrement doit être mis à jour pour quoi que ce soit, il n'a pas besoin de développement. Ils peuvent soumettre leur script standard que nous avons approuvé pour cette fonctionnalité. Et ils peuvent l'exécuter à travers exactement le même flux de travail que le développement. C'est vraiment une aubaine tout autour.

Jeff : Et puis cela nous permet de pousser le travail de plus en plus bas dans toute l'organisation. Parce qu'au fur et à mesure que nous faisons cela, le travail devient de moins en moins cher parce que je pourrais avoir un développeur fantaisiste et coûteux qui gère cela. Droit. Ou je peux avoir une personne du service client qui travaille directement avec le client, s'occupe de lui-même pendant qu'il est au téléphone avec un client qui corrige un problème.

Jeff : Je pense que l'automatisation est la clé de toute organisation. Et le dernier point que je dirai là-dessus, c'est que cela vous permet également d'exporter l'expertise. Droit. Maintenant, je suis peut-être la seule personne à savoir comment faire cela si j'avais besoin de faire un tas de commandes sur la ligne de commande. Mais si je mets ça dans l'automatisation, je peux donner ça à n'importe qui. Et les gens savent quel est le résultat final, mais ils n'ont pas besoin de connaître toutes les étapes intermédiaires. J'ai décuplé ma valeur en la poussant vers l'organisation et en prenant mon expertise et en la codifiant en quelque chose qui est exportable.

Drew : Vous avez parlé d'automatisation des tâches qui se produisent fréquemment. Y a-t-il un argument pour automatiser également les tâches qui se produisent si rarement qu'il faut beaucoup de temps à un développeur pour se remettre au courant de la façon dont cela devrait fonctionner ? Parce que tout le monde est oublié. Ça fait tellement longtemps. Cela fait un an, peut-être que personne ne l'a fait avant. Y a-t-il un argument en faveur de l'automatisation de ce genre de choses également ?

Jeff : C'est un exercice d'équilibre difficile. Droit. Et je dis toujours de le prendre au cas par cas. Et la raison pour laquelle je dis cela est que l'un des mantras de DevOps est que si quelque chose est douloureux, faites-le plus souvent. Droit. Parce que plus vous le faites souvent, plus la mémoire musculaire augmente et vous pouvez vous entraîner et aplanir ces problèmes.

Jeff : Le problème que nous voyons avec l'automatisation de tâches très peu fréquentes est que le paysage de l'environnement a tendance à changer entre les exécutions de cette automatisation. Droit. Ce qui finit par se produire, c'est que votre code fait des hypothèses particulières sur l'environnement et que ces hypothèses ne sont plus valides. Donc, l'automatisation finit par casser de toute façon.

Drew : Et puis vous avez deux problèmes.

Jef : D'accord. Droit. Exactement. Exactement. Et vous vous dites : « Est-ce que j'ai mal tapé ? Ou est-ce? Non, cette chose est en fait cassée. Alors-

Jeff : Vous avez mal tapé ou est-ce non, cette chose est en fait cassée. Ainsi, lorsqu'il s'agit d'automatiser des tâches peu fréquentes, nous procédons vraiment au cas par cas pour comprendre, eh bien, quel est le risque si cela ne fonctionne pas, n'est-ce pas. Si nous nous trompons, sommes-nous dans un mauvais état ou est-ce simplement que nous n'avons pas terminé cette tâche ? Donc, si vous pouvez vous assurer que cela échouera gracieusement et n'aura pas d'impact négatif, alors cela vaut la peine d'essayer de l'automatiser. Parce qu'à tout le moins, vous avez alors un cadre de compréhension de ce qui devrait se passer parce qu'à tout le moins, quelqu'un va pouvoir lire le code et comprendre, d'accord, c'est ce que nous faisions. Et je ne comprends pas pourquoi cela ne fonctionne plus, mais j'ai une compréhension claire de ce qui était censé se produire au moins au moment de la conception lorsque cela a été écrit.

Jeff : Mais si jamais vous vous trouvez dans une situation où une défaillance peut entraîner des modifications de données ou quelque chose comme ça, je fais généralement preuve de prudence et je le garde manuel uniquement parce que si j'ai un script d'automatisation, si je trouve un document de confluence c'est trois ans qui dit exécuter ce script, j'ai tendance à avoir une confiance à cent pour cent dans ce script et je l'exécute. Droit. Alors que s'il s'agit d'une série d'étapes manuelles qui ont été documentées il y a quatre ans, je vais dire, je dois faire une vérification ici. Droit? Permettez-moi de parcourir cela un peu et de parler à quelques personnes. Et parfois, lorsque nous concevons des processus, cela vaut la peine de forcer ce processus de réflexion, n'est-ce pas ? Et vous devez penser à la composante humaine et à la façon dont ils vont se comporter. Et parfois, cela vaut la peine de rendre le processus un peu plus lourd pour forcer les gens à se demander si je dois le faire maintenant ?

Drew : Existe-t-il d'autres moyens d'identifier ce qui devrait être automatisé en surveillant vos systèmes et en mesurant les choses ? Je veux dire, je pense à DevOps et je pense aux tableaux de bord comme l'une des choses, de beaux graphiques. Et je suis sûr qu'il y a beaucoup plus dans ces tableaux de bord qu'être jolis, mais c'est toujours agréable d'avoir de jolis tableaux de bord. Existe-t-il des moyens de mesurer ce que fait un système pour vous aider à prendre ce genre de décisions?

Jef : Absolument. Et ce genre d'enchaînement avec la partie métrique des cames, n'est-ce pas, quelles sont les choses que nous suivons dans nos systèmes pour savoir qu'ils fonctionnent efficacement ? Et l'un des pièges les plus courants des métriques est que nous recherchons les erreurs au lieu de vérifier le succès. Et ce sont deux pratiques très différentes, n'est-ce pas ? Ainsi, quelque chose pourrait circuler dans le système et ne pas nécessairement sortir par erreur, mais ne pas nécessairement passer par l'ensemble du processus comme il se doit. Donc, si nous déposons un message dans une file d'attente de messages, il devrait y avoir une métrique correspondante qui dit : « Et ce message a été récupéré et traité », n'est-ce pas ? Sinon, c'est vrai, vous allez rapidement avoir un déséquilibre et le système ne fonctionnera pas comme il le devrait. Je pense que nous pouvons utiliser les métriques comme un moyen de comprendre également différentes choses qui devraient être automatisées lorsque nous entrons dans ces mauvais états.

Jef : D'accord ? Parce que souvent, c'est une étape très simple qui doit être prise pour nettoyer les choses, n'est-ce pas ? Pour les personnes qui ont été opérationnelles pendant un certain temps, à droite, l'alerte d'espace disque, tout le monde le sait. Oh, nous sommes remplis de disque. Oh, nous avons oublié que c'est la fin du mois et que la facturation a fonctionné et que la facturation remplit toujours les journaux. Et puis le journal VAR consomme tout l'espace disque, nous devons donc exécuter une rotation du journal. Droit? Vous pourriez vous réveiller à trois heures du matin pour cela, si c'est en quelque sorte votre préférence. Mais si nous savons en quelque sorte que c'est le comportement, nos mesures devraient pouvoir nous donner un indice à ce sujet. Et nous pouvons simplement automatiser la commande de rotation du journal, n'est-ce pas ? Oh, nous avons atteint ce seuil, exécutez la commande de rotation du journal. Voyons si l'alerte disparaît. Si c'est le cas, continuez votre vie. Si ce n'est pas le cas, alors peut-être qu'on réveillera quelqu'un, d'accord.

Jeff : Vous voyez cela beaucoup plus avec l'automatisation de l'infrastructure également, c'est-à-dire : « Hé, nos requêtes par seconde atteignent-elles leur maximum théorique ? Peut-être devons-nous redimensionner le cluster. Peut-être devrions-nous ajouter trois ou quatre nœuds au pool d'équilibrage de charge. » Et nous pouvons le faire sans nécessairement nécessiter l'intervention de quelqu'un. Nous pouvons simplement examiner ces métriques et prendre cette mesure, puis contracter cette infrastructure une fois qu'elle passe en dessous d'un seuil particulier, mais vous devez avoir ces métriques et vous devez avoir ces crochets dans votre environnement de surveillance pour pouvoir le faire. Et c'est là que toute la partie métrique de la conversation entre en jeu.

Jeff : De plus, c'est aussi bien de pouvoir partager ces informations avec d'autres personnes parce qu'une fois que vous avez des données, vous pouvez commencer à parler de choses dans une réalité partagée, n'est-ce pas, parce que occupé est un terme générique, mais 5 200 requêtes par seconde est quelque chose de beaucoup plus concret sur lequel nous pouvons tous raisonner. Et je pense que si souvent, lorsque nous avons des conversations sur la capacité ou quoi que ce soit, nous utilisons ces termes à la main, alors qu'à la place, nous pourrions regarder un tableau de bord et donner des valeurs très spécifiques et nous assurer que tout le monde a accès à ces tableaux de bord, que ils ne sont pas cachés derrière un mur d'opérations auquel nous seuls avons accès pour une raison inconnue.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Droit. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Droit.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Est-ce une évaluation juste?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Droit. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Droit. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Droit. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Droit. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Droit? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Droit. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Droit. So you could be doing any manner of testing in there that is extremely complicated. Droit. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Droit. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Droit. Let me get Drew on the phone and see what's going on.” Droit. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Droit. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Droit. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. Vous savez ce que je veux dire? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff : Je voulais leur écrire, principalement des contributeurs individuels et des cadres intermédiaires, pour leur dire : « Vous n'avez pas besoin d'être un CTO pour pouvoir apporter ce genre de changements progressifs, et vous n'avez pas besoin d'avoir ce toute la révolution de la vente pour pouvoir bénéficier de certains des avantages de DevOps. » Donc, c'était vraiment une sorte de lettre d'amour pour eux de dire: «Hé, vous pouvez le faire en morceaux. Vous pouvez le faire vous-même. Et il y a toutes ces choses que vous ne pensez peut-être pas liées à DevOps parce que vous les considérez comme des outils et Kubernetes. Pas toutes les organisations… Si vous étiez pour cet État de New York, comme le gouvernement de l'État, vous n'allez pas simplement venir mettre en œuvre Kubernetes du jour au lendemain. Droit? Mais vous pouvez mettre en œuvre la façon dont les équipes se parlent, comment elles travaillent ensemble, comment nous comprenons les problèmes de chacun et comment nous pouvons résoudre ces problèmes grâce à l'automatisation. Ce sont des choses qui font partie de votre sphère d'influence et qui peuvent améliorer votre vie de tous les jours.

Jeff : C'était donc vraiment une lettre à ces gens, mais je pense qu'il y a suffisamment de données là-dedans et suffisamment d'informations pour que les personnes qui sont dans une organisation DevOps puissent en quelque sorte glaner et dire : « Hé, c'est toujours utile pour nous. ” Et beaucoup de gens, je pense, identifient rapidement en lisant le livre, qu'ils ne sont pas dans une organisation DevOps, ils ont juste un changement de titre de poste. Et cela arrive assez souvent. Alors ils disent : « Hé, nous sommes des ingénieurs DevOps maintenant, mais nous ne faisons pas ce genre de pratiques dont il est question dans ce livre et comment y arriver ?

Drew : Il semble donc que votre livre en fasse partie, mais existe-t-il d'autres ressources vers lesquelles les personnes souhaitant démarrer avec DevOps pourraient se tourner ? Existe-t-il de bons endroits pour apprendre ce genre de choses?

Jef : Ouais. Je pense que DevOps For Dummies d'Emily Freeman est un excellent point de départ. Il fait vraiment un excellent travail pour trier certains des concepts et idées de base, et ce que nous recherchons. Ce serait donc un bon point de départ, juste pour avoir une idée du terrain. Je pense que le Phoenix Project est évidemment une autre excellente source de Gene Kim. Et c'est formidable, cela prépare le terrain pour les types de problèmes que le fait de ne pas être dans un environnement DevOps peut créer. Et cela fait un excellent travail en mettant en évidence ces modèles et ces personnalités que nous voyons dans tous les types d'organisations encore et encore. Je pense que cela fait un excellent travail pour les mettre en évidence. Et si vous lisez ce livre, je pense que vous allez finir par crier sur les pages en disant : « Oui, oui. Ce. Ce." Donc, c'est un autre super endroit.

Jeff : Et à partir de là, plonger dans l'un des manuels DevOps. Je vais me donner un coup de pied pour avoir dit cela, mais le manuel Google SRE était un autre excellent endroit à regarder. Comprenez que vous n'êtes pas Google, alors ne vous sentez pas obligé de tout mettre en œuvre, mais je pense que beaucoup de leurs idées et stratégies sont valables pour n'importe quelle organisation, et sont d'excellents endroits où vous pouvez en quelque sorte prendre les choses et dire comme, "D'accord, nous allons, nous allons rendre notre environnement d'exploitation un peu plus efficace." Et cela, je pense, sera particulièrement important pour les développeurs qui jouent un rôle opérationnel, car cela se concentre sur une grande partie du type d'approche programmatique pour résoudre certains de ces problèmes.

Drew : Donc, j'ai tout appris sur DevOps. Qu'as-tu appris dernièrement, Jeff ?

Jeff : Kubernetes, mec. Ouais. Kubernetes a été une véritable source de lecture et de connaissances pour nous. Nous essayons donc de mettre en œuvre cela au Centro actuellement, comme un moyen de responsabiliser davantage les développeurs. Nous voulons pousser les choses un peu plus loin d'où nous en sommes. Nous avons beaucoup d'automatisation en place, mais pour le moment, lorsqu'il s'agit d'intégrer un nouveau service, mon équipe est encore assez fortement impliquée, selon la nature du service. Et nous ne voulons pas être dans cette ligne de travail. Nous voulons que les développeurs soient capables de faire passer une idée du concept au code jusqu'au déploiement, et de le faire là où l'expertise opérationnelle est codifiée au sein du système. Ainsi, au fur et à mesure que vous vous déplacez dans le système, le système vous guide. Nous pensons donc que Kubernetes est un outil qui nous aidera à le faire.

Jeff : C'est juste incroyablement compliqué. Et c'est un gros morceau à mordre. Alors, à quoi ressemblent les déploiements ? Comment tirer parti de ces opérateurs dans Kubernetes ? A quoi ressemble CICD dans ce nouveau monde ? Donc, il y a eu beaucoup de lecture, mais dans ce domaine, vous apprenez constamment, n'est-ce pas ? Peu importe depuis combien de temps vous y êtes, depuis combien de temps vous le faites, vous êtes un idiot dans un aspect de ce domaine quelque part. Donc, c'est juste quelque chose auquel vous vous adaptez

Drew : Eh bien, chapeau comme je le dis, même après toutes ces années, même si je comprends en quelque sorte où il se situe dans la pile, je n'ai toujours pas la moindre idée de ce que fait Kubernetes.

Jeff : Je me sens parfois comme ça. On dirait qu'il fait un peu de tout, n'est-ce pas ? C'est le DNS du 21ème siècle.

Drew: Si vous, l'auditeur, souhaitez en savoir plus sur Jeff, vous pouvez le trouver sur Twitter, où il est sombre et ringard, et trouver son livre et des liens vers des présentations passées et des articles de blog sur son site, accessibleabledevops.com. Merci de vous joindre à nous aujourd'hui, Jeff. Avez-vous eu des mots d'adieu?

Jeff : Continuez simplement à apprendre, sortez, continuez à apprendre et parlez à vos collègues. Parlez, parlez, parlez. Plus vous pouvez parler aux personnes avec lesquelles vous travaillez, plus vous comprendrez, plus vous générerez d'empathie pour eux, et s'il y a quelqu'un en particulier dans l'organisation que vous détestez, assurez-vous de lui parler en premier.