Arbeiten mit dem Herstellersupport
Bei der DENOG13 lief der Workshop Working with a vendor TAC - Do's and Don't zu dem ich mir Notizen zur späteren Verwendung gemacht hatte. Da ich bisher weder die Folien noch eine Aufzeichnung zum Workshop fand, habe ich diese Notizen zusammen mit eigenen Erfahrungen zu dem folgenden Text verarbeitet.
Unter Herstellersupport, im folgenden TAC (Technical Assistence Center) genannt, verstehe ich hier den fortgeschrittenen Support, den ein Hersteller wie Cisco oder Arista für Probleme leistet, bei denen der normale Level-1- oder Level-2-Support nicht weiterkommt. Manchmal bekommt man diese Art von Support auch vom Händler, bei dem man das Gerät gekauft hat.
Da dieser Support sehr aufwendig ist und entsprechend teuer, macht es sich bezahlt einige Regeln zu beachten, die in oben genanntem Workshop angesprochen wurden. Ich habe mir hier die Freiheit genommen, die Reihenfolge der Punkte aus dem Workshop zu ändern und einige davon zusammenzufassen.
Kenne dein Netzwerk
Es zahlt sich aus, das Netzwerk nach allseits anerkannten Regeln zu entwerfen, schon allein weil der Aufbau des Systems und die Funktion der Komponenten geläufig sind. Enthält das Netzwerk hingegen "clevere" Hacks, die zwar funktionieren, aber kaum jemand bekannt sind, dann rechne damit, dass du diese dem TAC-Mitarbeiter erklären musst.
Lasse TAC außerdem wissen, ob das Netzwerk unternehmenskritisch ist, produktiv, QA oder ein Laboraufbau. Das beeinflusst die Priorität ebenso wie die Herangehensweise.
Die Topologie deines Netzwerks mag dir bekannt sein, für die effektive Kommunikation ist es von Vorteil, wenn Du sie TAC beschreibst. Im einfachsten Fall reicht eine Aufzählung der Systeme und Gateways. In komplexen Setups hilft ein Ausschnitt aus den Netzplänen oder eine extra angefertigte Zeichnung. Wichtig ist, die Systeme konsistent mit der Fehlermeldung zu benennen.
Hab eine Vorstellung davon, was kaputt ist.
Du musst wissen, welche Systeme beeinträchtigt sind. Mit anderen Worten, mache erst Deine Hausaufgaben und analysiere das Problem soweit Du kannst und wende Dich erst dann an TAC. Deine Aufzeichnungen zum Problem helfen Dir dann, dieses zu kommunizieren.
Schwammige Begriffe, wie "zu langsam", musst Du erklären.
Lege eine gute klare Beschreibung vor
Beginne mit einer Zusammenfassung, ergänze Details und was du bereits getestet und überprüft hast.
Verstehe deine herstellerunabhängige Konfiguration
Nicht immer verwendet man nur Geräte eines Herstellers. Halte in diesem Fall eine Zusammenfassung bereit, die beschreibt, wie alles zusammenspielt. Die Ingenieure vom Herstellersupport kennen sich mit fremder Hardware/Software nicht so gut aus, wie mit der, für die sie Support leisten.
Informiere TAC über geplante Arbeiten
Das setzt zum einen einen zeitlichen Rahmen für die Untersuchung des Problems und ermöglicht es, geplante Änderungen bei der Fehlersuche zu berücksichtigen.
Informiere Dich, wie man Dateien an TAC sendet
Oft geht das über FTP- oder HTTP-Upload oder mit E-Mail-Anhängen. Die Details stehen meist auf den Hilfeseiten.
Merke dir, ob TAC einen Screenshot wollte oder die Dateien.
Wende dich nicht an TAC bevor Du an dem Problem arbeiten kannst.
Insbesondere brauchst du Zugang zum betroffenen System, um Tests zu machen, Logs und Debugmeldungen einzusammeln.
Sende keine leere Anfrage für einen Rückruf
Dabei geht Zeit verloren, bis der richtige Ansprechpartner gefunden ist.
Ein TAC-Call geht schneller, wenn Du gleich am Anfang die relevanten Informationen mitsendet. Es bringt nichts, vorher keine Informationen zu sammeln, nur um den Call schneller zu eröffnen.
Vermische keine technischen mit Status-Calls
Gemischte Calls verlieren Schwung bei der Fehlersuche, weil Manager oft nicht verstehen, wovon Techniker untereinander reden, und außerdem oft bestrebt sind, das Gespräch zu steuern.
Besser ist, eine kurze Pause für eine Zusammenfassung zu machen und diese dann in einem anderen Call weiterzugeben.
Sende keine E-Mail fahrlässig via Cc an das TAC
Jede E-Mail in der TAC-Mailbox, die nicht zugeordnet werden kann, erzeugt ein neues Ticket. Dieses bindet unnötig Ressourcen, bevor es geschlossen wird.
Dränge nicht blindlings um die Dinge zu beschleunigen
Eskalationen helfen in den seltensten Fällen, ein Ticket beim TAC zu beschleunigen. Eine Eskalation zu den Entwicklern bringt dir einen Software-Spezialisten. Eine Eskalation zum Mangement bringt dir einen Management-Spezialisten. Was du brauchst ist ein Netzwerk- oder System-Ingenieur.
Posted 2021-12-01