A traduzzione di l'articulu hè stata preparata apposta per i studienti di u corsu .
A missione di Intercom hè di persunalizà l'affari in linea. Ma ùn pudete micca persunalizà un pruduttu quandu ùn funziona micca. . U rendiment hè criticu per u successu di a nostra attività, micca solu perchè i nostri clienti ci paganu, ma ancu perchè noi stessi utilizemu. . Se u nostru serviziu ùn funziona micca, sentimu literalmente u dolore di i nostri clienti.
U funziunamentu lisu dipende da parechji fatturi, cum'è l'architettura di u software è a qualità di u travagliu di ogni ghjornu. Tuttavia, abbastanza à spessu tuttu vene falà à u fattu chì a persona chì hè sempre in cuntattu risponde chiama da . Stu tipu di supportu tecnicu pò esse un strumentu putente centratu in u cliente chì combina l'aiutu di l'ingegneri cù ciò chì i clienti ricevenu quandu compranu u vostru pruduttu. Questu hè ancu una grande opportunità per l'apprendimentu è a crescita, perchè dopu tuttu, i fallimenti è i sbagli ponu esse una bona opportunità per praticà e cumpetenze è capisce i meccanismi di travagliu cumplessi.
Esse "sempre in" fora di l'ore di travagliu hà un effettu preghjudiziu in a vostra vita.
Ma à u stessu tempu, essendu "sempre nantu" pò avè un effettu preghjudiziu in a vostra vita. Avete da esse prontu à risponde rapidamente è cumpetente à una alerta chì qualcosa hè rottu. Ancu s'ellu ùn site micca paginatu in ogni mumentu, esse "sempre attivu" pò creà ansietà, cum'è a so da a sperienza persunale. Per via di questu, a qualità di u sonnu deteriorate soprattuttu forte. Esse regularmente in a zona d'accessu à ogni mumentu di u ghjornu pò purtà à burnout, apatia, o, in generale, un desideriu di ùn vede mai più l'urdinatore.
Storia di u statu "sempre cunnessu" in Intercom
In i primi tempi di Intercom, u nostru Direttore Tecnicu, Ciaran, hà furnitu da sola una squadra intera di supportu tecnicu 24/7, sia in l'uffiziu sia fora. Cum'è l'Intercom cresce, una task force hè stata creata per aiutà Ciaran. Pocu dopu, novi squadre di sviluppu cuminciaru à creà parechje funziunalità è servizii novi, è anu pigliatu tutte e rispunsabilità di supportu tecnicu.
Ci era troppu persone "in chjama" in ogni mumentu.
À l'epica, stu approcciu paria un scontru perchè era un modu faciule per scala a nostra squadra di supportu tecnulugicu in un mumentu, allineatu cù i nostri valori, è adatta à i nostri . In fine, senza alcunu pianu, avemu finitu cù quattru o cinque squadre chì cuntattate regularmente i clienti durante e so ore di travagliu. U restu di e squadre di sviluppu ùn anu micca assai prublemi cumplessi chì puderanu lancià un errore, cusì raramente, o mai, chjamati.
Avemu capitu chì eramu in una situazione induve avemu avutu una meccanica di supportu tecnicu chì ùn pudemu micca esse fieru, è una quantità di prublemi critichi chì vuliamu risolve, cum'è:
- Ci era troppu persone pronte à piglià a sfida à ogni mumentu. A nostra infrastruttura ùn era micca abbastanza grande per esse bisognu di un minimu di cinque ingegneri di sviluppu per travaglià senza ghjorni rigulari.
- A qualità di i nostri allarmi è e prucedure di chjama ùn era micca coherente trà e squadre, è avemu usatu prucessi ad hoc per riviseghjà avvisi di prublemi novi è esistenti. L'istruzzioni in u runbook (da esse seguitu quandu anu infurmatu di un prublema) eranu soprattuttu evidenti da a so assenza.
- Sicondu a squadra in quale l'ingegneri anu travagliatu, avianu aspettazioni cunflittu. Per esempiu, solu a prima squadra di supportu tecnicu hà avutu alcuna compensazione per i turni di chjamà è i weekend disrupted.
- Ci pareva esse un livellu generale di tolleranza per e chjama inutili à l'ora strana.
- Infine, stu tipu di travagliu ùn hè micca per tutti. E circustanze di a vita a volte dimustranu chì i cambiamenti di u duvere ùn anu micca u megliu effettu nantu à e persone.
Truvà u statu ghjustu "sempre in".
Avemu decisu di creà una nova squadra virtuale chì eseguissi un travagliu di supportu tecnicu per ogni squadra durante l'ora di travagliu. A squadra serà custituita da vuluntarii, micca cuscritti da alcuna squadra in l'urganizazione. L'ingegneri di a squadra virtuale anu rotatu circa ogni sei mesi, passendu settimane "in chjama". Per furtuna, ùn avemu micca avutu prublemi à truvà abbastanza vuluntarii per assemblà una squadra virtuale.
In u risultatu, a nostra squadra di supportu hè stata ridutta da 30 persone à solu 6 o 7.
Allora u squadra hà accunsentutu è definitu ciò chì l'alerta di prublemi è e descrizzioni deve esse cum'è in u runbook, è hà descrittu un prucessu per trasmette alerti à a nova squadra di supportu. Anu definitu tutte l'alerta in u codice utilizendu un modulu Terraform, è cuminciaru à utilizà a rivisione di i pari per ogni cambiamentu. Avemu introduttu un livellu di compensazione per un turnu settimanale chì era abbastanza satisfactoriu per l'ufficiali. Avemu ancu creatu una squadra scalata di u sicondu livellu chì era custituita solu di managers. Questa squadra deve esse u puntu unicu di escalazione per l'ingegneri di supportu tecnicu.
Avemu avutu parechji mesi di travagliu duru, durante i quali avemu stabilitu stu prucessu, per via di u risultatu, avà ùn ci era micca ingegneri 30 nantu à chjama cum'è prima, ma solu 6 o 7. Durante l'ora di travagliu, i squadre trattanu indipindentamente i prublemi cù e so funzioni o servizii, nant'à Questu hè u tempu quandu u più grande nùmeru di breakdowns di solitu accade, ma in tutti l'altri tempi, supportu tecnicu hè furnitu da vuluntarii.
Ciò chì avemu amparatu
Dopu avemu lanciatu a nostra squadra di supportu tecnicu virtuale, avemu aspittatu un afflussu di novi compiti, cum'è l'investigazione di e cause di i prublemi o di riunite per risolve un solu prublema chì causava un outage. Tuttavia, i nostri squadre di sviluppu anu pigliatu a piena rispunsabilità per i fatturi chì causanu i fallimenti, è ogni risposta sussegwente era tipicamente immediata. Avemu ancu bisognu di evità una situazione in quale un compitu di cunsultazione tecnicu seria rinviatu à a squadra da quale hè vinutu, per ùn forzà l'ingegneri à cuntattà dopu l'ore.
U numeru di chiamate dopu l'ora hè cascatu à menu di 10 per mese.
U nostru prucessu di escalazione hè statu raramente utilizatu formalmente. Una credenza più cumuna era chì l'ingegnere hè statu aiutatu micca ufficialmente da a squadra chì era attualmente in linea, in particulare i nostri ragazzi in l'uffiziu di San Francisco. Parechji prublemi sò stati eliminati o ridotti per u travagliu in squadra è risolvendu in u volu.
L'ingegneri in u nostru uffiziu di San Francisco si sò uniti à a squadra à tempu pienu è andavanu oltre l'assistenza tecnica tipica. Ci hè statu affruntatu cù qualchi costi generali, ma sparghje a nostra squadra di supportu in parechje uffizii hà travagliatu à u nostru vantaghju, postu chì hè statu un bonu modu per custruisce relazioni, rinfurzà li, è amparà di più nantu à a pila di tecnulugia cù quale tutti travagliammu.
U travagliu di i sviluppatori di Intercom hè diventatu più consistente in i nostri squadre, è pudemu parlà cun fiducia di i benefici di esse un ingegnere di sistemi in u nostru situ. , affirmannu chì ùn ci hè bisognu di esse sempre cunnessu, salvu chì vulete esse.
Inseme à u travagliu fundamentale per stabilizzà è scala i nostri magazzini di dati, un focusu cuntinuu nantu à a risoluzione di i prublemi hà vistu u numeru di chjamate fora di l'ora caduta à menu di 10 per mese. Semu assai fieri di stu numeru.
Continuemu à travaglià per mantene è migliurà a nostra squadra di supportu tecnicu, è cum'è l'Intercom cresce, pudemu avè da ricunsiderà e nostre decisioni, perchè ciò chì travaglia oghje ùn hà micca bisognu di travaglià a prossima volta chì u nostru staffu duppià. Tuttavia, sta sperienza hè stata estremamente positiva per a nostra urganizazione è hà migliuratu assai a qualità di vita di i nostri ingegneri di sviluppu, a qualità di e nostre risposte à e chjama, è soprattuttu, l'esperienza di i nostri clienti.
Source: www.habr.com