Sisältö
- Valmistautuminen epäonnistumiseen
- Seuraavat vaiheet
- Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
- Oppiminen ja parantaminen harjoitusten avulla
Lähde: paineUA / iStockphoto
Ottaa mukaan:
Nykyaikaisten järjestelmien on kyettävä käsittelemään kaaosta, jotta vältetään seisokit. Siksi on tärkeämpää kuin koskaan testata järjestelmät perusteellisesti ja varmistaa niiden joustavuus.
Huolimatta suurimmista pyrkimyksistämme välttää niitä, IT-tapaukset ovat väistämätön osa työtä - ja yrittäminen pysyä eteenpäin liiketoimintaan vaikuttavilla seisokkeilla on vain vaikeampaa. Nykyään järjestelmät ovat tiukasti kytkettyjä ja yhä monimutkaisempia, ja liikkuvien osien mukana on enemmän mahdollisuuksia asioiden menemiseen pieleen.
Tämä on yksi syy siihen, miksi yhä useammat organisaatiot kääntyvät mikropalvelujen puoleen palvelun saatavuuden lisäämiseksi ja vikatilanteiden parantamiseksi. Mutta vaikka nämä ovat erinomaisia tiloja monoliittisten sovellusten rikkoutumiseen, ne voivat myös potentiaalisesti yhdistää epäonnistumisen riskin - elleivät ne ole suunniteltu nimenomaan joustavuutta ajatellen.
Valmistautuminen epäonnistumiseen
Hajautettujen järjestelmien luontaisesti kaoottisen luonteen vuoksi palveluita tulisi kehittää paitsi ennakoimaan myös vika, mutta myös palautumaan automaattisesti vikatilanteessa. Tämä tarkoittaa epäonnistumisten aloittamista säännöllisesti sen varmistamiseksi, että järjestelmäsi pystyvät käsittelemään kaaosta häiritsemättä palvelua loppukäyttäjille. Ja tämän saavuttamiseksi tarvitaan kyky simuloida tuotantomaista liikennettä testiympäristöissä.
Tietenkin, on hyvä idea testata joustavuus ennen kuin muutokset tekevät siitä tuotannon. Jos et tee tätä, et voi vahvistaa, että palvelusi tukevat sekä keskimääräistä että huippukuormitusta. Itse asiassa turvallisin veto on varmistaa, että tuotteesi pystyy käsittelemään jopa kaksi kertaa huippumäärän ilman, että sinun tarvitsee skaalata.
Joustavuustestauksessa oikeiden työkalujen ei pitäisi olla liian huolissaan pyyntöjen käsittelystä, vain siitä, että niiden lopputulos on oikea. Muista, että tietyissä olosuhteissa syöttöpalvelu voi epäonnistua luovuttamalla pyynnön muulle järjestelmälle, mutta ilmoittamatta virheestä. Älä riski seuraamalla tutkan alla lentäviä ongelmia varmistamalla, että todentaminen kokonaispisteestä toiseen tapahtuu. (Lisätietoja on artikkelissa Tekninen vika: Voimmeko elää heidän kanssaan?)
Seuraavat vaiheet
Kun on ymmärretty, kuinka palvelut käyttäytyvät kuormituksen alaisena, on aika alkaa esitellä vikatilanteita. Kuten kaikessa ohjelmistotestauksessa, parasta on käyttää automatisoituja työkaluja, joiden avulla voit helposti ja nopeasti toistaa skenaarioita, jotta voit koordinoida monimutkaisia tapahtumia, jotka vaikuttavat erilaisiin infrastruktuuritekniikoihin. Sen lisäksi, että pystyt tarkistamaan palveluihin tehtävät korjaukset ja muutokset, tämä antaa sinun suorittaa satunnaisia vikailmausskenaarioita missä tahansa ympäristössä ja aikataulussa.
Merkitykselliset vikatapahtumat riippuvat suurelta osin palveluidesi asettelusta, ja voit muotoilla ne esittämällä sinulle tärkeitä kysymyksiä. Esimerkiksi, miten vaikutus käyttöliittymää käyttäviin ihmisiin syntyy, kun tietokantaa ei tavoiteta tietyn ajanjakson ajan? Voivatko nämä käyttäjät edelleen navigoida web-käyttöliittymässä? Voivatko he edelleen julkaista päivityksiä tietoihinsä, ja käsitelläänkö nämä päivitykset oikein, kun tietokanta on jälleen tavoitettavissa?
Jos suoritat useita mikropalveluita, voit kysyä, tapahtuuko maailmanlaajuinen katkos, jos jokin yksittäinen palvelu kaatuu. Tai jos sinulla on jonotusmekanismi puskuroimaan palveluiden välistä viestintää, mitä tapahtuu, kun kuluttajapalvelu (tai palvelut) lakkaavat toimimasta? Voivatko käyttäjät edelleen työskennellä sovelluksesi kanssa? Ja kun otetaan huomioon keskimääräinen kuormitus, kuinka kauan sinulla on jonoja ennen ylivuotoa ja alkaa menettää s?
Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
Et voi parantaa ohjelmointitaitojasi, kun kukaan ei välitä ohjelmiston laadusta.
Kun olet määrittänyt muutaman keskeisen kysymyksen infrastruktuuristasi, voit alkaa luetella erilaisia tapoja simuloida näitä vikoja. Voi riittää, että tietty palvelu tai tietokantapalvelin lopetetaan. Haluat ehkä estää palvelun pääkierroksen lukkiutumattoman lukituksen simuloimiseksi, kun sen säilö on edelleen reagoiva ja käynnissä. Saatat päättää ottaa käyttöön sääntöjä verkossa liikenteen estämiseksi tiettyjen palvelujen välillä. Linux-ympäristöissä voit käyttää tc-työkaluja emuloimaan verkkotilanteita, kuten korkea viive, pudonneet, vioittuneet tai kopioidut paketit. (Voi olla tärkeää saada käyttäjät mukaan testaukseen. Lue lisää 4 syystä, miksi loppukäyttäjien on osallistuttava testaukseen ennen UAT: ta.)
Oppiminen ja parantaminen harjoitusten avulla
Yksi arvokkaimmista näkökohdista epäonnistumisskenaarioiden luomisessa on, että ne voivat paljastaa kaikki mahdolliset tavat, joilla järjestelmä voi epäonnistua, ja siten veistää polun itseparanemislogiikkaan. Tiimisi käy läpi vaiheet palvelujen palauttamiseksi manuaalisesti - hieno pora, muuten, vahvistaakseen, että osaa tehdä tämän SLA: n sisällä. Tämän palautusprosessin automatisointia voidaan työskennellä, mutta sillä välin voit levätä helposti tietäen, että joukkueesi on käynyt läpi palvelujen saamisen takaisin raiteilleen. Tekemällä epäonnistumisskenaariot satunnaisiksi ja säännöllisiksi ja paljastamatta ajon kaikkia yksityiskohtia, voit myös sisällyttää poraukseen diagnooseja - joka on loppujen lopuksi kriittinen osa SLA: ita.
Kaosisuunnittelu ottaa ytimessä järjestelmän monimutkaisuuden sellaisenaan, testaa sitä simuloimalla uusia ja hassuja olosuhteita ja tarkkailee miten järjestelmä reagoi. Tietojen suunnitteluryhmien on suunniteltava ja konfiguroitava järjestelmä uudelleen paremman joustavuuden saavuttamiseksi. On niin paljon mahdollisuuksia oppia uusia ja hyödyllisiä asioita. Voit esimerkiksi löytää tapauksia, joissa palvelut eivät saa päivityksiä, kun loppupään palvelut ovat muuttuneet, tai alueita, joissa seuranta puuttuu kokonaan. Ei ole pulaa mielenkiintoisista tavoista tehdä tuotteestasi joustavampi ja kestävämpi!