Tłumaczenie artykułu zostało przygotowane specjalnie dla studentów kursu .
Misją Intercom jest personalizacja biznesu internetowego. Ale nie możesz spersonalizować produktu, jeśli nie działa. . Wydajność ma kluczowe znaczenie dla powodzenia naszej działalności, nie tylko dlatego, że nasi klienci nam płacą, ale także dlatego, że sami z nich korzystamy . Jeśli nasza usługa nie działa, dosłownie czujemy ból naszych klientów.
Płynne działanie zależy od wielu czynników, takich jak architektura oprogramowania i jakość codziennej pracy. Często jednak wszystko sprowadza się do tego, że telefony odbiera osoba, która jest zawsze w kontakcie . Ten rodzaj wsparcia technicznego może być potężnym narzędziem zorientowanym na klienta, łączącym pomoc inżynierów z tym, co klienci otrzymują, kupując Twój produkt. To także świetna okazja do nauki i rozwoju, bo przecież porażki i błędy mogą być dobrą okazją do ćwiczenia umiejętności i zrozumienia skomplikowanych mechanizmów działania.
Bycie „zawsze aktywnym” poza godzinami pracy ma szkodliwy wpływ na Twoje życie.
Ale jednocześnie bycie „zawsze aktywnym” może mieć szkodliwy wpływ na Twoje życie. Musisz być gotowy, aby szybko i kompetentnie zareagować na alert, że coś jest uszkodzone. Nawet jeśli w danym momencie nie jesteś wywoływany, bycie „zawsze aktywnym” może powodować niepokój, co wiem z własnego doświadczenia. Z tego powodu jakość snu pogarsza się szczególnie mocno. Regularne przebywanie w strefie dostępu o dowolnej porze dnia może prowadzić do wypalenia, apatii lub ogólnie chęci, aby nigdy więcej nie zobaczyć komputera.
Historia stanu „zawsze połączone” w Interkomie
Na samym początku istnienia Intercom nasz dyrektor techniczny Ciaran samodzielnie zapewniał cały zespół wsparcia technicznego XNUMX godziny na dobę, XNUMX dni w tygodniu, zarówno w biurze, jak i poza nim. W miarę rozwoju firmy Intercom utworzono grupę zadaniową, która miała pomóc Ciaranowi. Wkrótce potem nowe zespoły programistów zaczęły tworzyć wiele nowych funkcji i usług oraz przejęły wszystkie obowiązki w zakresie wsparcia technicznego.
W danym momencie „na wezwanie” było zbyt wiele osób.
W tamtym czasie takie podejście wydawało się oczywiste, ponieważ stanowiło łatwy sposób na błyskawiczne skalowanie naszego zespołu pomocy technicznej, było zgodne z naszymi wartościami i odpowiadało naszym . Ostatecznie, bez żadnych planów, otrzymaliśmy cztery lub pięć zespołów, które regularnie kontaktowały się z klientami poza godzinami pracy. Pozostałe zespoły programistów nie miały wielu skomplikowanych problemów, które mogłyby spowodować błąd, więc rzadko, jeśli w ogóle, były wzywane.
Zdaliśmy sobie sprawę, że znaleźliśmy się w sytuacji, w której mamy mechanikę wsparcia technicznego, z której nie możemy być dumni, oraz szereg krytycznych problemów, które chcieliśmy naprawić, takich jak:
- Chętnych do podjęcia wyzwania w dowolnym momencie było zbyt wielu. Nasza infrastruktura nie była na tyle duża, aby wymagać pracy minimum pięciu inżynierów ds. rozwoju bez regularnych dni wolnych.
- Jakość naszych alarmów i procedur wezwań nie była spójna we wszystkich zespołach, dlatego korzystaliśmy z procesów ad hoc w celu przeglądu nowych i istniejących alertów o problemach. Instrukcje w elemencie Runbook (które należy zastosować w przypadku powiadomienia o problemie) były w większości widoczne z powodu ich braku.
- W zależności od zespołu, w którym pracowali inżynierowie, mieli sprzeczne oczekiwania. Na przykład tylko pierwszy zespół pomocy technicznej otrzymywał wynagrodzenie za dyżury i zakłócane weekendy.
- Wydawało się, że panuje ogólna tolerancja dla niepotrzebnych połączeń w dziwnych godzinach.
- Wreszcie ten rodzaj pracy nie jest dla każdego. Okoliczności życiowe czasami pokazywały, że zmiany obowiązków nie miały najlepszego wpływu na ludzi.
Znalezienie odpowiedniego stanu „zawsze włączonego”.
Postanowiliśmy stworzyć nowy wirtualny zespół, który w godzinach wolnych od pracy będzie wykonywał prace wsparcia technicznego dla każdego zespołu. Zespół będzie się składał z ochotników, a nie poborowych z żadnego zespołu w organizacji. Inżynierowie w zespole wirtualnym zmieniali się mniej więcej co sześć miesięcy, spędzając tygodnie „na wezwanie”. Na szczęście nie mieliśmy problemu ze znalezieniem wystarczającej liczby chętnych do skompletowania wirtualnego zespołu.
W rezultacie nasz zespół wsparcia został zredukowany z 30 osób do zaledwie 6 lub 7.
Następnie zespół uzgodnił i zdefiniował, jak powinny wyglądać alerty i opisy problemów w elemencie Runbook, a także opisał proces przekazywania alertów do nowego zespołu pomocy technicznej. Zdefiniowali wszystkie alerty w kodzie za pomocą modułu Terraform i rozpoczęli recenzowanie każdej zmiany. Wprowadziliśmy poziom wynagrodzenia za tygodniową zmianę, który był w miarę satysfakcjonujący dla oficerów dyżurnych. Stworzyliśmy także eskalowany zespół drugiego poziomu, który składał się wyłącznie z menedżerów. Zespół ten powinien stanowić pojedynczy punkt eskalacji dla inżynierów wsparcia technicznego.
Mieliśmy kilka miesięcy ciężkiej pracy, podczas której ustaliliśmy ten proces, w efekcie na dyżurze pracuje już nie 30 inżynierów, jak poprzednio, a tylko 6 lub 7. W godzinach pracy zespoły samodzielnie rozwiązują problemy ze swoimi funkcjami lub serwisowych, na. To właśnie wtedy zwykle zdarza się najwięcej awarii, natomiast w pozostałych przypadkach wsparcie techniczne zapewniają wolontariusze.
Czego się nauczyliśmy
Po uruchomieniu naszego wirtualnego zespołu wsparcia technicznego spodziewaliśmy się napływu nowych zadań, takich jak badanie przyczyn problemów czy wspólne zbieranie się w celu rozwiązania pojedynczego problemu, który był przyczyną przestoju. Jednak nasze zespoły programistów przejęły pełną odpowiedzialność za czynniki powodujące awarie, a każda późniejsza reakcja była zazwyczaj natychmiastowa. Musieliśmy także uniknąć sytuacji, w której zadanie konsultacji technicznej byłoby odsyłane do zespołu, od którego pochodzi, aby nie zmuszać inżynierów do kontaktu po godzinach.
Liczba połączeń po godzinach pracy spadła do mniej niż 10 miesięcznie.
Nasz proces eskalacji był rzadko stosowany formalnie. Bardziej powszechne było przekonanie, że inżynierowi nieoficjalnie pomagał zespół, który był aktualnie online, a zwłaszcza nasi ludzie z biura w San Francisco. Wiele problemów zostało wyeliminowanych lub zredukowanych dzięki pracy zespołowej i rozwiązywaniu ich na bieżąco.
Inżynierowie z naszego biura w San Francisco dołączyli do zespołu na pełny etat i wykraczali poza typowe wsparcie techniczne. Musieliśmy stawić czoła pewnym kosztom ogólnym, ale rozproszenie członkostwa naszego zespołu wsparcia w wielu biurach działało na naszą korzyść, ponieważ okazało się dobrym sposobem na budowanie relacji, wzmacnianie ich i zdobywanie wiedzy na temat stosu technologii, z którym wszyscy współpracujemy.
Praca programistów Intercom stała się bardziej spójna w naszych zespołach i możemy śmiało mówić o korzyściach płynących z bycia inżynierem systemowym na naszej stronie , stwierdzając, że nie ma potrzeby, aby zawsze być podłączonym, chyba że chcesz.
Oprócz podstawowych prac nad stabilizacją i skalowaniem naszych magazynów danych, ciągłe skupianie się na rozwiązywaniu problemów spowodowało, że liczba połączeń poza godzinami pracy spadła do mniej niż 10 miesięcznie. Jesteśmy bardzo dumni z tej liczby.
Kontynuujemy prace nad utrzymaniem i doskonaleniem naszego zespołu wsparcia technicznego, a w miarę rozwoju Intercom być może będziemy musieli ponownie rozważyć nasze decyzje, ponieważ to, co działa dzisiaj, niekoniecznie będzie działać przy następnym zwiększeniu liczby naszych pracowników. Jednakże to doświadczenie było niezwykle pozytywne dla naszej organizacji i znacznie poprawiło jakość życia naszych inżynierów ds. rozwoju, jakość naszych odpowiedzi na telefony, a przede wszystkim doświadczenie naszych klientów.
Źródło: www.habr.com