Hei, Habr! Olen tukenut Highload IT -järjestelmiä kymmenen vuoden ajan. En kirjoita tässä artikkelissa ongelmista, jotka liittyvät nginxin asettamiseen toimimaan 1000+ RPS -tilassa tai muista teknisistä asioista. Kerron havainnoistani ongelmista prosesseissa, joita syntyy tällaisten järjestelmien tukemisessa ja toiminnassa.
seuranta
Tekninen tuki ei odota, kunnes saapuu pyyntö, jonka sisältö on "Mitä Miksi... sivusto ei toimi taas?" Minuutin kuluessa sivuston kaatumisesta tuen pitäisi jo nähdä ongelma ja alkaa ratkaista sitä. Mutta sivusto on jäävuoren huippu. Sen saatavuus on yksi ensimmäisistä, joita seurataan.
Mitä tehdä tilanteelle, kun verkkokaupan jäljellä olevat tavarat eivät enää tule ERP-järjestelmästä? Vai onko asiakkaiden alennuksia laskeva CRM-järjestelmä lakannut vastaamasta? Sivusto näyttää toimivan. Ehdollinen Zabbix saa 200 vastauksensa. Päivystävä vuoro ei ole saanut ilmoituksia valvonnasta ja katselee tyytyväisenä Game of Thronesin uuden kauden ensimmäistä jaksoa.
Valvonta rajoittuu usein vain muistin, RAM-muistin ja palvelimen suorittimen kuormituksen mittaamiseen. Mutta yrityksille on paljon tärkeämpää saada tuotteiden saatavuus verkkosivustolle. Yhden virtuaalikoneen ehdollinen vika klusterissa johtaa siihen, että liikenne lakkaa kulkemasta siihen ja muiden palvelimien kuormitus kasvaa. Yritys ei menetä rahaa.
Siksi palvelimilla olevien käyttöjärjestelmien teknisten parametrien valvonnan lisäksi sinun on määritettävä liiketoimintamittarit. Mittarit, jotka vaikuttavat suoraan rahaan. Erilaisia vuorovaikutuksia ulkoisten järjestelmien kanssa (CRM, ERP ja muut). Tilausten määrä tietyltä ajanjaksolta. Onnistuneet tai epäonnistuneet asiakasvaltuudet ja muut tiedot.
Vuorovaikutus ulkoisten järjestelmien kanssa
Mikä tahansa verkkosivusto tai mobiilisovellus, jonka vuosiliikevaihto on yli miljardi ruplaa, on vuorovaikutuksessa ulkoisten järjestelmien kanssa. Alkaen edellä mainituista CRM:stä ja ERP:stä ja päättyen myyntitietojen siirtoon ulkoiseen Big Data -järjestelmään ostojen analysoimiseksi ja asiakkaalle tuotteen tarjoamiseksi, jonka hän varmasti ostaa (itse asiassa ei). Jokaisella tällaisella järjestelmällä on oma tuki. Ja usein viestintä näiden järjestelmien kanssa aiheuttaa kipua. Varsinkin kun ongelma on globaali ja sitä on analysoitava eri järjestelmissä.
Jotkut järjestelmät tarjoavat puhelinnumeron tai sähkeen järjestelmänvalvojilleen. Jossain sinun täytyy kirjoittaa kirjeitä esimiehille tai mennä näiden ulkoisten järjestelmien vikaseurantaan. Jopa yhden suuren yrityksen yhteydessä eri järjestelmät toimivat usein eri sovellusten kirjanpitojärjestelmissä. Joskus on mahdotonta seurata sovelluksen tilaa. Saat pyynnön yhdessä ehdollisen Jirassa. Sitten tämän ensimmäisen Jiran kommenttiin laitat linkin ongelmaan toisessa Jirassa. Sovelluksen toisessa Jirassa joku kirjoittaa jo kommentin, että sinun on soitettava ehdolliseen järjestelmänvalvojaan Andreylle ongelman ratkaisemiseksi. Ja niin edelleen.
Paras ratkaisu tähän ongelmaan olisi luoda yksittäinen viestintätila, esimerkiksi Slackiin. Kutsumme kaikki ulkoisten järjestelmien käyttöprosessiin osallistujat liittymään. Ja myös yksi seurantalaite, jotta sovelluksia ei kopioida. Sovelluksia tulisi seurata yhdestä paikasta aina ilmoitusten valvontaan ja vikaratkaisujen tuottamiseen tulevaisuudessa. Sanotte, että tämä on epärealistista ja historiallisesti on tapahtunut niin, että me työskentelemme yhdessä seurannassa ja he työskentelevät toisessa. Erilaisia järjestelmiä ilmestyi, heillä oli omat itsenäiset IT-ryhmänsä. Olen samaa mieltä, ja siksi ongelma on ratkaistava ylhäältä tietohallintojohtajan tai tuotteen omistajan tasolla.
Jokaisen järjestelmän, jonka kanssa olet vuorovaikutuksessa, tulisi tarjota tukea palveluna, jolla on selkeä SLA-sopimus ongelmien ratkaisemiseksi tärkeysjärjestyksen mukaan. Eikä silloin, kun ehdollisen järjestelmänvalvojan Andreyllä on minuutti sinua varten.
Pullonkaula Mies
Onko jokaisessa projektissa (tai tuotteessa) henkilö, jonka lomalle lähteminen aiheuttaa kouristuksia esimiesten keskuudessa? Tämä voi olla devops-insinööri, analyytikko tai kehittäjä. Loppujen lopuksi vain devops-insinööri tietää, millä palvelimilla mitkä kontit on asennettu, kuinka kontti käynnistetään uudelleen ongelman sattuessa, ja yleensä mitään monimutkaista ongelmaa ei voida ratkaista ilman häntä. Analyytikko on ainoa, joka tietää kuinka monimutkainen mekanismisi toimii. Mitkä datavirrat menevät minne. Millä pyyntöparametreilla mihin palveluihin, mihin saamme vastauksia.
Kuka ymmärtää nopeasti, miksi lokeissa on virheitä, ja korjaa nopeasti tuotteen kriittisen bugin? Tietenkin sama kehittäjä. On muitakin, mutta jostain syystä vain hän ymmärtää kuinka järjestelmän eri moduulit toimivat.
Ongelman syy on dokumentaation puute. Loppujen lopuksi, jos kaikki järjestelmäsi palvelut kuvattaisiin, ongelma olisi mahdollista käsitellä ilman analyytikkoa. Jos devops vei pari päivää kiireisestä aikataulustaan ja kuvasi kaikki palvelimet, palvelut ja ohjeet tyypillisten ongelmien ratkaisemiseksi, niin hänen poissaolonsa ongelma voitaisiin ratkaista ilman häntä. Sinun ei tarvitse nopeasti juoda olutta loppuun rannalla loman aikana ja etsiä wifi-yhteyttä ongelman ratkaisemiseksi.
Tukihenkilöstön pätevyys ja vastuullisuus
Suurissa projekteissa yritykset eivät säästele kehittäjäpalkoilla. He etsivät kalliita keski- tai senioreita vastaavista projekteista. Tuen kanssa tilanne on hieman erilainen. He yrittävät vähentää näitä kustannuksia kaikin mahdollisin tavoin. Yritykset palkkaavat halpoja eilisen Enikey-työntekijöitä ja lähtevät rohkeasti taisteluun. Tämä strategia on mahdollista, jos puhumme Zelenogradin tehtaan käyntikorttisivustosta.
Jos puhumme suuresta verkkokaupasta, niin jokainen seisontatunti maksaa enemmän kuin Enikey-järjestelmänvalvojan kuukausipalkka. Otetaan lähtökohtana 1 miljardi ruplaa vuosiliikevaihdosta. Tämä on minkä tahansa verkkokaupan vähimmäisliikevaihto luokituksen perusteella . Jaa tämä määrä tuntien määrällä vuodessa ja saat yli 100 000 ruplaa nettotappioita. Ja jos et laske yötunteja, voit turvallisesti tuplata määrän.
Mutta raha ei ole pääasia, eihän? (ei, tietysti tärkeintä) On myös mainetappioita. Tunnetun verkkokaupan kaatuminen voi aiheuttaa sekä arvosteluaallon sosiaalisissa verkostoissa että julkaisuja temaattisessa mediassa. Ja ystävien keskusteluja keittiössä tyyliin "Älä osta sieltä mitään, heidän nettisivunsa on aina alaspäin" ei voi mitata ollenkaan.
Nyt vastuuseen. Käytännössäni on ollut tapaus, jossa päivystävä ylläpitäjä ei vastannut ajoissa seurantajärjestelmän ilmoitukseen sivuston poissaolosta. Miellyttävänä kesäisenä perjantai-iltana Moskovan tunnetun verkkokaupan nettisivut makasivat hiljaa. Lauantaiaamuna tämän sivuston tuotepäällikkö ei ymmärtänyt, miksi sivusto ei avautunut, ja Slackin tuki- ja kiireellisissä ilmoituskeskusteluissa vallitsi hiljaisuus. Tällainen virhe maksoi meille kuusinumeroisen summan ja tälle päivystäjälle työnsä.
Vastuullisuus on vaikeasti kehitettävä taito. Joko ihmisellä on se tai ei. Siksi haastatteluissa yritän tunnistaa sen läsnäolon erilaisilla kysymyksillä, jotka osoittavat epäsuorasti, onko henkilö tottunut ottamaan vastuuta. Jos joku vastaa, että hän valitsi yliopiston, koska hänen vanhempansa sanoivat niin, tai vaihtaa työpaikkaa, koska hänen vaimonsa sanoi, ettei hän tienaa tarpeeksi, on parempi olla seurustelematta tällaisten ihmisten kanssa.
Vuorovaikutus kehitystiimin kanssa
Kun käyttäjät kohtaavat yksinkertaisia ongelmia tuotteen kanssa käytön aikana, tuki ratkaisee ne itse. Yrittää toistaa ongelman, analysoi lokit ja niin edelleen. Mutta mitä tehdä, kun tuotteessa ilmenee virhe? Tässä tapauksessa tuki antaa tehtävän kehittäjille, ja tästä hauskuus alkaa.
Kehittäjät ovat jatkuvasti ylikuormitettuja. He luovat uusia ominaisuuksia. Myyntivirheiden korjaaminen ei ole kiinnostavinta toimintaa. Seuraavan sprintin suorittamisen määräajat lähestyvät. Ja sitten epämiellyttävät ihmiset tuesta tulevat ja sanovat: "Lopeta kaikki heti, meillä on ongelmia." Tällaisten tehtävien prioriteetti on minimaalinen. Varsinkin kun ongelma ei ole kriittisin ja sivuston päätoiminnallisuus toimii, ja kun julkaisunhallinta ei juokse ympäriinsä pullistuvin silmin ja kirjoita: "Lisää tämä tehtävä kiireellisesti seuraavaan julkaisuun tai hotfix-korjaukseen."
Ongelmat, joilla on normaali tai matala prioriteetti, siirretään julkaisusta toiseen. Kysymykseen "Milloin tehtävä valmistuu?" saat vastauksia tyyliin: "Anteeksi, nyt on paljon tehtäviä, kysy tiimisi johtajilta tai julkaisupäälliköltä."
Tuottavuusongelmat ovat tärkeämpiä kuin uusien ominaisuuksien luominen. Huonot arvostelut eivät kestä kauan, jos käyttäjät törmäävät jatkuvasti virheisiin. Vahingoittunutta mainetta on vaikea palauttaa.
Kehityksen ja tuen väliset vuorovaikutusongelmat ratkaisee DevOps. Tätä lyhennettä käytetään usein tietyn henkilön muodossa, joka auttaa luomaan testiympäristöjä kehitystä varten, rakentamaan CICD-putkia ja tuomaan testatun koodin nopeasti tuotantoon. DevOps on lähestymistapa ohjelmistokehitykseen, kun kaikki prosessin osallistujat ovat tiiviissä vuorovaikutuksessa toistensa kanssa ja auttavat luomaan ja päivittämään ohjelmistotuotteita ja palveluita nopeasti. Tarkoitan analyytikoita, kehittäjiä, testaajia ja tukea.
Tässä lähestymistavassa tuki ja kehittäminen eivät ole eri osastoja, joilla on omat päämääränsä ja päämääränsä. Kehitys on mukana toiminnassa ja päinvastoin. Hajautettujen tiimien kuuluisa lause: "Ongelma ei ole minun puolellani" ei enää esiinny chateissa niin usein, ja loppukäyttäjät tulevat hieman onnellisemmiksi.
Lähde: will.com