Chris Bytaert, vétéran du DevOps, pionnier des DevOpsDays, partage son expérience et ses découvertes vous surprendront.
Il y a dix ans, nous avons soudainement fait un voyage. Nous avons réuni certains de nos bons amis à Gand (Belgique) pour discuter des expériences Agile, open-source et des premières expériences de cloud computing. En 2009, John Ollspoe et Paul Hammond ont donné une conférence à Velocity sur "10+ Deployments a Day: Dev and Ops Collaboration at Flickr" (et un enregistrement de cette conférence vaut la peine d'être visionné). Après avoir vu cette conférence, Patrick Debois a décidé de fonder DevOpsDays.
Est-il vrai que le monde DevOps a beaucoup changé au cours de ces 10 années? J'assiste aux événements DevOpsDays depuis le début de la conférence, et pendant ce temps j'ai accumulé une expérience significative. Dans cet article, je partagerai 10 tutoriels qui pourraient également vous être utiles.
1. Un ingénieur DevOps n'existe pas
De nombreuses équipes ont une personne avec le titre d'ingénieur DevOps, et tous les spécialistes n'aiment pas ce titre. Ce nom de profession donne la fausse impression que DevOps est un travail qui peut être effectué par une seule personne. Le plus souvent, un ingénieur DevOps est un ingénieur Linux qui, avec un peu de chance, peut résoudre des problèmes d'automatisation. Lorsque les recruteurs commencent à chercher un ingénieur DevOps, les demandeurs d'emploi doivent se poser les bonnes questions: «Qu'est-ce que l'entreprise attend vraiment du demandeur d'emploi? Cherchent-ils un ingénieur assembleur? Senora qui comprend les exigences non fonctionnelles? Un spécialiste du service opérationnel capable de gérer l'automatisation ou quelqu'un d'autre? " Le plus souvent, les entreprises recherchent un spécialiste qui dissuadera le reste des employés de ne pas répondre aux principes pratiques et aux exigences d'Agile.
Dans les organisations dotées de grands départements DevOps, en règle générale, personne n'est impliqué dans DevOps. Le mot «DevOps» ne parle que de séparation du reste de l'équipe, et le candidat peut obtenir un bon salaire et acquérir de nouvelles compétences au travail, mais il ne «fera pas de DevOps».
2. Les équipes DevOps n'existent pas
Nous avons souvent dit dans le passé que l'objectif de DevOps est d'éliminer la confusion entre les différentes équipes. En particulier, entre développeurs et collaborateurs des directions opérationnelles. Cependant, nous avons récemment rencontré un nouveau phénomène: l'émergence de nombreuses équipes DevOps.
Construire une équipe DevOps semble être une nouvelle pratique, mais il y a des contradictions évidentes ici. Dans une organisation, cette équipe s'occupera des outils de développement, dans une autre, c'est littéralement un mur entre l'équipe de développement et les spécialistes des opérations. Le problème est que ce mur crée de la confusion, de la frustration et réduit le niveau d'interaction utile. L'équipe qui s'appelle «DevOps» résout au mieux une variété de problèmes et a une certaine responsabilité pour les services avec lesquels elle travaille. Les équipes professionnelles préfèrent généralement ne pas avoir le mot «DevOps» dans leur nom.
D'après mon expérience, avoir le mot «DevOps» dans un nom d'équipe est susceptible d'entraver l'atteinte des résultats souhaités.
3. Les projets DevOps n'existent pas
Tous les projets sont finis. Vous développez, déployez votre solution et passez à autre chose. De plus, au cours des 10 dernières années, on a dit que DevOps était une amélioration continue et que l'amélioration continue était sans fin. À son tour, le résultat de vos projets sont des services de longue durée, et le service implique la séquence «Développement -> Déploiement -> Assistance santé»
Ce n'est qu'après avoir examiné les services en dehors des projets que nous pouvons voir des aspects facilement oubliés: les exigences non fonctionnelles. Les exigences non fonctionnelles incluent des fonctionnalités qui ne correspondent pas à un comportement spécifique. Ces exigences déterminent également notre évaluation des performances du système. Ces exigences incluent souvent des aspects classés comme DevOps: fiabilité, utilisabilité, maintenabilité et évolutivité. Toutes ces caractéristiques sont importantes pour obtenir des résultats commerciaux.
Lorsque vous travaillez sur des projets à court terme, vous risquez de ne pas accorder suffisamment d'attention à ce travail. Lorsque vous passerez au projet suivant, vous ne penserez plus aux exigences non fonctionnelles du précédent, car vous relèverez de nouveaux défis et le reste des problèmes ne vous dérangera plus. À son tour, lors de la gestion d'un service, vous êtes vraiment immergé dans le travail, et il est dans votre intérêt de tout peaufiner de manière à ce que tout se passe bien.
4. Les outils DevOps n'existent pas
Alors que de nombreux fournisseurs essaieront de vous vendre une variété d'outils, y compris un qui résoudra tous vos problèmes, DevOps ne concerne pas les outils. DevOps concerne les personnes et leurs interactions. Certains outils aident vraiment les gens à collaborer. Souvent, les outils peuvent aider des personnes d'horizons différents à partager la même terminologie et les mêmes écosystèmes. Pourtant, tout aussi souvent, les outils entravent une communication efficace.
Une culture basée sur les outils peut isoler les gens plutôt que les aider à interagir. Le fait est que les gens deviennent obsédés par leur chaîne d'outils et s'éloignent de ceux qui ne l'utilisent pas. Si certains outils peuvent être très utiles d'un point de vue technique, un certain nombre de nouveaux outils (appelés conventionnellement DevOps) ont élargi le fossé entre les différents groupes. Par exemple, j'entends souvent l'expression «cela fonctionne dans mon conteneur». Les développeurs utilisent cette phrase pour indiquer que «leur» travail est terminé. Les conteneurs en eux-mêmes ne résolvent pas les problèmes d'interopérabilité associés à l'exécution efficace des applications. Nous ne pouvons pas permettre aux outils de nous éloigner les uns des autres.
5. Il n'y a pas de certification dans DevOps
Aucun test à choix multiples ne peut confirmer que vous êtes capable de communiquer efficacement avec vos collègues. Les organisations proposant une certification peuvent avoir une expertise technique incroyable (et même une communication efficace), mais la certification ne peut pas montrer que quelqu'un est bon en DevOps.
Malheureusement, les équipes de direction exigent des certifications dans un domaine difficile à certifier. Familiarisez-vous avec vos logiciels et matériels préférés et explorez le cloud. Étudiez dans une université locale, lisez des livres dont vous pouvez apprendre beaucoup, en particulier des livres de Deming , Forsgren , Humble et bien d'autres... Mais ne vous attendez pas à être le meilleur de DevOps une fois que vous êtes certifié. Interagir avec des collègues est bien plus important.
6. Le pipeline DevOps n'existe pas
"DevOps a-t-il déjà fonctionné?" "Le pipeline DevOps fonctionne." "Le pipeline DevOps est cassé." Chaque fois que j'entends ces déclarations, je suis surpris que nous ayons trouvé cette terminologie. Avons-nous renommé le pipeline de déploiement, ou est-ce que dans certaines entreprises, les équipes DevOps travaillent sur cette infrastructure? Ou peut-être parce que les développeurs appellent l'équipe d'exploitation si le pipeline est cassé?
Malgré l'immense importance des technologies CI / CD, je suis sceptique quant à l'utilisation du terme «pipeline DevOps». Si le pipeline de développement se rompt, alors l'équipe des opérations est à blâmer. Les développeurs ne pensent pas au pipeline lorsqu'ils écrivent des tests. Le concept lui-même est également trompeur. Les pipelines sont construits pour chaque service ou application séparément, plutôt que sur l'ensemble du domaine DevOps. En créant des pipelines génériques, nous courons le risque d'augmenter l'écart entre les équipes, et ce n'est pas du tout l'objectif de DevOps.
Je recommande d'utiliser une technique que j'ai vue dans des centaines d'organisations à travers le monde: faire référence à chaque pipeline individuel comme un pipeline Application X. Cette terminologie permettra de savoir plus facilement quelle application rencontre des problèmes lors du test, du déploiement ou de la mise à niveau. Nous saurons également quelle équipe travaillera sur les correctifs de l'annexe X (éventuellement avec l'aide d'amis de l'équipe des opérations).
7. DevOps n'a pas de normes
Le plus difficile des milliers d'histoires DevOps est la standardisation. De la même manière que nous ne pouvons pas certifier les personnes, il n'y a pas de standard unique dans DevOps. Chaque organisation a son propre chemin, et ces chemins peuvent être très différents. Il n'y a pas de recette magique qui répertorie les outils et décrit les méthodes de création de flux d'automatisation qui deviendront soudainement DevOps dans votre organisation.
La norme dans DevOps signifie que vous appliquez une méthodologie spécifique qui permettra à votre organisation de commencer à collaborer et de s'éloigner de la politique du bureau, elle devrait également améliorer la qualité du travail, remonter le moral et vous permettre d'obtenir de meilleurs résultats avec moins de perturbations.
DevOps doit être compris comme un ensemble de pratiques similaires à la méthodologieITIL . N'oubliez pas que le L dans ITIL signifie Bibliothèque. Et cette bibliothèque ne doit pas être considérée comme un guide d'action, mais comme une liste de bonnes pratiques, à partir de laquelle vous devez choisir celle qui vous convient le mieux. ITIL a été détesté précisément à cause des implémentations infructueuses, dans lesquelles la bibliothèque a été utilisée précisément comme une instruction étape par étape. La standardisation dans DevOps conduira aux mêmes résultats.
8. Il n'existe pas de DevSecOps
Nous avons lancé DevOpsDays en 2009 et cette conférence était ouverte à tous. Bien sûr, au départ, c'était un événement pour les développeurs et les employés des équipes opérationnelles, mais tout le monde est venu vers nous: administrateurs de bases de données, testeurs, analystes d'affaires, financiers, et bien sûr spécialistes de la sécurité. En 2012, nous avons pris la parole lors des réunions de l' OWASP , parlant de ce que nous avons fait. Nous avons plaisanté en disant que le «S» dans DevOps représente la sécurité, tout comme le «S» en HTTPS.
DevOps est la sécurité au cœur. J'ai trouvé que les principes CD sont les mieux adaptés aux équipes de sécurité. Le CD est une exigence de sécurité: vous devez être en mesure de déployer à tout moment, cela vous donnera la possibilité de déployer et d'implémenter les mises à jour requises par votre entreprise ou des problèmes de sécurité.
D'une part, il est triste que nous devions trouver des mots pour inclure les personnes en charge de la sécurité. D'un autre côté, c'est bien que nous en ayons discuté à nouveau. Fondamentalement, il n'y a aucune différence entre DevSecOps et DevOps. La sécurité a toujours fait partie du développement et des opérations. Je peux utiliser le terme DevSecOps pour cela, mais il est préférable d'utiliser simplement le terme DevOps.
9. Vous ne pouvez pas passer à DevOps
Avez-vous déjà rencontré une entreprise qui fait une déclaration comme «Nous menons un projet DevOps au quatrième trimestre de cette année, et l'année prochaine nous passerons complètement à DevOps», ce qui a vraiment réussi? Donc je n'ai pas rencontré.
La livraison de logiciels ne s'arrête jamais, la technologie change toujours, elle a toujours besoin de soutien et (idéalement) l'approche et l'attitude envers DevOps devraient rester les mêmes. Une fois que vous aurez affiné votre approche de livraison, vous souhaiterez vous améliorer davantage. Pas parce que toutes les fonctionnalités de votre application ont été implémentées ou parce que l'écosystème dans lequel elle vit a cessé de se développer. Vous voudrez continuer à vous développer car la qualité de votre travail augmente de façon exponentielle et en même temps la qualité de vie augmente. DevOps continuera d'évoluer même après qu'une tâche ait obtenu le statut Terminé.
10. Il existe une chose telle que Dev-oops
Malheureusement, de nombreuses personnes ne comprennent pas l'importance de la collaboration. Ils construisent des murs entre les équipes, croient que les outils sont plus importants que les pratiques, exigent une certification de tout et de chacun. Ils pensent également que les 9 déclarations précédentes sont incorrectes. Et ces personnes lutteront à jamais pour réussir ce que j'appelle Dev-Oops.
DevOps consiste à penser que les outils et la séparation des équipes sont plus importants que les vrais principes DevOps qui peuvent améliorer votre travail. Efforçons-nous de faire du DevOps, pas du DevOops.
L'objectif principal
Nous dirigeons DevOpsDays depuis 10 ans et pendant ce temps, des milliers de personnes ont appris beaucoup de choses intéressantes les unes des autres dans un environnement facile et ouvert. Certains des concepts que je trouve en conflit avec les objectifs du DevOps et de l'agilité sont populaires. Concentrez-vous sur l'obtention de vos services pour aider votre entreprise et n'arrêtez pas d'apprendre. Et il ne s'agit pas de copier des outils et de les implémenter dans votre organisation. Il s'agit de se concentrer sur l'amélioration continue de toutes les manières.
Apprenez-en plus sur la façon d'obtenir une profession de haut niveau à partir de zéro ou de monter en gamme en termes de compétences et de salaire en suivant les cours en ligne rémunérés de SkillFactory:
- Cours DevOps (12 mois)
Plus de cours
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )