Pour terminer ce sujet : est-il vrai que les travaux d'exploitation et de maintenance ne peuvent plus être effectués ?

Vendredi dernier, Ma Chi et Lai Wei ont eu un échange en ligne, et le sujet était de savoir si les postes d'exploitation et de maintenance ne sont vraiment plus disponibles ? En tant qu'hôte, je suis à la fois l'allumeur et l'animateur :) J'ai beaucoup bénéficié d'écouter les deux vétérans partager certaines de leurs opinions respectives. Assurez-vous de l'enregistrer aujourd'hui pour ne pas l'oublier. Cela peut être considéré comme une critique de l'émission en direct.

À propos de la plateforme d'outils

La plateforme d'outils remplacera une partie de la main-d'œuvre C'est en fait une évidence et n'a pas besoin d'être présenté.

Mais qui va construire la plateforme d'outils ? Cela vaut la peine d'être vérifié. Les systèmes de surveillance, les plates-formes CI/CD, les plates-formes d'ingénierie du chaos, les services middleware, etc. sont tous des plates-formes et sont construits par Platform Engineer, appelé PE. PE est évidemment divisé en plusieurs groupes, et chaque groupe PE est responsable d'un nombre limité de plateformes. Ces équipes PE dispersées peuvent être organisées en une grande équipe, comme l'équipe d'infrastructure, ou elles peuvent être divisées en plusieurs équipes. Par exemple, l'équipe PE liée à la performance technique peut être placée dans un seul département (comme le département d'ingénierie de la performance). ), base de données et big data. Les équipes PE concernées sont placées dans un seul département (comme le département des données), et les équipes PE liées à l'assurance de la stabilité sont placées dans un seul département (comme le département d'exploitation et de maintenance).

La division de cette organisation peut être différente selon les entreprises, mais la relation n'est pas très grande. La clé est de savoir comment l'équipe PE doit effectuer son travail ? Le noyau de l'équipe PE doit faire ce qui suit :

• Construire une plateforme utile pour permettre à l'équipe R&D de l'entreprise de se mettre en libre-service
• La plateforme doit accumuler le meilleur pratiques. La plate-forme doit satisfaire l'entreprise, mais elle doit également disposer des meilleures pratiques de l'industrie. En théorie, si les besoins de l'entreprise entrent en conflit avec les meilleures pratiques de l'industrie, les meilleures pratiques de l'industrie devraient prévaloir autant que possible si cela est vraiment impossible à court terme. à terme, il devrait également formuler Nous devons mettre en œuvre le plan étape par étape et nous efforcer d'y parvenir à l'avenir, sinon, s'il y a de plus en plus de choses personnalisées et anti-modèles, le côté Plateforme deviendra de plus en plus inconfortable. à la fin, il sera dépassé et il sera renversé et tout recommencera
• Nous devons trouver des moyens d'utiliser les plateformes pour mettre en œuvre les spécifications au lieu d'utiliser les règles et réglementations pour mettre en œuvre les spécifications. un bon exemple. Ils ont une spécification qui oblige les programmes commerciaux à ne pas utiliser de disques locaux pour stocker les données d'état. Ils ne l'ont pas inclus. Il est promulgué comme un décret de ligne rouge, mais indique clairement au côté commercial que le conteneur sera redémarré régulièrement. laissez le conteneur dériver ! En fait, les personnes qui ont utilisé AWS doivent savoir que les machines virtuelles AWS redémarrent parfois de manière inexplicable. Il est de la responsabilité des développeurs d'applications de fournir des applications hautement disponibles pour une infrastructure peu fiable. évolution de la plate-forme, car les architectes qui sont bons en bases de données peuvent ne pas être bons en Hadoop, les architectes qui sont bons en Hadoop peuvent ne pas être bons en systèmes d'observabilité, et les architectes qui sont bons en systèmes d'observabilité peuvent ne pas être bons en ingénierie du chaos.
• Mais toutes les Plateformes ne se créent pas du jour au lendemain. Que faire si vous ne disposez pas encore de ces Plateformes ? L'entreprise devrait d'abord recruter un COE et laisser le COE servir de consultant commercial tout en renforçant les capacités de la plateforme. L'activité se développe rapidement et l'auto-développement de la plateforme est trop lent. Elle peut également rechercher des solutions auprès de fournisseurs externes. . Même le COE lui-même peut rechercher des solutions externes, en fonction de la situation.

À propos des fournisseurs externes

Intuitivement, tout le monde aura le sentiment que les entreprises européennes et américaines sont plus disposées à acheter des services SaaS, tandis que les entreprises nationales sont plus disposées à créer leurs propres services basés sur open source. Est-ce parce que la philosophie de l’entreprise nationale n’est pas bonne ? Pas vraiment. Le principal problème réside dans le manque d’entreprises et de produits ToB fiables dans de nombreux domaines nationaux. Imaginez si une entreprise ToB pouvait fournir à la partie A :

Une méthodologie excellente et avancée

• Des produits stables et faciles à utiliser
#🎜🎜 #Une équipe de réussite client excellente et stable pour aider les clients à mieux mettre en œuvre les meilleures pratiques
• En termes de prix, c'est moins cher que le recrutement de personnel et l'auto-recherche de la partie A
• #🎜🎜 ## 🎜🎜#Tant que le CXO n'a pas le cœur brisé, il choisira certainement de faire appel à un tel fournisseur externe. Mais existe-t-il une telle société ToB ? C’est un gros point d’interrogation. Nous avons créé Kuaimao Nebula Company pour fournir aux clients des produits d'observabilité et nous efforçons de devenir un tel fournisseur. J'espère que les collègues de ToB du secteur travailleront ensemble !
• En ce qui concerne la question de la sélection de carrière, même s'il n'y a peut-être pas de bon fournisseur dans un certain segment maintenant, qu'en sera-t-il dans trois ans ? Et dans 5 ans ? Les pays étrangers ont-ils déjà pris les devants ? Existe-t-il des fournisseurs à bon potentiel en Chine ? Si vous l'avez déjà, mon frère, oserez-vous encore continuer à vous consacrer à ce domaine de niche ? Aurions-nous dû faire des plans à l'avance ?

Bien sûr, lorsqu'il s'agit de nos prévisions pour l'avenir, nous sommes généralement trop optimistes ou trop pessimistes. Lorsqu'il s'agit d'estimations de temps, nous faisons généralement des prédictions à la fois trop avancées et trop en retard. C'est vrai, frère, cela dépend de la façon dont vous jugez.

À propos de la gestion des pannes d'urgence

La réponse aux pannes OnCall doit-elle être gérée par le R&D ? Ou l'exploitation et la maintenance ? Cette question est très intéressante. Ma Chi estime que 80 % des défauts en ligne sont liés à des changements apportés par la R&D, et que la R&D les connaît évidemment mieux. Laissez la R&D répondre aux défauts d'OnCall, ce qui signifie que la R&D peut répondre plus rapidement à 80 % des problèmes.

La recherche et le développement commerciaux sont comme ça. Les modifications de base de données, les modifications de base du réseau et les modifications de couche d'accès sont toutes identiques. Il semble plus raisonnable que la personne qui effectue la modification réponde à l'alarme de panne de son propre service.

En fait, cela dépend de deux conditions préalables :

1. La surveillance et l'observabilité sont suffisamment bien faites, et les problèmes causés par les changements peuvent être découverts à temps grâce à cette plateforme. Allez, tout le monde, j'espère que chaque entreprise dispose d'un ensemble complet d'observabilité. politiques. Système d'observation
2. Les problèmes introduits par les changements se reflètent immédiatement. Si les problèmes introduits par certains changements n'apparaissent qu'une semaine plus tard, il sera difficile pour la personne qui a effectué le changement de douter d'elle-même

En fait, nous pouvons traiter le changement dans deux situations. La surveillance ultérieure de la stabilité du service relève de la responsabilité de la personne qui a effectué le changement. Il s'agit d'un autre scénario qui doit être traité séparément. Alors, qui devrait faire le OnCall quotidien ? Il doit s'agir de ceux qui peuvent participer directement à la localisation des défauts et à l'arrêt des pertes. La raison est évidente. Si la personne OnCall reçoit une alarme et doit contacter d'autres personnes, la rapidité de l'arrêt des pertes sera alors trop faible.

Donc, tout d'abord, les alarmes doivent être traitées dans différentes catégories. Différentes alarmes OnCall sont différentes. Il n'est pas raisonnable de donner toutes les alarmes à la R&D ou à l'exploitation et à la maintenance. Cette approche absolue est déraisonnable.

À propos de la publication des modifications

Il existe un consensus sur l'objectif ultime, qui est de permettre à la recherche et au développement des entreprises de publier des versions librement, mais nous voulons aussi être contrôlés, nous voulons publier en toute sécurité et nous voulons assurer la continuité des activités. en relâchant. Cela impose des exigences extrêmement élevées au système CI/CD.

Si vous ne vous en souciez pas, changer la couche inférieure du système consiste simplement à exécuter un script par lots sur un lot de machines. Mais après avoir ajouté les exigences ci-dessus, cela devient beaucoup plus difficile et devient un projet systématique.

Du côté de la recherche et du développement des entreprises, il est nécessaire de faire des points observables, et un système de surveillance est nécessaire pour détecter les problèmes à temps, et même bloquer automatiquement le processus de libération après une alarme. Il doit y avoir des moyens de publication bleu-vert et de version canari, et certaines capacités d'analyse automatique du code et d'analyse de sécurité sont nécessaires. Le système d'outils est incomplet d'exiger aveuglément de la R&D pour garantir que les modifications peuvent être annulées et cela. les changements sont sécuritaires. Le niveau de capacités CI/CD peut essentiellement indiquer la force technique de l’entreprise.

Si votre entreprise fournit toujours à la R&D des connaissements pour l'exploitation et la maintenance, et que l'exploitation et la maintenance s'effectuent en ligne, vous devez vous demander s'il est raisonnable de le faire. Bien entendu, l’approche ci-dessus s’apparente davantage à une approche Internet et peut ne pas convenir à toutes les entreprises. Cette diffusion en direct ne donne qu’une idée, et vous devez la considérer vous-même.

Bien sûr, comment parvenir à cette situation idéale ? Comment procéder étape par étape avant d’atteindre cette situation idéale ? La question du temps n’a pas été abordée lors de la diffusion en direct. Si l'activité de l'entreprise est adaptée à un fonctionnement sur Kubernetes, il est relativement facile de créer un tel système à l'aide de Kubernetes et vous pouvez agir dès que possible. Si l'activité de l'entreprise doit fonctionner dans un environnement de machine physique ou de machine virtuelle, créez d'abord une plate-forme unifiée de publication des modifications, puis comblez les lacunes et améliorez-les progressivement.

À propos de l'optimisation des coûts

Les deux invités n'ont pas beaucoup parlé, mais tout le monde a été très prudent sur cette question. Rappelez à tout le monde :

1. Les gens coûtent plus cher que le matériel. Ne faites jamais quelque chose qui coûte 50 millions de main-d'œuvre et permet d'économiser 40 millions de dollars en matériel.
2. Autorisez suffisamment de puissance de calcul redondante pour l'entreprise. Si les ressources sont trop utilisées, nerveux. , le budget de ce lot n'est pas approuvé. Si la capacité provoque une panne, l'expérience client sera endommagée, l'opinion publique sera négative et le gain dépassera les pertes
3. L'exemple ridicule est celui pour sauver le. coût matériel de 3 millions, le volume d'achat est de 30 millions et le volume ne peut pas être maintenu. C'est vraiment nul

Résumé

À ce stade, le système de plateforme n'est pas encore aussi complet. Utilisation de la plateforme libre-service + COE. L'architecture +BP (Business Partner) pour construire un système d'exploitation et de maintenance semble fiable et réalisable. À l'avenir, lorsque la plate-forme sera suffisamment performante, les effectifs de BP pourront être réduits (BP a progressivement acquis la capacité de faire du COE). Si la plate-forme continue d'être complète, le COE pourra continuer à être réduit. la maintenance et la R&D peuvent ne pas être nécessaires.

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!