La traduko de la artikolo estis preparita specife por la kursanoj .
La misio de Intercom estas personecigi interretan komercon. Sed vi ne povas personecigi produkton kiam ĝi ne funkcias. . Agado estas kritika por la sukceso de nia komerco, ne nur ĉar niaj klientoj pagas al ni, sed ankaŭ ĉar ni mem uzas . Se nia servo ne funkcias, ni laŭvorte sentas la doloron de niaj klientoj.
Glata funkciado dependas de multaj faktoroj, kiel programara arkitekturo kaj la kvalito de ĉiutaga laboro. Tamen, sufiĉe ofte ĉio dependas de la fakto, ke la persono, kiu ĉiam estas en kontakto, respondas al vokoj de . Ĉi tiu speco de teknika subteno povas esti potenca klientcentra ilo, kiu kombinas la helpon de inĝenieroj kun tio, kion klientoj ricevas kiam ili aĉetas vian produkton. Ĉi tio ankaŭ estas bonega ŝanco por lernado kaj kresko, ĉar finfine malsukcesoj kaj eraroj povas esti bona ŝanco por praktiki kapablojn kaj kompreni kompleksajn labormekanismojn.
Esti "ĉiam sur" ekster laborhoroj havas malutilan efikon al via vivo.
Sed samtempe, esti "ĉiam ŝaltita" povas havi malutilan efikon al via vivo. Vi devas esti preta rapide kaj kompetente respondi al atentigo, ke io estas rompita. Eĉ se vi ne estas paĝita en ajna momento, esti "ĉiam ŝaltita" povas krei angoron, kiel mi scias el persona sperto. Pro tio, la kvalito de dormo malboniĝas precipe forte. Regule esti en la alirzono en ajna momento de la tago povas konduki al elĉerpiĝo, apatio aŭ, ĝenerale, deziro neniam revidi la komputilon.
Historio de la "ĉiam konektita" ŝtato en Intercom
En la tre fruaj tagoj de Intercom, nia Teknika Direktoro, Ciaran, sole disponigis tutan teamon de XNUMX/XNUMX teknika subteno, kaj en kaj ekster la oficejo. Ĉar Intercom kreskis, specialtrupo estis kreita por helpi Ciaran. Baldaŭ poste, novaj evoluigteamoj komencis krei multajn novajn funkciojn kaj servojn, kaj ili transprenis ĉiujn teknikajn subtenajn respondecojn.
Estis tro da homoj "alvokaj" en iu momento.
Tiutempe, ĉi tiu aliro ŝajnis nekomprenebla ĉar ĝi estis facila maniero por skali nian teknikan subtenan teamon en momento, ĝi kongruis kun niaj valoroj, kaj ĝi konvenis al nia. . Fine, sen iuj planoj, ni finis kun kvar aŭ kvin teamoj, kiuj regule kontaktis klientojn dum siaj nelaboraj horoj. La resto de la disvolvaj teamoj ne havis multajn kompleksajn problemojn, kiuj povus ĵeti eraron, do ili malofte, se iam, estis vokitaj.
Ni rimarkis, ke ni estas en situacio, kie ni havas teknikajn subtenajn mekanikojn pri kiuj ni ne povas esti fieraj, kaj kelkajn kritikajn problemojn, kiujn ni volis ripari, kiel ekzemple:
- Estis tro multaj homoj pretaj akcepti la defion en ajna momento. Nia infrastrukturo ne estis sufiĉe granda por postuli almenaŭ kvin evoluinĝenierojn labori sen regulaj libertagoj.
- La kvalito de niaj alarmoj kaj vokaj proceduroj ne estis konsekvenca inter teamoj, kaj ni uzis ad hoc procezojn por revizii novajn kaj ekzistantajn problemajn alarmojn. La instrukcioj en la kurlibro (sekvota kiam sciigite pri problemo) estis plejparte okulfrapaj pro sia foresto.
- Depende de la teamo en kiu la inĝenieroj laboris, ili havis konfliktajn atendojn. Ekzemple, nur la unua teknika subtena teamo havis ajnan kompenson por alvokaj deĵoroj kaj interrompitaj semajnfinoj.
- Ŝajnis esti ĝenerala nivelo de toleremo por nenecesaj vokoj je neparaj horoj.
- Fine, ĉi tiu tipo de laboro ne estas por ĉiuj. Vivcirkonstancoj foje montris ke devoŝanĝoj ne havis la plej bonan efikon al homoj.
Trovi la ĝustan "ĉiam sur" staton
Ni decidis krei novan virtualan teamon, kiu plenumus teknikan subtenon por ĉiu teamo dum nelaboraj horoj. La teamo estos formita de volontuloj, ne devistoj de iu teamo en la organizo. Inĝenieroj en la virtuala teamo rotaciis proksimume ĉiujn ses monatojn, pasigante semajnojn "alvoke". Feliĉe, ni ne havis problemon trovi sufiĉajn volontulojn por kunveni virtualan teamon.
Kiel rezulto, nia subtena teamo reduktiĝis de 30 homoj al nur 6 aŭ 7.
La teamo tiam konsentis kaj difinis, kiaj atentigoj kaj priskriboj devas aspekti en la kurlibro, kaj priskribis procezon por plusendi atentigojn al la nova subtena teamo. Ili difinis ĉiujn atentigojn en la kodo uzante Terraform-modulon, kaj komencis uzi kolegan revizion por ĉiu ŝanĝo. Ni enkondukis nivelon de kompenso por semajna deĵoro, kiu estis sufiĉe kontentiga por la deĵoraj oficiroj. Ni ankaŭ kreis duanivelan eskaladan teamon, kiu konsistis nur el administrantoj. Ĉi tiu teamo devus esti la ununura punkto de eskalado por teknikaj subtenaj inĝenieroj.
Ni havis plurajn monatojn da laborego, dum kiuj ni establis ĉi tiun procezon, sekve, nun estis ne 30 inĝenieroj survokaj kiel antaŭe, sed nur 6 aŭ 7. Dum laborhoroj, la teamoj sendepende traktas problemojn kun siaj funkcioj aŭ servoj, sur Ĉi tiu estas la tempo kiam la plej granda nombro da paneoj kutime okazas, sed en ĉiuj aliaj tempoj, teknika subteno estas provizita de volontuloj.
Kion ni lernis
Post kiam ni lanĉis nian virtualan teknikan subtenan teamon, ni atendis alfluon de novaj taskoj, kiel esplori la kaŭzojn de problemoj aŭ kunveni por solvi ununuran problemon, kiu kaŭzis malfunkcion. Tamen, niaj evoluigaj teamoj prenis plenan respondecon pri la faktoroj kaŭzantaj la fiaskojn, kaj ajna posta respondo estis kutime tuja. Ni ankaŭ bezonis eviti situacion, en kiu teknika konsulta tasko estos resendita al la teamo de kiu ĝi venis, por ne devigi inĝenierojn kontakti post horoj.
La nombro da posthoraj vokoj falis al malpli ol 10 monate.
Nia eskalada procezo malofte estis uzata formale. Pli ofta kredo estis ke la inĝeniero estis neoficiale helpita de la teamo kiu estis nuntempe enreta, precipe niaj uloj en la San Francisco-oficejo. Multaj aferoj estis eliminitaj aŭ reduktitaj per teamlaboro kaj solvado de ili sur la flugo.
Inĝenieroj en nia oficejo de San Francisco aliĝis al la teamo plentempe kaj iris preter tipa teknika subteno. Ni alfrontis iujn superkostojn, sed disvastigi nian subtenteaman membrecon tra pluraj oficejoj funkciis al nia avantaĝo, ĉar ĝi montriĝis bona maniero por konstrui rilatojn, plifortigi ilin kaj lerni pli pri la teknologia stako kun kiu ni ĉiuj laboras.
La laboro de Intercomprogramistoj fariĝis pli konsekvenca en niaj teamoj, kaj ni povas memfide paroli pri la avantaĝoj de esti sistema inĝeniero en nia retejo. , deklarante ke ne necesas ĉiam esti konektita krom se vi volas esti.
Kune kun fundamenta laboro por stabiligi kaj grimpi niajn datumbutikojn, daŭra fokuso pri solvado de problemoj vidis, ke la nombro da eksterhoraj vokoj malaltiĝis al malpli ol 10 monate. Ni estas tre fieraj pri ĉi tiu nombro.
Ni daŭre laboras pri konservado kaj plibonigo de nia teknika subtena teamo, kaj dum Intercom kreskas ni eble devos rekonsideri niajn decidojn, ĉar kio funkcias hodiaŭ ne nepre funkcios la venontan fojon kiam nia dungitaro duobliĝos. Tamen, ĉi tiu sperto estis ege pozitiva por nia organizo kaj multe plibonigis la vivokvaliton de niaj evoluinĝenieroj, la kvaliton de niaj respondoj al vokoj, kaj ĉefe, la sperton de niaj klientoj.
fonto: www.habr.com