Sisu
- Ettevalmistused ebaõnnestumiseks
- Järgmised sammud
- Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
- Õppimine ja õppuste parandamine
Allikas: pressureUA / iStockphoto
Ära võtma:
Kaasaegsed süsteemid peavad seisakute vältimiseks suutma hakkama saada kaosega. Seetõttu on süsteemide põhjalik testimine ja nende vastupidavuse tagamine tähtsam kui kunagi varem.
Vaatamata meie suurimatele jõupingutustele nende vältimiseks on IT-juhtumid vältimatu osa tööst - ja ettevõtlusega seotud seisakudest ettejäämine on ainult keerukam. Tänapäeval on süsteemid tihedalt ühendatud ja üha keerukamad ning liikuvamate osadega on rohkem võimalusi asjadeks valesti minna.
See on üks põhjus, miks üha enam organisatsioone pöördub mikroteenuste poole teenuste parema kättesaadavuse ja tõrkekindluse suurendamiseks. Kuid kuigi need on suurepärased ruumid monoliitsete rakenduste purustamiseks, võivad need potentsiaalselt ühendada ka rikkeohu - kui need pole spetsiaalselt vastupidavust silmas pidades kavandatud.
Ettevalmistused ebaõnnestumiseks
Arvestades hajutatud süsteemide olemuselt kaootilist olemust, tuleks teenuseid arendada mitte ainult rikke ennetamiseks, vaid ka rikke korral automaatselt taastamiseks. See tähendab, et korrapäraselt alustatakse tõrkeid tagamaks, et teie süsteemid saavad hakkama kaosega, ilma et see häiriks lõpptarbijatele osutatavaid teenuseid. Ja selle saavutamiseks on vaja oskust simuleerida tootmislaadset liiklust testimiskeskkondades.
Muidugi on hea mõte vastupidavust testida enne, kui muudatused selle tootmiseks muudavad. Kui te seda ei tee, ei saa te kontrollida, kas teie teenused toetavad nii keskmist kui ka tippkoormust. Tegelikult on kõige kindlam kihlvedu tagada, et teie toode suudab maksimeerida kuni kaks korda suurema summa, ilma et peaksite seda suurendama.
Vastupidavuse testimisel ei tohiks õiged tööriistad taotluste käitlemise pärast liiga palju muretseda, vaid see, et neil oleks lõpuks õige mõju. Pidage meeles, et teatud tingimustel võib sisestusteenus ülejäänud süsteemile päringut üle anda, kuid ei saa rikkest teatada. Ärge riskige seireradari all lennates probleemidega, veendudes, et valideerimine otsast lõpuni toimub tegelikult. (Lisateavet leiate jaotisest Tehnilised rikked: kas me saame nendega koos elada?)
Järgmised sammud
Pärast mõistmist, kuidas teenused koormuse all käituvad, on aeg hakata tutvustama tõrkejuhtumeid. Nagu kõigi tarkvara testimiste puhul, on ka kõige parem, kui teil on automatiseeritud tööriistad, mis võimaldavad stsenaariume hõlpsalt ja kiiresti reprodutseerida, et saaksite koordineerida keerulisi sündmusi, mis mõjutavad erinevaid infrastruktuuritehnoloogiaid. Lisaks võimalusele kontrollida teenuste parandusi ja muudatusi võimaldab see teil juhuslike rikete stsenaariume käivitada mis tahes keskkonnas ja ajakavas.
Tähenduslikud rikkejuhtumid sõltuvad suuresti teie teenuste paigutusest ja saate need sõnastada, esitades teile olulisi konkreetseid küsimusi. Näiteks kuidas mõjutab kasutajaliidese kasutamine inimesi, kui andmebaas muutub teatud aja jooksul kättesaamatuks? Kas need kasutajad saavad endiselt veebi kasutajaliideses navigeerida? Kas nad saavad endiselt oma teabele värskendusi välja anda ja kas neid värskendusi töödeldakse õigesti, kui andmebaas on uuesti juurdepääsetav?
Kui käitate mitut mikroteenust, võite küsida, kas mõni üksik teenus kokku jookseb, kas toimub globaalne seisak. Või kui teil on järjekordimehhanism teenuste vahelise suhtluse puhverdamiseks, mis juhtub siis, kui tarbijateenus (või teenused) lakkavad töötamast? Kas kasutajad saavad endiselt teie rakendusega töötada? Ja arvestades keskmist koormust, siis kui kaua teil on, enne kui järjekorrad ületanud ja hakkate s kaotama?
Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
Te ei saa oma programmeerimisoskusi parandada, kui keegi tarkvara kvaliteedist ei hooli.
Kui olete määratlenud mõned põhiküsimused oma infrastruktuuri kohta, võite hakata loetlema erinevaid viise nende tõrgete simuleerimiseks. Võib-olla piisab konkreetse teenuse või andmebaasiserveri peatamisest. Ummistuse simuleerimiseks võiksite blokeerida teenuse peamise lõime, kui selle konteiner on endiselt reageeriv ja töötab. Võite otsustada kehtestada oma võrgus reeglid, et blokeerida liiklus konkreetsete teenuste vahel. Linuxi keskkondades saate kasutada selliseid tööriistu nagu tc, et jäljendada selliseid võrguolukordi nagu kõrge latentsusaeg, langenud, rikutud või dubleeritud paketid. (Võib olla oluline kasutajate kaasamine katsetamisse. Loe lähemalt 4 põhjusest, miks lõppkasutajad peavad testimises osalema enne UAT-i.)
Õppimine ja õppuste parandamine
Rikketsenaariumide loomise üks kõige väärtuslikumaid aspekte on see, et need võivad paljastada kõik võimalikud viisid, kuidas süsteem võib ebaõnnestuda, ja seega rajada teed enesetervendamise loogika juurde. Teie meeskond läbib teenuste käsitsi taastamise sammud - muide, suurepärane õppetükk kinnitamaks, et nad suudavad seda SLA-de sees teha. Selle taastamisprotsessi automatiseerimist saab küll teha, kuid vahepeal saate puhata, teades, et teie meeskond on käinud läbi teenuste taastamise protsessi. Muutes rikke stsenaariumid juhuslikuks ja korrapäraseks ning avalikustamata jooksu üksikasju, võite ka puurimisse kaasata avastusi ja diagnoose - see on ju SLA-de kriitiline osa.
Kaosesuuringute keskmes võetakse süsteemi keerukus etteantud kujul, testitakse seda uute ja veiderde tingimuste simuleerimisega ning jälgitakse, kuidas süsteem reageerib. See on see, et andmetöötlusmeeskonnad peavad suurema vastupidavuse saavutamiseks süsteemi ümber kujundama ja ümber konfigureerima. Uute ja kasulike asjade õppimiseks on nii palju võimalusi. Näiteks võite leida juhtumeid, kus teenused ei saa värskendusi, kui alamteenuste teenused on muutunud, või piirkondi, kus jälgimine puudub täielikult. Puudub põnevaid viise oma toote vastupidavamaks ja vastupidavamaks muutmiseks!