ProHoster > Blogs > Administrācija > Piecas problēmas Highload IT sistēmu darbības un atbalsta procesos

Piecas problēmas Highload IT sistēmu darbības un atbalsta procesos

Sveiks, Habr! Es atbalstu Highload IT sistēmas jau desmit gadus. Es Å”ajā rakstā nerakstÄ«Å”u par problēmām, kas saistÄ«tas ar nginx iestatÄ«Å”anu darbam 1000+ RPS režīmā vai citām tehniskām lietām. DalÄ«Å”os savos novērojumos par problēmām procesos, kas rodas Ŕādu sistēmu atbalstÄ«Å”anā un darbÄ«bā.

Uzraudzība

Tehniskais atbalsts negaida, lÄ«dz tiek saņemts pieprasÄ«jums ar saturu ā€œKo kāpēc... vietne atkal nedarbojas?ā€ MinÅ«tes laikā pēc vietnes avārijas atbalsta dienestam jau vajadzētu redzēt problēmu un sākt to risināt. Bet vietne ir aisberga redzamā daļa. Tā pieejamÄ«ba ir viena no pirmajām, kas tiek uzraudzÄ«ta.

Ko darÄ«t ar situāciju, kad no ERP sistēmas vairs nepienāk atlikuŔās interneta veikala preces? Vai arÄ« CRM sistēma, kas aprēķina atlaides klientiem, vairs nereaģē? Å Ä·iet, ka vietne darbojas. NosacÄ«tā Zabbix saņem 200 atbildi. Dežūru maiņa nav saņēmusi nekādus paziņojumus no uzraudzÄ«bas un ar prieku skatās Troņu spēles jaunās sezonas pirmo sēriju.

UzraudzÄ«ba bieži aprobežojas tikai ar atmiņas, RAM un servera procesora slodzes mērÄ«Å”anu. Taču biznesam daudz svarÄ«gāk ir iegÅ«t produktu pieejamÄ«bu mājaslapā. Vienas virtuālās maŔīnas nosacÄ«ta kļūme klasterÄ« novedÄ«s pie tā, ka trafika pārtrauks iet uz to un palielināsies slodze uz citiem serveriem. Uzņēmums naudu nezaudēs.

Tāpēc papildus operētājsistēmu tehnisko parametru uzraudzÄ«bai serveros ir jākonfigurē biznesa metrika. Metrika, kas tieÅ”i ietekmē naudu. Dažādas mijiedarbÄ«bas ar ārējām sistēmām (CRM, ERP un citām). PasÅ«tÄ«jumu skaits uz noteiktu laika periodu. VeiksmÄ«gas vai neveiksmÄ«gas klientu autorizācijas un citi rādÄ«tāji.

Mijiedarbība ar ārējām sistēmām

Jebkura vietne vai mobilā lietojumprogramma, kuras gada apgrozÄ«jums pārsniedz miljardu rubļu, mijiedarbojas ar ārējām sistēmām. Sākot no iepriekÅ”minētā CRM un ERP un beidzot ar pārdoÅ”anas datu pārsÅ«tÄ«Å”anu uz ārēju Big Data sistēmu pirkumu analÄ«zei un klientam produkta piedāvāŔanai, ko viņŔ noteikti iegādāsies (patiesÄ«bā nē). Katrai Ŕādai sistēmai ir savs atbalsts. Un bieži saziņa ar Ŕīm sistēmām izraisa sāpes. It Ä«paÅ”i, ja problēma ir globāla un jums tā jāanalizē dažādās sistēmās.

Dažas sistēmas saviem administratoriem nodroÅ”ina tālruņa numuru vai telegrammu. Kaut kur jāraksta vēstules vadÄ«tājiem vai jāiet uz Å”o ārējo sistēmu kļūdu izsekotājiem. Pat viena liela uzņēmuma kontekstā dažādas sistēmas bieži darbojas dažādās lietojumprogrammu uzskaites sistēmās. Dažreiz kļūst neiespējami izsekot lietojumprogrammas statusam. JÅ«s saņemat pieprasÄ«jumu vienā nosacÄ«tā Jira. Pēc tam Ŕī pirmā Jira komentārā jÅ«s ievietojat saiti uz citu Jira problēmu. Otrajā Jirā aplikācijā kāds jau raksta komentāru, ka lai atrisinātu problēmu, jums jāzvana nosacÄ«tajam administratoram Andrejam. Un tā tālāk.

Labākais risinājums Å”ai problēmai bÅ«tu izveidot vienotu saziņas telpu, piemēram, Slack. Aicinot pievienoties visus ārējo sistēmu darbÄ«bas procesa dalÄ«bniekus. Un arÄ« viens izsekotājs, lai nedublētos lietojumprogrammas. Lietojumprogrammas ir jāizseko vienuviet, sākot no uzraudzÄ«bas paziņojumiem lÄ«dz kļūdu risinājumu izvadei nākotnē. JÅ«s teiksiet, ka tas ir nereāli un vēsturiski ir noticis tā, ka mēs strādājam vienā trakerā, bet viņi citā. ParādÄ«jās dažādas sistēmas, tām bija savas autonomas IT komandas. Es piekrÄ«tu, un tāpēc problēma ir jārisina no augÅ”as CIO vai produkta Ä«paÅ”nieka lÄ«menÄ«.

Katrai sistēmai, ar kuru jÅ«s mijiedarbojaties, ir jānodroÅ”ina atbalsts kā pakalpojumam ar skaidru SLA, lai atrisinātu problēmas pēc prioritātes. Un ne tad, kad nosacÄ«tajam adminam Andrejam jums ir minÅ«te.

Cilvēks ar saÅ”aurinājumu

Vai katram projektam (vai produktam) ir kāds cilvēks, kura doÅ”anās atvaļinājumā izraisa konvulsijas viņu priekÅ”nieku vidÅ«? Tas varētu bÅ«t devops inženieris, analÄ«tiÄ·is vai izstrādātājs. Galu galā tikai devops inženieris zina, kuros serveros ir instalēti konteineri, kā konteineru pārstartēt problēmas gadÄ«jumā, un vispār bez viņa nevar atrisināt jebkuru sarežģītu problēmu. AnalÄ«tiÄ·is ir vienÄ«gais, kurÅ” zina, kā darbojas jÅ«su sarežģītais mehānisms. Kuras datu straumes kurp nonāk. Pēc kādiem pieprasÄ«jumu parametriem uz kādiem pakalpojumiem, kādiem saņemsim atbildes.
KurÅ” ātri sapratÄ«s, kāpēc žurnālos ir kļūdas, un nekavējoties novērsÄ«s produkta bÅ«tisku kļūdu? Protams, tas pats izstrādātājs. Ir arÄ« citi, bet nez kāpēc tikai viņŔ saprot, kā darbojas dažādi sistēmas moduļi.

Å Ä«s problēmas cēlonis ir dokumentācijas trÅ«kums. Galu galā, ja bÅ«tu aprakstÄ«ti visi jÅ«su sistēmas pakalpojumi, tad problēmu bÅ«tu iespējams atrisināt bez analÄ«tiÄ·a. Ja devops paņēma pāris dienas no sava aizņemtā grafika un aprakstÄ«ja visus serverus, pakalpojumus un instrukcijas tipisku problēmu risināŔanai, tad problēmu viņa prombÅ«tnes laikā varētu atrisināt bez viņa. Atvaļinājuma laikā jums nav ātri jādzer alus pludmalē un jāmeklē Wi-Fi, lai atrisinātu problēmu.

Atbalsta personāla kompetence un atbildība

Lielos projektos uzņēmumi neskopojas ar attÄ«stÄ«tāju algām. Viņi meklē dārgus vidējos vai seniorus no lÄ«dzÄ«giem projektiem. Ar atbalstu situācija ir nedaudz atŔķirÄ«ga. Viņi cenÅ”as samazināt Ŕīs izmaksas visos iespējamos veidos. Uzņēmumi nolÄ«gst lētus vakardienas Enikey strādniekus un drosmÄ«gi dodas cīņā. Å Ä« stratēģija ir iespējama, ja mēs runājam par Zelenogradas rÅ«pnÄ«cas vizÄ«tkartes vietni.

Ja runājam par lielu interneta veikalu, tad katra dÄ«kstāves stunda maksā vairāk nekā Enikey administratora mēneÅ”alga. Par atskaites punktu ņemsim 1 miljardu rubļu gada apgrozÄ«juma. Tas ir jebkura interneta veikala minimālais apgrozÄ«jums no reitinga 100. gada TOP 2018. Sadaliet Å”o summu ar stundu skaitu gadā un iegÅ«stiet vairāk nekā 100 000 rubļu neto zaudējumus. Un, ja neskaita nakts stundas, varat droÅ”i dubultot summu.

Bet nauda taču nav galvenais, vai ne? (nē, protams, galvenais) Ir arÄ« reputācijas zaudējumi. PazÄ«stama interneta veikala kriÅ”ana var izraisÄ«t gan atsauksmju vilni sociālajos tÄ«klos, gan publikācijas tematiskajos medijos. Un draugu sarunas virtuvē stilā ā€œTur neko nepērc, viņu mājaslapa vienmēr nedarbojasā€ nemaz nav mērāmas.

Tagad pie atbildÄ«bas. Manā praksē bija gadÄ«jums, kad dežurējoÅ”ais administrators laikus nereaģēja uz uzraudzÄ«bas sistēmas paziņojumu par vietnes nepieejamÄ«bu. PatÄ«kamā vasaras piektdienas vakarā klusi gulēja kāda Maskavā pazÄ«stamā interneta veikala mājaslapa. Sestdienas rÄ«tā Ŕīs vietnes produktu menedžeris nesaprata, kāpēc vietne netiek atvērta, un Slack atbalsta un steidzamo paziņojumu čatos iestājās klusums. Šāda kļūda mums izmaksāja seÅ”ciparu summu, un Å”im dežurantam savu darbu.

AtbildÄ«ba ir grÅ«ti attÄ«stāma prasme. Vai nu cilvēkam tas ir, vai nav. Tāpēc interviju laikā cenÅ”os identificēt tās klātbÅ«tni ar dažādiem jautājumiem, kas netieÅ”i parāda, vai cilvēks ir pieradis uzņemties atbildÄ«bu. Ja cilvēks atbild, ka izvēlējies augstskolu tāpēc, ka tā teica vecāki, vai maina darbu tāpēc, ka sieva teica, ka viņŔ nepelna pietiekami, tad labāk ar tādiem nesaistÄ«ties.

Mijiedarbība ar izstrādes komandu

Ja lietotāji darbÄ«bas laikā saskaras ar vienkārŔām produkta problēmām, atbalsts tās atrisina pats. Mēģina atveidot problēmu, analizē žurnālus un tā tālāk. Bet ko darÄ«t, ja produktā parādās kļūda? Å ajā gadÄ«jumā atbalsts pieŔķir uzdevumu izstrādātājiem, un Å”eit sākas jautrÄ«ba.

Izstrādātāji ir pastāvÄ«gi pārslogoti. Viņi veido jaunas funkcijas. Kļūdu laboÅ”ana ar pārdoÅ”anu nav pati interesantākā darbÄ«ba. Tuvojas termiņi, lai pabeigtu nākamo sprintu. Un tad nāk nepatÄ«kami cilvēki no atbalsta un saka: "Nekavējoties pārtrauciet visu, mums ir problēmas." Šādu uzdevumu prioritāte ir minimāla. It Ä«paÅ”i, ja problēma nav viskritiskākā un vietnes galvenā funkcionalitāte darbojas, un laidienu pārvaldnieks neskraida apkārt ar izspieduŔām acÄ«m un neraksta: "Steidzami pievienojiet Å”o uzdevumu nākamajam laidienam vai labojumfailam."

Problēmas ar normālu vai zemu prioritāti tiek pārvietotas no laidiena uz laidienu. Uz jautājumu ā€œKad uzdevums tiks pabeigts?ā€ JÅ«s saņemsit atbildes Ŕādā stilā: "Atvainojiet, Å”obrÄ«d ir daudz uzdevumu, jautājiet saviem komandas vadÄ«tājiem vai atbrÄ«voÅ”anas menedžerim."

Produktivitātes problēmām ir lielāka prioritāte nekā jaunu lÄ«dzekļu radÄ«Å”anai. Sliktas atsauksmes nebÅ«s ilgi jāgaida, ja lietotāji pastāvÄ«gi paklups uz kļūdām. Sabojātu reputāciju ir grÅ«ti atjaunot.

Izstrādes un atbalsta mijiedarbÄ«bas problēmas atrisina DevOps. Å is saÄ«sinājums bieži tiek izmantots konkrētas personas formā, kas palÄ«dz izveidot testÄ“Å”anas vidi izstrādei, veido CICD konveijerus un ātri ievieÅ” pārbaudÄ«to kodu ražoÅ”anā. DevOps ir pieeja programmatÅ«ras izstrādei, kad visi procesa dalÄ«bnieki cieÅ”i mijiedarbojas viens ar otru un palÄ«dz ātri izveidot un atjaunināt programmatÅ«ras produktus un pakalpojumus. Es domāju analÄ«tiÄ·us, izstrādātājus, testētājus un atbalstu.

Å ajā pieejā atbalsts un attÄ«stÄ«ba nav dažādas nodaļas ar saviem mērÄ·iem un uzdevumiem. AttÄ«stÄ«ba ir saistÄ«ta ar darbÄ«bu un otrādi. Slavenā izplatÄ«to komandu frāze: ā€œProblēma nav manā pusēā€ čatos vairs tik bieži neparādās, un galalietotāji kļūst nedaudz laimÄ«gāki.

Avots: www.habr.com

Pievieno komentāru