Ahoj, Habr! Deset let podporuji Highload IT systémy. Nebudu psát v tomto článku o problémech s nastavením nginx pro provoz v režimu 1000+ RPS nebo o jiných technických záležitostech. Podělím se o pozorování problémů v procesech, které vznikají v podpoře a provozu takových systémů.
Monitoring
Technická podpora nečeká, až dorazí žádost s obsahem „Proč zase... web nefunguje?“. Podpora již minutu po výpadku webu musí vidět problém a začít ho řešit. Ale web je pouze špička ledovce. Jeho dostupnost je monitorována jako jedna z prvních.
Co dělat v situaci, kdy přestaly přicházet zbytky zboží z ERP systému do internetového obchodu? Nebo CRM systém, který vypočítává slevy pro zákazníky, přestal odpovídat? Web přitom na první pohled funguje. Podmínkový Zabbix dostává svou odpověď 200. Pohotovostní směna nedostala žádná oznámení z monitorování a šťastně sleduje první epizodu nového sezony „Hry o trůny“.
Často se monitorování omezuje pouze na měření stavu paměti, operační paměti a zatížení procesorů. servery. Ale pro podnikání je daleko důležitější mít přehled o dostupnosti zboží na webu. Podmínkové selhání jednoho virtuálního stroje v clusteru povede k tomu, že na něj přestane směřovat provoz a zatížení na ostatních serverech vzroste. Společnost neztratí žádné peníze.
Proto kromě monitorování technických parametrů operačních systémů na serverech je třeba nastavovat obchodní metriky. Metriky, které přímo ovlivňují finance. Různé interakce s externími systémy (CRM, ERP a další). Počet objednávek za určitou dobu. Úspěšné nebo neúspěšné autorizace zákazníků a další metriky.
Interakce s externími systémy
Každá webová stránka nebo mobilní aplikace s ročním obratem přes miliardu korun interaguje s externími systémy. Počínaje zmiňovanými CRM a ERP a konče přenosem dat o prodeji do externího systému Big Data pro analýzu nákupů a nabídku zboží, které si určitě koupí (ve skutečnosti ne). Každý takový systém má svoji podporu. A často komunikace s těmito systémy přináší bolesti. Zejména když je problém globální a je třeba ho analyzovat v různých systémech.
Některé systémy poskytují telefon nebo telegram svých administrátorů. Někde je třeba psát e-maily manažerům nebo chodit do bug trackerů těchto externích systémů. Dokonce i v rámci jedné velké společnosti různé systémy často pracují v různých systémech pro sledování žádostí. Sledovat stav žádosti se někdy stává nemožným. Dostaneš žádost v jedné vymezené Jira. Poté v komentáři této první Jira vložíš odkaz na úkol v jiné Jira. Ve druhé Jira už někdo píše komentář, že je třeba zavolat podmíněnému adminovi Andrejovi, aby se otázka vyřešila. A tak dále.
Optimálním řešením tohoto problému by bylo vytvoření jednotného prostoru pro komunikaci, například ve Slacku. Pozvání všech účastníků procesu správy externích systémů. A také jednoho trackera, aby se žádosti nedublovaly. Žádosti by měly být sledovány na jednom místě, počínaje upozorněním monitorování až po zavedení řešení bugů do produkce. Řeknete, že to je nerealistické a historicky jste pracovali v jednom trackeru, zatímco oni v jiném. Objevily se různé systémy, měly své autonomní IT týmy. Souhlasím, a proto je třeba problém řešit shora na úrovni CIO nebo product ownera.
Každý systém, se kterým interagujete, by měl poskytovat podporu jako službu s jasným SLA na řešení problémů podle priorit. A ne teprve když má podmíněný admin Andrej chvilku na vás.
Člověk jako zúžení hrdla láhve
Každý projekt (nebo produkt) má takovou osobu, jejíž dovolená vyvolává šokování v managementu. Může to být devops inženýr, analytik nebo vývojář. Jen devops inženýr ví, na jakých serverech jsou nainstalovány jaké kontejnery, jak restartovat kontejner v případě problému a každě složité problémy se bez něj neřeší. Analytik je ten, kdo ví, jak funguje váš složitý mechanismus. Jaké toky dat kam směřují. Při jakých parametrech dotazů do jakých služeb, jaké odpovědi dostaneme.
Kdo rychle pochopí, proč se v logách objevily chyby a pohotově opraví kritickou chybu v produkci? Samozřejmě ten vývojář. Jsou i jiní, ale jen on rozumí, jak jsou různé moduly systému uspořádány.
Jádrem tohoto problému je nedostatek dokumentace.Vždyť pokud by byly všechny služby vašeho systému popsány, problém by se dal vyřešit i bez analytika. Kdyby si devops vyčlenil pár dní ze svého nabitého plánu a popsal všechny servery, služby a pokyny pro řešení typických problémů, problém během jeho absence by se dal vyřešit i bez něj. Není nutné na dovolené rychle dopíjet pivo na pláži a hledat wi-fi k vyřešení problému.
Kvalifikace a odpovědnost pracovníků podpory.
Na velkých projektech firmy nešetří na platech vývojářům. Honí drahé střední nebo seniorní specialisty z podobných projektů. Situace s podporou je však trochu jiná. Tyto náklady se snaží jakýmikoliv způsoby snížit. Firmy najímají levné, včerejší pomocné pracovníky a odvážně jdou do boje. Taková strategie je možná, pokud jde o webovou stránku nějakého závodu v Zelenogradě.
Pokud se jedná o velký internetový obchod, každý hodinu výpadku stojí více než měsíční plat adm tára pomocného pracovníka. Vezměme za výchozí bod 1 miliardu rublů v ročním obratu. To je minimální obrat jakéhokoliv internetového obchodu z žebříčku Rozdělte tuto částku na počet hodin v roce a získáte více než 100 000 rublů čistých ztrát. A pokud nebudeme počítat noční hodiny, můžeme částku bez obav zdvojnásobit.
Ale peníze přece nejsou to hlavní, že? (ne, samozřejmě že to není hlavní) Existují také reputační ztráty. Hodina, kdy známý internetový obchod nefunguje, může vyvolat vlnu reakcí na sociálních sítích a také články v oborových médiích. A rozhovory přátel u stolu ve stylu „Nekupuj tam nic, jejich web pořád nefunguje“ se nedají vůbec změřit.
Nyní k odpovědnosti. Ve své praxi jsem měl případ, kdy pohotovostní administrátor nereagoval včas na upozornění systému monitoringu o nedostupnosti webu. V příjemný letní páteční večer ležel web jednoho známého moskevského internetového obchodu tiše. V sobotu ráno produktový manažer tohoto webu nechápal, proč se web neotevírá, a v chatové podpoře a urgentních upozorněních na Slacku panovalo ticho. Tato chyba nás stála šesticíselnou částku, a tento pohotovostní administrátor tak přišel o práci.
Odpovědnost je dovednost, kterou je obtížné rozvíjet. Buď ji má člověk, nebo nemá. Proto se na pohovorech snažím zjistit její přítomnost různými otázkami, které nepřímo ukazují, zda je člověk zvyklý na to, že bere odpovědnost na sebe. Pokud člověk odpoví, že si vybral vysokou školu, protože to řekli rodiče, nebo mění práci, protože manželka říká, že málo vydělává, tak s takovými lidmi je lepší se nespojit.
Interakce s vývojovým týmem
Když se během provozu objeví u uživatelů jednoduché problémy, podpora je řeší vlastními silami. Snaží se problém reprodukovat, analyzuje logy a tak dále. Ale co dělat, když se na prodě objeví bug? V tomto případě podpora zakládá úkol pro vývojáře a tady to začíná být zajímavé.
Vývojáři jsou neustále přepracovaní. Zabývají se vytvářením nových funkcí. Oprava bugů na produkčním prostředí není říkejme nejzajímavější činností. Termíny pro dokončení dalšího sprintu hoří. A tady přicházejí nepříjemní lidé z podpory a říkají: „Okamžitě přestaňte vše, máme problém.“ Priorita takových úkolů je minimální. Zvlášť když problém není tak kritický a základní funkce webu fungují, a když release manager neběhá s vyvalenýma očima a nepíše: „Okamžitě zařaďte tento úkol do nejbližšího vydání nebo hotfixu.“
Úkoly s běžnou nebo nízkou prioritou se přesouvají z vydání do vydání. Na otázku "Kdy bude úkol splněn?" uslyšíte odpovědi jako: "Omlouvám se, máme teď hodně úkolů, zeptej se týmových lídrů nebo manažera vydání."
Problémy v produkci mají vyšší prioritu než vytváření nových funkcí. Negativní zpětná vazba nenechá na sebe dlouho čekat, pokud se uživatelé neustále setkávají s chybami. Poškozenou pověst je těžké obnovit.
Otázky spolupráce mezi vývojem a podporou řeší DevOps. Tato zkratka se často používá ve smyslu konkrétního člověka, který pomáhá vytvářet testovací prostředí pro vývoj, buduje CI/CD pipeline a rychle nasazuje otestovaný kód do produkce. DevOps je přístup k vývoji software, kdy se všichni účastníci procesu úzce spolupracují a pomáhají rychleji vytvářet a aktualizovat softwarové produkty a služby. Mám na mysli analytiky, vývojáře, testery a podporu.
Podpora a vývoj v tomto přístupu nejsou různé oddělení se svými cíli a úkoly. Vývoj je zapojen do provozu a naopak. Slabě známá fráze distribuovaných týmů: "Problém není na mé straně" už se tak často neobjevuje v chatech a koncoví uživatelé jsou o něco šťastnější.
Zdroj: habr.com
