Maison > Tutoriel système > Linux > le corps du texte

Application de l'évolution automatisée en SRE

PHPz
Libérer: 2024-01-15 21:30:06
avant
1352 Les gens l'ont consulté
Présentation SRE est l'abréviation de Site Reliability Engineering. Il s'agit d'un nouveau modèle d'exploitation et de maintenance qui a évolué à partir du processus interne d'assurance technique des produits de Google et définit l'étendue des responsabilités du nouveau poste. Différent du modèle d'exploitation et de maintenance traditionnel, SRE met l'accent sur les systèmes automatisés et préconise le développement de certains outils d'exploitation et de maintenance automatisés basés sur des scénarios grâce à des méthodes d'ingénierie logicielle pour remplacer les opérations répétitives et manuelles. Dans ce Chat, nous présenterons l'évolution de l'automatisation du SRE à travers quelques cas de pratiques SRE étrangères.

Le contenu comprend :
La valeur des systèmes automatisés pour les SRE ; L'évolution des systèmes d'automatisation ;
Cas d'application de l'automatisation SRE de sociétés Internet étrangères ;
Pratique de l'automatisation dans le domaine de l'exploitation et de la maintenance domestiques.

1. Qu'est-ce que le SRE ? SRE est l'abréviation de Site Reliability Engineering. C'est un mot ou un poste nouvellement défini provenant de sociétés Internet étrangères. À l’ère du modèle traditionnel d’administrateur système, nous appelions ce rôle opération et maintenance, et à l’étranger, cela s’appelait Opération.

Le vice-président de Google SRE est Ben Treynor. Lorsqu'il a rejoint l'entreprise en 2003, sa première tâche était de former une « équipe d'exploitation et de maintenance de la production » de 7 personnes. Mais il a vite découvert que, compte tenu de la vitesse d'augmentation du nombre de machines Google, le modèle traditionnel d'exploitation et de maintenance ne pouvait pas répondre rapidement aux exigences d'exploitation et de maintenance fiables. Puisqu'il est lui-même développeur de logiciels senior, il a formé l'équipe d'exploitation et de maintenance, tout comme une équipe de R&D. Nous avons recruté de nombreux ingénieurs R&D qui ont des capacités de développement et des connaissances en gestion de système. Le plus important est qu'ils méprisent le travail répétitif. Ils consolident certaines bonnes pratiques, méthodes, processus et méthodes dans le code et utilisent cette méthode pour faire face à l'expansion de l'échelle et à l'augmentation de la complexité.

2. La valeur du système d'automatisation pour SRE Les activités SRE typiques sont divisées en quatre parties : l'ingénierie logicielle, l'ingénierie système, les anecdotes et la charge de processus. Parmi eux, nous pouvons voir qu'il existe un type de travail qui est directement lié aux services quotidiens d'exploitation et de maintenance, mais il est défini comme un travail inefficace dans SRE, et Google utilise toujours un mot spécial - Travail pour le décrire.

Trivia est un travail manuel, répétitif et tactique dans les services d'exploitation et de maintenance. Sa croissance est linéaire avec celle des services. Cette partie du travail peut être automatisée. Google a publiquement proposé que les SRE veillent à ce qu'au moins 50 % de leur temps soit consacré à des projets d'ingénierie logicielle, car si elles ne sont pas contrôlées, les questions triviales deviendront de plus en plus nombreuses et occuperont rapidement la majeure partie du temps du personnel SRE. Le travail de réduction des questions insignifiantes et d’expansion de l’échelle des services est le E (Ingénierie) du SRE.

De cette vidéo, nous pouvons voir que la valeur de l'automatisation pour le SRE vient principalement de deux aspects : la performance et l'efficacité. Lorsqu'il s'agit d'automatisation, la première chose à laquelle beaucoup de gens pensent est l'amélioration de l'efficacité. En fait, plutôt que la simple amélioration de l'efficacité, le personnel de SRE met l'accent sur l'équilibre entre les performances du système, la vitesse et la flexibilité. L'automatisation garantit les performances du système en éliminant les incohérences causées par l'exécution manuelle des opérations et en garantissant « une exécution cohérente des procédures avec une portée claire et des étapes connues ». C'est la valeur principale de l'automatisation.

Les systèmes d'automatisation peuvent fournir une plate-forme évolutive et largement applicable. La plateforme peut centraliser les problèmes, gérer les erreurs système à grande échelle et exécuter des tâches de manière plus continue et plus fréquente que les humains. Et comme la plateforme peut exposer ses propres indicateurs de performance, elle peut également nous aider à découvrir des détails qui n’étaient pas facilement perceptibles lors du processus précédent. Bien entendu, la base de la plateforme réside dans une conception et une mise en œuvre correctes. Il nous est plus facile de comprendre l’amélioration que l’automatisation apporte à l’efficacité. Bien que nous comparions et analysons souvent l'effort et le temps consacrés à l'écriture d'un programme automatisé et la partie économisée en annulant le travail manuel, nous devrions voir qu'une fois l'automatisation mise en œuvre, une certaine opération sera découplée de l'opérateur spécifique, donc lorsque nous procéderons quand mesurés, le temps et les efforts économisés grâce à l’automatisation devraient bénéficier à tous les utilisateurs.

Joseph Bironas, SRE responsable du processus en ligne du cluster de centres de données Google, a déclaré un jour : "Si nous continuons à produire des processus et des solutions qui ne peuvent pas être automatisés, nous continuerons à avoir besoin de personnes pour effectuer la maintenance du système. Si nous devons embaucher du personnel pour le faire, ce travail revient à nourrir les machines avec du sang humain, de la sueur et des larmes. C'est comme un monde Matrix sans effets spéciaux mais rempli d'administrateurs système en colère. "

3. L'évolution de l'automatisation Le processus d'automatisation de Google SRE est passé par les étapes ci-dessus. La première étape est une étape de non-automatisation qui repose entièrement sur des opérations manuelles, puis utilise des scripts d'automatisation spécifiques au système gérés en externe pour fonctionner. L'automatisation spécifique du système évolue progressivement vers l'automatisation générale du système, puis remplace les systèmes d'automatisation gérés en externe par une automatisation gérée en interne. Le système automatisé a finalement évolué vers un système automatisé intégré à la plate-forme d'exploitation et de maintenance et ne nécessitant pas de déclenchement manuel.

4. Cas d'application de l'automatisation SRE de sociétés Internet étrangères Le système de gestion des ressources de Google, Borg, est un système de publication d'applications automatisé typique que Google SRE utilise depuis longtemps. Pourquoi la gestion des ressources est-elle si importante ? Parce que l'échelle est trop grande, les coûts d'exploitation deviennent le seul obstacle à l'évolution. Techniquement parlant, un système de gestion unifié des ressources est très difficile à mettre en œuvre et la qualité de l'infrastructure détermine les capacités de ce système. En particulier dans un environnement distribué, les exigences en matière de serveurs physiques dans différents scénarios commerciaux ne sont pas exactement les mêmes. La condition préalable pour que Borg de Google puisse parvenir à une gestion unifiée des ressources est la prise en charge de technologies de base telles que GoogleFS, BigTable, Chubby, GSLB, etc. SRE est l'utilisateur de ce système et fournit constamment des commentaires et améliore l'utilisation du système Borg pour la fiabilité du système. . Exigences, jusqu'à présent, Borg est toujours le système de publication d'applications utilisé en interne par Google.

Tout d'abord, le système Borg est une architecture système entièrement en couches. Du système de fichiers le plus basique au déchargement de charge supérieur, chaque couche de la pile technologique est unique au sein de Google. L'avantage est que l'expérience peut être accumulée et réutilisée. L'architecture des systèmes des entreprises nationales passera également par une structure organisationnelle hiérarchique dans le processus de développement. Au-delà des facteurs humains, de nombreuses hiérarchies sont construites en combinant plusieurs systèmes. En apparence, nous avons réduit les coûts, mais en réalité, nous avons augmenté les coûts de maintenance de la main-d'œuvre. À ce stade, l’avancement des systèmes étrangers peut être mis de côté. Que devons-nous faire lors du choix de la technologie ? Par expérience, le système à une seule couche composé de plusieurs systèmes open source partagés par des pairs est une méthode raccourcie avec des effets évidents à court terme. Une fois que les activités d'une entreprise se développent à un rythme rapide, chaque refactorisation est un outil dévastateur pour renverser et recommencer. Grâce à mon expérience dans divers systèmes d'entreprise, grandes et petites, je comprends profondément cette dynamique de changement. En SRE, l'idée de changer d'outil n'est pas de remplacer les anciens outils open source par de nouveaux outils open source, mais nos exigences de fiabilité doivent simplifier le nombre de sélections d'outils et véritablement prendre en compte nos propres besoins sur cette base. à la fin, nous devons La route vers des systèmes d'automatisation auto-développés.

Deuxièmement, la technologie d'infrastructure du système Borg est suffisamment avancée. Le SRE n'est-il pas un peu redondant ? Évidemment, le progrès technologique ne peut pas remplacer la méthodologie SRE. Le concept DevOps le plus populaire du secteur n'inclut actuellement pas davantage de descriptions de coût et de fiabilité. Il se concentre sur diverses pratiques telles que l'automatisation et l'amélioration de la productivité. Ces pratiques ne peuvent pas résoudre le problème central du développement durable des scénarios commerciaux, qui est l’équilibre entre la fiabilité de l’entreprise et le contrôle des coûts. La méthode SRE vise à obtenir un maximum d’avantages commerciaux au moindre coût. Ainsi, le poste SRE recrute un ingénieur d'exploitation et de maintenance système capable d'écrire du code. Si vous faites uniquement de l'exploitation et de la maintenance, vous ne pourrez certainement pas retenir un pur développeur. Par conséquent, nous devons augmenter notre latitude cognitive et résoudre le système commercial interne actuel de l'entreprise du point de vue de l'ingénierie logicielle. D'après l'expérience personnelle de l'auteur, nous sommes une entreprise technologique qui développe des produits, notamment des systèmes de test, des systèmes de gestion de projet, des systèmes de contrôle de processus, des systèmes de publication, etc. Quelle que soit la taille de votre entreprise, vous en aurez besoin. Sans pilote SRE, nous choisirions un outil pour combler le vide. Cependant, les systèmes ne sont pas liés les uns aux autres, et personne en interne ne peut réellement piloter l’itération de ce sujet. Enfin, nous laissons l'exploitation, la maintenance ou le développement résoudre simplement ce problème. La situation actuelle est que ce problème ne peut pas être complètement résolu.

Troisièmement, le SRE est présent partout dans les sociétés Internet étrangères, mais il existe très peu de telles positions ou diffusion d'idées en Chine. Est-ce dû à des différences culturelles ? L'auteur estime que dans le processus d'évolution continue du système national d'exploitation et de maintenance, la vitesse de développement est nettement plus lente que le niveau cognitif actuel à l'étranger. Mais avec la montée en puissance de Taobao, le Département de support technique d'Alibaba est en fait le meilleur moyen de vérifier le SRE national. Les avantages du SRE sont évidents, mais il sera très difficile de promouvoir l’entreprise auprès des petites et moyennes entreprises. Le problème central est que le système des prestataires de services techniques étrangers est très solide. Lorsque les petites et moyennes entreprises souhaitent procéder à une transformation SRE, elles peuvent obtenir les solutions d'un grand nombre de prestataires de services techniques. Et les entreprises sont prêtes à consacrer une partie du coût au processus de pré-recherche de ces technologies. Les entreprises nationales s’attendent à acheter des technologies matures et ne sont pas disposées à investir de l’énergie dans les infrastructures. Le contrôle des coûts repose également sur des considérations liées au coût de la main-d'œuvre, et il est difficile pour les fournisseurs de technologies de disposer d'une marge de manœuvre. Ainsi, dans une telle situation difficile, le développement des activités de cloud computing peut jouer un rôle de lubrifiant. En d’autres termes, l’économie technologique partagée pourrait être un moyen de mettre en œuvre le SRE en Chine. Par exemple, Shuren Cloud, où travaille l'auteur, est une plate-forme légère de gestion d'applications qui met en œuvre le concept SRE. Grâce à la coopération avec les entreprises, elle complète la construction de plate-forme requise par les entreprises. Dans ce processus de coopération, le système évolué sert de valeur ajoutée et est promu par Shuren Cloud Platform dans d'autres entreprises pour parvenir à une situation gagnant-gagnant. À en juger par les résultats, les entreprises ont obtenu de bons résultats en matière de pratique du SRE et les prestataires de services techniques ont eu l'opportunité de mettre en pratique le SRE.

Quatrièmement, les SRE font bon usage des outils. Le changement dans la façon dont nous résolvons les problèmes, de la résolution de problèmes à une analyse approfondie du problème, en passant par la fourniture d'un modèle et d'une liste de contrôle pour résoudre le problème. Par exemple, le SRE de Netflix fournit une liste de contrôle au SRE pour résoudre les performances du système Linux :

5. Pratique de l'automatisation dans le domaine de l'exploitation et de la maintenance domestiques

En se limitant à l'itération rapide du développement dans le domaine de l'exploitation et de la maintenance domestiques, l'auteur décomposera l'état actuel des pratiques d'automatisation à partir des trois domaines les plus préoccupants comme point de rupture.
1. Surveillance et alarme

Il existe de nombreux types d'outils de surveillance et d'alarme domestiques, mais il existe très peu de solutions populaires pouvant être mises en œuvre. Le plus couramment utilisé par les entreprises traditionnelles est Zabbix. De plus, Open-Falcon, un outil de surveillance Internet open source au niveau de l'entreprise développé par Xiaomi en Chine, est également une option. Mais dans les deux scénarios, il n’y a aucun moyen d’éviter une question très directe, à savoir comment utiliser le chemin le plus court pour analyser votre problème et résoudre le problème réel dans le scénario commercial. Du point de vue de la surveillance, il existe plusieurs dimensions au niveau du système, au niveau de l'entreprise et au niveau du service. Lorsqu'on traite des problèmes du point de vue du SRE, la planification de la capacité est la première étape, plutôt que la planification basée sur divers retards du système basés sur une expérience a priori. Dès le début, les outils n’étaient donc pas le problème le plus difficile. Prenons Zabbix comme exemple. Les dimensions qui peuvent être surveillées sont la santé du système, le QPS de la base de données et la mémoire de Redis. Mais si le site Web ralentit, je ne peux rien faire du point de vue de la surveillance. Une analyse complète des liens est nécessaire pour déterminer le problème et le résoudre. Si nous suivons l'expérience DevOps, il est peu probable que nous posions ce genre de question, mais lorsque nous rencontrons un problème, comment changer automatiquement de serveur ou étendre automatiquement la capacité pour résoudre le problème. Le contrôle des coûts est incontrôlable dans un scénario DevOps. Les responsables ne peuvent que forcer les coûts budgétaires, et ni en amont ni en aval ne peuvent pleinement comprendre le coût des opérations commerciales.
2. Surveillance des journaux

La surveillance des journaux nationaux utilise largement la pile technologique ELK (Elasticsearch, Logstash et Kibana). Cette pile technologique est très populaire et a également résolu un grand nombre de problèmes de logs internes dans les entreprises. Mais dans les scénarios réels, la gestion des journaux métier reste très pénible. L’une est l’interrogation des journaux en temps réel et la seconde est l’agrégation des journaux historiques. Comment fournir efficacement l'utilisation de la requête de journaux ? L'équipe d'exploitation et de maintenance de Qunar a partagé une méthode en fournissant des services ELK à la demande pour les départements internes sur Apache Mesos, les développeurs peuvent interroger leurs propres journaux d'entreprise et analyser leurs propres journaux. . Une fois la requête terminée, l'instance de service ELK est automatiquement détruite. L’auteur estime que cette approche innovante est en réalité la pratique de la réflexion SRE.
3. Système d'intégration et de publication continue

L'outil le plus couramment utilisé pour l'exploitation et la maintenance domestiques consiste à utiliser Jenkins pour terminer l'intégration et la publication continues. Mais nous arrêtons souvent la pratique approfondie tant que nous pouvons utiliser Jenkins. Du point de vue SRE, nous analysons d'abord quels sont les problèmes commerciaux de l'intégration continue, car pendant le processus d'intégration continue, le système de test sera connecté. Par conséquent, l’auteur estime que le but de l’intégration continue est d’améliorer continuellement la qualité des produits. Avec l'objectif principal à l'esprit, ce que nous contrôlons n'est pas seulement la manière dont les tâches Jenkins sont gérées, mais aussi si l'efficacité des tests peut être améliorée et le temps d'intégration peut être raccourci. Établir une liste d’objectifs puis l’intégrer dans le processus d’amélioration SRE produira certainement des résultats différents. La publication continue est un autre sujet. En fait, le problème est que les utilisateurs ne comprennent pas pleinement la publication. La version inclut la version en niveaux de gris, la version de test, la version glissante, la version de restauration et d'autres scénarios. Et chaque scénario devrait être réversible. Comment résoudre ce problème ? Jenkins ne peut pas résoudre ce problème à lui seul. Vous avez besoin d'outils étendus pour le résoudre, comme l'assistance d'un ensemble de plates-formes légères de gestion d'applications.

6.Résumé

À en juger par l'histoire du développement de l'industrie, la normalisation technologique est un processus évolutif inévitable, et l'automatisation de l'exploitation et de la maintenance est en fait une manifestation de la normalisation. Dès la première étape du démarrage du SRE, les responsabilités professionnelles doivent être triées et triées, et les problèmes qui doivent être résolus doivent être documentés dans une liste de contrôle. Faciliter une mise en œuvre rapide en entreprise. L'étape suivante consiste à visualiser ces indicateurs et scénarios commerciaux pour aider l'entreprise à réduire les coûts d'exploitation et à quantifier les objectifs du système de service. Pour les entreprises compétentes, les interfaces des différentes ressources seront unifiées au cours du processus de développement.Ce processus sera très long, d'après l'expérience de l'auteur, et doit être répété par petites étapes et mis en œuvre avec soin en fonction des résultats réels. Parce que la plateforme, quel qu’en soit le coût, n’est qu’une glorieuse réussite politique et ne résout pas efficacement le problème des coûts. La forme d'automatisation la plus élevée est sans aucun doute un système intelligent, mais du point de vue de l'auteur, peut-être que tout le monde a regardé trop de films de science-fiction, ce qui a dilué l'objectif du génie logiciel, qui est d'utiliser des méthodes scientifiques pour maximiser les avantages des logiciels. Mais ce n’est certainement pas un système d’auto-guérison très intelligent. De l'avis de l'auteur, ce système d'intelligence artificielle est une autre dimension du génie logiciel, tout comme la comparaison entre les téléphones mobiles Nokia et les téléphones mobiles Apple. Le modèle SRE résout comment faire bon usage de la chaîne d'outils actuelle pour maximiser la valeur du mobile Nokia. téléphones, plutôt que d’être remplacés par un système d’intelligence artificielle. Peut-être qu'un jour dans le futur, SRE prendra directement sa retraite et laissera les robots remplacer l'ensemble du système d'exploitation et de maintenance, mais SRE finira par laisser une marque profonde dans l'histoire de la technologie.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

source:linuxprobe.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal