Ich klickte auf meinem Softphone auf „Annehmen“ und nahm den Anruf an. Ein Teil von mir wollte es ignorieren, aber dieses Problem ärgerte mich schon zu lange.
Es war einer der Jungs vom Anwendungsteam. Obwohl er nur ein paar hundert Meter entfernt auf der anderen Seite des Gebäudes saß, fühlte es sich an, als wären wir die meiste Zeit eine Million Meilen voneinander entfernt.
Auch der Projektleiter schwebte nun über dieser Neuimplementierung. Ich mochte sie, aber sie wurde nervös. Der Kunde und alle anderen wollten, dass dies gestern funktionierte.
„Könnte es ein Problem mit den VLANs sein?“, fragte die Stimme über das Telefon.
Es war eine unsinnige Frage, aber das wollte ich nicht sagen. Ehrlich gesagt war ich überrascht, dass er nicht fragte, ob es ein Problem mit der Firewall war, da diese Dinge normalerweise dort zu beginnen scheinen. Ich versicherte ihm, dass es innerhalb eines einzelnen VLANs oder zwischen den VLANs, die wir mit diesem Problem untersuchten, überhaupt keine Blockierung gab. Ich habe wirklich nicht geglaubt, dass dies ein Netzwerkproblem ist, aber das ist normalerweise das erste, was beschuldigt wird.
Wir erreichten eine weitere Sackgasse, also vereinbarten wir nach dem Mittagessen ein Treffen mit mehreren anderen Teamleitern.
Ich verließ das Büro und schnappte mir einen Burger King, ein schuldiges Vergnügen, das ich an stressigen Tagen zu leicht zu rechtfertigen finde. Der Anruf war für 1 Uhr, was mich ärgerte, da ich zurückeilen musste, aber als ich mich an meinen Schreibtisch zurücklehnte, hatte ich zumindest noch ein paar Pommes zum Naschen und eine große Cola zum Schlürfen übrig.
Fast unmittelbar nach der Teilnahme an der Telefonkonferenz begann der Sicherheitsmanager zu fragen, warum wir keine Trennung zwischen bestimmten VLANs hatten. Natürlich bezog sich das überhaupt nicht auf das Problem, aber ich musste unser Netzwerk erklären und wie gut es in diesem Fall war, dass zwischen dem App-Server und den Backend-Datenbanken nichts war. Es war alles Layer 2, und ehrlich gesagt ärgerte es mich, dass unser Sicherheitsmann unser Netzwerk immer noch nicht kannte.
Der Projektmanager mischte sich ein und fragte höflich, wie ich die Konnektivität behoben habe, um zu meinen Schlussfolgerungen zu kommen. Sie benutzte Begriffe wie „Level-Set“ und „Bubble-Up“, die ich hörte, aber kurzerhand als Kauderwelsch abtat.
Wie hätte ich antworten sollen? Sie war schlau, das wusste ich, aber sie hatte keine Ahnung von Netzwerken. Ich fing an, über das Verfolgen von Pfaden und dergleichen zu sprechen, was sofort dazu führte, dass jemand Firewalls in den Pfad einbrachte. Ich wusste nicht, wer das zuerst angesprochen hat – ich glaube, es war einer der Jungs vom Anwendungsteam.
Ich verdrehte die Augen, aber zumindest führte dies dazu, dass jemand im Speicher- oder Anwendungsteam, ich bin mir nicht sicher, welcher, anfing, über Zeitüberschreitungen zu sprechen.
Bingo!
Ich sprang aufgeregt ein, um zu bestätigen, was er sagte, und erklärte, dass die Verbindung in Ordnung ist, wenn die Server sprechen, aber eine Zeitüberschreitung aufweisen. Ich habe versichert, dass es keine Konfigurationen gibt, die zu Timeouts führen würden, insbesondere weil es sich um Layer 2 zwischen den Geräten handelt. Dies akzeptierte aus irgendeinem Grund die gesamte Gruppe. Endlich machten wir Fortschritte.
Dieses Problem lag auf der Anwendungsseite des Hauses, aber es waren mehrere Treffen erforderlich, um mögliche Netzwerkprobleme mit Leuten zu untersuchen, die nur oberflächliche Kenntnisse über Netzwerke hatten. Es gab sicherlich den Wunsch, zusammenzuarbeiten, und wir haben herzlich gelacht, nachdem das Problem gelöst war, aber der Weg dorthin war schmerzhaft.
Vorname, ich wusste nichts über die betreffende Anwendung oder den Backend-Speicher. Wie haben sie eigentlich miteinander kommuniziert? Welche Ports wurden verwendet? War das wirklich ein kompletter Ausfall oder war es sporadisch?
Zweite, die meisten anderen Teamleiter wussten sehr wenig über Networking, gingen aber sofort davon aus, dass es das Problem war. Das bedeutete, dass ich zuerst sicherstellen musste, dass dies nicht der Fall war, und es dann einer Gruppe von Leuten beweisen musste, die wenig über Broadcast-Domänen, TCP/IP, Zugriffskontrolllisten und Stateful-Firewalls wussten.
Dritte, war die Person, die die Anklage leitete, kein Full-Stack-Ingenieur, oder mit anderen Worten, der Projektmanager hatte kein angemessenes Verständnis aller technischen Bereiche im Zusammenhang mit dem Vorfall. Das bedeutete, dass wir uns nicht in eine klare Richtung bewegten; Die Anstrengung war sicherlich kollaborativ, aber es fühlte sich auch unzusammenhängend an und als würden wir im Dunkeln schießen.
Ich glaube nicht, dass meine Erfahrung einzigartig ist. Viele von uns Technologieprofis haben beim Versuch der Zusammenarbeit das Schuldspiel erlebt. Stammeswissen zwischen Silos ist in der Unternehmens-IT immer noch sehr real, und obwohl es gelegentlich Full-Stack-Ingenieure und Projektmanager mit tiefem technischen Wissen geben mag, haben wir es im Großen und Ganzen immer noch mit abgeschirmten Teams und minimalem Wissensaustausch zu tun.
Die Probleme, mit denen ich konfrontiert war Fehlerbehebung bei Anwendungen Ich habe genau das beschrieben. Jeder einzelne Teamleiter kannte sein Gebiet sehr gut, aber wir wussten sehr wenig über die Gebiete des anderen. Zum Beispiel wusste ich nicht, wie die Anwendung mit ihren Backend-Servern kommunizierte, und bis zu dieser Fehlerbehebungssitzung wusste ich überhaupt nicht, welche Server miteinander kommunizierten.
Außerdem wussten die Anwendungsleute nicht, dass diese speziellen Server keine Firewalls dazwischen hatten. Ich muss mich fragen, wie lange sie nur diese eine Theorie diskutiert haben, bevor sie den Vorfall in unserem Ticketing-System erstellt haben.
Darüber hinaus hatte der Projektmanager, der den Vorfall bearbeitete, keinen einheitlichen Überblick über die technischen Aspekte des Vorfalls, abgesehen von schlecht formulierten E-Mails und mehrdeutigen Notizen im Ticket.
Wenn Teams an einem bestimmten Problem oder Design zusammenarbeiten, ist der Informationsaustausch von entscheidender Bedeutung. Aber oft ist es entweder schwierig zu teilen oder zufällige Informationen von einem hohen Niveau aus zu verstehen. Protokolldateien, Daten-Dumps, E-Mails und Ticketnotizen haben alle ihren Platz, aber wir brauchen eine bessere Lösung, um die Lücke zwischen Teams zu schließen, die versuchen, im Dunkeln zusammenzuarbeiten.
Die Automatisierung der häufigsten Schritte zur Fehlerbehebung, mit denen wir gerne beginnen, ist eine Möglichkeit, eine Basis von Informationen zu erhalten, die leicht weitergegeben werden können. Tatsächlich sollte ein ausgeklügeltes Automatisierungstool über die einfache Automatisierung der häufigsten Fehlerbehebungsaufgaben hinausgehen, sondern auch eine Vielzahl von plattformbezogenen Show-Befehlen ausführen, um genau zum Zeitpunkt des Auftretens des Problems eine Basislinie zu erhalten.
Mehrere Teams könnten dann gleichzeitig auf dieselben Informationen zugreifen, um sie sowohl in technischer Tiefe als auch in einem grafischen Format zu analysieren, wodurch Wissen demokratisiert würde, das sonst in den Händen einzelner Teams oder schlimmer noch einzelner Ingenieure liegen würde.
Ich bin kein Speicherexperte und kein Anwendungsentwicklungsguru. Ich vermute, dass sich Ingenieure in den meisten Unternehmen immer noch auf einen oder nur wenige Bereiche spezialisieren, so wie ich es tue. Wenn wir schnell vorankommen wollen, um die Ursache für die Verlangsamung einer Anwendung zu identifizieren oder warum ein Pfad in unserer Infrastruktur vollständig unterbrochen ist, müssen wir zusammenarbeiten.
Eine Kultur der Zusammenarbeit, die Schuldzuweisungen ablehnt und Tools nutzt, die Wissen demokratisieren und es teamübergreifend leicht verfügbar machen, ist der richtige Weg, es nicht auf unseren lokalen Laufwerken zu horten und sicherlich nicht zuerst dem Netzwerk die Schuld zu geben.