Die vertaling van die artikel is spesifiek vir die studente van die kursus voorberei .
Interkom se missie is om aanlyn besigheid te verpersoonlik. Maar jy kan nie 'n produk verpersoonlik as dit nie werk nie. . Prestasie is van kritieke belang vir die sukses van ons besigheid, nie net omdat ons kliënte ons betaal nie, maar ook omdat ons self gebruik . As ons diens nie werk nie, voel ons letterlik ons kliënte se pyn.
Gladde werking hang af van baie faktore, soos sagteware-argitektuur en die kwaliteit van daaglikse werk. Dit kom egter heel dikwels daarop neer dat die persoon wat altyd in kontak is oproepe van antwoord . Hierdie soort tegniese ondersteuning kan 'n kragtige kliëntgerigte hulpmiddel wees wat die hulp van ingenieurs kombineer met wat kliënte kry wanneer hulle jou produk koop. Dit is ook 'n wonderlike geleentheid vir leer en groei, want mislukkings en foute kan immers 'n goeie geleentheid wees om vaardighede te oefen en komplekse werkmeganismes te verstaan.
Om buite werksure "altyd aan" te wees, het 'n nadelige uitwerking op jou lewe.
Maar terselfdertyd kan dit 'n nadelige uitwerking op jou lewe hê om "altyd aan" te wees. Jy moet gereed wees om vinnig en bekwaam te reageer op 'n waarskuwing dat iets stukkend is. Selfs al word jy nie op enige gegewe oomblik geblaai nie, kan dit angs skep om "altyd aan" te wees, soos ek uit persoonlike ondervinding weet. As gevolg hiervan verswak die kwaliteit van slaap veral sterk. Om op enige tyd van die dag gereeld in die toegangsone te wees, kan lei tot uitbranding, apatie, of, in die algemeen, 'n begeerte om nooit weer die rekenaar te sien nie.
Geskiedenis van die "altyd gekoppelde" toestand in Interkom
In die baie vroeë dae van Intercom het ons Tegniese Direkteur, Ciaran, eiehandig 'n hele span 24/7 tegniese ondersteuning verskaf, beide binne en buite die kantoor. Soos Interkom gegroei het, is 'n taakspan geskep om Ciaran te help. Kort daarna het nuwe ontwikkelingspanne baie nuwe kenmerke en dienste begin skep, en hulle het alle tegniese ondersteuningsverantwoordelikhede oorgeneem.
Daar was te veel mense "op roep" op enige gegewe oomblik.
Destyds het hierdie benadering soos 'n no-brainer gelyk, want dit was 'n maklike manier om ons tegniese ondersteuningspan op 'n oomblik se kennisgewing te skaal, dit het in lyn gebring met ons waardes, en dit het gepas by ons . Uiteindelik, sonder enige planne, het ons met vier of vyf spanne geëindig wat gereeld kliënte gekontak het gedurende hul nie-werksure. Die res van die ontwikkelingspanne het nie baie komplekse probleme gehad wat 'n fout kon veroorsaak nie, so hulle is selde, indien ooit, gebel.
Ons het besef dat ons in 'n situasie was waar ons tegniese ondersteuningsmeganika het waarop ons nie trots kon wees nie, en 'n aantal kritieke probleme wat ons wou regmaak, soos:
- Daar was te veel mense wat gereed was om die uitdaging op enige gegewe tydstip aan te pak. Ons infrastruktuur was nie groot genoeg om 'n minimum van vyf ontwikkelingsingenieurs te vereis om sonder gereelde afdae te werk nie.
- Die kwaliteit van ons alarms en oproepprosedures was nie konsekwent oor spanne heen nie, en ons het ad hoc-prosesse gebruik om nuwe en bestaande probleemwaarskuwings te hersien. Die instruksies in die runbook (wat gevolg moet word wanneer van 'n probleem in kennis gestel word) was meestal opvallend deur hul afwesigheid.
- Afhangende van die span waarin die ingenieurs gewerk het, het hulle teenstrydige verwagtinge gehad. Slegs die heel eerste tegniese ondersteuningspan het byvoorbeeld enige vergoeding gehad vir diensskofte en ontwrigte naweke.
- Daar was blykbaar 'n algemene vlak van verdraagsaamheid vir onnodige oproepe op vreemde ure.
- Ten slotte, hierdie tipe werk is nie vir almal nie. Lewensomstandighede het soms gewys dat diensverskuiwings nie die beste uitwerking op mense gehad het nie.
Om die regte "altyd aan"-toestand te vind
Ons het besluit om 'n nuwe virtuele span te skep wat tegniese ondersteuningswerk vir elke span sou verrig gedurende nie-werksure. Die span sal bestaan uit vrywilligers, nie dienspligtiges van enige span in die organisasie nie. Ingenieurs op die virtuele span het ongeveer elke ses maande geroteer en weke "op roep" deurgebring. Gelukkig het ons geen probleem gehad om genoeg vrywilligers te kry om 'n virtuele span saam te stel nie.
Gevolglik is ons ondersteuningspan van 30 mense tot net 6 of 7 verminder.
Die span het toe ooreengekom en gedefinieer hoe kwessiewaarskuwings en beskrywings in die runbook moet lyk, en 'n proses beskryf om waarskuwings na die nuwe ondersteuningspan aan te stuur. Hulle het alle waarskuwings in die kode gedefinieer met behulp van 'n Terraform-module, en het portuurbeoordeling vir elke verandering begin gebruik. Ons het 'n vlak van vergoeding vir 'n weeklikse skof ingestel wat vir die diensbeamptes redelik bevredigend was. Ons het ook 'n tweedevlak-eskalasiespan geskep wat net uit bestuurders bestaan het. Hierdie span behoort die enkele punt van eskalasie vir tegniese ondersteuningsingenieurs te wees.
Ons het etlike maande se harde werk gehad, waartydens ons hierdie proses gevestig het, gevolglik was daar nou nie 30 ingenieurs op roep soos voorheen nie, maar net 6 of 7. Gedurende werksure hanteer die spanne onafhanklik probleme met hul funksies of dienste, op Dit is die tyd wanneer die grootste aantal onklaarrakings gewoonlik plaasvind, maar te alle ander tye word tegniese ondersteuning deur vrywilligers verskaf.
Wat ons geleer het
Nadat ons ons virtuele tegniese ondersteuningspan bekend gestel het, het ons 'n toestroming van nuwe take verwag, soos om die oorsake van probleme te ondersoek of bymekaar te kom om 'n enkele probleem op te los wat 'n onderbreking veroorsaak het. Ons ontwikkelingspanne het egter volle verantwoordelikheid geneem vir die faktore wat die mislukkings veroorsaak het, en enige daaropvolgende reaksie was tipies onmiddellik. Ons moes ook 'n situasie vermy waarin 'n tegniese konsultasietaak teruggestuur sou word na die span waaruit dit kom, om nie ingenieurs te dwing om na-ure te kontak nie.
Die aantal na-uurse oproepe het tot minder as 10 per maand gedaal.
Ons eskalasieproses is selde formeel gebruik. ’n Meer algemene opvatting was dat die ingenieur nie-amptelik gehelp is deur die span wat tans aanlyn was, veral ons ouens in die San Francisco-kantoor. Baie kwessies is uitgeskakel of verminder deur spanwerk en die vinnige oplossing daarvan.
Ingenieurs in ons San Francisco-kantoor het voltyds by die span aangesluit en het verder gegaan as tipiese tegniese ondersteuning. Ons het te kampe gehad met 'n paar oorhoofse koste, maar die verspreiding van ons ondersteuningspanlidmaatskap oor verskeie kantore het tot ons voordeel gewerk, want dit was 'n goeie manier om verhoudings te bou, dit te versterk en meer te wete te kom oor die tegnologiestapel waarmee ons almal werk.
Die werk van interkom-ontwikkelaars het meer konsekwent in ons spanne geword, en ons kan met selfvertroue praat oor die voordele van 'n stelselingenieur op ons webwerf , wat verklaar dat dit nie nodig is om altyd gekoppel te wees nie, tensy jy wil wees.
Saam met fundamentele werk om ons datawinkels te stabiliseer en te skaal, het 'n voortgesette fokus op probleemoplossing daartoe gelei dat die aantal buite-uurse oproepe tot minder as 10 per maand gedaal het. Ons is baie trots op hierdie nommer.
Ons gaan voort om te werk aan die instandhouding en verbetering van ons tegniese ondersteuningspan, en soos Interkom groei, sal ons dalk ons besluite moet heroorweeg, want wat vandag werk, sal nie noodwendig werk die volgende keer wat ons personeel verdubbel nie. Hierdie ervaring was egter uiters positief vir ons organisasie en het die lewenskwaliteit van ons ontwikkelingsingenieurs, die kwaliteit van ons reaksies op oproepe, en bowenal, die ervaring van ons kliënte aansienlik verbeter.
Bron: will.com