Qu'estce que DevOps ? — fracassant

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 notes

Mise à jour hebdomadaire

Transcription

Drew McLellan : C'est un praticien DevOps qui se concentre sur les niveaux réalisables des implémentations DevOps, peu importe où vous en êtes dans votre parcours. Il est directeur des opérations de production de la plate-forme de publicité numérique Centro, en plus d'être un conférencier, 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 implémenter les techniques DevOps dans le type d'environnements imparfaits dans lesquels la plupart des développeurs travaillent. Nous savons donc qu'il est un expert en DevOps, mais saviez-vous que George Clooney le considère comme le meilleur constructeur d'avions en papier d'une génération ? Mes amis Smashing, veuillez souhaiter la bienvenue à Jeff Smith. Salut Jeff. Comment ça va ?

Jeff Smith : Je défonce, Drew, comment ça va ?

Drew : Je vais bien. Merci. Ça fait plaisir à entendre. Je voulais donc vous parler aujourd'hui du sujet du DevOps, qui est l'un de vos principaux domaines clés. Beaucoup de nos auditeurs seront impliqués dans le développement de sites Web et d'applications, mais n'ont peut-être qu'une connaissance vague de ce qui se passe du côté des opérations. Je sais que ceux d'entre nous qui pourraient travailler dans de plus grandes entreprises auront des équipes entières de collègues qui feront des opérations. Nous sommes juste 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 obtiendrez peut-être 20 réponses différentes. Je vais donc vous donner mon avis, d'accord, et sachez que si vous êtes à une conférence et que vous le mentionnez, vous pourriez vous battre à coups de poing 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 entre les équipes et la façon 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 de base de DevOps viennent de l'ancien monde où le développement et les opérations étaient toujours contradictoires, 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 déborde de là. DevOps consiste donc 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 le développeur comprenne mieux les opérations et que les opérations comprennent davantage le développement, 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 améliorer notre travail. Car encore une fois, si je comprends votre point de vue et en tient compte dans mon travail, ça va être beaucoup plus bénéfique pour chacun de nous. Et il y a beaucoup de choses que les opérateurs peuvent apprendre des développeurs en termes d'automatisation et de la façon dont nous abordons les choses afin 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, donc vous entendez 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 éliminer à travers l'organisation. nous pouvons à partir des opérations 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'introduction, c'est que nous pensons que c'est juste pour ces grandes organisations avec des équipes opérationnelles dédiées et des choses comme ça, mais une chose à laquelle penser est que les opérations se produisent dans votre organisation, quelle que soit la taille. C'est juste que vous le fassiez, 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 sa 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 le type de choses que font les opérations.

Drew : En tant que développeurs professionnels, quelle est l'importance de vous pensez que c'est 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 très important, surtout à cette phase du parcours DevOps. Et la raison pour laquelle je pense que c'est important, c'est que celui-là, 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 l'élaboration de votre 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 avait à voir avec 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 parfois cela se traduit par des choix de conception particuliers ou des choix de mise en œuvre qui peuvent ne pas être optimaux pour un déploiement de production.

Jeff : Ils pourraient être bien. 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. Ainsi, ils savent quand engager les opérations tôt, car c'est un modèle commun que nous voyons, le développement fait un choix. Je ne dirai même pas de 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 était complètement inconscient. Donc, avoir juste un peu plus de connaissances sur les opérations, même s'il suffit de dire, peut-être que nous devrions faire appel aux opérations 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 dev et ops 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 être construit dans le rôle de développement, et amenant les développeurs à consulter peuvent vraiment améliorer la solution globale simplement en ayant cette communication claire et une compréhension de ce que l'autre fait. On dirait que c'est le même principe joué avec DevOps, ce qui est vraiment, vraiment bon à entendre. . 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 soit pas seulement à propos de… Nous ne parlons pas seulement d'outils ici, n'est-ce pas ? Mais plus sur les processus et les moyens de communiquer sur les flux de travail, n'est-ce pas ?

Jeff : Absolument. Donc, mon mantra depuis 20 ans a toujours été les outils de traitement des personnes. Vous incitez 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. Je place donc 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 changement directement à la production, cela n'a pas d'importance, n'est-ce pas ? A quoi bon l'outil ? Ces outils font donc définitivement partie de la conversation, uniquement parce qu'ils constituent un moyen normalisé d'atteindre certains objectifs communs que nous avons définis.

Jeff : Mais vous devez vous assurer que ces objectifs sont être défini a du sens 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 existe de nombreuses entreprises et organisations et des raisons pour lesquelles vous ne voudriez pas faire cela. Alors peut-être que quelque chose comme un pipeline de déploiement continu n'a pas de sens pour vous. Ainsi, même si les outils sont 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 ne le faites pas. t allez 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'avez 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 publications de Netflix et de Google. S'il vous plaît, arrêtez 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 si, eh bien, ils résolvaient des problèmes très différents de ceux que vous avez. un produit de service. J'ai trois développeurs, j'ai un dépôt Git vide et j'ai des rêves d'introductions en bourse. Pour être tout à fait dans une approche DevOps pour créer ce produit, quels sont les noms des blocs de construction 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 endroit par lequel je commencerais serait de le faire autant que 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 un problème. Mais si vous en êtes à ce point où vous dites d'accord, nous sommes prêts à prendre ce truc en interne et nous sommes prêts à passer au niveau supérieur. Je dirais que le premier point de départ est de savoir où sont vos points faibles ? Quelles sont les choses qui vous causent des problèmes ?

Jeff : Donc, 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 effectue un commit, car parfois nous expédions des éléments qui sont pris en compte par les tests unitaires que nous avons déjà écrits. Alors peut-être que vous commencez 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 là que vous commencez, simplement parce que votre situation particulière et vos points de douleur 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. Et ça devrait être comme, oh, je sais exactement ce que c'est. Ainsi, 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éballer et commencer à utiliser 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 passez de genre, oh oui, les déploiements prennent trois heures et ce n'est pas grave. 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 de 30 minutes? Votre appétit devient insatiable pour l'amélioration. Donc, les choses débordent en quelque sorte de là. 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 juste é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 vous y pensez. Et c'est important parce que la culture, et nous entrons un peu plus loin 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 avez soumis un PR sans test automatisé, ce n'est pas grave. Les gens l'acceptent et passent à autre chose.

Jeff : Mais il y a aussi d'autres organisations où c'est un péché capital. Droit. Où, si vous avez fait ça, 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 quand même la culture. C'est la culture qui applique cette norme pour dire : « Ce n'est tout simplement pas ce que nous faisons ». est ce qui applique ce mécanisme parmi le peuple. Ce n'est qu'un petit exemple de l'importance de la culture. Si vous avez une organisation où la culture est une culture de peur, une culture de rétribution. C'est comme si vous faisiez une erreur, n'est-ce pas, c'est un sacrilège. Droit. Cela équivaut à de la trahison. Exact.

Jeff : Vous créez des comportements dans cette organisation qui sont contraires à 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 un moyen d'é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 sommes tous allés 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 mettons la culture au premier plan, car de nombreux 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 également 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 tout type de changement. Et la plupart des gens sont des gardiens de 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. 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.[19659008]Jeff : Vous pouvez apporter ces changements culturels en tant que contributeur individuel, simplement en épousant ces idées et ces comportements à voix haute et en disant : « Ce sont les avantages que nous en tirons. » C'est pourquoi je pense que la culture doit être au premier plan parce que vous devez amener tout le monde à adhérer à cette idée et qu'ils doivent comprendre qu'en tant qu'organisation, cela en vaudra la peine et la soutenir.

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

Jeff : Exactement.

Drew : Ouais. Je suis vraiment intéressé par le domaine de l'automatisation car au cours de ma carrière, je n'ai jamais vu une automatisation mise en place qui n'a 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 de l'espace libre, et c'est juste un poids sur vos épaules.

Drew : En prenant une approche DevOps, quel genre de choses chercheriez-vous à automatiser dans vos workflows ? Et quels avantages vous attendriez-vous à en retirer par rapport à l'exécution manuelle des tâches ?

Jeff : En ce qui concerne l'automatisation, à votre avis, il est très rare qu'il y ait un moment où l'automatisation n'a pas rendu la vie meilleure. 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 point de la demande. Droit. Parce qu'à un moment donné, vous devez dire : « Je vais arrêter de faire cela manuellement et je vais l'automatiser. »

Jeff : vous dites : « Vous savez quoi ? Cela va prendre deux semaines. Je sais que nous réalisons normalement le traitement en quelques heures, mais cela va prendre 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ù, fondamentalement, j'échantillonnerais tous les différents types de demandes reçues sur une période de quatre semaines, disons. Et je les classerais en tant que travail planifié, travail non planifié, travail à valeur ajoutée, travail de labeur. Le labeur est un travail qui n'est pas vraiment utile, mais pour une raison quelconque, mon organisation doit le faire. se 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 si 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 il n'a que très peu de valeur. Mais si c'est l'une de ces choses que nous obtenons deux, trois fois par mois, d'accord, jetons un coup d'œil à cela. Très bien.

Jeff : Maintenant, que pouvons-nous faire pour accélérer cela ? Et le fait est que lorsque nous parlons d'automatisation, nous sommes immédiatement passés à : "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 faire 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. Penses-tu 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. Exact.

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 : « Très bien. Enchaînons toutes ces choses ensemble et faisons-en tout simplement un. » Ce n'est pas comme si vous deviez plonger dans le grand bain, cliquer dessus et l'oublier tout de suite. Vous pouvez intervenir 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. 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. Nous sommes un peu risqués sur cette partie, alors peut-être que nous aurons juste une vérification humaine avant de continuer. valeur ajoutée à un processus particulier ? Et cela est particulièrement important pour les opérations. Parce que souvent, les opérations servent d'intermédiaire pour un processus. Ensuite, leur implication n'est rien de plus qu'une chose d'accès. Droit. C'est comme, eh bien, les opérations doivent le faire parce qu'elles sont la seule personne qui a accès. Parce que la réalité est que ce n'est pas que nous craignions que les développeurs aient un 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 n'avait que des couteaux tranchants, je vais faire très attention à qui je donne ça. 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 il 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 les données, besoin de corriger un mauvais enregistrement, peu importe. Et cela passerait toujours par mon équipe. Et c'est comme, eh bien, nous n'ajoutons aucune valeur à cela parce que je ne peux pas approuver ce billet. Droit. Je n'ai aucune idée. Vous avez écrit le logiciel, alors à quoi cela sert-il de m'asseoir par-dessus votre épaule et de dire : « Eh bien, je pense que c'est sûr » ? Droit. Je n'ai ajouté aucune valeur à la saisie parce que je tape juste exactement ce que vous m'avez dit de taper. Exact.

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

Jeff : Nous l'avons mis dans un Workflow JIRA, où nous avions un bot qui automatiserait l'exécution des commandes spécifiées dans le ticket JIRA. Et puis nous pouvions préciser dans le ticket JIRA que cela nécessitait l'approbation de l'un des nombreux ingénieurs seniors. Exact.

Jeff : Il est plus logique qu'un ingénieur approuve le travail d'un autre ingénieur parce qu'il a le contexte. Droit. Ils n'ont pas à attendre les opérations. La pièce d'audit est résolue car 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 exécute cette commande textuellement dans le terminal. Exact.

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

Jeff : Maintenant, nous en sommes complètement éloignés. Et le développement est en fait capable d'externaliser certaines de ces fonctionnalités vers les parties inférieures de l'organisation. Ils l'ont poussé au service client. C'est comme maintenant, lorsque 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 avec 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'en faisant cela, le travail devient de moins en moins cher parce que je pourrais avoir un développeur sophistiqué et coûteux qui l'exécute. Droit. Ou je peux demander à un responsable du service client qui travaille directement avec le client de l'exécuter lui-même pendant qu'il est au téléphone avec un client pour corriger un problème.

Jeff : L'automatisation, je pense, 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 le donner à 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'automatiser les tâches qui se produisent fréquemment. Existe-t-il un argument en faveur de l'automatisation des tâches qui se produisent si rarement qu'il faut un certain 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 aussi ?

Jeff : C'est un exercice d'équilibre difficile. Droit. Et je dis toujours à prendre au cas par cas. Et la raison pour laquelle je dis cela, c'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 vous gagnez en mémoire musculaire et vous vous entraînez et résolvez ces problèmes. 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 ces hypothèses ne sont plus valides. Donc, l'automatisation finit par se casser de toute façon.

Drew : Et puis vous avez deux problèmes.

Jeff : 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. Donc-

Jeff : Tapez mal ou est-ce non, cette chose est en fait cassée. Donc, quand 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 de tenter de l'automatiser. Parce qu'à tout le moins, alors vous avez 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 passer au moins au moment de la conception lorsque cela a été écrit.

Jeff : Mais si vous êtes jamais dans une situation où un échec pourrait 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 vieux de 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 documentées il y a quatre ans, je vais me dire, je dois faire une vérification ici. Droit? Permettez-moi de parcourir un peu cela 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 à penser que devrais-je le faire maintenant ? ? 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 que ces tableaux de bord ne se limitent pas à ê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 ?

Jeff : Absolument. Et ce genre de passe dans la partie métrique des caméras, n'est-ce pas, quelles sont les choses que nous suivons dans nos systèmes pour savoir qu'elles 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, non ? Ainsi, quelque chose pourrait circuler dans le système et ne pas nécessairement sortir d'erreur, mais pas nécessairement suivre tout le processus comme il se doit. Donc, si nous laissons tomber 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, d'accord, vous allez rapidement avoir un déséquilibre et le système ne fonctionne pas comme il le devrait. Je pense que nous pouvons utiliser des métriques comme moyen de comprendre également différentes choses qui devraient être automatisées lorsque nous entrons dans ces mauvais états.

Jeff: N'est-ce pas ? 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 sont en opération depuis un certain temps, n'est-ce pas, 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 la facturation a été exécutée et la facturation remplit toujours les journaux. And then VAR log is consuming all the disc space, so we need to run a log rotate. Right? You could get woken up at three in the morning for that, if that’s sort of your preference. But if we sort of know that that’s the behavior, our metrics should be able to give us a clue to that. And we can simply automate the log rotate command, right? Oh, we’ve reached this threshold, execute the log rotate command. Let’s see if the alert clears. If it does, continue on with life. If it doesn’t, then maybe we wake someone up, right.

Jeff: You’re seeing this a lot more with infrastructure automation as well, right, where it’s like, “Hey, are our requests per second are reaching our theoretical maximum. Maybe we need to scale the cluster. Maybe we need to add three or four nodes to the load balancer pool.” And we can do that without necessarily requiring someone to intervene. We can just look at those metrics and take that action and then contract that infrastructure once it goes below a particular threshold, but you got to have those metrics and you got to have those hooks into your monitoring environment to be able to do that. And that’s where the entire metrics portion of the conversation comes in.

Jeff: Plus it’s also good to be able to share that information with other people because once you have data, you can start talking about things in a shared reality, right, because busy is a generic term, but 5,200 requests per second is something much more concrete that we can all reason about. And I think so often when we’re having conversations about capacity or anything, we use these hand-wavy terms, when instead we could be looking at a dashboard and giving very specific values and making sure that everyone has access to those dashboards, that they’re not hidden behind some ops wall that only we have access to for some unknown reason.

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. Right. 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.” Right.

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. Is that a fair assessment?

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. Right. 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. Right. 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. Right. 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. Right. 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. Right? 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. Right. 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. Right. So you could be doing any manner of testing in there that is extremely complicated. Right. 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. Right. 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. Right. Let me get Drew on the phone and see what’s going on.” Right. And Drew can say, “Oh right. This plugin is upgraded, but it’s not compatible with our current version of WordPress or whatever.” Right. 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. Right. 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. You know what I mean? 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: I wanted to write it to them, mainly individual contributors and middle managers to say like, “You don’t need to be a CTO to be able to make these sorts of incremental changes, and you don’t have to have this whole sale revolution to be able to gain some of the benefits of DevOps.” So it was really sort of a love letter to them to say like, “Hey, you can do this in pieces. You can do this yourself. And there’s all of these things that you may not think are related to DevOps because you’re thinking of it as tools and Kubernetes.” Not every organization… If you were for this New York State, like the state government, you’re not going to just come in and implement Kubernetes overnight. Right? But you can implement how teams talk to each other, how they work together, how we understand each other’s problems, and how we can address those problems through automation. Those are things that are within your sphere of influence that can improve your day to day life.

Jeff: So it was really a letter to those folks, but I think there’s enough data in there and enough information for people that are in a DevOps organization to sort of glean from and say like, “Hey, this is still useful for us.” And a lot of people, I think identify quickly by reading the book, that they’re not in a DevOps organization, they just have out a job title change. And that happens quite a bit. So they say like, “Hey, we’re DevOps engineers now, but we’re not doing these sorts of practices that are talked about in this book and how do we get there?”

Drew: So it sounds like your book is one of them, but are there other resources that people looking to get started with DevOps could turn to? Are there good places to learn this stuff?

Jeff: Yeah. I think DevOps For Dummies by Emily Freeman is a great place to start. It really does a great job of sorting of laying out some of the core concepts and ideas, and what it is we’re striving for. So that would be a good place to start, just to sort of get a lay of the land. I think the Phoenix Project is obviously another great source by Gene Kim. And that is great, that sort of sets the stage for the types of issues that not being in a DevOps environment can create. And it does a great job of sort of highlighting these patterns and personalities that occur that we see in all types of organizations over and over again. I think it does a great job of sort of highlighting those. And if you read that book, I think you’re going to end up screaming at the pages saying, “Yes, yes. This. This.” So, that’s another great place.

Jeff: And then from there, diving into any of the DevOps handbook. I’m going to kick myself for saying this, but the Google SRE Handbook was another great place to look. Understand that you’re not Google, so don’t feel like you’ve got to implement everything, but I think a lot of their ideas and strategies are sound for any organization, and are great places where you can sort of take things and say like, “Okay, we’re, we’re going to make our operations environment a little more efficient.” And that’s, I think going to be particularly salient for developers that are playing an ops role, because it does focus on a lot of the sort of programmatic approach to solving some of these problems.

Drew: So, I’ve been learning all about DevOps. What have you been learning about lately, Jeff?

Jeff: Kubernetes, man. Yeah. Kubernetes has been a real sort of source of reading and knowledge for us. So we’re trying to implement that at Centro currently, as a means to sort of further empower developers. We want to take things a step further from where we’re at. We’ve got a lot of automation in place, but right now, when it comes to onboarding a new service, my team is still fairly heavily involved with that, depending on the nature of the service. And we don’t want to be in that line of work. We want developers to be able to take an idea from concept to code to deployment, and do that where the operational expertise is codified within the system. So, as you move through the system, the system is guiding you. So we think Kubernetes is a tool that will help us do that.

Jeff: It’s just incredibly complicated. And it’s a big piece to sort of bite off. So figuring out what do deployments look like? How do we leverage these operators inside Kubernetes? What does CICD look like in this new world? So there’s been a lot of reading, but in this field, you’re constantly learning, right? It doesn’t matter how long you’ve been in it, how long you’ve been doing it, you’re an idiot in some aspect of this field somewhere. So, it’s just something you kind of adapt to

Drew: Well, hats off as I say, even after all these years, although I sort of understand where it sits in the stack, I still really don’t have a clue what Kubernetes is doing.

Jeff: I feel similar sometimes. It feels like it’s doing a little bit of everything, right? It is the DNS of the 21st century.

Drew: If you, the listener, would like to hear more from Jeff, you can find him on Twitter, where he’s at dark and nerdy, and find his book and links to past presentations and blog posts at his site, attainabledevops.com. Thanks for joining us today, Jeff. Did you have any parting words?

Jeff: Just keep learning, just get out there, keep learning and talk to your fellow peers. Talk, talk, talk. The more you can talk to the people that you work with, the better understanding, the better empathy you’ll generate for them, and if there’s someone in particular in the organization you hate, make sure you talk to them first.

(il)