Ahoj Habr! IT systémy Highload podporujem už desať rokov. Nebudem v tomto článku písať o problémoch nastavenia nginx na prácu v režime 1000+ RPS alebo iných technických veciach. Podelím sa o svoje postrehy o problémoch v procesoch, ktoré vznikajú pri podpore a prevádzke takýchto systémov.
monitorovanie
Technická podpora nečaká, kým príde požiadavka s obsahom „Čo Prečo... stránka opäť nefunguje?“ Do minúty po páde stránky by podpora už mala vidieť problém a začať ho riešiť. Stránka je však špičkou ľadovca. Jeho dostupnosť je jednou z prvých, ktoré sa sledujú.
Čo robiť so situáciou, keď zvyšný tovar internetového obchodu už neprichádza z ERP systému? Alebo prestal reagovať CRM systém, ktorý počíta zľavy pre klientov? Zdá sa, že stránka funguje. Podmienený Zabbix dostane odpoveď 200. Služobná zmena nedostala žiadne upozornenia z monitorovania a s radosťou sleduje prvú epizódu novej sezóny Game of Thrones.
Monitorovanie sa často obmedzuje len na meranie stavu pamäte, RAM a zaťaženia procesora servera. Ale pre podnikanie je oveľa dôležitejšie získať dostupnosť produktu na webovej stránke. Podmienené zlyhanie jedného virtuálneho počítača v klastri povedie k tomu, že naň prestane chodiť prevádzka a zvýši sa zaťaženie ostatných serverov. Spoločnosť nepríde o peniaze.
Preto okrem sledovania technických parametrov operačných systémov na serveroch musíte nakonfigurovať obchodné metriky. Metriky, ktoré priamo ovplyvňujú peniaze. Rôzne interakcie s externými systémami (CRM, ERP a iné). Počet objednávok za určité časové obdobie. Úspešné alebo neúspešné autorizácie klientov a ďalšie metriky.
Interakcia s externými systémami
Akákoľvek webová stránka alebo mobilná aplikácia s ročným obratom viac ako miliarda rubľov interaguje s externými systémami. Počnúc vyššie spomínaným CRM a ERP a končiac prenosom údajov o predaji do externého Big Data systému na analýzu nákupov a ponúknutie produktu klientovi, ktorý si určite kúpi (v skutočnosti nie). Každý takýto systém má svoju podporu. A často komunikácia s týmito systémami spôsobuje bolesť. Najmä ak je problém globálny a potrebujete ho analyzovať v rôznych systémoch.
Niektoré systémy poskytujú svojim správcom telefónne číslo alebo telegram. Niekde musíte písať listy manažérom alebo ísť do bug trackerov týchto externých systémov. Dokonca aj v kontexte jednej veľkej spoločnosti často fungujú rôzne systémy v rôznych aplikačných účtovných systémoch. Niekedy je nemožné sledovať stav aplikácie. Dostanete žiadosť v jednom podmienenom Jira. Potom v komentári tohto prvého Jira vložíte odkaz na problém v inom Jira. V druhej Jire v aplikácii už niekto píše komentár, že na vyriešenie problému musíte zavolať podmieneného správcu Andrey. A tak ďalej.
Najlepším riešením tohto problému by bolo vytvorenie jednotného priestoru na komunikáciu, napríklad v Slacku. Pozvanie všetkých účastníkov procesu prevádzky externých systémov, aby sa pripojili. A tiež jeden sledovač, aby sa neduplikovali aplikácie. Aplikácie by mali byť sledované na jednom mieste, od monitorovacích upozornení až po výstupy riešení chýb v budúcnosti. Poviete si, že to je nereálne a historicky sa stalo, že my pracujeme v jednom trackeri a oni v inom. Objavili sa rôzne systémy, mali svoje autonómne IT tímy. Súhlasím, a preto treba problém riešiť zhora na úrovni CIO alebo produktového vlastníka.
Každý systém, s ktorým komunikujete, by mal poskytovať podporu ako službu s jasnou SLA na riešenie problémov podľa priority. A nie, keď má na vás podmienečný admin Andrey minútu.
Muž s prekážkou
Má každý na projekte (alebo produkte) osobu, ktorej odchod na dovolenku spôsobuje kŕče medzi ich nadriadenými? Môže to byť devops inžinier, analytik alebo vývojár. Koniec koncov, iba devops inžinier vie, ktoré servery majú nainštalované aké kontajnery, ako reštartovať kontajner v prípade problému a vo všeobecnosti sa bez neho nedá vyriešiť žiadny zložitý problém. Analytik je jediný, kto vie, ako funguje váš zložitý mechanizmus. Ktoré dátové toky kam smerujú. Pod akými parametrami požiadaviek na ktoré služby, ktoré dostaneme odpovede.
Kto rýchlo pochopí, prečo sú v protokoloch chyby, a rýchlo opraví kritickú chybu v produkte? Samozrejme ten istý vývojár. Existujú aj iné, ale z nejakého dôvodu iba on chápe, ako fungujú rôzne moduly systému.
Koreňom tohto problému je nedostatok dokumentácie. Koniec koncov, ak by boli popísané všetky služby vášho systému, potom by bolo možné problém vyriešiť bez analytika. Ak by si devops vzal pár dní zo svojho nabitého programu a opísal všetky servery, služby a pokyny na riešenie typických problémov, problém v jeho neprítomnosti by sa dal vyriešiť aj bez neho. Na vyriešenie problému nemusíte rýchlo dopiť pivo na pláži a hľadať wi-fi.
Kompetencia a zodpovednosť pomocného personálu
Na veľkých projektoch firmy na platoch developerov nešetria. Hľadajú drahých stredných či seniorov z podobných projektov. S podporou je situácia trochu iná. Tieto náklady sa snažia všetkými možnými spôsobmi znižovať. Spoločnosti najímajú lacných včerajších pracovníkov Enikey a smelo sa pustia do boja. Táto stratégia je možná, ak hovoríme o webovej stránke vizitky závodu v Zelenograde.
Ak sa bavíme o veľkom internetovom obchode, tak každá hodina výpadku stojí viac ako mesačný plat správcu Enikey. Zoberme si 1 miliardu rubľov ročného obratu ako východiskový bod. Toto je minimálny obrat akéhokoľvek internetového obchodu z hodnotenia . Vydeľte túto sumu počtom hodín za rok a získajte viac ako 100 000 rubľov čistých strát. A ak nepočítate nočné hodiny, pokojne môžete sumu zdvojnásobiť.
Ale peniaze nie sú hlavná vec, však? (nie, samozrejme to hlavné) Existujú aj reputačné straty. Pád známeho internetového obchodu môže spôsobiť vlnu recenzií na sociálnych sieťach aj publikácií v tematických médiách. A konverzácie priateľov v kuchyni v štýle „Nič tam nekupujte, ich web je vždy nefunkčný“ sa nedajú vôbec merať.
Teraz k zodpovednosti. V mojej praxi sa vyskytol prípad, keď službukonajúci správca nereagoval včas na upozornenie z monitorovacieho systému o nedostupnosti stránky. V príjemný letný piatkový večer pokojne ležala stránka známeho internetového obchodu v Moskve. V sobotu ráno produktový manažér tejto stránky nechápal, prečo sa stránka neotvorila a v podporných a urgentných notifikačných chatoch v Slacku nastalo ticho. Takáto chyba nás stála šesťcifernú sumu a tento dôstojník svoju prácu.
Zodpovednosť je ťažko rozvíjateľná zručnosť. Buď na to človek má alebo nie. Preto sa pri rozhovoroch snažím jeho prítomnosť identifikovať rôznymi otázkami, ktoré nepriamo ukazujú, či je človek zvyknutý niesť zodpovednosť. Ak niekto odpovie, že si vybral univerzitu, pretože to povedali jeho rodičia, alebo zmení prácu, pretože jeho žena povedala, že nezarába dosť, potom je lepšie sa s takýmito ľuďmi nemiešať.
Interakcia s vývojovým tímom
Keď používatelia počas prevádzky narazia na jednoduché problémy s produktom, podpora ich vyrieši sama. Pokúša sa reprodukovať problém, analyzuje protokoly atď. Čo však robiť, keď sa v produkte objaví chyba? V tomto prípade podpora pridelí úlohu vývojárom a tu začína zábava.
Vývojári sú neustále preťažení. Vytvárajú nové funkcie. Oprava chýb s predajom nie je najzaujímavejšia činnosť. Blížia sa termíny na dokončenie ďalšieho šprintu. A potom prídu nepríjemní ľudia z podpory a povedia: "Okamžite prestaňte so všetkým, máme problémy." Priorita takýchto úloh je minimálna. Najmä vtedy, keď problém nie je najkritickejší a hlavná funkcionalita stránky funguje a keď správca vydania nepobehuje s vypúlenými očami a nenapíše: „Naliehavo pridajte túto úlohu do ďalšieho vydania alebo rýchlej opravy.“
Problémy s normálnou alebo nízkou prioritou sa presúvajú z vydania do vydania. Na otázku „Kedy bude úloha dokončená? dostanete odpovede v štýle: „Prepáčte, práve teraz je veľa úloh, opýtajte sa vedúcich tímu alebo manažéra vydania.“
Problémy s produktivitou majú vyššiu prioritu ako vytváranie nových funkcií. Zlé recenzie na seba nenechajú dlho čakať, ak používatelia neustále narážajú na chyby. Poškodenú povesť je ťažké obnoviť.
Otázky interakcie medzi vývojom a podporou rieši DevOps. Táto skratka sa často používa v podobe konkrétnej osoby, ktorá pomáha vytvárať testovacie prostredia pre vývoj, zostavuje CICD pipeline a rýchlo prináša testovaný kód do produkcie. DevOps je prístup k vývoju softvéru, keď všetci účastníci procesu navzájom úzko spolupracujú a pomáhajú rýchlo vytvárať a aktualizovať softvérové produkty a služby. Mám na mysli analytikov, vývojárov, testerov a podporu.
V tomto prístupe podpora a rozvoj nie sú rozdielne oddelenia s vlastnými cieľmi a zámermi. Vývoj sa podieľa na prevádzke a naopak. Slávna fráza distribuovaných tímov: „Problém nie je na mojej strane“ sa už v chatoch tak často neobjavuje a koncoví používatelia sú o niečo šťastnejší.
Zdroj: hab.com