Myös katastrofin aikana on aina aikaa kupilliseen teetä.
DRP (katastrofipalautussuunnitelma) on asia, jota ei ihannetapauksessa koskaan tarvita. Mutta jos parittelukauden aikana vaeltavat majavat yhtäkkiä purevat päävalokuidun läpi tai nuorempi ylläpitäjä pudottaa tuotantopohjan, haluat ehdottomasti olla varma, että sinulla on valmiina suunnitelma mitä tehdä kaikelle tälle häpeälle.
Kun paniikissa olevat asiakkaat alkavat soittaa tekniseen tukeen, juniori etsii syanidia, avaat viisaasti punaisen kirjekuoren ja alat laittaa kaikkea järjestykseen.
Tässä viestissä haluan jakaa suosituksia DRP:n kirjoittamisesta ja mitä sen tulisi sisältää. Tarkastellaan myös seuraavaa:
- Opi ajattelemaan kuin konna.
- Analysoidaan kupillisen teetä apokalypsin aikana.
- Ajattele kätevää DRP-rakennetta
- Katsotaanpa, miten se testataan
Mitkä yritykset voivat hyötyä tästä?
On erittäin vaikea vetää rajaa, kun IT-osasto alkaa tarvita näitä asioita. Sanoisin, että tarvitset varmasti DRP:tä, jos:
- Palvelimen, sovelluksen pysäyttäminen tai jonkin tietokannan menettäminen johtaa merkittäviin tappioihin koko yritykselle.
- Sinulla on täysi IT-osasto. Tarkoitan siis osastoa yrityksen täysivaltaisena yksikkönä, jolla on oma budjetti, eikä vain muutama väsynyt työntekijä verkkoa laittamassa, viruksia siivoamassa ja tulostimien täytössä.
- Sinulla on realistinen budjetti ainakin osittaiseen irtisanomiseen hätätilanteessa.
Kun IT-osasto on kuukausia kerjäänyt ainakin paria kiintolevyä vanhalle palvelimelle varmuuskopioita varten, tuskin pystyt järjestämään kaatuneen palvelun täysimittaista siirtoa varakapasiteeteihin. Vaikka dokumentaatio ei ole tarpeeton tässäkään.
Dokumentointi on tärkeää
Aloita dokumentoinnista. Oletetaan, että palvelusi toimii Perl-skriptillä, joka on kirjoitettu kolme järjestelmänvalvojien sukupolvea sitten, eikä kukaan tiedä, miten se toimii. Kertynyt tekninen velka ja dokumentaation puute ampuvat väistämättä paitsi polveen, myös muihin raajoihin, se on pikemminkin ajan kysymys.
Kun sinulla on hyvä kuvaus palvelukomponenteista, nosta kaatumistilastot. Melkein varmasti ne ovat täysin tyypillisiä. Esimerkiksi levy on täynnä ajoittain, mikä saa solmun epäonnistumaan, kunnes se puhdistetaan manuaalisesti. Tai sitten asiakaspalvelu ei ole käytettävissä, koska joku taas unohti uusia varmenteen, mutta hän ei voinut tai halunnut ottaa Let's Encryptia käyttöön.
Ajatukset kuin sabotööri
Vaikeinta on ennakoida ne onnettomuudet, joita ei ole koskaan ennen tapahtunut, mutta jotka voivat mahdollisesti pilata palvelusi kokonaan. Täällä pelaamme yleensä roistoja kollegoiden kanssa. Ota paljon kahvia ja jotain maukasta ja lukitse itsesi kokoushuoneeseen. Varmista vain, että samassa kokouksessa lukitsit ne insinöörit, jotka itse nostivat kohdepalvelun tai työskentelevät sen kanssa säännöllisesti. Sitten alat piirtää joko taululle tai paperille kaikkia mahdollisia kauhuja, joita palvelullesi voi tapahtua. Ei ole tarpeen tarkentaa tiettyä siivoojaa ja kaapeleiden irrottamista, riittää, kun tarkastellaan skenaariota "Paikallisen verkon eheyden loukkaaminen".
Yleensä tyypilliset hätätilanteet sopivat seuraaviin tyyppeihin:
- Verkkovirhe
- Käyttöjärjestelmän palveluvirhe
- Sovellusvirhe
- raudan epäonnistuminen
- Virtualisointivirhe
Käy vain läpi jokainen näkymä ja katso, mikä koskee palveluasi. Esimerkiksi Nginx-daemon voi pudota eikä nousta - tämä on käyttöjärjestelmän vika. Harvinainen tilanne, joka ajaa verkkosovelluksesi toimimattomaan tilaan, on ohjelmistovika. Tämän vaiheen kehittämisen aikana on tärkeää selvittää ongelman diagnoosi. Kuinka erottaa virtualisoinnissa ripustettu käyttöliittymä esimerkiksi kaatuneesta Ciscosta ja verkon kaatumisesta. Tämä on tärkeää löytää nopeasti vastuulliset ja alkaa vetää häntää, kunnes onnettomuus on korjattu.
Kun tyypilliset ongelmat on kirjattu ylös, kaadamme lisää kahvia ja alamme pohtia oudoimpia skenaarioita, kun jotkin parametrit alkavat ylittää normin. Esimerkiksi:
- Mitä tapahtuu, jos aktiivisen solmun aika siirtyy minuutin taaksepäin suhteessa muihin klusterin jäseniin?
- Ja jos aika siirtyy eteenpäin, ja jos 10 vuotta?
- Mitä tapahtuu, jos klusterisolmu yhtäkkiä menettää verkon synkronoinnin aikana?
- Ja mitä tapahtuu, jos kaksi solmua eivät jaa johtajuutta toistensa tilapäisen eristäytymisen vuoksi verkon yli?
Tässä vaiheessa käänteinen lähestymistapa auttaa paljon. Ota tiimin itsepäisin jäsen, jolla on sairas mielikuvitus, ja anna hänelle tehtäväksi järjestää kiertokulku mahdollisimman lyhyessä ajassa, mikä kaataa palvelun. Jos se on vaikea diagnosoida, vielä parempi. Et usko niitä outoja ja siistejä ideoita, joita insinöörit keksivät, kun heille annetaan idea rikkoa jotain. Ja jos lupaat heille testitelineen tätä varten, se on erittäin hyvä.
Mikä tämä sinun DRP on?!
Olet siis määritellyt uhkamallin. He ottivat huomioon myös paikalliset asukkaat, jotka leikkaavat valokaapeleita kuparia etsiessään, sekä sotilastutkan, joka pudottaa radioreleen tiukasti perjantaisin klo 16. Nyt meidän on keksittävä, mitä tälle kaikelle tehdään.
Sinun tehtäväsi on kirjoittaa samat punaiset kirjekuoret, jotka avataan hätätilanteessa. Odota heti, että kun (ei jos!) Kaikki on pilalla, lähellä on vain kokemattomin harjoittelija, jonka kädet tärisevät rajusti tapahtuvan kauhusta. Katso kuinka hätäkyltit toteutetaan lääkärin vastaanotoilla. Esimerkiksi mitä tehdä anafylaktisen shokin kanssa. Hoitohenkilökunta tietää kaikki protokollat ulkoa, mutta kun lähistöllä oleva henkilö alkaa kuolla, kaikki tarttuvat usein avuttomasti kaikkeen. Tätä varten seinällä on selkeä ohje, jossa on esimerkiksi "avaa pakkaus sellaista ja sellaista" ja "ruiskuta niin monta yksikköä lääkettä suonensisäisesti".
Hätätilanteessa on vaikea ajatella! Selkärangan jäsentämiseen pitäisi olla yksinkertaiset ohjeet.
Hyvä DRP koostuu muutamasta yksinkertaisesta lohkosta:
- Kenelle ilmoittaa onnettomuuden alkamisesta. Tämä on tärkeää, jotta eliminointiprosessi voidaan rinnastaa mahdollisimman paljon.
- Kuinka diagnosoida oikein - jäljitämme, katsomme systemctl-tilasta servicename ja niin edelleen.
- Kuinka paljon aikaa voidaan käyttää kuhunkin vaiheeseen. Jos sinulla ei ole aikaa korjata sitä käsin SLA-aikana, virtuaalikone tapetaan ja rullataan eilisestä varmuuskopiosta.
- Kuinka varmistaa, että kolari on ohi.
Muista, että DRP käynnistyy, kun palvelu on täysin epäonnistunut, ja palautuu loppuun, vaikka tehokkuus on heikentynyt. Pelkästään varauksen menettämisen ei pitäisi aktivoida DRP:tä. Voit myös määrätä kupin teetä DRP:ssä. Vakavasti. Tilastojen mukaan monet onnettomuudet muuttuvat epämiellyttävistä katastrofaalisiin, koska henkilökunta paniikissa ryntää korjaamaan jotain, tappaen samalla ainoan datan sisältävän elävän solmun tai viimeistelemällä klusterin. Yleensä 5 minuuttia kupillista teetä antaa sinulle vähän aikaa rauhoittua ja analysoida, mitä tapahtuu.
Älä sekoita DRP:tä ja järjestelmäpassia! Älä ylikuormita sitä tarpeettomilla tiedoilla. Anna vain mahdollisuus siirtyä nopeasti ja kätevästi haluttuun dokumentaation osioon hyperlinkkien kautta ja lukea laajennetussa muodossa tarvittavista palveluarkkitehtuurin osista. Ja itse DRP:ssä on vain suorat ohjeet siitä, minne ja miten muodostaa yhteys tietyillä kopiointi-liitämiskomennoilla.
Kuinka testata oikein
Varmista, että jokainen vastuullinen työntekijä pystyy suorittamaan kaikki kohteet. Ratkaisevaimmalla hetkellä voi käydä ilmi, että insinöörillä ei ole käyttöoikeuksia vaadittuun järjestelmään, vaaditulla tilillä ei ole salasanoja tai hänellä ei ole aavistustakaan, mitä "Yhdistä palvelunhallintakonsoliin välityspalvelimen kautta pääkonttori" tarkoittaa. Jokaisen kohteen tulee olla mahdollisimman yksinkertainen.
väärä - "Siirry virtualisointiin ja käynnistä kuollut solmu uudelleen"
oikein - "Yhdistä verkkokäyttöliittymän kautta osoitteeseen virt.example.com, lataa solmuosiossa uudelleen virheen aiheuttava solmu."
Vältä epäselvyyttä. Muista pelästynyt harjoittelija.
Muista testata DRP. Tämä ei ole vain esittelysuunnitelma - sen avulla sinä ja asiakkaasi pääset nopeasti ulos kriittisestä tilanteesta. On parasta tehdä tämä useita kertoja:
- Yksi asiantuntija ja useat harjoittelijat työskentelevät testipenkissä, joka jäljittelee mahdollisimman paljon todellista palvelua. Asiantuntija katkaisee palvelun eri tavoin ja mahdollistaa harjoittelijoiden palauttaa sen DRP:n mukaan. Kaikki ongelmat, epäselvyydet dokumentaatiossa ja virheet kirjataan. Harjoittelijoiden koulutuksen jälkeen DRP:tä täydennetään ja yksinkertaistetaan hämärissä paikoissa.
- Testaus todellisessa palvelussa. Itse asiassa et voi koskaan luoda täydellistä kopiota todellisesta palvelusta. Siksi pari kertaa vuodessa on tarpeen sammuttaa osa palvelimista suunnitellusti, katkaista yhteyksiä ja järjestää muita uhkaluettelosta tulevia onnettomuuksia palautusmääräyksen arvioimiseksi. On parempi olla 10 minuutin suunniteltu katkos keskellä yötä kuin äkillinen useiden tuntien kesto huippukuormituksen aikana ja tietojen katoaminen.
- Onnettomuuden todellinen eliminointi. Kyllä, tämä on myös osa testausta. Jos tapahtuu onnettomuus, joka ei ollut uhkaluettelossa, on DRP täydennettävä ja viimeisteltävä sen tutkinnan tulosten perusteella.
Avainkohdat
- Jos paskaa voi tapahtua, se ei vain tapahdu, vaan se tapahtuu mitä katastrofaalisimmassa skenaariossa.
- Varmista, että sinulla on resurssit vikasietoa varten.
- Varmista, että sinulla on varmuuskopiot, ne luodaan automaattisesti ja niiden johdonmukaisuus tarkistetaan säännöllisesti.
- Harkitse tyypillisiä uhkaskenaarioita.
- Anna insinööreille mahdollisuus keksiä epätyypillisiä vaihtoehtoja palvelun toteuttamiseksi.
- DRP:n tulee olla yksinkertaisia ja tyhmiä ohjeita. Kaikki monimutkainen diagnostiikka vasta sen jälkeen, kun asiakkaat ovat palauttaneet palvelun. Vaikka se on valmiustilassa.
- Luettele tärkeimmät puhelinnumerot ja yhteystiedot DRP:ssä.
- Testaa säännöllisesti työntekijöitä DRP:n ymmärtämiseksi.
- Järjestä tuotteelle suunnitellut onnettomuudet. Telineet eivät voi korvata kaikkea.
Lähde: will.com