Szia Habr! Tíz éve támogatom a Highload informatikai rendszereket. Ebben a cikkben nem írok az nginx 1000+ RPS módban történő beállításának problémáiról vagy egyéb technikai dolgokról. Megosztom észrevételeimet az ilyen rendszerek támogatása és működtetése során felmerülő folyamatok problémáiról.
megfigyelés
A technikai támogatás nem várja meg, amíg megérkezik a „Miért... az oldal nem működik újra?” tartalommal. A webhely összeomlása után egy percen belül az ügyfélszolgálatnak már látnia kell a problémát, és el kell kezdenie annak megoldását. De az oldal a jéghegy csúcsa. Elérhetőségét az elsők között kell ellenőrizni.
Mi a teendő akkor, ha egy webáruház megmaradt áruja már nem érkezik meg az ERP rendszerből? Vagy a CRM-rendszer, amely az ügyfelek kedvezményeit számítja ki, nem válaszol? Úgy tűnik, hogy az oldal működik. A feltételes Zabbix megkapja a 200-as választ. Az ügyeletes műszak nem kapott értesítést a felügyelettől, és boldogan nézi a Game of Thrones új évadának első epizódját.
A megfigyelés gyakran csak a memória, a RAM és a szerver processzorterhelésének mérésére korlátozódik. De a vállalkozások számára sokkal fontosabb, hogy a termék elérhető legyen a webhelyen. A fürt egyik virtuális gépének feltételes meghibásodása azt a tényt eredményezi, hogy a forgalom leáll, és megnő a többi szerver terhelése. A cég nem veszít pénzt.
Ezért a szervereken lévő operációs rendszerek műszaki paramétereinek figyelése mellett üzleti mérőszámokat is be kell állítani. A pénzt közvetlenül befolyásoló mutatók. Különféle interakciók külső rendszerekkel (CRM, ERP és mások). Megrendelések száma egy adott időszakra. Sikeres vagy sikertelen ügyfélengedélyek és egyéb mutatók.
Kölcsönhatás külső rendszerekkel
Bármely webhely vagy mobilalkalmazás, amelynek éves forgalma meghaladja az egymilliárd rubelt, kölcsönhatásba lép a külső rendszerekkel. Kezdve a fent említett CRM-től és ERP-től, és befejezve az értékesítési adatok külső Big Data rendszerbe történő átvitelével a vásárlások elemzésére és olyan termék felkínálására az ügyfélnek, amelyet biztosan meg fog vásárolni (sőt, nem). Minden ilyen rendszernek megvan a maga támogatása. És gyakran fájdalmat okoz a kommunikáció ezekkel a rendszerekkel. Különösen akkor, ha a probléma globális, és különböző rendszerekben kell elemeznie.
Egyes rendszerek telefonszámot vagy táviratot biztosítanak rendszergazdáik számára. Valahol levelet kell írnia a menedzsereknek, vagy el kell mennie ezeknek a külső rendszereknek a hibakövetőihez. Még egy nagy cég kontextusában is gyakran különböző rendszerek működnek különböző alkalmazás-elszámolási rendszerekben. Néha lehetetlenné válik egy alkalmazás állapotának nyomon követése. Egy feltételes Jira-ban kap egy kérést. Majd ennek az első Jira kommentjébe teszel egy linket a másik Jira problémájára. A második Jira az alkalmazásban már valaki olyan megjegyzést ír, hogy fel kell hívnia Andrey feltételes rendszergazdát a probléma megoldásához. És így tovább.
A legjobb megoldás erre a problémára az lenne, ha egyetlen kommunikációs teret hoznánk létre, például a Slackben. A külső rendszerek üzemeltetésének folyamatában részt vevő összes résztvevő meghívása a csatlakozásra. És egyetlen nyomkövető is, hogy ne duplikálják az alkalmazásokat. Az alkalmazásokat egy helyen kell nyomon követni, az értesítések figyelésétől a jövőbeni hibamegoldások kimenetéig. Azt fogja mondani, hogy ez irreális, és történelmileg megtörtént, hogy mi az egyik nyomkövetőben dolgozunk, ők pedig egy másikban. Különféle rendszerek jelentek meg, önálló informatikai csapataik voltak. Egyetértek, ezért a problémát felülről, informatikai igazgató vagy terméktulajdonos szinten kell megoldani.
Minden rendszernek, amellyel kapcsolatba lép, egyértelmű SLA-val rendelkező szolgáltatásként kell támogatást nyújtania a problémák prioritás szerinti megoldásához. És nem akkor, amikor Andrey feltételes adminisztrátornak van egy perce az Ön számára.
Szűk keresztmetszetű ember
Mindenkinek van egy projektben (vagy termékben) olyan személye, akinek nyaralni indulása görcsöket okoz a feletteseiben? Ez lehet devops mérnök, elemző vagy fejlesztő. Hiszen csak egy devops mérnök tudja, hogy melyik szerveren milyen konténerek vannak telepítve, probléma esetén hogyan kell újraindítani a konténert, és általában minden bonyolult probléma nem oldható meg nélküle. Az elemző az egyetlen, aki tudja, hogyan működik az Ön összetett mechanizmusa. Melyik adatfolyam hova megy. Milyen szolgáltatásokra vonatkozó kérések milyen paraméterei alapján, melyikre kapunk választ.
Ki fogja gyorsan megérteni, miért vannak hibák a naplókban, és azonnal kijavít egy kritikus hibát a termékben? Természetesen ugyanaz a fejlesztő. Vannak mások is, de valamiért csak ő érti a rendszer különböző moduljainak működését.
A probléma gyökere a dokumentáció hiánya. Hiszen ha a rendszere összes szolgáltatását leírnák, akkor elemző nélkül is megoldható lenne a probléma. Ha a devops néhány napot kivett elfoglaltságából, és leírta az összes szervert, szolgáltatást és utasításokat a tipikus problémák megoldásához, akkor a probléma az ő távollétében nélküle is megoldható lenne. Nem kell gyorsan megitatni a sört a tengerparton nyaralás közben, és Wi-Fi-t keresni a probléma megoldásához.
A kisegítő személyzet kompetenciája és felelőssége
A nagy projekteknél a cégek nem fukarkodnak a fejlesztők fizetésén. Hasonló projektekből keresnek drága közép- vagy időseket. A támogatással kicsit más a helyzet. Ezeket a költségeket igyekeznek minden lehetséges módon csökkenteni. A cégek olcsó tegnapi Enikey munkásokat vesznek fel, és bátran harcba indulnak. Ez a stratégia akkor lehetséges, ha egy zelenográdi üzem névjegykártyás webhelyéről beszélünk.
Ha egy nagy webáruházról beszélünk, akkor minden leállási óra többe kerül, mint egy Enikey rendszergazda havi fizetése. Vegyünk kiindulópontnak 1 milliárd rubel éves forgalmat. Ez minden online áruház minimális forgalma az értékelésből . Ossza el ezt az összeget az évi órák számával, és több mint 100 000 rubel nettó veszteséget kap. És ha nem számolod az éjszakai órákat, nyugodtan megduplázhatod a mennyiséget.
De nem a pénz a fő, igaz? (nem, persze a fő) Vannak hírnévveszteségek is. Egy jól ismert webáruház bukása a közösségi oldalakon és a tematikus médiában megjelent publikációkban egyaránt kritikai hullámot válthat ki. A baráti beszélgetések a konyhában pedig a „ne vegyél ott semmit, mindig leáll a honlapjuk” stílusban egyáltalán nem mérhetőek.
Most a felelősségre. A gyakorlatomban előfordult, hogy az ügyeletes adminisztrátor nem reagált időben a felügyeleti rendszer értesítésére az oldal elérhetetlenségéről. Egy kellemes nyári péntek estén csendesen hevert egy jól ismert moszkvai webáruház honlapja. Szombaton délelőtt ennek az oldalnak a termékmenedzsere nem értette, miért nem nyílik meg az oldal, a Slackben pedig csönd volt a támogatási és sürgős értesítő chatekben. Egy ilyen hiba hat számjegyű összegbe került nekünk, ennek az ügyeletes tisztnek pedig a munkája.
A felelősségvállalás nehezen fejleszthető készség. Az embernek vagy van, vagy nincs. Ezért az interjúk során különféle kérdésekkel igyekszem azonosítani a jelenlétét, amelyek közvetve megmutatják, hogy az ember hozzászokott-e a felelősségvállaláshoz. Ha valaki azt válaszolja, hogy azért választott egyetemet, mert a szülei mondták, vagy munkahelyet vált, mert a felesége azt mondta, hogy nem keres eleget, akkor jobb, ha nem vesz részt ilyen emberekkel.
Interakció a fejlesztő csapattal
Ha a felhasználók egyszerű problémákkal szembesülnek egy termékkel működés közben, a támogatás ezeket magától megoldja. Megpróbálja reprodukálni a problémát, elemzi a naplókat, és így tovább. De mi a teendő, ha hiba jelenik meg a termékben? Ebben az esetben a támogatás kiosztja a feladatot a fejlesztőknek, és itt kezdődik a móka.
A fejlesztők folyamatosan túlterheltek. Új funkciókat hoznak létre. Az értékesítéssel kapcsolatos hibák javítása nem a legérdekesebb tevékenység. Közeleg a határidő a következő sprint teljesítésére. Aztán jönnek kellemetlen emberek a támogatástól, és azt mondják: "Azonnal hagyjon fel mindent, problémáink vannak." Az ilyen feladatok prioritása minimális. Különösen akkor, ha a probléma nem a legkritikusabb, és a webhely fő funkciója működik, és amikor a kiadáskezelő nem rohangál kidülledt szemekkel, és nem írja ki: "Sürgősen adja hozzá ezt a feladatot a következő kiadáshoz vagy gyorsjavításhoz."
A normál vagy alacsony prioritású problémák kiadásról kiadásra kerülnek. A „Mikor készül el a feladat?” kérdésre? a következő stílusú válaszokat kapod: "Elnézést, sok feladat van most, kérdezd meg a csapatvezetőket vagy a kiadásmenedzsert."
A termelékenységi problémák nagyobb prioritást élveznek, mint az új funkciók létrehozása. A rossz vélemények nem várnak sokáig, ha a felhasználók folyamatosan hibákba botlanak. A sérült hírnevet nehéz helyreállítani.
A fejlesztés és a támogatás közötti interakció problémáit a DevOps oldja meg. Ezt a rövidítést gyakran egy konkrét személy formájában használják, aki segít a fejlesztéshez tesztkörnyezetek létrehozásában, CICD-folyamatokat épít, és gyorsan bevezeti a tesztelt kódot a termelésbe. A DevOps a szoftverfejlesztés olyan megközelítése, amikor a folyamat minden résztvevője szorosan együttműködik egymással, és segít a szoftvertermékek és -szolgáltatások gyors létrehozásában és frissítésében. Gondolok itt elemzőkre, fejlesztőkre, tesztelőkre és támogatásra.
Ebben a megközelítésben a támogatás és a fejlesztés nem különböző részlegek, amelyek saját célokkal és célkitűzésekkel rendelkeznek. A fejlesztés részt vesz a működésben és fordítva. Az elosztott csapatok híres mondata: „A probléma nem az én oldalamon” már nem jelenik meg olyan gyakran a chatekben, és a végfelhasználók egy kicsit boldogabbak lesznek.
Forrás: will.com