Wie wir den „Always Connected“-Status geändert haben, um Burnout vorzubeugen

Die Übersetzung des Artikels wurde speziell für die Studierenden des Kurses erstellt „DevOps-Praktiken und -Tools“.

Die Mission von Intercom ist die Personalisierung des Online-Geschäfts. Aber Sie können ein Produkt nicht personalisieren, wenn es nicht funktioniert. wie es sollte. Leistung ist entscheidend für den Erfolg unseres Unternehmens, nicht nur weil unsere Kunden uns bezahlen, sondern auch weil wir selbst sie nutzen mit Ihrem Produkt. Wenn unser Service nicht funktioniert, spüren wir im wahrsten Sinne des Wortes den Schmerz unserer Kunden.

Der reibungslose Betrieb hängt von vielen Faktoren ab, beispielsweise von der Softwarearchitektur und der Qualität der täglichen Arbeit. Allerdings kommt es oft darauf an, dass die Person, die immer in Kontakt ist, Anrufe entgegennimmt PagerDuty. Diese Art von technischem Support kann ein leistungsstarkes, kundenorientiertes Tool sein, das die Hilfe von Ingenieuren mit dem kombiniert, was Kunden beim Kauf Ihres Produkts erhalten. Dies ist auch eine großartige Gelegenheit zum Lernen und Wachstum, denn schließlich können Misserfolge und Irrtümer eine gute Gelegenheit sein, Fähigkeiten zu üben und komplexe Arbeitsmechanismen zu verstehen.

Außerhalb der Arbeitszeit „immer erreichbar“ zu sein, wirkt sich nachteilig auf Ihr Leben aus.

Aber gleichzeitig kann es sich nachteilig auf Ihr Leben auswirken, „immer online“ zu sein. Sie müssen bereit sein, schnell und kompetent auf eine Warnung zu reagieren, dass etwas kaputt ist. Selbst wenn Sie zu einem bestimmten Zeitpunkt nicht angepiept werden, kann es Angst auslösen, „immer erreichbar“ zu sein, wie ich aus eigener Erfahrung weiß. Dadurch verschlechtert sich die Schlafqualität besonders stark. Der regelmäßige Aufenthalt in der Zugriffszone zu jeder Tageszeit kann zu Burnout, Apathie oder ganz allgemein dem Wunsch führen, den Computer nie wieder zu sehen.

Geschichte des Status „Immer verbunden“ in Intercom

In den Anfängen von Intercom leistete unser technischer Direktor Ciaran im Alleingang ein ganzes Team rund um die Uhr technischen Support, sowohl innerhalb als auch außerhalb des Büros. Als Intercom wuchs, wurde eine Task Force gegründet, um Ciaran zu unterstützen. Bald darauf begannen neue Entwicklungsteams mit der Entwicklung vieler neuer Funktionen und Dienste und übernahmen alle technischen Supportaufgaben.

Es waren zu jedem Zeitpunkt zu viele Leute auf Abruf.

Damals schien dieser Ansatz eine Selbstverständlichkeit zu sein, da er eine einfache Möglichkeit darstellte, unser technisches Support-Team im Handumdrehen zu skalieren, er mit unseren Werten übereinstimmte und zu unseren passte Sinn des Eigentums. Am Ende hatten wir keine Pläne, sondern vier oder fünf Teams, die regelmäßig Kunden während ihrer arbeitsfreien Zeit kontaktierten. Der Rest der Entwicklungsteams hatte nicht viele komplexe Probleme, die einen Fehler auslösen könnten, daher wurden sie selten, wenn überhaupt, angerufen.

Uns wurde klar, dass wir uns in einer Situation befanden, in der wir über technische Support-Mechaniker verfügten, auf die wir nicht stolz sein konnten, und eine Reihe kritischer Probleme, die wir beheben wollten, wie zum Beispiel:

• Es gab zu jedem Zeitpunkt zu viele Menschen, die bereit waren, sich der Herausforderung zu stellen. Unsere Infrastruktur war nicht groß genug, um mindestens fünf Entwicklungsingenieure ohne regelmäßige freie Tage arbeiten zu lassen.
• Die Qualität unserer Alarme und Anrufverfahren war nicht in allen Teams konsistent und wir verwendeten Ad-hoc-Prozesse, um neue und bestehende Problemwarnungen zu überprüfen. Die Anweisungen im Runbook (die zu befolgen sind, wenn ein Problem gemeldet wird) fielen größtenteils dadurch auf, dass sie fehlten.
• Je nachdem, in welchem ​​Team die Ingenieure arbeiteten, hatten sie widersprüchliche Erwartungen. Beispielsweise erhielt nur das allererste technische Supportteam eine Entschädigung für Bereitschaftsdienste und gestörte Wochenenden.
• Es schien eine allgemeine Toleranz gegenüber unnötigen Anrufen zu ungewöhnlichen Zeiten zu geben.
• Schließlich ist diese Art von Arbeit nicht jedermanns Sache. Die Lebensumstände zeigten manchmal, dass Dienstverschiebungen nicht die beste Wirkung auf die Menschen hatten.

Den richtigen „Always-on“-Zustand finden

Wir beschlossen, ein neues virtuelles Team zu gründen, das außerhalb der Arbeitszeit für jedes Team technische Supportarbeiten durchführt. Das Team besteht aus Freiwilligen und nicht aus Wehrpflichtigen eines Teams der Organisation. Die Ingenieure des virtuellen Teams wechselten etwa alle sechs Monate und waren wochenlang „auf Abruf“. Glücklicherweise hatten wir kein Problem damit, genügend Freiwillige zu finden, um ein virtuelles Team zusammenzustellen.

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

Anschließend einigte sich das Team darauf und definierte, wie Problemwarnungen und -beschreibungen im Runbook aussehen sollten, und beschrieb einen Prozess zur Weiterleitung von Warnungen an das neue Support-Team. Sie definierten alle Warnungen im Code mithilfe eines Terraform-Moduls und begannen, bei jeder Änderung eine Peer-Review-Methode anzuwenden. Wir haben eine Vergütung für eine wöchentliche Schicht eingeführt, die für die diensthabenden Beamten durchaus zufriedenstellend war. Außerdem haben wir ein eskaliertes Team der zweiten Ebene zusammengestellt, das nur aus Managern bestand. Dieses Team sollte die zentrale Eskalationsstelle für Techniker des technischen Supports sein.

Wir hatten mehrere Monate harter Arbeit, in denen wir diesen Prozess etabliert haben; das Ergebnis war, dass jetzt nicht wie zuvor 30 Ingenieure auf Abruf waren, sondern nur noch 6 oder 7. Während der Arbeitszeit bearbeiten die Teams selbstständig Probleme mit ihren Funktionen bzw In dieser Zeit kommt es in der Regel zu den meisten Pannen, zu allen anderen Zeiten wird technische Unterstützung jedoch von Freiwilligen geleistet.

Was wir gelernt haben

Nachdem wir unser virtuelles technisches Support-Team ins Leben gerufen hatten, erwarteten wir einen Zustrom neuer Aufgaben, etwa die Untersuchung der Ursachen von Problemen oder die Zusammenkunft zur Lösung eines einzelnen Problems, das einen Ausfall verursacht hatte. Allerdings übernahmen unsere Entwicklungsteams die volle Verantwortung für die Faktoren, die die Ausfälle verursachten, und jede nachfolgende Reaktion erfolgte in der Regel sofort. Wir mussten auch vermeiden, dass eine technische Beratungsaufgabe an das Team zurückgesendet wird, von dem sie stammte, um die Ingenieure nicht dazu zu zwingen, sich außerhalb der Geschäftszeiten zu melden.

Die Zahl der Anrufe außerhalb der Geschäftszeiten ist auf weniger als 10 pro Monat gesunken.

Unser Eskalationsprozess wurde selten formell genutzt. Eine häufigere Annahme war, dass dem Ingenieur inoffiziell von dem Team geholfen wurde, das gerade online war, insbesondere von unseren Mitarbeitern im Büro in San Francisco. Viele Probleme konnten durch Teamarbeit und spontane Lösung beseitigt oder reduziert werden.

Ingenieure in unserem Büro in San Francisco verstärkten das Team hauptberuflich und leisteten über den typischen technischen Support hinaus. Wir waren mit einigen Gemeinkosten konfrontiert, aber die Verteilung der Mitglieder unseres Supportteams auf mehrere Niederlassungen war für uns von Vorteil, da es sich als eine gute Möglichkeit erwies, Beziehungen aufzubauen, sie zu stärken und mehr über den Technologie-Stack zu erfahren, mit dem wir alle arbeiten.

Die Arbeit der Intercom-Entwickler in unseren Teams ist konsistenter geworden und wir können getrost über die Vorteile sprechen, die die Arbeit als Systemingenieur auf unserer Website mit sich bringt Karriereund besagt, dass es nicht nötig ist, immer verbunden zu sein, es sei denn, man möchte es sein.

Neben der grundlegenden Arbeit zur Stabilisierung und Skalierung unserer Datenspeicher hat die kontinuierliche Konzentration auf die Problemlösung dazu geführt, dass die Zahl der Anrufe außerhalb der Geschäftszeiten auf weniger als 10 pro Monat gesunken ist. Auf diese Zahl sind wir sehr stolz.

Wir arbeiten weiterhin daran, unser technisches Support-Team zu erhalten und zu verbessern, und wenn Intercom wächst, müssen wir möglicherweise unsere Entscheidungen überdenken, denn was heute funktioniert, wird nicht unbedingt funktionieren, wenn sich unser Personal das nächste Mal verdoppelt. Diese Erfahrung war jedoch äußerst positiv für unser Unternehmen und hat die Lebensqualität unserer Entwicklungsingenieure, die Qualität unserer Antworten auf Anrufe und vor allem die Erfahrung unserer Kunden erheblich verbessert.

Source: habr.com