Dobrý den, Habr! Podporuji IT systémy Highload již deset let. Nebudu v tomto článku psát o problémech s nastavením nginx pro práci v režimu 1000+ RPS nebo jiných technických věcech. Podělím se o své postřehy o problémech v procesech, které vznikají při podpoře a provozu takových systémů.
Sledování
Technická podpora nečeká, až dorazí požadavek s obsahem „Co Proč... stránka opět nefunguje?“ Během minuty po pádu webu by podpora již měla problém vidět a začít ho řešit. Ale stránka je špičkou ledovce. Jeho dostupnost je jednou z prvních sledovaných.
Co dělat se situací, kdy zbylé zboží internetového obchodu již nedorazí z ERP systému? Nebo přestal reagovat CRM systém, který klientům počítá slevy? Zdá se, že web funguje. Podmíněný Zabbix obdrží odpověď 200. Pracovní směna neobdržela žádná upozornění z monitorování a spokojeně sleduje první epizodu nové sezóny Game of Thrones.
Monitorování je často omezeno pouze na měření stavu paměti, RAM a zatížení procesoru serveru. Ale pro podnikání je mnohem důležitější získat dostupnost produktu na webu. Podmíněné selhání jednoho virtuálního stroje v clusteru povede k tomu, že na něj přestane chodit provoz a zvýší se zatížení ostatních serverů. Společnost o peníze nepřijde.
Kromě sledování technických parametrů operačních systémů na serverech je tedy potřeba konfigurovat obchodní metriky. Metriky, které přímo ovlivňují peníze. Různé interakce s externími systémy (CRM, ERP a další). Počet objednávek za určité časové období. Úspěšné nebo neúspěšné autorizace klientů a další metriky.
Interakce s externími systémy
Jakákoli webová stránka nebo mobilní aplikace s ročním obratem více než miliarda rublů interaguje s externími systémy. Počínaje výše zmíněným CRM a ERP a konče přenosem prodejních dat do externího Big Data systému pro analýzu nákupů a nabídnutí klientovi produkt, který si určitě koupí (ve skutečnosti ne). Každý takový systém má svou vlastní podporu. A často komunikace s těmito systémy způsobuje bolest. Zvláště když je problém globální a potřebujete jej analyzovat v různých systémech.
Některé systémy poskytují svým administrátorům telefonní číslo nebo telegram. Někde je potřeba psát dopisy manažerům nebo jít na bug trackery těchto externích systémů. I v rámci jedné velké společnosti často fungují různé systémy v různých aplikačních účetních systémech. Někdy je nemožné sledovat stav aplikace. Obdržíte žádost v jedné podmíněné Jira. Pak do komentáře tohoto prvního Jiry dáte odkaz na problém v jiném Jirovi. V druhém Jirovi v aplikaci už někdo píše komentář, že k vyřešení problému musíte zavolat podmíněnému správci Andrey. A tak dále.
Nejlepším řešením tohoto problému by bylo vytvořit jednotný prostor pro komunikaci, například ve Slacku. Zveme všechny účastníky procesu provozu externích systémů, aby se připojili. A také single tracker, aby se aplikace neduplikovaly. Aplikace by měly být sledovány na jednom místě, od upozornění na monitorování až po výstup řešení chyb v budoucnu. Řeknete si, že to je nereálné a historicky se stalo, že my pracujeme v jednom trackeru a oni v jiném. Objevily se různé systémy, měly své autonomní IT týmy. Souhlasím, a proto je potřeba problém řešit shora na úrovni CIO nebo product ownera.
Každý systém, se kterým komunikujete, by měl poskytovat podporu jako službu s jasnou dohodou SLA pro řešení problémů podle priority. A ne, když má na vás podmíněný admin Andrey minutu.
Muž s úzkým hrdlem
Má každý na projektu (nebo produktu) člověka, jehož odjezd na dovolenou vyvolává křeče mezi jejich nadřízenými? Může to být devops inženýr, analytik nebo vývojář. Koneckonců, pouze devops technik ví, které servery mají nainstalované jaké kontejnery, jak restartovat kontejner v případě problému a obecně bez něj nelze vyřešit jakýkoli složitý problém. Analytik je jediný, kdo ví, jak váš složitý mechanismus funguje. Které datové toky kam směřují. Za jakých parametrů požadavků na které služby, které obdržíme odpovědi.
Kdo rychle pochopí, proč jsou v protokolech chyby, a rychle opraví kritickou chybu v produktu? Samozřejmě stejný vývojář. Existují další, ale z nějakého důvodu pouze on chápe, jak fungují různé moduly systému.
Kořenem tohoto problému je nedostatek dokumentace. Koneckonců, pokud by byly popsány všechny služby vašeho systému, pak by bylo možné problém vyřešit bez analytika. Kdyby si devops vzal pár dní ze svého nabitého programu a popsal všechny servery, služby a instrukce pro řešení typických problémů, pak by se problém v jeho nepřítomnosti dal vyřešit bez něj. Nemusíte rychle dopít pivo na pláži na dovolené a hledat wi-fi, abyste problém vyřešili.
Kompetence a odpovědnost podpůrného personálu
Na velkých projektech firmy na platech developerů nešetří. Z podobných projektů hledají drahé střední nebo seniory. S podporou je situace trochu jiná. Tyto náklady se snaží všemožně snižovat. Společnosti najímají levné včerejší pracovníky Enikey a odvážně vyráží do bitvy. Tato strategie je možná, pokud mluvíme o webové stránce vizitky závodu v Zelenogradu.
Pokud se bavíme o velkém internetovém obchodě, tak každá hodina výpadku stojí více, než je měsíční plat správce Enikey. Vezměme si jako výchozí bod 1 miliardu rublů ročního obratu. Jedná se o minimální obrat jakéhokoli internetového obchodu z hodnocení . Vydělte tuto částku počtem hodin za rok a získejte více než 100 000 rublů čistých ztrát. A pokud nepočítáte noční hodiny, můžete částku klidně zdvojnásobit.
Ale peníze nejsou to hlavní, že? (ne, samozřejmě to hlavní) Dochází i k reputačním ztrátám. Pád známého internetového obchodu může způsobit jak vlnu recenzí na sociálních sítích, tak publikace v tematických médiích. A konverzace přátel v kuchyni ve stylu „Nic tam nekupujte, jejich web je neustále mimo“ se nedají vůbec měřit.
Nyní k odpovědnosti. V mé praxi se vyskytl případ, kdy službukonající správce včas nereagoval na upozornění monitorovacího systému o nedostupnosti stránky. V příjemný letní páteční večer tiše ležel web známého internetového obchodu v Moskvě. V sobotu ráno produktový manažer tohoto webu nechápal, proč se web neotevře, a v chatech podpory a urgentních upozornění ve Slacku bylo ticho. Taková chyba nás stála šestimístnou částku a tento důstojník svou práci.
Zodpovědnost je těžká dovednost rozvíjet. Buď to člověk má nebo ne. Snažím se proto při rozhovorech jeho přítomnost ztotožnit s různými otázkami, které nepřímo ukazují, zda je člověk zvyklý nést zodpovědnost. Pokud někdo odpoví, že si vybral univerzitu, protože to řekli jeho rodiče, nebo změní práci, protože jeho žena řekla, že nevydělává dost, pak je lepší se s takovými lidmi nezaplést.
Interakce s vývojovým týmem
Když uživatelé během provozu narazí na jednoduché problémy s produktem, podpora je vyřeší sama. Pokusí se problém reprodukovat, analyzuje protokoly a tak dále. Co ale dělat, když se v produktu objeví chyba? V tomto případě podpora zadá úkol vývojářům a tady začíná zábava.
Vývojáři jsou neustále přetěžováni. Vytvářejí nové funkce. Oprava chyb s prodejem není ta nejzajímavější činnost. Blíží se termíny pro dokončení dalšího sprintu. A pak přijdou nepříjemní lidé z podpory a říkají: "Okamžitě všeho nech, máme problémy." Priorita takových úkolů je minimální. Zvláště když problém není nejkritičtější a hlavní funkce webu funguje a když správce vydání neběhá s vypoulenýma očima a nepíše: „Urychleně přidejte tuto úlohu do příští verze nebo opravy hotfix.“
Problémy s normální nebo nízkou prioritou se přesouvají z vydání do vydání. Na otázku "Kdy bude úkol dokončen?" obdržíte odpovědi ve stylu: „Promiňte, právě teď je spousta úkolů, zeptejte se vedoucích týmu nebo manažera vydání.“
Problémy s produktivitou mají vyšší prioritu než vytváření nových funkcí. Špatné recenze na sebe nenechají dlouho čekat, pokud uživatelé neustále narážejí na chyby. Poškozenou pověst je těžké obnovit.
Problémy interakce mezi vývojem a podporou řeší DevOps. Tato zkratka se často používá v podobě konkrétní osoby, která pomáhá vytvářet testovací prostředí pro vývoj, staví CICD pipeline a rychle přináší testovaný kód do produkce. DevOps je přístup k vývoji softwaru, kdy všichni účastníci procesu spolu úzce spolupracují a pomáhají rychle vytvářet a aktualizovat softwarové produkty a služby. Mám na mysli analytiky, vývojáře, testery a podporu.
V tomto přístupu nejsou podpora a rozvoj různá oddělení s vlastními cíli a záměry. Vývoj je zapojen do provozu a naopak. Slavná věta distribuovaných týmů: „Problém není na mé straně“ se už v chatech tak často neobjevuje a koncoví uživatelé jsou o něco šťastnější.
Zdroj: www.habr.com