A cikk fordítása kifejezetten a kurzus hallgatói számára készült .
Az Intercom küldetése az online üzlet személyre szabása. De nem lehet személyre szabni egy terméket, ha az nem működik. . A teljesítmény kulcsfontosságú vállalkozásunk sikere szempontjából, nem csak azért, mert ügyfeleink fizetnek nekünk, hanem azért is, mert mi magunk . Ha szolgáltatásunk nem működik, szó szerint érezzük ügyfeleink fájdalmát.
A zökkenőmentes működés számos tényezőtől függ, például a szoftverarchitektúrától és a napi munka minőségétől. Azonban elég gyakran az a tény, hogy a mindig kapcsolatban lévő személy fogadja a hívásokat . Ez a fajta technikai támogatás hatékony ügyfélközpontú eszköz lehet, amely egyesíti a mérnökök segítségét azzal, amit az ügyfelek a termék megvásárlásakor kapnak. Ez egyben remek lehetőség a tanulásra és a fejlődésre is, hiszen végül is a kudarcok, hibák jó alkalmat jelenthetnek a készségek gyakorlására és a bonyolult működési mechanizmusok megértésére.
A munkaidőn kívüli „mindig bekapcsolt” állapot káros hatással van az életére.
De ugyanakkor a „mindig bekapcsolt” állapot káros hatással lehet az életére. Készen kell állnia arra, hogy gyorsan és hozzáértően reagáljon a riasztásra, ha valami elromlott. Még ha pillanatnyilag nem is lapoznak, a "mindig bekapcsolva" szorongást kelthet, amint azt személyes tapasztalatból tudom. Emiatt különösen erősen romlik az alvás minősége. A hozzáférési zónában való rendszeres tartózkodás a nap bármely szakában kiégést, apátiát vagy általában azt a vágyat, hogy soha többé ne lássuk a számítógépet.
A „mindig csatlakoztatott” állapot története az Intercom-ban
Az Intercom kezdeti napjaiban műszaki igazgatónk, Ciaran egymaga biztosította a hét minden napján, XNUMX órában technikai támogatást nyújtó teljes csapatot az irodában és azon kívül egyaránt. Ahogy az Intercom növekedett, egy munkacsoportot hoztak létre Ciaran megsegítésére. Nem sokkal ezután az új fejlesztőcsapatok sok új funkciót és szolgáltatást kezdtek létrehozni, és átvették az összes műszaki támogatási feladatot.
Túl sok ember volt „ügyeletben” egy adott pillanatban.
Abban az időben ez a megközelítés teljesen feleslegesnek tűnt, mert egyszerű módja volt a technikai támogatási csapatunk egy pillanat alatt bővítésének, összhangba került értékeinkkel, és megfelelt a mi szempontunknak. . Végül minden terv nélkül négy-öt csapathoz jutottunk, akik munkaidőn kívül rendszeresen felvették a kapcsolatot az ügyfelekkel. A többi fejlesztőcsapatnak nem volt sok olyan bonyolult problémája, amely hibát okozhatna, ezért ritkán hívták őket, ha egyáltalán nem.
Felismertük, hogy olyan helyzetbe kerültünk, amikor nem lehetünk büszkék a műszaki támogatási mechanikánkra, és számos kritikus problémát szeretnénk megoldani, mint például:
- Túl sok ember állt készen arra, hogy bármikor vállalja a kihívást. Infrastruktúránk nem volt elég nagy ahhoz, hogy legalább öt fejlesztőmérnököt igényeljen a rendszeres szabadnapok nélküli munkavégzés.
- Riasztásaink és hívási eljárásaink minősége nem volt egységes a csapatok között, és eseti folyamatokat alkalmaztunk az új és a meglévő problémariasztások áttekintésére. A runbook utasításai (amit követni kell, ha hibaüzenetet kaptak) leginkább a hiányukon voltak szembetűnőek.
- Attól függően, hogy milyen csapatban dolgoztak a mérnökök, egymásnak ellentmondó elvárásaik voltak. Például csak a legelső technikai támogatási csapat kapott kompenzációt az ügyeleti műszakokért és a megzavart hétvégékért.
- Úgy tűnt, hogy általánosan tolerálják a szükségtelen hívásokat a páratlan órákban.
- Végül, ez a fajta munka nem mindenkinek való. Az életkörülmények időnként azt mutatták, hogy az ügyeletváltás nem volt a legjobb hatással az emberekre.
A megfelelő „mindig bekapcsolt” állapot megtalálása
Úgy döntöttünk, hogy létrehozunk egy új virtuális csapatot, amely minden csapat számára technikai támogatást végez a munkaidőn kívül. A csapat önkéntesekből áll majd, nem a szervezet egyik csapatának sorkatonaiból. A virtuális csapat mérnökei körülbelül hathavonta váltották egymást, és heteket töltöttek „ügyeletben”. Szerencsére nem okozott gondot elegendő önkéntest találni egy virtuális csapat összeállításához.
Ennek eredményeként támogatói csapatunk létszáma 30 főről 6-7 főre csökkent.
A csapat ezután megállapodott és meghatározta, hogy a hibariasztásoknak és -leírásoknak hogyan kell kinézniük a runbookban, és leírták a riasztások továbbításának folyamatát az új támogatási csapatnak. Egy Terraform modul segítségével határozták meg az összes riasztást a kódban, és minden változásnál elkezdték a szakértői értékelést. A heti műszakért olyan mértékű kompenzációt vezettünk be, amely eléggé kielégítette az ügyeleteseket. Létrehoztunk egy másodszintű eszkalált csapatot is, amely csak vezetőkből állt. Ennek a csapatnak kell lennie a technikai támogatási mérnökök egyetlen eszkalációs pontjának.
Több hónapos kemény munkánk során alakítottuk ki ezt a folyamatot, ennek eredményeként most nem 30 mérnök volt készenlétben, mint korábban, hanem csak 6-7. Munkaidőben a csapatok önállóan kezelik a funkciójukkal, ill. szolgáltatások, on Általában ekkor történik a legtöbb meghibásodás, de minden más időpontban önkéntesek biztosítják a technikai támogatást.
Amit tanultunk
Virtuális technikai támogatási csapatunk elindítása után új feladatok beáramlására számítottunk, mint például a problémák okainak kivizsgálása, vagy egy kimaradást okozó probléma megoldása érdekében történő összefogás. Fejlesztőcsapatunk azonban teljes felelősséget vállalt a hibákat okozó tényezőkért, és minden későbbi válasz jellemzően azonnali volt. Azt is el kellett kerülnünk, hogy egy műszaki konzultációs feladatot visszaküldjenek annak a csapatnak, ahonnan az jött, hogy ne kényszerítsük a mérnököket a munkaidő utáni kapcsolatfelvételre.
A munkaidőn túli hívások száma havi 10 alá csökkent.
Eszkalációs eljárásunkat ritkán használták formálisan. Egy elterjedtebb vélekedés az volt, hogy a mérnököt nem hivatalosan az éppen online dolgozó csapat segítette, különösen a mi srácaink a San Francisco-i irodában. Sok problémát sikerült megszüntetni vagy csökkenteni csapatmunkával és menet közbeni megoldással.
A San Francisco-i irodánk mérnökei teljes munkaidőben csatlakoztak a csapathoz, és túlléptek a tipikus műszaki támogatáson. Némi rezsiköltséggel kellett szembenéznünk, de a támogatási csoport tagságunk több irodára való szétosztása a javunkra vált, mivel ez jó módja annak, hogy kapcsolatokat építsünk, erősítsünk, és többet tudjunk meg arról a technológiai halmazról, amellyel mindannyian dolgozunk.
Az Intercom fejlesztőinek munkája egységesebbé vált csapatainkban, és bátran beszélhetünk oldalunkon a rendszermérnöki munka előnyeiről , amely kijelenti, hogy nem szükséges mindig kapcsolatban lenni, hacsak nem akarod.
Az adattáraink stabilizálására és bővítésére irányuló alapvető munka mellett a problémamegoldásra való folyamatos összpontosítás eredményeként a munkaidőn kívüli hívások száma havi 10 alá esett. Nagyon büszkék vagyunk erre a számra.
Továbbra is dolgozunk technikai támogatási csapatunk fenntartásán és fejlesztésén, és az Intercom növekedésével előfordulhat, hogy át kell gondolnunk a döntéseinket, mert ami ma működik, az nem feltétlenül fog működni a következő alkalommal, amikor munkatársaink megduplázódnak. Ez a tapasztalat azonban rendkívül pozitív volt szervezetünk számára, és nagymértékben javította fejlesztőmérnökeink életminőségét, a hívásokra adott válaszaink minőségét, és mindenekelőtt ügyfeleink tapasztalatait.
Forrás: will.com
