Mouvement DevOps

Plus qu’un simple accès root pour les développeurs !

Ou même pas ça. La grande idée derrière le “mouvement” ne donne pas simplement aux développeurs plus de corde ; il s’agit d’assurer de meilleures lignes de communication entre les équipes développeurs et opérations de l’entreprise. Une grande partie de cela n’est pas nouvelle, en fait, c’est une refonte du mouvement kaizen ⁇ au sein des chaînes d’approvisionnement industrielles traditionnelles (en particulier l’automobile) au cours du siècle précédent. Les tableaux de bord Kanban ne sont que la dernière refonte des tableaux de bord (doublement en tant que gestionnaires d’inventaire de flux de travail) couvrant l’effort quotidien collectif pour expédier des produits de qualité qui plaisent aux clients et aux partenaires commerciaux.

La gestion des contraintes est essentielle au processus. En identifiant tout d’abord les goulets d’étranglement dans le système, vous pouvez recentrer vos efforts sur l’optimisation de ces ressources pour une efficacité maximale. Les optimisations au-delà de ces zones ne valent presque toujours pas la peine — le workflow sera toujours limité par ces ressources.

Développement basé sur le tronc

Encourager les changements progressifs grâce à des processus automatisés de test, de promotion et de libération selon une cadence planifiée est un excellent moyen de faire rouler le ballon, mais une grande partie du contrôle de la qualité dans les déploiements SaaS/PaaS implique l’adoption développement basé sur le tronc et ses concepts de branche par abstraction. (Veuillez visiter le lien pour une discussion approfondie des caractéristiques et des inconvénients).

En substance, le multivers du long terme git Les branches créent la fiction psychologique que la fusion combinée de tous ces travaux de développement local (et de tests !) conduira à un tout qui est au moins aussi grand que la somme de ses parties. L’expérience est le meilleur juge, ce qui indique que des ensembles complets de nouvelles fonctionnalités devraient être conçus incrémentalement, in-situ, sur le code source existant de la succursale de production/libération. Fondamentalement, vous concevez vos stratégies de développement dans les limites de la physique du monde biologique, qui dit :

        Surgery on a patient must result
        in good outcomes (at all times) for
        that patient, not just for siblings
        or future generations.

Pipelines CI/CD

Le développement basé sur le tronc est la base de tous les pipelines de contrôle des modifications automatisés qui ont grandi au cours des deux dernières décennies.

Code Is Law (Développement + Infrastructure + Configuration)

Un peu de perspective historique d’abord ; la ligne de poinçon suit ces quatre paragraphes. Le fil conducteur ici est qu’Apache a presque toujours été en avance sur son temps.

Retour dans le pré-CFEngine Apache Software Foundation a conservé tous ses fichiers de configuration informatique et scripts de support dans CVS, puis Subversion. En outre, chaque service que nous avons exécuté était associé à “carnet d’adresses” pour guider les administrateurs dans leurs tâches de maintenance pratiques.

Le workflow était moins qu’idéal : outre la création de nos propres arborescences de ports FreeBSD corrigées localement dans des packages (binaires) déployables à partir de zéro, le personnel a dû exercer une discipline difficile à appliquer lors du déploiement des modifications en production, en s’engageant d’abord dans le contrôle des versions, en se connectant au serveur cible, en mettant à jour son paiement et en redémarrant potentiellement le service — tout ce travail répétitif effectué à la main. En réalité, la plupart du temps, les administrateurs système ont piraté directement sur le serveur cible et se sont engagés à partir du paiement de ce serveur, risquant beaucoup de conflits de fusion au fur et à mesure que l’arbre était mis à jour (soit alors, soit à un moment donné par des actions futures exécutées par un autre membre du personnel). Un flux de travail plutôt moins transparent, avec une sécurité douteuse de gestion des mots de passe, pour une équipe d’opérations collaborative.

De nos jours, ils gardent tout dans un git-Arbre source de marionnettes soutenu, et provisionnement / déploiement / configuration directement dans le cloud à l’aide de packages Ubuntu génériques en amont, qui est une approche quelque peu moderne de leurs travaux informatiques, depuis programmé git Les extraits par le maître de marionnettes finiront par déployer des mises à jour lorsque les agents de marionnettes se réinséreront. Mais l’intégration continue et le déploiement continu sont en cours, même à ce jour.

D’autre part, une initiative précoce et révolutionnaire de type CI à l’ASF (pour les projets réels de TLP du logiciel Apache) a été Apache Gump, qui a été le fruit de brillants collègues comme Sam Ruby et la société. Ce que gump a fait, c’est vérifier périodiquement, construire et tester HEAD (y compris HEAD de tous les dépôts) du tronc de chaque base de code dans le dépôt Subversion (mais remonte à CVS) pour chaque projet, il pouvait réussir à comprendre comment construire (qui était par et largement limité aux projets Java à l’origine). Les rapports ont été automatiquement envoyés à chaque communauté de développement et archivés pour la postérité. Cette activité d’ automatisation du travail perspicace se poursuit encore (avec git) jusqu’à ce jour ! Toute communauté de développement de taille entreprise n’exécutant pas son propre serveur Gump est 20y derrière l’état de la technique à l’ASF (IMO ; ne me lancez pas sur les dépendances des modules logiciels épinglés en version open source dans /trunk|master/ …).

Voici le point en bref : toutes vos sources (développement, infrastructure et configuration) appartiennent au contrôle des versions (ne partageant pas nécessairement le même référentiel) qui peut être examiné par tout le personnel de devops et fait partie de votre ensemble complet de pipelines de test-automatisation entre les révisions de patch et les déploiements de production. Une enquête sur l’état de la technique, où les changements sont testés/provisionnés/déployés sur demande dans les paramètres IaC/CaC, est sur le site de mon ami et visionnaire Paul Hammant ici. Je vous en prie, jetez un œil !

Virtualisation et conteneurisation

A Animaux vs. Bovins Redux.

Les systèmes de conteneurs tels que Docker sont des technologies de virtualisation redéployables et personnalisables qui sont généralement utilisées pour prendre en charge une structure de cluster d’applications MicroService Architecture (MSA) comme Kubernetes. Ils reprennent là où les systèmes de virtualisation se sont arrêtés, négociant une prise en charge illimitée des systèmes d’exploitation par machine virtuelle (entièrement) isolés pour les machines virtuelles basées sur le noyau Linux qui ont une personnalisation et une intégration beaucoup plus programmables avec l’hôte Linux parent sur lequel ils s’exécutent. En outre, ils peuvent être reconstruits et téléchargés vers un service de distribution central (comme l’artefact) pour une réutilisation à grande échelle dans plusieurs chaînes de dépendance et des déploiements de serveur exécutable brut.

Mise à l’échelle verticale et horizontale

Les conteneurs reconfigurables téléchargeables à partir d’un serveur central permettent des possibilités difficiles à réaliser avec la technologie de virtualisation de base - vous n’êtes pas bloqué dans les limites matérielles d’un serveur unique pour faire évoluer vos services pour répondre à la demande. En d’autres termes, la mise à l’échelle horizontale en déployant le même conteneur dans des ensembles d’hôtes, à la demande, est une fonctionnalité de première classe immédiatement réalisable des structures MSA basées sur Docker. De même que le déploiement de dizaines de conteneurs supplémentaires que les coeurs de processeur sur le même hôte.

Mesurer, limiter et contrôler les efforts de lutte contre l’incendie, réels et pratiqués

L’une des autres choses clés à reconnaître est de faire la distinction entre le travail planifié et non planifié dans l’une de vos mesures de suivi de la productivité et la façon dont les ressources sont allouées à ces tâches. Le travail non planifié équivaut à lutte contre les incendies, et si trop de temps (plus de ~20 %) est consacré à ces tâches, le travail planifié, qui est le véritable besoin de l’entreprise, est en retard.

Les goulets d’étranglement dans le système peuvent rarement faire face au travail non planifié, il est donc important d’avoir suffisamment de ressources supplémentaires pour gérer la charge accrue et le carnet de commandes qui en résulte.

L’une des principales leçons tirées de la COVID-19 au début de 2020, en tant que capacité hospitalière en termes d’informatique, est qu’il y a une chose telle qu’être trop maigre, du moins en ce qui concerne la dotation en personnel devops (le matériel est une autre histoire). Planification d’urgence pour une journée pluvieuse, soit avec “redondant” personnel ou des initiatives de formation croisée, combinées à des exercices préparatoires réguliers, non seulement éloignent le médecin, mais sont en fait critiques.

Utiliser le programme

Au niveau de la gestion, une perspective globale de gestion du changement entre les changements des développeurs et des opérations est essentielle. Les deux équipes doivent être conscientes des changements de l’autre. Idéalement avec les détails de planification mis à disposition en cours de route. De grandes choses peuvent se produire lorsque les équipes sont un mélange sain de développeurs et de personnel d’exploitation, dans une culture transparente et axée sur les données du travail collaboratif.

La philosophie de l’inclusion de multiples parties prenantes dans la création et l’ évolution d’un produit de travail tangible a des implications bien au-delà des équipes dev et ops qui partagent le contrôle et la responsabilité d’un effort d’ingénierie de serveur. Cette leçon ne cesse d’être répétée dans le monde des entreprises moderne, car de nouveaux domaines d’expression humaine créative prennent forme dans le secteur des entreprises, ainsi que dans la réinvention des anciennes façons de faire des affaires ensemble.