Cultuur van samenwerking

by Philip Gervasi September 20, 2017

Ik klikte op "Beantwoorden" op mijn softphone en nam de oproep aan. Een deel van mij wilde het negeren, maar dit probleem irriteerde me al te lang.

Het was een van de jongens van het Applications-team. Hoewel hij maar een paar honderd meter verderop aan de andere kant van het gebouw zat, voelde het meestal alsof we miljoenen kilometers van elkaar verwijderd waren.

De projectmanager van deze nieuwe implementatie zweefde nu ook. Ik vond haar leuk, maar ze werd zenuwachtig. De klant en alle anderen wilden dit gisteren werkend hebben.

"Zou het een probleem kunnen zijn met de VLAN's?", vroeg de stem aan de telefoon.

Het was een onzinnige vraag, maar dat ging ik niet zeggen. Eerlijk gezegd was ik verrast dat hij niet vroeg of het een probleem met de firewall was, aangezien dit meestal is waar deze dingen beginnen. Ik verzekerde hem dat er helemaal geen blokkering was binnen een enkel VLAN of tussen de VLAN's waar we naar keken met dit probleem. Ik geloofde echt niet dat dit een netwerkprobleem was, maar dat is meestal het eerste dat de schuld krijgt.

We bereikten een nieuwe impasse, dus we planden een vergadering voor na de lunch met verschillende andere teamleiders.

Ik verliet het kantoor en pakte wat Burger King, een schuldig genoegen dat ik op stressvolle dagen te gemakkelijk vind te rechtvaardigen. Het telefoontje was om 1 uur, wat me irriteerde omdat ik terug moest haasten, maar toen ik achter mijn bureau zat, had ik tenminste nog wat friet over om op te kauwen en een grote cola om te nippen.

Vrijwel onmiddellijk na deelname aan de telefonische vergadering begon de beveiligingsmanager zich af te vragen waarom we geen segregatie hadden tussen bepaalde VLAN's. Dit had natuurlijk helemaal geen betrekking op het probleem, maar ik moest ons netwerk uitleggen en hoe het in dit geval een goede zaak was dat er niets tussen de app-server en backend-databases zat. Het was allemaal laag 2 en eerlijk gezegd was ik geïrriteerd dat onze beveiligingsmedewerker ons netwerk nog steeds niet kende.

De projectmanager kwam tussenbeide en vroeg beleefd hoe ik de verbindingsproblemen had opgelost om tot mijn conclusies te komen. Ze gebruikte termen als "level-set" en "bubble-up" die ik hoorde maar summier verwierp als wartaal.

Hoe moest ik antwoorden? Ze was slim, dat wist ik, maar ze wist niets van netwerken. Ik begon te praten over het traceren van paden en dat soort dingen, wat er meteen toe leidde dat iemand firewalls in het pad naar voren bracht. Ik wist eerst niet wie dat ter sprake bracht – ik denk dat het een van de jongens van het Applications-team was.

Ik rolde met mijn ogen, maar het resulteerde er in ieder geval in dat iemand in het opslag- of applicatieteam, ik weet niet zeker welke, begon te praten over time-outs.

Bingo!

Ik sprong opgewonden in om te bevestigen wat hij zei en legde uit dat connectiviteit prima is als de servers praten maar een time-out hebben. Ik verzekerde dat er geen configuraties waren die time-outs zouden veroorzaken, vooral omdat het allemaal laag 2 was tussen de apparaten. Dit accepteerde om de een of andere reden de hele groep. We begonnen eindelijk wat vooruitgang te boeken.

Dit probleem lag aan de applicatiekant van het huis, maar er waren verschillende vergaderingen voor nodig om mogelijke netwerkproblemen te onderzoeken met mensen die slechts oppervlakkige kennis van netwerken hadden. Er was zeker een verlangen om samen te werken, en we hebben goed gelachen nadat het probleem was opgelost, maar het proces om daar te komen was pijnlijk.

Voornaam*, wist ik niets van de applicatie of de backend-opslag in kwestie. Hoe communiceerden ze eigenlijk met elkaar? Welke poorten werden gebruikt? Was dit echt een volledige storing of was het met tussenpozen?

Tweede, wisten de meeste andere teamleiders heel weinig van netwerken, maar gingen er meteen van uit dat dit het probleem was. Dat betekende dat ik er eerst voor moest zorgen dat het niet zo was en het vervolgens moest bewijzen aan een groep mensen die weinig afwisten van broadcastdomeinen, TCP/IP, toegangscontrolelijsten en stateful firewalls.

Derde, was de persoon die de leiding had geen full-stack engineer, met andere woorden, de projectmanager had geen redelijk begrip van alle technische gebieden die verband hielden met het incident. Dit betekende dat we geen duidelijke richting uitgingen; de inspanning was zeker een samenwerking, maar het voelde ook onsamenhangend en alsof we in het donker aan het fotograferen waren.

Ik denk niet dat mijn ervaring uniek is. Velen van ons technologieprofessionals hebben het schuldspel ervaren in een poging tot samenwerking. Stamkennis tussen silo's is nog steeds zeer reëel in enterprise-IT, en hoewel er af en toe een full-stack engineer en projectmanager met diepgaande technische kennis is, hebben we over het algemeen nog steeds te maken met afgeschermde teams en minimale kennisdeling.

De problemen die ik tegenkwam in de probleemoplossing voor toepassingen Ik beschreef illustreren dit zeer ding. Individueel kende elke teamleider zijn gebied buitengewoon goed, maar we wisten heel weinig van elkaars gebieden. Ik wist bijvoorbeeld niet hoe de applicatie met zijn backend-servers communiceerde, en tot deze probleemoplossingssessie wist ik helemaal niet welke servers met elkaar communiceerden.

Ook wisten de applicatiemensen niet dat deze specifieke servers geen firewalls ertussen hadden. Ik moet me afvragen hoe lang ze alleen die ene theorie hebben besproken voordat ze het incident in ons ticketingsysteem creëerden.

Bovendien had de projectmanager die het incident afhandelde geen eenduidig ​​beeld van de technische aspecten van het incident, behalve slecht geformuleerde e-mails en onduidelijke aantekeningen in het ticket.

Wanneer teams samenwerken aan een specifiek probleem of ontwerp, is het delen van informatie van cruciaal belang. Maar vaak is het moeilijk om willekeurige informatie van een hoog niveau te delen of moeilijk te begrijpen. Logbestanden, datadumps, e-mail en ticketnotities hebben allemaal hun plaats, maar we hebben een betere oplossing nodig om de kloof te overbruggen tussen teams die in het donker proberen samen te werken.

Het automatiseren van de meest voorkomende stappen voor probleemoplossing waarmee we graag beginnen, is een manier om een ​​basislijn van informatie te krijgen die gemakkelijk kan worden gedeeld. In feite zou een geavanceerde automatiseringstool verder moeten gaan dan het simpelweg automatiseren van de meest voorkomende probleemoplossingstaken, maar ook een verscheidenheid aan platformgerelateerde showopdrachten uitvoeren om een ​​basislijn te krijgen op het moment dat het probleem zich voordoet.

Meerdere teams zouden dan tegelijkertijd toegang hebben tot dezelfde informatie om deze te analyseren, zowel in technische diepte als in een grafisch formaat, waardoor kennis wordt gedemocratiseerd die anders in handen zou zijn van individuele teams, of erger nog, individuele ingenieurs.

Ik ben geen expert op het gebied van opslag en ik ben geen goeroe voor applicatie-ontwikkeling. Ik vermoed dat ingenieurs in de meeste bedrijfsorganisaties nog steeds gespecialiseerd zijn in een of slechts enkele gebieden, net als ik. Als we snel vooruitgang willen boeken bij het identificeren van de oorzaak van traagheid in een applicatie of waarom een ​​pad in onze infrastructuur volledig verbroken is, zullen we moeten samenwerken.

Een cultuur van samenwerking die het schuldspel verwerpt en tools gebruikt die kennis democratiseren en gemakkelijk beschikbaar maken voor teams, is de juiste weg voorwaarts, niet oppotten op onze lokale schijven, en zeker niet eerst het netwerk de schuld geven.