J'ai cliqué sur "Répondre" sur mon softphone et j'ai pris l'appel. Une partie de moi voulait l'ignorer, mais ce problème m'ennuyait depuis trop longtemps.
C'était l'un des gars de l'équipe Applications. Même s'il était assis à quelques centaines de mètres de l'autre côté du bâtiment, nous avions l'impression d'être à des millions de kilomètres l'un de l'autre la plupart du temps.
Le chef de projet sur cette nouvelle implémentation planait maintenant aussi. Je l'aimais bien, mais elle devenait nerveuse. Le client et tous les autres d'ailleurs voulaient que cela fonctionne hier.
"Cela pourrait-il être un problème avec les VLAN?", A demandé la voix au téléphone.
C'était une question absurde, mais je n'allais pas dire ça. Franchement, j'ai été surpris qu'il n'ait pas demandé si c'était un problème avec le pare-feu, car c'est généralement là que ces choses semblent commencer. Je lui ai assuré qu'il n'y avait aucun blocage dans un seul VLAN ou entre les VLAN que nous examinions avec ce problème. Je ne pensais vraiment pas que c'était un problème de réseau, mais c'est généralement la première chose à blâmer.
Nous sommes arrivés à une autre impasse, nous avons donc prévu une réunion après le déjeuner avec plusieurs autres chefs d'équipe.
J'ai quitté le bureau et j'ai attrapé du Burger King, un plaisir coupable que je trouve trop facile à justifier les jours stressants. L'appel était pour 1 heures, ce qui m'a ennuyé car je devais me précipiter, mais au moins quand je me suis assis à mon bureau, il me restait des frites à grignoter et un grand coca à siroter.
Presque immédiatement après avoir rejoint la conférence téléphonique, le responsable de la sécurité a commencé à se demander pourquoi nous n'avions pas de séparation entre certains VLAN. Bien sûr, cela ne concernait en rien le problème, mais j'ai été obligé d'expliquer notre réseau et comment, dans ce cas, c'était une bonne chose qu'il n'y ait rien entre le serveur d'application et les bases de données principales. Tout était au niveau 2, et franchement j'étais ennuyé que notre responsable de la sécurité ne connaisse toujours pas notre réseau.
Le chef de projet est intervenu et a poliment demandé comment j'avais dépanné la connectivité afin d'arriver à mes conclusions. Elle a utilisé des termes comme "level-set" et "bulle-up" que j'ai entendus mais sommairement rejetés comme du charabia.
Comment étais-je censé répondre ? Elle était intelligente, je le savais, mais elle ne connaissait rien au réseautage. J'ai commencé à parler de tracer des chemins et de ce genre de choses qui ont immédiatement amené quelqu'un à mettre en place des pare-feu dans le chemin. Je ne savais pas qui en avait parlé au début – je pense que c'était l'un des gars de l'équipe Applications.
J'ai roulé des yeux, mais au moins, quelqu'un de l'équipe de stockage ou d'applications, je ne sais pas lequel, a commencé à parler de délais d'attente.
Bingo!
J'ai sauté avec enthousiasme pour confirmer ce qu'il a dit et expliqué que la connectivité est bonne si les serveurs parlent mais expirent. J'ai assuré qu'il n'y avait pas de configurations qui entraîneraient des délais d'attente, en particulier parce que tout était de la couche 2 entre les appareils. Ceci, pour une raison quelconque, l'ensemble du groupe a accepté. Nous commencions enfin à faire des progrès.
Ce problème était du côté des applications de la maison, mais il a fallu plusieurs réunions pour explorer les problèmes de réseau possibles avec des personnes qui n'avaient qu'une connaissance superficielle du réseautage. Il y avait certes une envie de collaborer, et on a bien rigolé une fois le problème résolu, mais le cheminement pour y arriver a été pénible.
Prénom, je ne savais rien de l'application ou du stockage principal en question. Comment communiquaient-ils réellement les uns avec les autres ? Quels ports étaient utilisés ? Était-ce vraiment une panne complète ou était-ce intermittent?
Seconde, la plupart des autres chefs d'équipe en savaient très peu sur le réseautage, mais ont immédiatement supposé que c'était le problème. Cela signifiait que je devais d'abord m'assurer que ce n'était pas le cas, puis le prouver à un groupe de personnes qui connaissaient peu les domaines de diffusion, TCP/IP, les listes de contrôle d'accès et les pare-feu dynamiques.
Troisième, la personne qui a mené la charge n'était pas un ingénieur full stack, ou en d'autres termes, le chef de projet n'avait pas une compréhension raisonnable de tous les domaines techniques liés à l'incident. Cela signifiait que nous n'avancions pas dans une direction claire; l'effort était certainement collaboratif, mais il se sentait aussi décousu et comme si nous tournions dans le noir.
Je ne pense pas que mon expérience soit unique. Beaucoup d'entre nous, professionnels de la technologie, avons expérimenté le jeu du blâme dans une tentative de collaboration. Les connaissances tribales entre les silos sont toujours très réelles dans l'informatique d'entreprise, et bien qu'il puisse y avoir occasionnellement un ingénieur full stack et un chef de projet possédant des connaissances techniques approfondies, nous avons toujours affaire à des équipes cloisonnées et à un partage de connaissances minimal.
Les problèmes auxquels j'ai été confronté dans le dépannage des applications J'ai décrit illustrer cette chose même. Individuellement, chaque chef d'équipe connaissait extrêmement bien son domaine, mais nous connaissions très peu les domaines de chacun. Par exemple, je ne savais pas comment l'application parlait à ses serveurs principaux et, jusqu'à cette session de dépannage, je ne savais pas du tout quels serveurs se parlaient.
De plus, les gens de l'application ne savaient pas que ces serveurs particuliers n'avaient pas de pare-feu entre eux. Je me demande combien de temps ils ont discuté de cette seule théorie avant de créer l'incident dans notre système de billetterie.
Et en plus de cela, le chef de projet qui gérait l'incident n'avait aucune vue unifiée sur les aspects techniques de l'incident autre que des e-mails mal rédigés et des notes ambiguës dans le ticket.
Lorsque des équipes collaborent sur un problème ou une conception spécifique, le partage d'informations est essentiel. Mais souvent, il est difficile de partager ou de donner un sens à des informations aléatoires à un niveau élevé. Les fichiers journaux, les vidages de données, les e-mails et les notes de ticket ont tous leur place, mais nous avons besoin d'une meilleure solution pour combler le fossé entre les équipes qui tentent de collaborer dans l'obscurité.
L'automatisation des étapes de dépannage les plus courantes avec lesquelles nous aimons commencer est un moyen d'obtenir une base d'informations facilement partageable. En fait, un outil d'automatisation sophistiqué doit aller au-delà de la simple automatisation des tâches de dépannage les plus courantes, mais également exécuter une variété de commandes show liées à la plate-forme pour obtenir une ligne de base au moment où le problème se produit.
Plusieurs équipes pourraient alors accéder aux mêmes informations en même temps pour les analyser, à la fois en profondeur technique et sous forme graphique, démocratisant ainsi des connaissances qui seraient autrement entre les mains d'équipes individuelles, ou pire, d'ingénieurs individuels.
Je ne suis pas un expert en stockage et je ne suis pas un gourou du développement d'applications. Je suppose que dans la plupart des organisations d'entreprise, les ingénieurs se spécialisent encore dans un ou seulement quelques domaines, tout comme moi. Si nous voulons faire des progrès rapides pour identifier la cause de la lenteur d'une application ou pourquoi un chemin dans notre infrastructure est complètement cassé, nous allons devoir travailler ensemble.
Une culture de collaboration qui rejette le jeu du blâme et utilise des outils qui démocratisent les connaissances et les rendent facilement disponibles dans toutes les équipes est la voie à suivre, sans les stocker sur nos disques locaux, et certainement pas en blâmant d'abord le réseau.