Wie wir den Status "Immer in Kontakt" geändert haben, um professionelles Burnout zu verhindern

Die Übersetzung des Artikels wurde speziell für Studenten des Kurses "DevOps Practices and Tools" erstellt .




Die Mission von Intercom ist es, das Online-Geschäft personalisiert zu gestalten. Eine Personalisierung eines Produkts ist jedoch nicht möglich, wenn es nicht wie gewünscht funktioniert. Effizienz ist entscheidend für den Erfolg unseres Geschäfts, und zwar nicht nur, weil unsere Kunden uns bezahlen, sondern auch, weil wir unser Produkt selbst verwenden. Wenn unser Service nicht funktioniert, spüren wir buchstäblich den Schmerz unserer Kunden.

Die Verfügbarkeit hängt von vielen Faktoren ab, z. B. von der Softwarearchitektur und der Qualität der täglichen Arbeit. Oftmals kommt es jedoch darauf an, dass eine Person, die immer in Kontakt ist, Anrufe von PagerDuty entgegennimmt . Ein solcher technischer Support kann ein leistungsfähiges kundenorientiertes Tool sein, das die Unterstützung von Ingenieuren mit dem kombiniert, was Kunden beim Kauf Ihres Produkts erhalten. Es bietet auch eine großartige Gelegenheit zum Lernen und Wachstum, da Misserfolge und Fehler letztendlich ein gutes Feld sein können, um Fähigkeiten zu entwickeln und die komplexen Mechanismen der Arbeit zu verstehen.

Außerhalb der Arbeitszeit immer in Kontakt zu bleiben, schadet Ihrem Leben.

Gleichzeitig kann sich der Zustand "immer in Kontakt" nachteilig auf Ihr Leben auswirken. Sie sollten bereit sein, schnell und kompetent auf einen Alarm zu reagieren, der auf einen Defekt hinweist. Auch wenn Sie in diesem Moment nicht von einem Pager angerufen werden, erzeugt der Zustand „immer in Kontakt“ ein Gefühl der Angst, das weiß ich selbst aus persönlicher Erfahrung. Vor allem deshalb verschlechtert sich die Schlafqualität. Ein regelmäßiger Aufenthalt im Zugangsbereich zu jeder Tageszeit kann zu Burnout, Apathie oder generell zum Wunsch führen, nie wieder einen Computer zu sehen.

Intercom-Statusverlauf bei Intercom


In den ersten Tagen von Intercom war allein unser technischer Direktor Kiaran ein ganzes Team von technischem Support rund um die Uhr, sowohl im Büro als auch außerhalb. Als Intercom aufwuchs, wurde eine Task Force eingerichtet, die Ciaran helfen sollte. Bald darauf begannen neue Entwicklungsteams, viele neue Funktionen und Dienste zu entwickeln, und sie übernahmen bereits alle Aufgaben des technischen Supports.

In jedem Moment waren zu viele Menschen „in Kontakt“.

Zu dieser Zeit schien dieser Ansatz eine Selbstverständlichkeit zu sein, da das technische Support-Team jederzeit auf einfache Weise skaliert werden konnte, unsere Werte erfüllte und unser Verantwortungsbewusstsein bewahrte . Infolgedessen haben wir ohne Pläne vier oder fünf Teams, die sich regelmäßig während der Nachstunden mit Kunden in Verbindung gesetzt haben. Die restlichen Entwicklungsteams hatten nicht viele schwierige Momente, die einen Fehler auslösen konnten, und wurden daher selten, wenn überhaupt, angerufen.

Wir stellten fest, dass wir uns in einer Situation befinden, in der wir über die Mechanik des technischen Supports verfügen, auf die wir nicht stolz sein können, und über eine Reihe kritischer Probleme, die wir beseitigen wollten, wie z.

  • Zu viele Menschen waren bereit, die Herausforderung zu einem bestimmten Zeitpunkt anzunehmen. Unsere Infrastruktur war nicht so groß, dass mindestens fünf Entwicklungsingenieure erforderlich waren, die ohne ein normales Wochenende arbeiteten.
  • Die Qualität unserer Alarme und Anrufverfahren wurde nicht zwischen den Teams koordiniert, sondern es wurden spezielle Prozesse verwendet, um neue und vorhandene Alarme zu Problemen zu überprüfen. Die Anweisungen im Runbook (die befolgt werden sollten, wenn eine Benachrichtigung über ein Problem eingeht) fielen in ihrer Abwesenheit zumeist auf.
  • Abhängig von dem Team, in dem die Ingenieure arbeiteten, hatten sie widersprüchliche Erwartungen. Zum Beispiel hatte nur das allererste technische Support-Team eine Entschädigung für Dienstzeiten und Wochenendausfälle.
  • Es stellte sich heraus, dass unnötige Anrufe zu unpassenden Zeiten generell toleriert werden.
  • Schließlich ist diese Art von Arbeit nicht für jedermann geeignet. Die Lebensumstände zeigten manchmal, dass Dienstverschiebungen die Menschen nicht in bester Weise betreffen.


Suche nach dem korrekten Status von "Immer in Kontakt"


Wir haben beschlossen, ein neues virtuelles Team zu erstellen, das die technische Unterstützung für jedes Team übernimmt, wenn es arbeitsfrei ist. Das Team besteht aus Freiwilligen, die nicht von einem Team der Organisation eingezogen wurden. Die Ingenieure in einem virtuellen Team wechselten ungefähr alle sechs Monate und verbrachten Wochen damit, in Kontakt zu bleiben. Glücklicherweise hatten wir kein Problem damit, genügend Freiwillige zu finden, um ein virtuelles Team zusammenzustellen.

Infolgedessen wurde unser Support-Team von 30 auf nur noch 6 oder 7 Personen reduziert.

Dieses Team stimmte dann zu und bestimmte, wie die Problemwarnungen und -beschreibungen im Runbook aussehen sollten, und beschrieb den Prozess der Weiterleitung von Warnungen an ein neues Supportteam. Sie identifizierten alle Warnungen im Code mithilfe des Terraform-Moduls und begannen, für jede Änderung eine Expertenbeurteilung vorzunehmen. Wir haben eine Vergütung für die wöchentliche Schicht eingeführt, die für die Diensthabenden durchaus geeignet war. Wir haben auch ein eskaliertes Second-Level-Team geschaffen, das nur aus Managern bestand. Dieses Team sollte der einzige Eskalationspunkt für die Techniker des technischen Supports sein.

Wir hatten mehrere Monate harte Arbeit, in denen wir diesen Prozess begannen, so dass jetzt nicht mehr 30 Ingenieure wie zuvor, sondern nur noch 6 oder 7 in Kontakt blieben. Während der Arbeitszeit beschäftigen sich Teams selbständig mit Problemen mit ihren Funktionen oder Diensten Diese Zeit ist in der Regel für die meisten Pannen verantwortlich, während die restlichen Freiwilligen technische Unterstützung leisten.

Was haben wir gelernt?


Nachdem wir unser virtuelles technisches Support-Team ins Leben gerufen hatten, erwarteten wir einen Zustrom neuer Aufgaben, z. B. die Untersuchung der Ursachen von Problemen oder die allgemeine Erfassung, um ein Problem zu lösen, das den Fehler verursacht hat. Unsere Entwicklungsteams übernahmen jedoch die volle Verantwortung für die Faktoren, die die Ausfälle verursachten, und jede nachfolgende Reaktion war in der Regel eine sofortige Maßnahme. Wir mussten auch eine Situation vermeiden, in der die Aufgabe der technischen Beratung an das Team zurückgegeben wurde, von dem sie angekommen war, um die Ingenieure nicht zu zwingen, sich nach Stunden in Verbindung zu setzen.

Abwesenheitsgespräche gingen auf weniger als 10 pro Monat zurück.

Formal wurde unser Eskalationsprozess selten angewendet. Die allgemeinere Meinung war, dass der Ingenieur, der gerade online ist, dem Ingenieur informell hilft, insbesondere für unsere Mitarbeiter aus dem Büro in San Francisco. Viele Probleme wurden behoben oder ihre Anzahl wurde durch Teamarbeit und sofortige Lösung verringert.

Die Ingenieure in unserem Büro in San Francisco haben sich dem gesamten Team angeschlossen und gingen über den üblichen technischen Support hinaus. Wir standen vor der Frage nach bestimmten Gemeinkosten, aber die Erweiterung unserer Support-Team-Mitgliedschaft auf mehrere Büros, die uns zur Verfügung standen, erwies sich als eine gute Möglichkeit, Beziehungen aufzubauen, sie zu stärken und mehr über den Technologie-Stack zu erfahren, mit dem wir alle zusammenarbeiten.

In unseren Teams ist die Arbeit der Intercom-Entwickler konsequenter geworden, und wir können auf unserer Karriere- Website mit Zuversicht über die Vorteile einer Position als Systemingenieur sprechen. Dabei müssen Sie nicht immer in Kontakt bleiben, wenn Sie dies nicht möchten.

Neben der grundlegenden Arbeit zur Stabilisierung und Skalierung unserer Data Warehouses hat die ständige Aufmerksamkeit auf die Lösung von Problemen dazu geführt, dass die Anzahl der Anrufe während der freien Stunden auf weniger als 10 pro Monat gesenkt wurde. Wir sind sehr stolz auf diese Nummer.

Wir arbeiten weiterhin an der Aufrechterhaltung und Verbesserung unseres technischen Supportteams, und mit dem Anwachsen von Intercom müssen wir möglicherweise unsere Entscheidungen überdenken, da das, was heute funktioniert, nicht unbedingt funktioniert, wenn sich die Anzahl unserer Mitarbeiter das nächste Mal verdoppelt. Dennoch war diese Erfahrung für unser Unternehmen äußerst positiv: Sie hat die Lebensqualität unserer Entwicklungsingenieure, die Qualität unserer Reaktionen auf Herausforderungen und vor allem die Erfahrung unserer Kunden erheblich verbessert.

Source: https://habr.com/ru/post/de476742/


All Articles