[LL Blog] - Ein Einblick in die Zusammenarbeit des Ops-Teams

von Linden Lab am 22.09.2014 um 1:40pm PDT (22:40 Uhr MESZ)
- Blogübersetzung -

Quelle: SL Brand Center

Von Zeit zu Zeit treten Störungen auf, die unser operatives Team schnell beheben muss, damit alles in Second Life rund um die Uhr sauber läuft für die Benutzer aus der gesamten Welt.

Wie arbeitet das operative Team bei Linden Lab zusammen, um diese Vorfälle schnell anzugehen? Landon McDowell (Landon Linden), unser Leiter für operative Geschäfte und Plattformentwicklung, hat eine großartige Schilderung seiner anfänglichen Erfahrungen mit unserer Herangehensweise geschrieben, genauso wie einige Gedanken dazu, warum es so gut funktioniert. Das ist ein bisschen außerhalb der üblichen "Tools & Tech"-Themen in diesem Blog, aber wir dachten, Second Life Nutzer, die mit der Arbeitsweise von operativen Teams vertraut sind, würden einen Einblick auf die Ansätze unseres Teams begrüßen:

Zwei Wochen nach meinem Amtsantritt in der operativen Gruppe bei Linden Lab, wurde ich mit meinem ersten größeren Zwischenfall konfrontiert. Es war am frühen Nachmittag und ich war gerade in einem nachmittäglichen Nudel-Koma, als die Alarmmeldungen im IRC aufpoppten. Die komplette Hitliste unserer Hauptfunktionen war in den Überschriften zu sehen, - Logins, gleichzeitige Zugriffe, usw.

Die Meldung ging dann raus an #ops zur Weiterbearbeitung (Anm: #ops ist ein IRC-Kanal des LL-Support), aber ich hatte mich bereits mit eingeklinkt. Dies war nicht mein erstes Rodeo. Ich war darauf vorbereitet, ein Konferenzgespräch zu führen oder in einem Chatraum zu landen, um nach Lösungen zu suchen. Aber das geschah nie.

Stattdessen hatten die anderen damit begonnen, im IRC neue Verbindungen aufzubauen und andere dazuzuholen. Ich war völlig überfordert von einem Textstrom, der über meinen Bildschirm rauschte, während die Ingenieure Rückmeldungen gaben und ihre Erkenntnisse diskutierten.

Das Problem wurde dann schnell auf einen bestimmten Lastverteiler reduziert. Ich war erst kurze Zeit im Chatraum, als ein Ingenieur das Wort ergriff: "Es stehen keine Ports mehr zur Verfügung." Von da an war die Lösung überschaubar: ein wenig schnelles TCP-Tuning und das Hinzufügen von weiterer Backend-Hardware, um die Dinge schnell zu stabilisieren, bevor man sich um eine langfristige Lösung kümmerte.

Ich aber saß nur da und starrte auf den Bildschirm und ich fragte mich, was zum Teufel da gerade passiert war, fragte mich, auf was zum Teufel ich mich eingelassen hatte. Ich dachte, ich wäre ein erfahrener Profi, aber ich hatte noch nie gesehen, dass eine Störungsbeseitigung bei einem Vorfall so glatt und schnell durchgeführt wurde. Es machte sich bei mir leichte Panik breit, dass das eine Nummer zu groß für mich war.

Am folgenden Tag war ich in der Lage, den Vorfall durch das Lesen der Chat-Protokolle zu überprüfen, was wir Scrollback nennen. Mein Vertrauen begann langsam wieder zurückzukehren. Ich arbeitete mich Zeile für Zeile durch den Vorfall, Server für Server, Aktion für Aktion. Nachdem ich die kurze Störungsanalyse abgeschlossen hatte, fühlte ich, dass ich mit etwas mehr Übung und Erfahrung dies auch machen könnte. Ich erkannte auch, dass die von Experten schwerpunktmäßig im Chat durchgeführte Bearbeitung der Vorfälle, mit Abstand die beste und effizienteste Methode zur Behandlung von Ausfällen ist.

Die Geschwindigkeit mittels Text-Kommunikation ist viel schneller. Ein normaler Erwachsener kann etwa doppelt so schnell lesen wie zuhören. Dieser Effekt wird mit Chat-Kommunikation gebündelt, was bedeutet, dass sich mehrere Sprecher gleichzeitig verständlich unterhalten können. Mit etwas Praxis kann ein Teilnehmer auch schnell mehrere unterschiedliche Gespräche verstehen, die im gleichen Kanal verschachtelt ablaufen. Diese Vorteile können nicht genug hervorgehoben werden.

In einem Raum, oder in einer Telefonkonferenz, kann nur eine Person zur gleichen Zeit sprechen. Bei einem Ausfall wegen einer Störung, wenn die Anspannung hoch ist, kann man diese Art des Herangehens nur schwer aufrecht erhalten. Menschen wollen normalerweise sofort ihre Erkenntnisse herauslassen. Es gibt zwar Methoden damit umzugehen, wie zum Beispiel einen Moderator oder Schlagwort-Protokolle. In der Praxis setzt sich dann aber oft das durch, was einer meiner Mitarbeiter "Mountain View-Protokoll" nennt und wo der lauteste Sprecher derjenige ist, der gehört wird.

In Textform sind Bearbeiter in der Lage, sich aus einem Gespräch auszuklinken, sich auf einige Untersuchungen oder Aktionen zu konzentrieren, wieder in das Gespräch zurückzukehren und die Lücke mit einem Scrollback schnell zu schließen, die aufgrund der Abwesenheit entstanden ist. Wenn sich Teilnehmer bei einer verbalen Kommunikation kurz ausklinken, um einige Arbeiten zu erledigen, verlieren sie den Überblick über das Gespräch, was zu einer Menge von Wiederholungen führt.

Die Bearbeiter tauchen nie alle gleichzeitig auf. Oftmals werden sie erst in der Mitte eines Vorfalls dazugeholt. Der Vorteil des Chat-Protokolls kommt hier wirklich voll zum Tragen, weil Nachzügler automatisch ein Update bis zum gegenwärtigen Zeitpunkt bekommen. "Ich lese den Scrollback" ist unser Standard-Einstieg in den Chat und jeder weiß dann, dass jemand neu dazugekommen ist und eine Minute braucht, um auf den aktuellen Stand zu kommen. Selbst in Fällen, wenn eine schnelle Einweisung für einen Neueinsteiger notwendig ist, kann jemand in einem separaten Kanal oder auf eine private Nachricht wechseln, ohne sich vom Hauptgespräch zu lösen.

Andere Arten der Textkonversation sind natürlich auch nützlich beim Bearbeiten einer Störung. Zum Beispiel können die Emotionen bei Ausfällen schon mal etwas heftig werden und gelegentlich muss man jemanden bitten, seine Triebwerke wieder abzukühlen. Dies wird schnell und effektiv in privaten Chat-Nachrichten gemacht, ohne denjenigen vor dem Rest der Mannschaft in Verlegenheit zu bringen.

Bei Linden Lab benennen wir einen bestimmten Chat-Commander, der den Prozess einer Störungsbearbeitung steuern soll. Chat-Systeme geben uns eine einfache Möglichkeit, jemanden mit Chat-Symbolen und/oder in der Überschrift des Kanals zu kennzeichnen, der gerade die Leitung hat. Jeder der neu dazukommt, weiß sofort, wer verantwortlich ist, ohne den Rest des Teams mit einer Frage abzulenken.

Das Durchführen einer Störungsbearbeitung in einem Chat-Kanal ist auch ein unglaublich effektiver Weg der passiven Verbreitung von Informationen an ein breiteres Publikum. Eine große Zahl von Leuten kann in Ruhe in einem Chat-Kanal mitlesen, ganz anders als in einem physischen Raum. Weitere formale Statusberichte an verschiedene Beteiligte, wie zum Beispiel den Support, sind natürlich auch notwendig, aber die Möglichkeit für diese Beteiligten, dem Vorgang in Echtzeit zu folgen, gibt ihnen zusätzlichen Kontext, der sonst eher nicht in einem knappen Statusbericht vermittelt wird.

Und zu guter Letzt sind wir in der Lage, auf ein Problem mit Spitzeneffizienz zu reagieren, unabhängig davon, wo jemand in diesem Moment gerade ist. Störungen warten nicht auf die Office Hours, um aufzutauchen. Unsere einzige Option ist wirklich als dezentrales Team zu arbeiten, aber es ist natürlich großartig, dass die Dezentralisierung gleichzeitig auch ein Vorteil bei der Bearbeitung von Störungen ist.

Die Vorteile der Chat-basierten Störungsbearbeitung hören nicht mit dem Ende des Vorfalls auf. Ein detailliertes Protokoll der Ereignisse zu haben, ist von unschätzbarem Wert bei der Durchführung von Störungsanalysen. Die Leute haben ein schrecklich schlechtes Gedächtnis, vor allem während der stressigen Vorfälle. Das Protokoll gibt uns einen Verlauf der Vorfälle mit genauen Zeiten, die niemals von Bearbeitern erstellt werden könnten, die das aus ihren "Erinnerungen" aufzeichnen würden.

Die Chat-Protokolle für einen Vorfall sind auch ein potentes Lehrmittel. Neue Mitarbeiter können sie nutzen, um über die Einzelheiten und Eigenarten von Systemen etwas zu erfahren, was man sonst nur selten in der Dokumentation oder in direkten Anweisungen findet. Ganz allgemein ergibt das Protokoll ein bemerkenswert klares Bild von dem, was richtig und was schief gelaufen ist bei der Bearbeitung einer Störung, was es dem Team ermöglicht, das besser nachzuvollziehen und ihre Prozesse mit der Zeit zu verbessern.

Chat-basierte Störungsbeseitigung ist nicht einfach. Es erfordert eine disziplinierte Gruppe und Engagement, weil es im Widerspruch zu unseren Instinkten während einer Kommunikation abläuft. Es kann nervenaufreibend sein, für Neulinge genauso wie für Erfahrene. Nicht jeder kommt damit zurecht. Extrem intelligente Menschen sind schon daran gescheitert, weil sie nicht in der Lage waren, das durchzuhalten. Aber wenn es funktioniert, ist es eine wunderbare Sache, ein Ballett in einem Kriegsgebiet, schön, erschreckend, und herrlich.

Quelle: An Inside Look at How The Ops Team Collaborates

............................................................................................................................................................

Anm.:
Ich bin etwas spät mit meiner Übersetzung zu diesem Blogpost. Aber ich habe es zeitlich einfach nicht früher hinbekommen. Gepostet wurde es am letzten Montag.

Das Thema ist im Grunde aber nicht zeitgebunden. Hier wurde einfach ein kleiner Einblick hinter die Kulissen von Linden Lab gegeben. Und ich fand das interessant und auch beruhigend. Denn es zeigt, dass die Lindens eben keine ignorante Gruppe von Leuten sind, die sich den ganzen Tag lang überlegen, wie sie den SL-Nutzern am besten eine überziehen können. Dieses Bild von LL wird leider von einigen Leuten immer wieder gern so dargestellt. Vor allem, wenn sie durch einen Vorfall oder eine Entscheidung von Linden Lab selbst betroffen waren. Aber eigentlich sitzen da auch nur Menschen und die geben meiner Ansicht nach ihr Bestes, um den Ozeandampfer Second Life am Laufen zu halten.