Comment mettre en pratique les « quatre rois » de l'auto-révolution

Le forum d'exploitation et de maintenance invite les vétérans du domaine de l'exploitation et de la maintenance à fournir des informations approfondies à travers des entretiens et des invitations à se rencontrer, en vue de former un consensus avancé et de promouvoir l'industrie pour qu'elle avance mieux.

Dans ce numéro, nous invitons Wang Mingsong. Le patron Wang a proposé les « Quatre règles » pour la pratique des applications cloud natives, qui sont largement reconnues dans l'industrie. À partir de 2019, toutes les activités IDC de la société Boss Wang ont été déplacées vers le cloud. L'échelle n'est pas petite, mais l'équipe SRE est très petite, un peu comme NetFlix. Dans cette conférence, examinons le fonctionnement des opérations et de la maintenance du cloud senior.

C'est le 7ème numéro du "Forum Exploitation et Maintenance", terre-à-terre et de haut niveau, commençons !

Aperçu de la question

• J'ai rencontré Boss Wang pour la première fois à cause d'une discussion au sein du groupe WeChat. Boss Wang a proposé quatre pratiques d'application cloud natives. Il pense que tant que ces quatre seront mises en œuvre, l'application sera essentiellement cloud. natif. Amis du groupe, je suis profondément d'accord avec cela et je l'ai nommé « Quatre Wangs ». Le patron Wang peut-il partager l'essence de « Quatre Wangs » avec les lecteurs de SRETalk ?
• Les « Quatre Rois » répertorient quelques bonnes pratiques, qui doivent être coordonnées par la R&D. Lors de leur mise en œuvre au sein de l'entreprise, y a-t-il des obstacles ? Comment l'as-tu réglé ?
• Certains articles décrivent récemment comment ils mesurent de manière globale le ROI et pensent qu'il est plus rentable de passer au cloud, comme l'article du père de RoR et de M. Zou de Tuyou Games dans le dernier numéro de Operation and Maintenance Forum Baijia. Il semble que vous soyez plus enclin à utiliser le cloud en profondeur. Pouvez-vous partager vos réflexions avec tout le monde ?
• Il y a eu un article récent « L'avenir de l'exploitation et de la maintenance est l'ingénierie des plates-formes ». Êtes-vous d'accord avec ce point de vue ? Quels rôles et limites votre équipe a-t-elle dans l'ingénierie de plateforme ? Comment planifiez-vous ce que l’on appelle l’ingénierie de plateforme (en particulier dans un environnement multi-cloud) ?
• Dans le modèle de travail de Boss Wang, je pense que seules des personnes très expérimentées sont nécessaires. Le sang neuf est trop jeune pour assumer le rôle de coach R&D. Mais sans sang neuf, il est impossible de maintenir un plan à long terme. vous partagez comment vous faites ?
• Nous savons, Mingsong, que vous avez toujours été un partisan de « l'auto-révolution de l'exploitation et de la maintenance », qui est « anti-humaine ». Pouvez-vous nous parler de la réflexion derrière cela ?

Présentation de l'invité

Avant de commencer, laissez le patron Wang se présenter. Parlons de votre historique professionnel, en particulier de votre expérience dans l’utilisation du cloud, et donnons-nous quelques informations générales.

Vers 2005, j'ai fait le fonctionnement et la maintenance du BBS à l'école, ce qui était considéré comme une initiation. Après l'obtention de mon diplôme, j'ai rejoint une grande entreprise Internet (NDLR : en référence à Baidu) qui est aujourd'hui en déclin, depuis le niveau P1 d'exploitation et de maintenance dans tous les secteurs. En 2010, je me suis enfui et j'ai rejoint une start-up d'Internet mobile. À cette époque, je faisais pratiquement tout, du câblage réseau système à l'informatique de la salle informatique, le cycle d'achat de serveurs était un peu long même pour les petites entreprises, alors j'ai commencé à le faire. envisagez d'utiliser le cloud à ce moment-là.

Depuis 2011, j'utilise Suguang Cloud pendant un certain temps, qui est basé sur VMware. L'expérience est très mauvaise. De mon point de vue personnel, la convivialité et l'économie ne sont pas bonnes. être plus rapide à installer la machine qu’IDC. Ensuite, le réseau est également bizarre, causant beaucoup de problèmes. En même temps, j'ai également utilisé Shanda Cloud pendant un certain temps. L'expérience était meilleure que Sugon, mais c'était en fait au niveau des vps. On a l'impression que la couche VPC n'a pas été réalisée. Je n'ai pas osé y mettre des ressources trop importantes, puis j'ai arrêté de les utiliser après des tirages répétés (c'est peut-être parce que je les ai mal utilisées et que ce n'est pas facile à surveiller).

J'ai commencé à utiliser ucloud en 2013. Cela utilise principalement des machines virtuelles et pas grand-chose d'autre. Mais le produit vpc aurait dû être disponible à ce moment-là, et certaines activités importantes auraient été avancées.

En 2014, parce que j'ai commencé à faire des affaires à l'étranger, j'ai commencé à utiliser AWS. En 2019, toutes les activités d'IDC ont migré vers le cloud.

Questions d'entretien

J'ai rencontré Boss Wang pour la première fois à cause d'une discussion au sein du groupe WeChat. Boss Wang a proposé quatre pratiques d'application cloud natives. Il pense que tant que ces quatre seront mises en œuvre, l'application sera essentiellement cloud. natif. Amis du groupe, je suis profondément d'accord avec cela et je l'ai nommé « Quatre Wangs ». Le patron Wang peut-il partager l'essence de « Quatre Wangs » avec les lecteurs de SRETalk ?

J'ai mis la version détaillée des quatre rois natifs du cloud dans le dépôt du suédois Ma Gong (https://github.com/lipingtababa/cloud-native-best-practices). Tout le monde est invité à soulever des problèmes, et moi. fera de même. Le contenu des quatre rois natifs du cloud

la version brève est mise à jour de temps en temps :

1. Utilisez des objets pour stocker des fichiers statiques
2. Utilisez un rôle, pas ak sk
3. Essayez d'utiliser des services d'hébergement
4. Ne pas stocker de données sur le serveur

Ces quatre éléments En fait, le point de départ tourne essentiellement autour de l'apatridie des applications et de la sécurité des données, tout en prenant en compte le coût, les performances et la fiabilité. Le champ d'application ne se limite pas au cloud computing. . L'IDC traditionnel peut également être implémenté comme référence.

NDLR : Cette version simplifiée ne semble pas avoir beaucoup de contenu, mais elle contient en réalité beaucoup de choses, je vous propose de la lire. Si vous n'arrivez pas à cliquer sur le lien "Cloud Native King Si Tiao", rendez-vous sur. le dépôt ci-dessus et recherchez "Cloud Native King Si Tiao.md" C'est tout.

Les « Quatre Rois » répertorient quelques bonnes pratiques, qui doivent être coordonnées par la R&D. Lors de leur mise en œuvre au sein de l'entreprise, y a-t-il des obstacles ? Comment l'as-tu réglé ?

Je n'ai rencontré presque aucun obstacle, mais c'était parce que nous avions nos propres circonstances.

D'une part, nous n'avions d'autre choix que de passer au cloud à cette époque, et le contrôle des coûts était un objectif difficile, il n'y avait donc pas d'autre voie d'apaisement parmi laquelle choisir.

Nous sommes une nouvelle entreprise issue de l'équipe, nous n'avons donc donné qu'un an pour effectuer la transition. L'objectif fixé par la direction est de rendre transparente la migration de l'entreprise rentable sur des milliers de machines existantes. Comme nous faisions uniquement des affaires à l'étranger à l'époque, nous n'avons pas du tout envisagé de solutions non cloud. Cependant, la direction exigeait toujours que les coûts du cloud soient inférieurs à ceux d'IDC auparavant.

Si vous déplacez directement l'architecture d'origine vers le cloud, l'objectif de coût fixé par la direction ne sera certainement pas atteint (le patron Feng de Pigsty a écrit de nombreux articles similaires pour prouver l'avantage en termes de coût de l'IDC traditionnel par rapport au cloud), donc là Il n'y avait alors qu'un seul choix : transformer l'architecture existante pour l'adapter au cloud, afin qu'après la migration, les objectifs de coût, de performance et de stabilité puissent être atteints.

D'un autre côté, laissez la R&D participer pleinement à la sélection des modèles et à l'optimisation des coûts, et chacun pourra parvenir à un consensus.

J'ai passé environ un an à l'avance pour commencer à sélectionner les cloud publics, et j'ai spécialement participé à des formations pour apprendre à mieux utiliser le cloud, et j'ai progressivement formé ma propre méthodologie. Avant la migration, j'ai également amené les membres clés de la R&D à participer à des formations pertinentes. Après la formation, ils ont pu comprendre que bon nombre de mes pratiques étaient correctes. De plus, lors de la migration proprement dite, AWS a également fourni une solution plus professionnelle. conception. Par conséquent, il est relativement facile de mettre en œuvre le contenu des « quatre rois ». Par exemple :

1 Le stockage des données dans EBS coûte très cher, donc le stockage des données dans S3 est un choix très économique grâce à la formation et à la comparaison de différentes solutions. , R&D a rendu cette situation très claire, elle aura donc une plus grande volonté d'apporter des modifications aux programmes.

2. Le rôle est une exigence de sécurité, car le SDK AWS le prend très bien en charge. Il n'y a aucune différence de difficulté entre utiliser Role ou ak sk au premier démarrage si vous le contrôlez bien dès le début, ce ne sera pas un problème. pour la recherche et le développement.

3. Concernant les services d'hébergement, en effet, la R&D ne se soucie pas de savoir s'il s'agit d'exploitation et de maintenance ou d'utilisation de services existants. Tant que notre exploitation et notre maintenance pourront abandonner notre obsession, cela suffira.

4. Ne stockez pas de données sur le serveur. En fait, nous avons traversé une période relativement difficile.

Notre migration cette fois s'effectue depuis un environnement IDC avec prise en charge complète de la plateforme vers AWS. Avec l'aide des partenaires AWS, la nouvelle architecture est conçue conformément aux meilleures pratiques d'AWS et répond aux habitudes et exigences d'utilisation précédentes.

Mais en raison de la reconstruction, il existe encore des différences d'utilisation. Étant donné que l'ASG est utilisé, le serveur est directement détruit lors d'une réduction ou d'une migration par défaut. Si des données persistantes doivent y être stockées, elles disparaîtront. Ainsi, après ce délai, la R&D peut fondamentalement accepter que les données commerciales en ligne n'existent pas sur le serveur. .

Et grâce à cette conception, nos besoins en stockage sur serveur peuvent être aussi réduits que possible. Tout ce qui dépasse 100G nécessite mon approbation. J'ai économisé beaucoup de coûts EBS

Plus tard, lorsque l'équipe R&D a déployé K8S, elle a eu une compréhension plus approfondie de cela. Après tout, les données contenues dans le conteneur seront perdues.

Récemment, certains articles ont déclaré qu'ils mesuraient de manière globale le retour sur investissement et pensaient qu'il était plus rentable de passer au cloud, comme l'article du père de RoR et de M. Zou de Tuyou Games dans le dernier numéro. du forum Baijia sur l'exploitation et la maintenance. Il semble que vous soyez plus enclin à utiliser le cloud en profondeur. Pouvez-vous partager vos réflexions avec tout le monde ?

En fait, j'ai préconisé les « meilleures pratiques », mais j'ai également fait savoir à tout le monde que « les meilleures pratiques sont l'art de l'empereur en matière d'investisseurs ou de gestion ». L'utilisation des meilleures pratiques est susceptible de nuire à vous-même et à bien d'autres. les emplois des gens peuvent être optimisés. Si l'optimisation est réalisée sans détruire les emplois, il y aura plus de choix.

Que vous alliez vers le cloud ou vers le cloud dépend de vos intérêts, de la force du soutien de la direction et de votre bagage historique. Si j'étais à la place de M. Zou ou de DHH, je ne m'en tiendrai peut-être pas à mes opinions actuelles. Je peux m'en tenir au cloud :

D'une part, c'est la reconnaissance de la direction La direction a subi des pertes d'actifs inutilisés. Je fais depuis longtemps l'optimisation des ressources IDC inutilisées, c'est donc le cas. pas spécial de construire une salle informatique auto-construite à l'étranger. Facile, le passage au cloud est fondamentalement la seule solution prise en charge par la direction.

D'autre part, comme mentionné ci-dessus, par hasard, notre architecture a été complètement transformée, et le coût de transformation est supporté par la direction, nous pouvons donc profiter pleinement des avantages du cloud.

Dernier point, notre modèle économique ne repose toujours pas sur une activité stable à long terme, à forte charge et apatride. Ce type d'entreprise est plus adapté aux IDC traditionnels.

Je pense que le coût pour M. Zou ou DHH de transformer leur architecture système existante est trop élevé. Même si cela peut réduire le coût de la main-d'œuvre du service d'exploitation et de maintenance, il peut être difficile d'obtenir de l'aide car cela implique également d'autres. intérêts des départements.

Mais s'il s'agit d'une nouvelle entreprise ou d'un nouveau projet, je pense qu'il n'y a pas de scénario plus approprié que le cloud. Choisissez un fournisseur de cloud approprié et utilisez une architecture cloud native pour mettre en œuvre l'entreprise, afin que l'ensemble de l'entreprise soit flexible. termes de performance et de coût.

De nombreux amis se sont plaints de la destruction des nuages, du verrouillage, etc. Mais du point de vue des investisseurs ou de la direction, tous les éléments doivent permettre d'atteindre la rentabilité de l'entreprise. Les personnes/cloud/IDC sont tous des éléments pour réaliser des affaires. Si les investisseurs veulent réaliser des affaires, ils doivent non seulement payer le coût de ces éléments, mais aussi être. pouvoir obtenir des éléments qui répondent à vos besoins dans les meilleurs délais (c'est plus important). Obtenir l'élément cloud ne pourrait pas être plus simple. La qualité et le prix du produit sont relativement standards. Vous pouvez le payer en quelques clics. Vous pouvez le payer sur demande, mais vous pouvez cesser de l'utiliser à tout moment. Mais qu’en est-il des gens ? Il est difficile d'acquérir des personnes, la qualité est difficile à déterminer et elle n'est pas standardisée. Il y aura des fluctuations de prix (augmentations de salaire) et vous ne pouvez pas être licencié par hasard. Si vous quittez votre emploi, vous ne serez pas remplacé. par quelqu'un qui est absolument le même. Les gens peuvent être très créatifs, mais lorsqu'il s'agit de normalisation et de choses mécaniques ennuyeuses, les gens ne peuvent jamais être l'adversaire des machines, encore moins des services SaaS.

Pour la situation de M. Zou, si son équipe commerciale n'est pas disposée à transformer l'architecture du programme, son choix actuel est la meilleure pratique : choisir un IDC avec un avantage en termes de coût pour une entreprise stable et à forte charge, et louer des machines au lieu d'acheter. eux; entreprise flexible Sur le cloud.

Pour Basecamp de 37signals, le paramètre de modèle de tarification du produit détermine qu'il est un peu difficile pour eux de migrer vers le cloud. La plupart des services SaaS sont désormais payants en fonction de l'utilisation ou du nombre d'utilisateurs, mais Basecamp vend principalement des forfaits illimités, qui ne coûtent que 199 $ par mois. Ce modèle de tarification signifie qu’ils ne peuvent pas utiliser pleinement l’élasticité du cloud pour réaliser des bénéfices et ne peuvent que surréserver des ressources à bas prix. Si ce modèle tarifaire n’est pas modifié, quelle que soit la manière dont l’architecture est optimisée, il se peut qu’il ne soit pas adapté au cloud.

Il y a eu un article récent "L'avenir de l'exploitation et de la maintenance est l'ingénierie des plates-formes". Êtes-vous d'accord avec ce point de vue ? Quels rôles et limites votre équipe a-t-elle dans l'ingénierie de plateforme ? Comment planifiez-vous ce que l’on appelle l’ingénierie de plateforme (en particulier dans un environnement multi-cloud) ?

A-t-il été écrit par Ruan Yifeng ou Charity Majors ? Mais je n’ai jamais lu ces deux articles auparavant, et je les ai juste jeté un bref coup d’œil. Je ne suis pas entièrement d’accord avec cela et personnellement, je n’essaierais pas de faire de l’ingénierie de plate-forme interne.

Tout d’abord, parlons de ce avec quoi je ne suis pas d’accord : cet article contient des malentendus sur les concepts.

Tout d'abord, DevOps n'est pas un poste. J'essaie de le comprendre depuis longtemps, et le sentiment final est que c'est un modèle de développement. Mais le cœur de ce modèle de développement est la R&D, et tous les éléments doivent se concentrer sur des services d’itération R&D efficaces. L'article pensait initialement que DevOps était un poste, mais a ensuite estimé que ce poste était destiné au développement commercial. Je pense que ce sont des interprétations inappropriées.

Deuxièmement, l'exploitation et la maintenance offrent de riches explorations vers l'avenir. La transformation n'est pas un sujet nouveau. Tout le monde a compris depuis longtemps que le secteur de l'exploitation et de la maintenance est un secteur en déclin. Au cours des dix dernières années, de nombreuses opérations et maintenance ont tenté de se transformer et de trouver une issue pour la prochaine étape. tentent de s'engager dans le CI/CD, et certains tentent de s'engager dans le CI/CD. Certains tentent de faire de la recherche et du développement en matière de surveillance, certains tentent de développer des plates-formes d'exploitation et de maintenance automatisées, certains tentent de s'engager dans de nouveaux domaines (. comme les K8, le big data, l'IA, le cloud computing, etc.), et certains tentent de s'orienter vers d'autres sous-projets (comme le DBA, la sécurité des réseaux) ).

On constate que nombre de ces transformations servent le modèle de développement DevOps.

L'ingénierie de plate-forme est peut-être un modèle de mise en œuvre, mais avec la force du produit et le niveau de R&D du groupe d'exploitation et de maintenance, j'ai peur que faire de l'ingénierie de plate-forme par moi-même ne puisse que m'amuser, et même la stabilité ne puisse être garantie, ce qui ne fait qu'augmenter la possibilité d'en prendre la responsabilité. Cependant, si une équipe de production et de recherche plus professionnelle est mise en place pour le faire, d'une part, il sera difficile d'obtenir un soutien si elle ne fait pas ses affaires correctement et n'a rien à voir avec les principaux revenus de l'entreprise. , ce n'est qu'une plateforme d'auto-utilisation. Il n'est pas économique de recruter autant de personnes pour fabriquer un produit sans revenus, et il est encore plus difficile d'obtenir du soutien. De plus, cette approche n'a aucun sens de participation. l'exploitation et la maintenance existantes, et cela ne peut pas être considéré comme une transformation.

Donc, je pense que la bonne approche est d'utiliser des plates-formes et des outils matures (open source/auto-construit payant, SaaS peut être utilisé. Vous pouvez effectuer une certaine personnalisation et un développement secondaire basé sur ces plates-formes, mais ne réinventez pas la). roue.

Enfin, ma compréhension de la plateforme dans cet article est également différente.

D'une part, la plate-forme elle-même peut être fournie sous forme de SaaS, et aucune intégration secondaire n'est nécessaire. La raison principale est désormais que l'environnement SaaS national n'est pas bon et que les services logiciels n'y prêtent pas attention. intégration et compatibilité mutuelles, mais préfèrent être vastes et complets. Lorsque nous regardons à l'étranger, nous constatons qu'il existe de nombreux SaaS ou logiciels dans des domaines de niche à l'étranger, qui sont très bons et peuvent être intégrés à d'autres logiciels. L'écosystème est très bon, donc l'intégration est facile à configurer, et il n'y en a pas. beaucoup de charge de travail pour le développement secondaire.

D'un autre côté, les utilisateurs de la plateforme doivent être des R&D, et les R&D doivent pouvoir l'utiliser directement sans avoir besoin d'exploitation et de maintenance pour la transmettre ou l'approuver.

Donc, à l'avenir, nous aurons vraiment besoin d'utiliser une plateforme. C'est une plateforme réalisée par une équipe de production et de recherche professionnelle, pas un jouet fabriqué par nous-mêmes, c'est plutôt une plateforme que l'équipe de production et de recherche utilise directement ; qu'un préposé à l'exploitation et à la maintenance se tenant au milieu pour faire office de microphone.

Donc, pour l'ingénierie de plateforme, je choisis d'utiliser activement des logiciels matures ou des services SaaS, et de les proposer autant que possible pour une utilisation directe par l'équipe de production et de recherche.

L'exploitation et la maintenance n'effectuent que certains points de contrôle nécessaires en fonction du coût et de la sécurité, et les contrôlent via des politiques, des autorisations et des audits pour garantir que l'équipe de production et de recherche peut les utiliser correctement.

Sous le modèle de travail du patron Wang, je pense que seules des personnes très expérimentées sont nécessaires. Le sang neuf est trop jeune pour assumer le rôle de coach R&D. Mais sans sang neuf, il est impossible de maintenir un plan à long terme. . Pouvez-vous partager votre expérience ? Comment avez-vous constitué votre équipe ?

C'est une bonne question car je ne l'ai pas résolue non plus. Ce n'est pas un problème avec ce modèle de travail.

Il existe une demande de talents seniors dans de nombreuses entreprises et dans de nombreux types d'emplois, et ils sont tous confrontés au même problème auquel je suis confronté actuellement. Quel type de travail ne nécessite pas de talents seniors ? Je pense que le contenu du travail est très standardisé, que les exigences de l'entreprise ne sont pas élevées et que chacun peut donner des instructions claires en fonction des besoins et bien le faire. Même les machines peuvent le faire.

M. Zou a un dicton selon lequel l'exploitation et l'entretien traditionnels sont similaires au nettoyage. Le contenu du travail est important mais la valeur n'est pas élevée. Je suis tout à fait d’accord avec cette affirmation. C’est le dilemme auquel nous sommes actuellement confrontés en matière d’exploitation et de maintenance. Alors, l’équipe de nettoyage développe-t-elle ses propres outils de nettoyage ou les achète-t-elle ?

Comme j'utilise un grand nombre de produits matures et de services externes, je peux effectuer des tâches de nettoyage de manière plus stable, tout comme le nettoyage à l'aide de divers outils de nettoyage automatiques et semi-automatiques. Mais vous n’avez pas à vous inquiéter du manque de capacité de nettoyage d’une personne qui conduit à un nettoyage impur, ou du manque de professionnalisme qui conduit à un simple scan puis à la remise du travail. Bien que le nettoyage nécessite un peu plus d'apprentissage et de difficulté pour bien utiliser ces outils que les outils traditionnels, la SOP globale est moindre qu'auparavant car les outils matures protègent les détails.

Alors, ne perdons pas de temps sur du contenu de travail à faible valeur. Ce type de travail doit être réalisé avec des logiciels professionnels ou SaaS. Ils ont des économies d'échelle, de bonnes fonctionnalités et des SLA. Nous devrions concentrer notre travail sur les domaines qui préoccupent davantage les entreprises, la direction et les investisseurs.

Nous savons que le patron Wang a toujours été un partisan de « l'auto-révolution en matière d'exploitation et de maintenance », qui est « anti-humaine ». Pouvez-vous nous parler de la réflexion derrière cela ?

Le fait que nous constatons maintenant est que l'exploitation et la maintenance ne sont pas une industrie en plein essor. La plupart des entreprises ne disposent pas d'un énorme service d'exploitation et de maintenance pour soutenir le fonctionnement du système de l'entreprise. Elles peuvent même n'avoir besoin que d'une seule personne. assumer des tâches informatiques, de gestion de réseau, de sécurité et autres. Nous n'avons pas de marge d'amélioration, il y a très peu de directeurs d'exploitation et de maintenance, et les responsables d'exploitation et de maintenance sont fondamentalement la limite. Avec le nombre de personnes que je gère actuellement, vous pouvez m'appeler directeur d'exploitation et de maintenance.

L'industrie est également dans le même état désormais. Un grand nombre de formations permettent une exploitation et une maintenance rapides, suffisantes et bon marché. Il y a très peu d'opérations et de maintenance de milieu à haut de gamme. Les opérations et la maintenance ne sont pas comme les ingénieurs réseau ou les administrateurs de base de données. Notre pile technologique est très compliquée et il n'y a pas de certification faisant autorité pour évaluer nos capacités. des parcours de carrière et la formation d'un marché de talents sains. Par conséquent, le positionnement sur le marché de notre exploitation et de notre maintenance est en fait une corvée. « La technologie qui n'écrit pas de code commercial » est peut-être notre positionnement le plus précis.

Selon le concept DevOps, nous devrions accélérer la réalisation des activités et fournir de bons services, plutôt que de créer le chaos dans la production et la recherche. Mais le sens et le travail de l’exploitation et de la maintenance ne concernent pas uniquement le DevOps. C’est là que mon point de vue diffère de celui de beaucoup d’autres.

D'une part, l'exploitation et la maintenance sont le « chien de garde » des actifs numériques de l'entreprise. De ce point de vue, l'exploitation et la maintenance représentent les intérêts de la direction et des investisseurs, protègent correctement les actifs numériques de l'entreprise et veillent à ce qu'ils puissent. être utilisé correctement Utilisé pour répondre à diverses exigences réglementaires et participer à divers audits internes. C'est le frein et l'équilibre de la direction au sein de l'équipe de production et de recherche. C'est en fait le sens de l'exploitation et de la maintenance initiales.

D'un autre côté, le pays vous récompense avec de la nourriture. Les exigences réglementaires sont de plus en plus strictes. Qu'il s'agisse de sécurité des réseaux, de sécurité des données ou de protection des informations personnelles, un personnel dédié est nécessaire pour être responsable des travaux connexes. Pour les petites entreprises, ces tâches doivent être réalisées concurremment par l'exploitation et la maintenance, notamment la sécurité des données, qui doivent être directement impliquées dans l'exploitation et la maintenance des actifs numériques. C'est la condition nécessaire à l'exploitation et à la maintenance dans la nouvelle ère.

Donc, si vous voulez comprendre cela, vous constaterez que les Devops et les plateformes ne sont qu'une petite partie du travail d'exploitation et de maintenance. Nous devons nous libérer de ces enchevêtrements, nous détacher, et aussi détacher les équipes de production et de recherche. , faire du bon travail dans notre perspective de gestion et de supervision.

Lecture approfondie

• ​​Forum Exploitation et Maintenance n°6 : Tuyou Zou Yi - Comment faire l'exploitation et la maintenance des petites et moyennes entreprises ? ​​
• ​​Le cinquième numéro du Forum d'exploitation et de maintenance : Du Xiaoman et Chen Cunli, un "commandant" de 20 ans, parlent d'exploitation et de maintenance, de performances et de croissance​​
• ​Le quatrième numéro de le Forum d'exploitation et de maintenance : un autre tir dans le cloud Shao Haiyang - Un vétéran de Linux de 25 ans parle des huit honneurs et des huit hontes du DevOps​​
• ​​Operation and Maintenance Hundred Forum Numéro 3 : Lai Wei-Comment stabiliser l'opération et travail de maintenance​
• ​​Exploitation et maintenance Baijia Forum Numéro 2 : Zuoyebang Nie'an - Comment transformer l'exploitation et la maintenance, écoutez les idées OPaS de Zuoyebang​​
• ​​Exploitation et maintenance Baijia Forum Numéro 1 : Jingyuan - Géométrie d'exploitation et de maintenance​​

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!