La position actuelle:Accueil du site>C'est la capacité, c'est la culture.

C'est la capacité, c'est la culture.

2022-05-14 13:57:24InfoQ

Introduction

Dans un article précédent
Si seulement une semaine,Comment améliorer rapidement la stabilité du système en ligne?
Nous résumons l'impactITFacteurs de qualité et de stabilité du système et moyens d'améliorer rapidement la qualité et la stabilité du système.Nous connaissons les accidents de production et la conception architecturale、Développement de code、Changement en ligne、Configuration de l'entreprise、Les opérations d’exploitation et d’entretien et les dépendances externes sont liées à l’ensemble du cycle de vie de l’exploitation et de l’entretien.,Et les problèmes de code architectural(CodeBug+Conception architecturale)Environ30%,Et un rendez - vous.70%L'accident se produit entre le codage du programme et le fonctionnement réel.,Peu importe le Code d'architecture lui - même.Ces problèmes de code non Architectural sont principalement liés àITErreur de changement、Erreur de configuration des paramètres opérationnels、Capacité de performance insuffisante、Erreur de dépendance externe du système etITFacteurs liés aux erreurs d'exploitation et d'entretien.Parmi euxITLes erreurs de modification et de configuration des paramètres opérationnels sont en fait liées à la publication des versions.,Si le calcul est combiné, les deux types de facteurs sont responsables de tous les accidents de production.20%Ci - dessus,Problèmes de code non architecturaux1/3Gauche et droite.Aujourd'hui, nous résumons les pratiques et l'expérience en matière de sécurité..

Qu'est - ce qu'une version?

Tout d'abord,,Nous devons d'abord clarifier les définitions suivantes:,Pour s'assurer qu'on parle de la même chose que vous..
Premièrement,Qu'est - ce qu'une version
?Tout ce qui est fait parITMise en œuvre,Ce qui modifie le comportement du système de production(Même si ce n'est qu'un changement dans les paramètres du système)La collection et les procédures sont une version.Il inclut à la fois la version elle - même,Y compris le processus de publication.
Deuxièmement,Quelles procédures sont incluses dans une version?
Comme une version comprend un processus de publication , Quel est le processus? ?Comme le montre la figure ci - dessous, L'équipe de l'auteur pense qu'une version est publiée à partir de “Exigences de version”C'est parti., À la fin et au début de la publication “Suivi des publications”Fin, Inclure au moins une clarification des exigences de mainlevée 、 Élaboration d'une stratégie de diffusion 、 Préparation de la version à publier 、 Exécution de plusieurs étapes, comme la publication et le suivi de la publication .
null
Troisièmement,Classification des versions
. Dans le cadre de la mise en oeuvre de la philosophie de libération sécuritaire , Le contenu ciblé et le processus de sécurité varient considérablement d'une version à l'autre. . D'après l'expérience pratique de l'équipe de l'auteur , Nous classons approximativement les versions par taille de publication comme suit: :
  • Petite version
    . Les exigences en matière de publication peuvent être minimes Feature,Ou peut - être unBugFix, Il ne s'agit généralement que d'un module système ou d'un microservice lui - même. .
  • Version massive
    . Les exigences de publication peuvent être une grande itération de mise à niveau technique , Par exemple, l'architecture du système passe d'une application monomère à une architecture de micro - services , Ou un changement radical dans la structure de la base de données du modèle de données . Ou peut - être la dernière grande entreprise en ligne , Comme une nouvelle entreprise 0À1Publication, Impliquant plusieurs systèmes ou services en amont et en aval , La publication elle - même peut être effectuée en plusieurs étapes .
  • Version normale
    . Entre petites et grandes versions , Peut impliquer un ou plusieurs (Pas plus de3- Oui.) Différents modules ou changements de microservice , Il n'y a pas de changement important dans l'architecture du système ou le modèle d'entreprise , Une version normale peut être mise en ligne une fois publiée .

Comment mettre en pratique la libération de sécurité ?

L'équipe de l'auteur s'est penchée sur les accidents de production causés directement par la publication de versions antérieures. ( Environ tous les accidents 20%) Subdivisé ,Obtenir les données suivantes.
null
Le Code lui - même n'est pas inclus ici Bug Problèmes de production , Parce que quand on compte les accidents de production ,CodeBug Les questions sont classées séparément . Selon la pratique à long terme , Basé sur le concept de cycle de vie de la version et le rapport de classification des accidents ci - dessus , L'équipe de l'auteur prend différentes mesures en fonction de la taille de la version pour assurer la sécurité de la publication. .
Voyons d'abord.
Petites versions
. La publication à petite échelle n'implique généralement pas de collaboration en amont et en aval. , Les scénarios de publication peuvent être aussi simples que “Développement-Tests-Publication”Processus simple pour.C'est - à - dire, La clé de la sortie à petite échelle est de s'assurer que le code bien connu lui - même est de qualité fiable. , Le processus de déploiement en ligne peut être effectué sans surprise . L'analyse historique des accidents nous dit aussi , Problèmes de qualité du Code 30%,“ Mauvais fonctionnement du changement + Tester les données sales ” Les erreurs humaines de fonctionnement pendant le déploiement en ligne représentent au moins 10%Ci - dessus. Pour résoudre ces deux types de problèmes, , L'industrie a beaucoup de bonnes pratiques . Comme un examen de code inter - événement 、 Seuil de qualité strictement appliqué 、 Des pratiques telles que l'automatisation des fonctions et des essais de performance garantissent la qualité du Code lui - même. ; Les pipelines répétables de changement de déploiement automatisent entièrement le processus de déploiement , Éviter les erreurs humaines .C'est tout.DevOps Et les problèmes à résoudre dans la théorie de la prestation continue , Il y a d'innombrables documents pertinents ,Ne pas agrandir ici.
Revenez voir
Version normale publiée
Et
Version massive
. La différence essentielle par rapport à une version plus petite est que , Ces deux types de publications impliquent plus de modules ou de services système , Nécessité d'une plus grande coordination en amont et en aval . Comme vous pouvez le voir ci - dessus, la classification des accidents représente ,“ Erreur de schéma de publication ”Et“Collaboration en amont et en aval” Les erreurs de changement associées aux accidents de production représentent au moins 30%, Si l'on ne tient compte que de la nécessité d'élaborer un plan de libération détaillé et un plan de collaboration en amont et en aval pour la libération à grande échelle, , La proportion d'accidents de production causés par ces problèmes sera plus élevée .Donc,, Version à grande échelle , Sauf pour les petites versions DevOps Au - delà des pratiques de prestation continue , Il est plus important d'élaborer une stratégie de diffusion et un mécanisme de collaboration en amont et en aval. , Assurer la sécurité des rejets à la source .En bas, Concentrons - nous sur ces deux types de questions .

Processus de lancement de la recherche et du développement axés sur la publication

Analyse plus approfondie des accidents de production causés par des erreurs dans le plan de libération ou la collaboration en amont et en aval , On a trouvé ça
Mauvais comportement
En fait, il peut être résumé comme suit :
  • Seuls les changements apportés à l'architecture du système et les calendriers de développement sont pris en compte dans le traitement des grandes exigences opérationnelles. ,
    Le plan de publication et l'architecture du système ne sont pas considérés du point de vue de la publication
  • La stratégie de publication a été élaborée trop tard
    , L'impact des modules associés n'a été identifié qu'avant la publication de l'exigence principale. , Pour provoquer ou retarder la mise en service d'une jambe boiteuse
  • Système ou architecture trop complexe ,
    Évaluation inadéquate ou omission de l'évaluation
    Cause des défauts en ligne du système
  • La stratégie de publication est trop radicale
    , Prendre une seule fois BigBangChangements, Le rythme de publication et les ajustements de l'architecture du système n'ont pas été pleinement pris en compte du point de vue de l'impact opérationnel.
  • Plan de libération non pris en considération ,Sous la forme
    . Aucun plan de secours d'urgence n'a été élaboré ou ne peut être mis en œuvre.
Pour résoudre ces problèmes, Pour une libération sûre , Besoin d'un centre de publication clair “
Processus de lancement de la recherche et du développement axés sur la publication
”.En bas, Nous décrivons les éléments clés de ce processus en prenant comme exemple une version à grande échelle typique. .
Exemple:
Dans l'une des principales activités de l'entreprise , Deux systèmes parallèles fonctionnent , L'ancien système était une application monolithique basée sur la base de données à l'époque précédente , Le nouveau système est un système distribué basé sur l'informatique en mémoire . Après une période de validation parallèle , L'entreprise décide de migrer la majeure partie du trafic restant vers le nouveau système , Le processus de migration doit tenir pleinement compte de la continuité des opérations existantes. , Retards dans la conduite des affaires après la migration 、TPS Et des performances telles que la capacité . Les anciens et les nouveaux systèmes ne sont pas compatibles sur le plan des données , Le nouveau système implique plusieurs centres de données .

  • Élaborer une stratégie de publication exécutable et déplacer la phase de formulation de la politique à gauche .
Pour les grandes versions , La première chose à faire après la détermination des exigences en matière de mainlevée est d'élaborer une stratégie de mainlevée exécutoire. , Au lieu de concevoir l'architecture , Parfois, il faut même adapter les exigences de publication aux politiques de publication. . Une bonne stratégie de publication est une stratégie réalisable , Le contenu et l'Organisation de la publication doivent être clairs (Version),Plan de publication, Et la sécurité organisationnelle et humaine dans la mise en œuvre du plan .
  • La politique de publication contient au moins “ Version Scheme ”Et“Plan de publication”Deux parties. Le schéma de version fait référence aux limites du système et aux composants du module déterminés en fonction des exigences de version. . Qu'il y ait ou non des modifications de code ou de configuration dans le système ou le module concerné , Dans la mesure où il s'agit d'un système lié à l'achèvement des exigences correspondantes , Fait partie du schéma de version . Le plan de publication est conçu pour les versions de publication identifiées , Identifier les parties concernées et définir un plan complet pour la mise en œuvre de la version . Au début de l'élaboration de la stratégie de publication , Peut - être pas très clair. DayByDayPlan, L'accent est mis sur l'identification des parties concernées et des responsabilités correspondantes. ,Et à partIT Soutien organisationnel nécessaire pour assurer la mise en œuvre de la version en dehors du changement de système .
  • La stratégie de publication exige l'approbation et le soutien de tous les participants directs. . Un participant direct est un participant qui: “ Version Scheme ” Toutes les parties impliquées dans 、 Product Manager 、Équipe R & D、Équipe d'essai、 Équipe o & M et équipes liées à l’infrastructure et à la sécurité .
  • Politique de publication pour désigner un responsable de publication clair .
Prenons l'exemple des exigences en matière de migration des entreprises dans l'exemple . Cette version inclut les anciens systèmes 、Nouveau système、 Données commerciales dans les anciens et les nouveaux systèmes et systèmes de base de données correspondants 、 Infrastructure du Centre de données et du Réseau pour l'exploitation des anciens et des nouveaux systèmes . Parce que les données des anciens et des nouveaux systèmes ne sont pas compatibles et que les nouveaux systèmes impliquent plusieurs centres de données , En plus de se concentrer sur les modifications que le nouveau système lui - même peut impliquer , Le plan de publication doit mettre l'accent sur le plan de migration des données commerciales. , Système de soutien de l'infrastructure sous - jacente après la migration des entreprises vers le nouveau système et mise en place d'un mécanisme de suivi et de rétroaction après la migration des entreprises vers le système distribué .C'est évident, Pour réussir la migration des entreprises , La personne responsable du produit qui peut coordonner plusieurs parties ou la personne responsable du nouveau système est la personne responsable de la libération idéale. . Dès que ce qui précède a été établi , Le responsable de la mainlevée devrait convoquer toutes les parties intéressées pour discuter pleinement des questions clés du plan. , Élaboration d & apos; un programme et d & apos; un plan d & apos; action cohérents .

  • Ajuster la conception de l'architecture et le plan d'essai en fonction de la politique de publication
    .
La principale raison pour laquelle la phase de la politique de publication a été déplacée à gauche avant la conception de l'architecture était que , Le schéma de version formulé dans la stratégie de publication nécessite souvent la conception de l'architecture et la coordination du schéma d'essai correspondant. .
Par exemple, les exigences en matière de migration des entreprises dans l'exemple , Il existe au moins deux versions différentes /Programme de migration.
Programme I: Migration ponctuelle des données commerciales de l'ancien système vers le nouveau système , S'assurer que les données d'affaires peuvent être retournées à l'ancien système en même temps en cas de problème avec le nouveau système pendant la mise en service après la migration .
Conception architecturale: Mettre l'accent sur la conception de systèmes et d'outils de récupération appropriés pour assurer la faisabilité de la récupération ponctuelle des données d'affaires et la faible consommation de temps .
Protocole d'essai: Mettre l'accent sur la mise à l'essai et l'exercice du plan de migration et de récupération des données commerciales et du temps nécessaire .
Programme II: Migrer les données commerciales de l'ancien système vers le nouveau système par lots , Routage en fonction des différents clients dans la phase d'accès des clients , Les demandes d'accès sont acheminées simultanément vers les anciens et les nouveaux systèmes lors de la migration par lots. , Le nouveau système accepte les demandes et les traite sans retourner de réponse , À des fins de vérification seulement , Basculer le trafic réel après vérification .
Conception architecturale: Nouvelle passerelle d'accès client et prise en charge des anciens et des nouveaux systèmes , Routage de l'accès au service en fonction de la politique par lots du Service , Et prend en charge le changement de logique de routage pendant l'exécution ; Il est possible que l'ancien système puisse être modifié en conséquence pour rendre possible la migration de la partie opérationnelle. .
Protocole d'essai: Mettre l'accent sur l'essai de la capacité d'acheminement personnalisée de la passerelle d'accès et de la stabilité et de la performance de l'acheminement de la passerelle , Les essais doivent être effectués dans la mesure du possible. 100% Simuler le déploiement réel de l'environnement de production cible . Si l'ancien système nécessite également des modifications architecturales , Le plan d'essai correspondant est également nécessaire .

  • Organiser le propriétaire pour examiner et publier le plan d'exécution détaillé le plus tôt possible
    .
Une fois que les modifications pertinentes de la version publiée sont essentiellement terminées , Un plan détaillé d'exécution de la mainlevée doit être élaboré en même temps que la vérification des essais et la personne responsable de la mainlevée doit convoquer toutes les parties concernées pour examen afin de verrouiller les ressources de mainlevée ou d'apporter les ajustements et les modifications nécessaires. . Le plan d'exécution de la publication devrait comprendre au moins les éléments de base suivants: :

Lors de la mise en œuvre du plan d'exécution , Il est préférable d'avoir une norme pour chaque élément principal checklist, Et de manière standard ( Comme le calendrier d'exécution ou le système de gestion du changement, etc. ) Gestion intégrée de tous les plans d'exécution de la mainlevée , Facilité d'intégration avec le mécanisme de gestion des rejets et amélioration progressive .

  • Des exercices complets doivent être effectués sur les liens clés impliquant une coordination et un fonctionnement plus manuels. .
Comme dans le premier scénario de l'exemple , Les processus de migration et de récupération uniques des données d'affaires peuvent eux - mêmes impliquer une collaboration multipartite , Doit être combiné à la conception architecturale 、 Migrer les outils de Fetch, etc. , Organiser tout le personnel pour effectuer des exercices à l'avance ,Encore quelques fois.

  • La fin de l'exécution de la publication n'est pas égale à la fin de la publication , La confirmation de suivi après la publication est le signe de la fin de la publication. .
Seulement si“ Première liste de contrôle ” Toutes les vérifications ont été écrasées et vérifiées pour s'assurer qu'elles sont correctes. , Cette publication est terminée. .

La libération de sécurité devrait devenir une culture

L'équipe de l'auteur a fait beaucoup d'exploration 、 Pratiques et améliorations , Enfin, une certaine expérience pratique et une certaine méthodologie ont été précipitées .Vous avez peut - être découvert, La libération de sécurité ci - dessus est recommandée “
Processus de lancement de la recherche et du développement axés sur la publication
” En fait, seuls les liens clés impliqués dans la libération de sécurité sont décrits. , Contenu de base du travail pour chaque lien clé , Aucune recommandation n'a été donnée sur la façon dont ces travaux devraient être entrepris et par qui. .
En fait, Il existe de nombreuses façons d'obtenir la libération de sécurité ci - dessus. . L'équipe de l'auteur a effectué l'examen du changement 、 Suivi des accidents 、Analyse des accidents、 Pratique de forage et de modification de l'architecture visant à la stabilité ,Il y a des gains et des pertes. Nous avons constaté que nous voulions maximiser l'efficacité des processus et des pratiques de travail décrits ci - dessus. , Le facteur le plus important pour maximiser la sécurité des rejets est en fait
Responsable de la publication de chaque version / Si l'exécuteur testamentaire est en mesure de mettre en oeuvre le processus de haute qualité
, Cela inclut ses propres capacités , Y compris la capacité organisationnelle .Donc,,
Si c'est le cas,“ Processus de lancement de la recherche et du développement axés sur la publication ” Pour aider les organisations et les gens à améliorer leurs capacités en matière de sécurité , La mise en œuvre de ce processus de haute qualité est une culture de libération sûre
. Les principes suivants doivent être respectés pour favoriser une culture de libération sécuritaire: :
Principe I
: La personne responsable de la libération de chaque version est entièrement responsable de la libération de la sécurité de la version.
Principe II
: L'organisation ou le gestionnaire devrait créer des mécanismes appropriés pour permettre aux responsables de la mise en oeuvre de la version d'assumer l'entière responsabilité.
Principe III
:Tiens bon.“ Processus de lancement de la recherche et du développement axés sur la publication ”, Publier la sécurité comme processus de R & D 、 Critères d'évaluation importants pour déterminer si la conception de l'architecture est raisonnable ou non
Principe 4
:Petit pas, cours., Faites de votre mieux pour éviter les versions massives , Publier des versions à grande échelle seulement lorsque cela n'est pas possible

Références

  • 《DevOps Guide pratique》
  • 《Exécution continue》

Mentions de copyright
Auteur de cet article [InfoQ],Réimpression s’il vous plaît apporter le lien vers l’original, merci
https://fra.chowdera.com/2022/134/202205141342145066.html

Recommandé au hasard