Sveiki, Habr! Jau dešimt metų palaikau Highload IT sistemas. Šiame straipsnyje nerašysiu apie nginx nustatymo problemas dirbti 1000+ RPS režimu ar kitus techninius dalykus. Pasidalinsiu savo pastebėjimais apie procesų problemas, kylančias palaikant ir eksploatuojant tokias sistemas.
Stebėjimas
Techninė pagalba nelaukia, kol gausite užklausą su turiniu „Kodėl... svetainė vėl neveikia?“ Per minutę po to, kai svetainė sugenda, palaikymo komanda jau turėtų pastebėti problemą ir pradėti ją spręsti. Tačiau svetainė yra ledkalnio viršūnė. Jo prieinamumas yra vienas iš pirmųjų, kuris stebimas.
Ką daryti susidarius situacijai, kai iš ERP sistemos nebeatkeliauja likusios internetinės parduotuvės prekės? O gal CRM sistema, skaičiuojanti nuolaidas klientams, nustojo reaguoti? Atrodo, kad svetainė veikia. Sąlyginis Zabbix gauna 200 atsakymą. Darbo pamaina negavo jokių stebėjimo pranešimų ir su džiaugsmu žiūri pirmąją naujojo „Sostų žaidimo“ sezono seriją.
Stebėjimas dažnai apsiriboja tik atminties būsenos, RAM ir serverio procesoriaus apkrovos matavimu. Tačiau verslui daug svarbiau, kad produktas būtų prieinamas svetainėje. Sąlyginis vienos virtualios mašinos klasteryje gedimas lems tai, kad srautas į ją nustos ir padidės kitų serverių apkrova. Įmonė pinigų nepraras.
Todėl, be serverių operacinių sistemų techninių parametrų stebėjimo, reikia sukonfigūruoti verslo metrikas. Metrika, kuri tiesiogiai veikia pinigus. Įvairi sąveika su išorinėmis sistemomis (CRM, ERP ir kt.). Užsakymų skaičius tam tikram laikotarpiui. Sėkmingi arba nesėkmingi klientų įgaliojimai ir kita metrika.
Sąveika su išorinėmis sistemomis
Bet kuri svetainė ar mobilioji programa, kurios metinė apyvarta viršija milijardą rublių, sąveikauja su išorinėmis sistemomis. Pradedant nuo aukščiau paminėtų CRM ir ERP ir baigiant pardavimo duomenų perkėlimu į išorinę Big Data sistemą, skirtą pirkiniams analizuoti ir pasiūlyti klientui prekę, kurią jis tikrai pirks (tiesą sakant, ne). Kiekviena tokia sistema turi savo palaikymą. Ir dažnai bendravimas su šiomis sistemomis sukelia skausmą. Ypač kai problema yra globali ir ją reikia analizuoti skirtingose sistemose.
Kai kurios sistemos suteikia telefono numerį arba telegramą savo administratoriams. Kažkur reikia rašyti laiškus vadovams arba eiti į šių išorinių sistemų klaidų stebėjimo priemones. Net ir vienos didelės įmonės kontekste skirtingos sistemos dažnai veikia skirtingose taikomųjų programų apskaitos sistemose. Kartais tampa neįmanoma stebėti programos būsenos. Jūs gaunate prašymą vienoje sąlyginėje Jira. Tada šio pirmojo Jira komentare įdėjote nuorodą į problemą kitoje Jira. Antroje programoje Jira kažkas jau rašo komentarą, kad Norėdami išspręsti problemą, turite paskambinti sąlyginiam administratoriui Andrejui. Ir taip toliau.
Geriausias šios problemos sprendimas būtų sukurti vieną bendravimo erdvę, pavyzdžiui, „Slack“. Kviečiame prisijungti visus išorinių sistemų eksploatavimo proceso dalyvius. Taip pat vienas sekimas, kad programos nesidubliuotų. Programos turėtų būti stebimos vienoje vietoje – nuo stebėjimo pranešimų iki klaidų sprendimų ateityje. Sakysite, kad tai nerealu ir istoriškai susiklostė taip, kad mes dirbame viename trackeryje, o jie – kitame. Atsirado įvairios sistemos, jos turėjo savo savarankiškas IT komandas. Sutinku, todėl problemą reikia spręsti iš viršaus CIO arba produkto savininko lygmeniu.
Kiekviena sistema, su kuria bendraujate, turėtų teikti palaikymą kaip paslaugą su aiškiu SLA, kad būtų galima išspręsti problemas pagal prioritetą. Ir ne tada, kai sąlyginis administratorius Andrejus turi minutę tau.
Butelio kaklelio žmogus
Ar kiekvienas projekte (ar gaminyje) turi asmenį, kurio atostogos sukelia konvulsijas tarp jų vadovų? Tai gali būti devops inžinierius, analitikas ar kūrėjas. Juk tik devops inžinierius žino, kuriuose serveriuose kokie konteineriai yra įdiegti, kaip iš naujo paleisti konteinerį iškilus problemai ir apskritai be jo neįmanoma išspręsti bet kokios sudėtingos problemos. Analitikas yra vienintelis, kuris žino, kaip veikia jūsų sudėtingas mechanizmas. Kurie duomenų srautai kur eina. Pagal kokius užklausų parametrus į kokias paslaugas, kokias gausime atsakymus.
Kas greitai supras, kodėl žurnaluose yra klaidų, ir greitai ištaisys kritinę produkto klaidą? Žinoma, tas pats kūrėjas. Yra ir kitų, bet kažkodėl tik jis supranta, kaip veikia skirtingi sistemos moduliai.
Šios problemos priežastis yra dokumentų trūkumas. Juk jei būtų aprašytos visos jūsų sistemos paslaugos, tai būtų galima išspręsti problemą ir be analitiko. Jei devops paėmė kelias dienas iš savo įtempto grafiko ir apibūdino visus serverius, paslaugas ir instrukcijas tipinėms problemoms spręsti, tada problema jam nesant galėtų būti išspręsta be jo. Atostogaujant nereikia greitai išgerti alaus paplūdimyje ir ieškoti belaidžio interneto, kad išspręstumėte problemą.
Pagalbinio personalo kompetencija ir atsakomybė
Vykdydamos didelius projektus, įmonės negaili atlyginimų kūrėjams. Jie ieško brangių viduriniųjų ar senjorų iš panašių projektų. Su palaikymu situacija yra šiek tiek kitokia. Jie visais įmanomais būdais stengiasi sumažinti šias išlaidas. Įmonės samdo nebrangius vakarykščius Enikey darbuotojus ir drąsiai stoja į mūšį. Ši strategija įmanoma, jei kalbame apie Zelenogrado gamyklos vizitinių kortelių svetainę.
Jei kalbame apie didelę internetinę parduotuvę, tai kiekviena prastovos valanda kainuoja daugiau nei Enikey administratoriaus mėnesinis atlyginimas. Paimkime atskaitos tašką 1 milijardo rublių metinės apyvartos. Tai yra minimali bet kurios internetinės parduotuvės apyvarta pagal reitingą . Padalinkite šią sumą iš valandų skaičiaus per metus ir gaukite daugiau nei 100 000 rublių grynųjų nuostolių. O jei neskaičiuojate nakties valandų, galite drąsiai padvigubinti sumą.
Bet pinigai nėra pagrindinis dalykas, tiesa? (ne, žinoma, svarbiausia) Taip pat yra reputacijos praradimo. Žinomos internetinės parduotuvės žlugimas gali sukelti tiek apžvalgų bangą socialiniuose tinkluose, tiek publikacijas teminėje žiniasklaidoje. O draugų pokalbių virtuvėje stiliumi „Nieko ten nepirk, jų svetainė visada neveikia“ niekaip negali pamatuoti.
Dabar apie atsakomybę. Mano praktikoje buvo atvejis, kai budintis administratorius laiku nereagavo į stebėjimo sistemos pranešimą apie aikštelės neprieinamumą. Malonų vasaros penktadienio vakarą ramiai gulėjo žinomos Maskvoje internetinės parduotuvės svetainė. Šeštadienio rytą šios svetainės produkto vadovas nesuprato, kodėl svetainė neatsidaro, o palaikymo ir skubių pranešimų pokalbiuose „Slack“ tvyrojo tyla. Tokia klaida mums kainavo šešiaženklę sumą, o šis budėtojas – savo darbą.
Atsakomybė yra sunkiai ugdomas įgūdis. Arba žmogus ją turi, arba ne. Todėl interviu metu jos buvimą stengiuosi tapatinti įvairiais klausimais, kurie netiesiogiai parodo, ar žmogus įpratęs prisiimti atsakomybę. Jeigu žmogus atsako, kad universitetą pasirinko dėl to, kad taip pasakė tėvai, arba keičia darbą, nes žmona pasakė, kad neuždirba, tai su tokiais geriau nesivelk.
Bendravimas su kūrėjų komanda
Kai naudotojai susiduria su paprastomis gaminio problemomis, palaikymas jas išsprendžia pats. Bando atkurti problemą, analizuoja žurnalus ir pan. Bet ką daryti, kai gaminyje atsiranda klaida? Tokiu atveju palaikymas paskiria užduotį kūrėjams ir čia prasideda linksmybės.
Kūrėjai yra nuolat perkrauti. Jie kuria naujas funkcijas. Išpardavimo klaidų taisymas nėra pati įdomiausia veikla. Artėja terminai užbaigti kitą sprintą. Ir tada ateina nemalonūs žmonės iš palaikymo ir sako: „Nedelsdami meskite viską, turime problemų“. Tokių užduočių prioritetas yra minimalus. Ypač tada, kai problema nėra pati kritiškiausia ir veikia pagrindinis svetainės funkcionalumas, o leidimų tvarkyklė nelaksto išpūtusi akis ir nerašo: „Skubiai pridėkite šią užduotį į kitą leidimą ar karštąsias pataisas“.
Įprasto arba žemo prioriteto problemos perkeliamos iš leidimo į leidimą. Į klausimą „Kada užduotis bus atlikta? gausite atsakymus tokiu stiliumi: „Atsiprašome, šiuo metu yra daug užduočių, paklauskite savo komandos vadovų ar išleidimo vadovo“.
Produktyvumo problemos yra svarbesnės nei naujų funkcijų kūrimas. Blogi atsiliepimai netruks sulaukti, jei vartotojai nuolat susidurs su klaidomis. Sugadintą reputaciją sunku atkurti.
Kūrimo ir palaikymo sąveikos problemas išsprendžia „DevOps“. Ši santrumpa dažnai naudojama kaip konkretus asmuo, kuris padeda sukurti bandymo aplinką plėtrai, kuria CICD konvejerius ir greitai pristato išbandytą kodą į gamybą. „DevOps“ – tai požiūris į programinės įrangos kūrimą, kai visi proceso dalyviai glaudžiai bendrauja vieni su kitais ir padeda greitai sukurti bei atnaujinti programinės įrangos produktus ir paslaugas. Turiu omenyje analitikus, kūrėjus, testuotojus ir palaikymą.
Pagal šį požiūrį parama ir plėtra nėra skirtingi padaliniai, turintys savo tikslus ir uždavinius. Vystymas yra susijęs su eksploatavimu ir atvirkščiai. Garsioji paskirstytų komandų frazė: „Problema ne mano pusėje“ pokalbiuose nebepasirodo taip dažnai, o galutiniai vartotojai tampa šiek tiek laimingesni.
Šaltinis: www.habr.com