Helló, Habr! Tíz éve támogatom a Highload IT rendszereket. Ebben a cikkben nem fogok a nginx 1000+ RPS üzemmódba állításáról vagy más technikai dolgokról írni. Inkább a támogatás és üzemeltetés során felmerülő folyamatproblémákról osztom meg a tapasztalataimat.
Monitorozás
A technikai támogatás nem várja meg, amíg megérkezik a "Miért nem működik ismét a weboldal?" tartalmú kérdés. A támogatásnak az oldal leállása után egy perccel már látnia kell a problémát, és el kell kezdenie annak megoldását. De a weboldal csak a jéghegy csúcsa.A hozzáférhetőségét az egyik első dologként szokás megfigyelni.
Mi a teendő, ha az online bolt termékszámai megszűntek érkezni az ERP rendszerből? Vagy ha a CRM rendszer, amely a klienskedvezményeket számolja ki, nem válaszol? A weboldal pedig látszólag működik. A Zabbix például kapja a 200-as válaszát. A műszaknak nem érkezett értesítés a monitorozástól, és boldogan nézik a "Trónok harca" új szezonjának első epizódját.
Gyakran a monitorozás csak a memória és a processzorkihasználtság mérésére korlátozódik. szerverek. De a vállalkozás számára sokkal fontosabb, hogy a termékek elérhetősége a weboldalon biztosítva legyen. Egy virtuális gép leállása a klaszterben azt eredményezi, hogy a forgalom nem oda irányul, és a többi szerverre nő a teher. A cég nem veszít pénzt.
Ezért a szerverek operációs rendszereinek technikai paramétereinek ellenőrzése mellett be kell állítani az üzleti mutatókat is. Olyan mutatókat, amelyek közvetlen hatással vannak a forgalomra. Különféle interakciók külső rendszerekkel (CRM, ERP stb.). A rendelési mennyiség egy adott időintervallumban. A sikeres vagy sikertelen ügyfélbejelentkezések és más mutatók.
Külső rendszerekkel való interakció
Bármely weboldal vagy mobilalkalmazás, amelynek éves forgalma meghaladja az egy milliárd rubelt, külső rendszerekkel lép kapcsolatba. Az említett CRM és ERP rendszerektől kezdve az értékesítési adatok átadásáig egy külső Big Data analitikai rendszernek, amely képes ajánlani a felhasználónak a pontosan vásárolni kívánt terméket (valójában nem). Minden ilyen rendszernek megvan a saját támogatása. Gyakran előfordul, hogy a kommunikáció ezekkel a rendszerekkel problémákat okoz. Különösen, ha a probléma globális, és azt különböző rendszerekben kell elemezni.
Néhány rendszer megadja a telefonját vagy a Telegram-ját az adminisztrátorainak. Másutt e-mailt kell írni a menedzsereknek, vagy hibakövető rendszerekbe kell járniuk a külső rendszerekhez. Még egy nagy cégen belül is különböző rendszerek gyakran más-más jegykezelő rendszerekben működnek. A kérvény állapotának nyomon követése néha lehetetlenné válik. Egy feltételezett Jirában kapod a kérvényt. Majd a kommentben beillesztesz egy linket egy másik Jirához. A második Jirában már írnak egy kommentet a kérvénynél arról, hogy fel kellene hívni egy feltételezett adminisztrátort, Andrejt, a probléma megoldásához. Mindezek mellett.
A probléma optimális megoldása egy egységes kommunikációs tér létrehozása lenne, például a Slacken. Minden résztvevőt meghívni a külső rendszerek üzemeltetésének folyamatába. Valamint egy egységes nyomkövető, hogy elkerüljük a kérvények megkettőzését. A kérvényeket egy helyen kell nyomon követni, a monitoring értesítésétől kezdve a hibák megoldásáig a produkcióban. Azt mondanád, hogy ez lehetetlen, és hogy történelmileg úgy alakult, hogy mi egy nyomkövetőben dolgozunk, ők pedig egy másikban. Különböző rendszerek jelentek meg, saját autonóm IT csapataikkal. Egyetértek, ezért a problémát a CIO vagy a terméktulajdonos szintjén kell kezelni.
Minden rendszerrel, amellyel kapcsolatba lépsz, támogatást kell nyújtania szolgáltatásként, világos SLA-val a problémák prioritási sorrend szerinti megoldására. Nem pedig akkor, amikor egy feltételezett adminisztrátor, Andrej, éppen rátud szánni egy percet.
Ember - palacknyak
Minden projektben (vagy termékben) van egy ilyen ember, akinek a szabadságra menetele miatt a vezetőség összeomlik? Ő lehet devops mérnök, elemző vagy fejlesztő. Hiszen csak a devops mérnök tudja, hogy mely szervereken milyen konténerek futnak, hogyan lehet újraindítani egy konténert, ha probléma van, és egyáltalán, bármilyen bonyolult problémát nélküle nem lehet megoldani. Az elemző pedig az egyetlen, aki tudja, hogyan működik a bonyolult mechanizmusod. Milyen adatfolyamok hova mennek. Milyen paraméterek mellett milyen szolgáltatásokba kérdezzünk be, és milyen válaszokat fogunk kapni.
Ki fogja gyorsan megérteni, miért vannak hibák a naplóban, és sürgősen megoldja a kritikus hibát a produkcióban? Természetesen az a fejlesztő. Vannak mások is, de valamiért csak ő érti, hogyan működnek a rendszer különböző moduljai.
A probléma gyökere a dokumentáció hiánya.Mert ha az összes szolgáltatásodat dokumentálnák, akkor a probléma az elemző nélkül is megoldható lenne. Ha a devops pár napot ki tudna szakítani sűrű időbeosztásából, és leírná az összes szervert, szolgáltatást, és az eljárásokat a tipikus problémák megoldásához, akkor a hiánya miatt felmerülő problémát is meg lehetne oldani. Nem kellene a tengerparton gyorsan meginni a sörét, és wifi-t keresni a probléma megoldásához.
A támogatási munkatársak kompetenciája és felelőssége.
Nagyobb projekteknél a cégek nem fukarkodnak a fejlesztők fizetésével. Magas áron toborozzák a tehetséges középkategóriás vagy senior szakembereket hasonló projektekről. A támogatás helyzete némileg eltér. Ezeket a költségeket minden módon próbálják csökkenteni. A cégek olcsó, tegnap még kezdő informatikusokat alkalmaznak, és bátran belépnek a harcba. Ez a stratégia választható, ha egy zöldövezeti üzem látogatója oldaláról van szó.
Ha egy nagy internetáruházról van szó, akkor minden egyes órányi leállás több, mint egy kezdő admin havi fizetése. Vegyük alapul az 1 milliárd rubel éves forgalmat. Ez a minimális forgalom bármely, a TOP-100-as ranglistán szereplő internetáruház esetében 2018-ból. De a pénz nem fontos, ugye?
De a pénz mégsem a legfontosabb, ugye? (nem, természetesen a legfontosabb) Vannak még reputációs veszteségek is. Egy ismert internetes bolt leállása órája olyan visszajelzéseket válthat ki a közösségi médiában, mint a szakmai sajtóban való publikációk. Az olyan baráti beszélgetések, mint „Ne vásárolj ott semmit, folyamatosan leáll a weboldaluk”, pedig egyáltalán nem mérhetők.
Most nézzük meg a felelősséget. Az én tapasztalatom szerint volt már olyan eset, amikor a készenléti adminisztrátor nem reagált időben a monitoring rendszer értesítésére, hogy a weboldal nem elérhető. Egy kellemes nyári péntek estén egy népszerű moszkvai internetes bolt weboldala csendben leállt. Szombat reggel a bolt termékmenedzsere nem értette, miért nem nyílik meg a weboldal, és a támogatási csevegésekben és sürgős értesítésekben a Slack-en csengett a csend. Ez a hiba számunkra hatcifres összegbe került, a készenléti adminisztrátornak pedig munkát jelentett.
A felelősség - olyan készség, amelyet nehéz kialakítani. Ez vagy megvan az emberben, vagy nincs. Ezért az interjúk során próbálom kideríteni, hogy van-e felelősségtudat különböző kérdésekkel, amelyek közvetve mutatják, hogy az illető hajlamos-e a felelősséget vállalni. Ha valaki azt válaszolja, hogy az egyetemét azért választotta, mert a szülei azt mondták, vagy az állását úgy váltja, mert a felesége azt mondta, hogy keveset keres, akkor az ilyen emberekkel jobb nem foglalkozni.
Kapcsolat a fejlesztő csapattal
Amikor a termelési környezetben a felhasználók egyszerű problémákkal találkoznak, a támogatás megoldja azokat a saját erejével. Megpróbálják reprodukálni a problémát, elemzik a logokat és így tovább. De mi a teendő, amikor egy hiba bukkan fel a termelési környezetben? Ebben az esetben a támogatás feladatot nyit a fejlesztők számára, és itt kezdődik a legérdekesebb rész.
A fejlesztők folyamatosan túlterheltek. Új funkciók létrehozásával foglalkoznak. A termelésbeli hibák javítása mondjuk nem a legizgalmasabb tevékenység. Határidők sürgetik a következő sprint befejezését. És itt jönnek a támogató emberek, mondván: „Sürgősen hagyj mindent, problémáink vannak.” Az ilyen feladatok prioritása minimális. Különösen akkor, amikor a probléma nem túl kritikus, és az alapfunkciók működnek, és amikor a kiadási menedzser nem rohangál tágra nyílt szemekkel, és nem írja: „Sürgősen tegyétek ezt a feladatot a következő kiadásba vagy hotfixbe.”
A szokásos vagy alacsony prioritású feladatok egyik kiadásból a másikba vándorolnak. Amikor azt kérdezed: „Mikor lesz kész a feladat?”, olyan válaszokat kapsz, mint: „Sajnálom, most sok feladat van, kérdezd a csapatvezetőket vagy a kiadás menedzsert.”
A produkciós problémák nagyobb prioritást élveznek, mint az új funkciók létrehozása. A negatív visszajelzések nem váratnak magukra, ha a felhasználók folyamatosan hibákba ütköznek. Nehéz helyrehozni a megrongált hírnevet.
A fejlesztés és a támogatás közötti együttműködési kérdéseket a DevOps oldja meg. Ezt a mozaikszót gyakran egy konkrét személy képviseli, aki segít létrehozni a tesztkörnyezeteket a fejlesztés számára, felépíti a CICD pipeline-okat, és gyorsan helyezi át a tesztelt kódot a produkcióba. A DevOps egy olyan szoftverfejlesztési megközelítés, ahol a folyamat összes résztvevője szorosan együttműködik egymással, és segít abban, hogy gyorsabban készítsenek és frissítsenek szoftvertermékeket és szolgáltatásokat. Ezen azt értem, hogy az elemzők, a fejlesztők, a tesztelők és a támogató csapat mind benne van.
A támogatás és a fejlesztés ebben a megközelítésben nem különböző osztályok, saját célokkal és feladatokkal. A fejlesztés bele van vonva a működtetésbe, és fordítva. A távoli csapatok híres mondata: „A probléma nem az én oldalamon van” már nem jelenik meg olyan gyakran a csevegésekben, és a végfelhasználók egy kissé boldogabbá válnak.
Forrás: habr.com
