Menu

Collaboration dans DevOps

collaboration devops

Essayez Notre Instrument Pour Éliminer Les Problèmes

Collaboration dans DevOps:

Petits incréments de livraisons dans DevOps a été expliqué en détail dans notre précédent tutoriel.

Nous savons que le mantra clé de DevOps est la collaboration et c'est pourquoi le mot DevOps est arrivé.

Lire => Tutoriels DevOps approfondis

La collaboration consiste à se réunir en une seule équipe pour résoudre tout problème du programme, ce qui entrave l'orientation client du programme en gardant à l'esprit les objectifs du programme et les résoudre en les assumant comme leur propre problème le plus rapidement possible, sans aucun jeu de blâme.

Collaboration dans DevOps

La collaboration apprend à tout le monde à se parler, à se rencontrer face à face, à s’impliquer dans leurs réunions, discussions, à comprendre les tâches de chacun, à faire preuve de transparence dans le travail et à travailler de manière proactive pour prévenir les problèmes.

comment gérer certaines situations

VIDÉO Partie 2 Bloc 5: Collaboration - 15 minutes 36 secondes

Transcription:

Le terme collaboration est répété à maintes reprises dans DevOps et le mantra Devops est la collaboration. Alors, comprenons ce que signifie réellement «collaboration» dans le contexte du développement logiciel et du DevOps.

Selon moi, dès qu'une organisation dit, nous mettons en œuvre DevOps, automatiquement la pensée de collaboration qui est attachée à la pratique des devops démarre dans l'esprit de chacun et les rend plus concentrés et alertes à la collaboration et ils commencent à sentir qu'ils ont besoin de collaborer. . C’est la magie de la collaboration.

Ainsi, initier la collaboration DevOps dès le début du projet est très essentiel pour l'organisation et l'équipe. L'équipe je veux dire, les membres de l'équipe du programme.

Je vais expliquer quelques exemples où j'ai vu Dev collaborer avec Ops et ops collaborer avec l'équipe de développement afin que nous sachions ce que signifie réellement collaborer dans le contexte DevOps.

C'est la représentation de l'instance un.

Il y avait un cas où il y avait un problème inconnu dans le script d'installation ou le script de configuration que l'équipe ops trouvait un défi dans l'installation du logiciel sur une configuration particulière d'un cluster dans une géographie particulière.

Cela lançait une erreur inconnue et était un problème de production pur, qui ne s'est jamais produit dans l'environnement de développement et l'équipe des opérations a vraiment dépensé beaucoup d'efforts pour les résoudre par elle-même en pensant que c'est quelque chose lié à la configuration, et qu'ils doivent résoudre il, qui n’a pas été résolu depuis assez longtemps.

Puis aussitôt l'équipe de développement est intervenue sans même être invitée à aider, même si le fuseau horaire était différent, il a pris le contrôle du site de production, vous savez généralement que l'accès à la production ne sera pas donné à tout le monde, Ops partage juste l'erreur détails ou toute autre information dont l'équipe a besoin à des fins de débogage.

Mais cette situation est nécessaire pour donner accès à l'un des membres de l'équipe de développement, qui a consacré quelques heures à analyser le problème en direct et a fourni un travail immédiat.Le problème a donc été résolu rapidement.

C'est le cas de la collaboration où l'équipe de développement a volontairement possédé le problème et a aidé l'équipe des opérations à le résoudre. C'est un pur exemple de collaboration.

De même, un autre exemple, permettez-moi de le montrer sous forme de diagramme, que j'ai dessiné. Un autre exemple est que les choses fonctionnaient plutôt bien après la mise à niveau du logiciel sur un site particulier pendant quelques jours, tout d'un coup les performances de l'application ont commencé à ralentir.

Les utilisateurs finaux ont commencé à faire face à de graves pertes transactionnelles en raison de ce ralentissement. De nombreux appels de réclamation ont commencé à arriver aux représentants du service clientèle, je veux dire, et ils ont, à leur tour, commencé à faire un suivi avec l'équipe sur le problème.

Dans ce cas, immédiatement les équipes de développement et d'exploitation se sont réunies, et avec les informations et les détails de télémétrie fournis par l'équipe des opérations à l'équipe de développement, ils ont pu déboguer le problème et identifier qu'il y avait un problème dans l'aspect du partage de charge et par conséquent, la performance était lente.

Ainsi, les deux équipes ont travaillé ensemble pour résoudre le problème et ramener à la normale en quelques heures. Donc, ici, le Dev et l'Ops se sont présentés ensemble et ont collaboré ensemble pour résoudre le problème au lieu que le Dev dise son problème d'Ops et Ops pense qu'il s'agit du problème de Dev et l'équipe de développement doit le regarder et le résoudre.

Il s'agit d'un exemple clair de collaboration où tout le monde possède les problèmes, au lieu de jouer au jeu du blâme, quel que soit le problème ou perdre du temps à découvrir de qui il s'agit, en gardant à l'esprit que l'utilisateur final souffre et que le problème a besoin. à réparer bientôt.

Donc, encore une fois ici, le problème ne doit pas provenir uniquement de la production, il peut s'agir de n'importe quel problème de développement de logiciel interne, aussi simple qu'un problème quotidien, ou un problème de conception, ou un problème d'architecture, ou même un simple problème d'outil.

Tout problème lié au programme ou tout problème dont l'équipe sait que, causant des dommages au client ou ralentissant le programme doit appartenir à tout le monde, au lieu d'isoler le problème qu'il s'agit d'un problème de développement ou d'un problème d'exploitation ou d'un problème de test, et contribuer à y remédier le plus rapidement possible, est une collaboration.

Ainsi, la collaboration dans le contexte DevOps est le développement et les opérations qui se réunissent et travaillent ensemble pour résoudre le problème le plus tôt possible, en gardant à l'esprit l'attention du client.

La collaboration est à la fois la responsabilité du développement et des opérations sur ce qui se passe en direct, la surveillance et la journalisation et la vérification des performances étant au top pour résoudre le problème qui se produit en particulier en production dans l'intérêt de l'utilisateur final.

OU simplement, je peux dire que toute l'équipe, travaillant constamment ensemble pour résoudre le problème afin d'atteindre les objectifs du programme, en gardant à l'esprit l'attention du client, c'est la collaboration. Je le répète, travailler constamment ensemble pour résoudre les problèmes afin d'atteindre les objectifs du programme en gardant à l'esprit l'orientation client, c'est la collaboration.

Puis une question se pose, comment développer cette collaboration et quand devons-nous initier la collaboration au sein de l'équipe, qui sont à des kilomètres les uns des autres?

logiciel espion de téléphone portable pour android

De toute évidence, nous savons que le développement et les opérations ne peuvent pas co-localiser. L'équipe Ops doit être plus proche du site de travail ou des centres de données, et le développeur doit être plus proche du centre de développement logiciel. Alors, comment réaliser la collaboration constante entre les deux équipes ??

Tout d'abord, initier une collaboration DevOps dès le début du projet est très essentiel pour l'organisation et l'équipe. L'équipe que je veux dire ici, ce sont les membres de l'équipe du programme.

Pratiquer quelques-unes des choses suivantes aiderait à combler le fossé entre l'équipe et à surmonter la contrainte des équipes virtuelles et aiderait à réaliser la collaboration.

Voyons donc quelles sont ces pratiques qui aident à réaliser la collaboration.

Impliquer le développement dans toutes les réunions et discussions pertinentes de l'équipe des opérations et vice versa.

Cela les rassemble non seulement, mais aide également à comprendre chacun de leur domaine de travail, leurs problèmes quotidiens et l'impact de leur travail les uns sur les autres, et quelles sont les choses essentielles que chacun devrait prendre en compte pour éviter les problèmes plus tard et par conséquent, les rapproche et initie à chaque fois une discussion confortable entre eux.

Avant l'introduction de la pratique DevOps, l'équipe de développement ne se souciait jamais de la livraison du logiciel aux opérations. Vous savez qu'ils ignoraient ou ne se préoccupaient jamais de choses comme l'infrastructure, les configurations, les configurations de serveur, les configurations réseau, la surveillance des performances en direct, etc.,

Ils avaient l'habitude de penser que toutes ces activités relèvent de la responsabilité de l'équipe des opérations et l'équipe de développement n'en avait jamais entendu parler. Auparavant, l'équipe de livraison pour le développement signifiait être la livraison à l'équipe des opérations uniquement, mais avec la pratique DevOps, la livraison signifie à la production et pas seulement aux opérations.

De même, les opérations ne se souciaient jamais du code produit par l'équipe de développement. Tout problème auquel ils sont confrontés lors de l'installation du logiciel, des problèmes de fonctionnalité ou de performance dans la production, ils se contentaient de renvoyer la responsabilité à l'équipe de développement et de leur demander de le réparer et de le rendre.

Ainsi, connaître le travail de chacun, comprendre sa tâche et s'approprier le problème de chacun tout au long du cycle aide l'équipe à résoudre les problèmes rapidement.

Parce qu'ils savent où est le problème et ce qui se passe dans le programme et ce qui cause le problème dans la production et peuvent donc directement aller le résoudre sans trop de difficulté.

Ainsi, la collaboration signifie que l'équipe de développement doit comprendre l'infrastructure et la configuration, et l'équipe des opérations doit se soucier du code, de la qualité, de la livraison et des délais.

Comprendre la dépendance les uns des autres aidera à accélérer le travail et à le livrer à temps.

Comme lors de l'installation de logiciels, l'équipe d'exploitation dépend d'une équipe de développement pour résoudre les problèmes liés à l'installation. De même, lors du codage, l'équipe de développement dépend d'un grand nombre de conditions préalables qui existent en direct que l'équipe des opérations doit fournir pour prendre soin pendant le processus de codage.

Un autre Exemple L'équipe de test dépend de l'équipe d'exploitation pour fournir des échantillons de données en direct de la production à des fins de test. Détails de la configuration de l'environnement à configurer dans l'environnement de développement, etc.

Ainsi, les deux équipes doivent collaborer les unes avec les autres et comprendre la dépendance l'une à l'autre et fournir les données ou les informations à temps sans causer de retard en gardant à l'esprit le facteur de fuseau horaire.

Maintenez la transparence en adoptant les pratiques DevOps telles que le contrôle de source ou le contrôle de version, ce qui permet à l'équipe de tout comprendre sur le programme et aide à éviter tout malentendu.

Donc, il s'agit essentiellement de maintenir la transparence au sein de l'équipe.

Les membres de l'équipe n'ont pas besoin de dépendre d'une personne ou d'une information particulière, par exemple si quelqu'un veut connaître la configuration mise en place à un nœud particulier du cluster, ils n'ont donc pas besoin d'attendre que l'équipe des opérations se réveille et leur fournir ces détails, au lieu de cela, ils peuvent accéder à l'outil de contrôle de version et récupérer ces informations et terminer leur tâche sans délai.

Apprendre les uns des autres, en particulier de l'erreur des autres, est la plus grande caractéristique de la collaboration. Pour qu’ils ne répètent pas ces erreurs déjà commises par quelqu'un d’autre.

Ainsi, le développement apprend de l'opération et les opérations apprennent du développement, qu'il s'agisse d'une nouvelle technologie, d'un nouvel outil ou d'une action plus simple et meilleure. Où les deux sont sur la même longueur d'onde et donc ils collaborent les uns avec les autres en apprenant les uns des autres.

Les opérations avaient toujours l'impression que l'équipe de développement était très lente et qu'elles ne pouvaient pas livrer à temps, maintenant qu'elles interagissent avec l'équipe de développement au jour le jour, elles comprennent ce qui cause le retard, que ce soit moins de clarté dans le exigences, problème de conception, problème de codage ou tout autre problème d'outil.

Même ils participent et fournissent leurs précieuses suggestions pour s'améliorer.

De plus, en cas de problème provenant de la production ou du site de développement, DevOps introduit une culture consistant à résoudre d'abord le problème plutôt qu'à essayer de savoir qui ou quelle équipe a introduit ce problème. Et donc tout le monde essaie de se concentrer sur la résolution du problème plutôt que de perdre du temps à découvrir qui a causé le problème.

Alors, arrêtez de blâmer et de considérer le problème de chacun comme le sien et de s'avancer pour les résoudre ensemble et de soutenir le problème, se soutenir mutuellement pendant leurs problèmes est à nouveau une collaboration.

Donc, je peux dire, arrêtez de blâmer le jeu, blâmer le jeu est à nouveau une caractéristique de la collaboration.

Quand tout le monde commence à penser communément dans la même direction, le même état d'esprit et à travailler sur les mêmes aspects et pratiques, c'est à nouveau une collaboration comme à chaque fois qu'une nouvelle fonctionnalité est développée, tout le monde réfléchit à comment tester cela, comment déployer cela, comment surveiller cela, est une collaboration.

Donc, penser communément, au sein de l'équipe est à nouveau une caractéristique de la collaboration.

Prenons une pause maintenant et comprenons un peu plus la collaboration dans notre prochaine vidéo.

Tutoriel PREV | Tutoriel SUIVANT

lecture recommandée

^