Nykyään Bitrix24-palvelulla ei ole satoja gigabittejä liikennettä, eikä sillä ole valtavaa palvelinkantaa (vaikka olemassa olevia on tietysti melko vähän). Mutta monille asiakkaille se on tärkein työkalu yrityksessä työskentelyyn, se on todella liiketoimintakriittinen sovellus. Siksi ei ole mahdollista kaatua. Entä jos kolari tapahtui, mutta palvelu "palautui" niin nopeasti, ettei kukaan huomannut mitään? Ja miten on mahdollista toteuttaa vikasietoisuus menettämättä työn laatua ja asiakkaiden määrää? Bitrix24:n pilvipalveluiden johtaja Alexander Demidov puhui blogissamme siitä, kuinka varausjärjestelmä on kehittynyt tuotteen 7 vuoden aikana.
"Julkaisimme Bitrix24:n SaaS-palveluna 7 vuotta sitten. Suurin vaikeus oli luultavasti seuraava: ennen kuin se lanseerattiin julkisesti SaaS-muodossa, tämä tuote oli yksinkertaisesti olemassa laatikollisen ratkaisun muodossa. Asiakkaat ostivat sen meiltä, isännöivät sitä palvelimillaan, perustivat yritysportaalin – yleinen ratkaisu työntekijöiden viestintään, tiedostojen säilytykseen, tehtävien hallintaan, CRM:ään, siinä kaikki. Ja vuoteen 2012 mennessä päätimme tuoda sen markkinoille SaaS-muodossa, hallinnoimalla sitä itse, varmistaen vikasietoisuuden ja luotettavuuden. Saimme kokemusta matkan varrella, koska siihen asti meillä ei yksinkertaisesti ollut sitä - olimme vain ohjelmistovalmistajia, emme palveluntarjoajia.
Palvelua käynnistettäessä ymmärsimme, että tärkeintä on varmistaa palvelun vikasietoisuus, luotettavuus ja jatkuva saatavuus, sillä jos sinulla on yksinkertainen tavallinen nettisivu, esimerkiksi kauppa ja se putoaa sinulle ja istuu siellä. tunnin ajan, vain sinä kärsit, menetät tilauksia, menetät asiakkaita, mutta asiakkaallesi itselleen tämä ei ole hänelle kovin kriittistä. Hän oli tietysti järkyttynyt, mutta hän meni ja osti sen toiselta sivustolta. Ja jos tämä on sovellus, johon kaikki yrityksen sisäinen työ, viestintä, päätökset sidotaan, niin tärkeintä on saada käyttäjien luottamus, eli olla pettämättä ja kaatumatta. Koska kaikki työ voi pysähtyä, jos jokin sisällä ei toimi.
Bitrix.24 SaaS-muodossa
Kokosimme ensimmäisen prototyypin vuotta ennen julkista julkaisua, vuonna 2011. Kokosimme sen noin viikossa, katselimme, kiertelimme - se jopa toimi. Eli voit mennä lomakkeeseen, syöttää sinne portaalin nimen, uusi portaali avautuu ja käyttäjäkunta syntyisi. Katselimme sitä, arvioimme tuotteen periaatteessa, romutimme sen ja jatkoimme sen hiomista koko vuoden. Koska meillä oli iso tehtävä: emme halunneet tehdä kahta erilaista koodipohjaa, emme halunneet tukea erillistä pakattua tuotetta, erillisiä pilviratkaisuja – halusimme tehdä kaiken yhden koodin sisällä.
Tyypillinen web-sovellus siihen aikaan oli yksi palvelin, jolla pyörii jokin PHP-koodi, mysql-tietokanta, tiedostot ladataan, dokumentit, kuvat laitetaan latauskansioon - no, kaikki toimii. Valitettavasti tämän avulla on mahdotonta käynnistää kriittisesti vakaata verkkopalvelua. Siellä hajautettua välimuistia ei tueta, tietokannan replikointia ei tueta.
Muotoilimme vaatimukset: tämä on kyky sijaita eri paikoissa, tukea replikointia ja ihanteellisesti sijaita eri maantieteellisesti hajautetuissa palvelinkeskuksissa. Erota tuotelogiikka ja itse asiassa tietojen tallennus. Osaat skaalata dynaamisesti kuormituksen mukaan ja sietää staattista kokonaisuutta. Näistä pohdinnoista itse asiassa syntyivät tuotteelle asetetut vaatimukset, joita hiottiin vuoden aikana. Tänä aikana yhtenäiseksi osoittautuneessa alustassa - laatikkoratkaisuille, omalle palvelullemme - teimme tukea niille asioille, joita tarvitsimme. Mysql-replikoinnin tuki itse tuotteen tasolla: toisin sanoen koodin kirjoittava kehittäjä ei ajattele kuinka hänen pyyntönsä jaetaan, hän käyttää sovellusliittymäämme ja me tiedämme kuinka jakaa kirjoitus- ja lukupyynnöt oikein isäntien välillä. ja orjia.
Olemme tehneet tuotetason tuen erilaisille pilviobjektien tallennusvälineille: google-tallennustila, amazon s3 sekä tuki avoimen pinon swiftille. Tästä syystä tämä oli kätevä sekä meille palveluna että pakettiratkaisun parissa työskenteleville kehittäjille: jos he vain käyttävät API:amme työhönsä, he eivät ajattele minne tiedosto lopulta tallennetaan, paikallisesti tiedostojärjestelmään tai objektitiedostojen tallennustilassa.
Tämän seurauksena päätimme heti, että varaamme koko palvelinkeskuksen tasolla. Vuonna 2012 lanseerasimme kokonaan Amazon AWS:n, koska meillä oli jo kokemusta tästä alustasta - oma verkkosivustomme oli siellä. Meitä houkutteli se, että Amazonilla on jokaisella alueella useita käytettävyysvyöhykkeitä - itse asiassa (oman terminologiansa mukaan) useita palvelinkeskuksia, jotka ovat enemmän tai vähemmän toisistaan riippumattomia ja mahdollistavat varauksen kokonaisen datakeskuksen tasolla: jos se äkillisesti epäonnistuu, tietokannat replikoidaan master-master, web-sovelluspalvelimet varmuuskopioidaan ja staattiset tiedot siirretään s3-objektien tallennustilaan. Kuorma on tasapainotettu - tuolloin Amazonin elb, mutta vähän myöhemmin tulimme omiin kuormantasajiimme, koska tarvitsimme monimutkaisempaa logiikkaa.
He halusivat sen mitä he saivat...
Kaikki perusasiat, jotka halusimme varmistaa - itse palvelinten vikasieto, web-sovellukset, tietokannat - kaikki toimi hyvin. Yksinkertaisin skenaario: jos jokin verkkosovelluksistamme epäonnistuu, kaikki on yksinkertaista - ne kytketään pois tasapainotuksesta.
Tasapainotin (tuohon aikaan Amazonin kyynärpää) merkitsi epäkunnossa olleet koneet epäterveellisiksi ja sulki niiltä kuormanjaon. Amazonin automaattinen skaalaus toimi: kuorman kasvaessa autoskaalaukseen lisättiin uusia koneita, kuorma jaettiin uusille koneille - kaikki oli hyvin. Tasapainottimissamme logiikka on suunnilleen sama: jos sovelluspalvelimelle tapahtuu jotain, poistamme siitä pyynnöt, heitämme nämä koneet pois, käynnistämme uudet ja jatkamme työtä. Järjestelmä on muuttunut hieman vuosien varrella, mutta toimii edelleen: se on yksinkertainen, ymmärrettävä, eikä siinä ole vaikeuksia.
Työskentelemme ympäri maailmaa, asiakkaiden kuormitushuiput ovat täysin erilaisia, ja sovinnollisesti meidän pitäisi pystyä suorittamaan tiettyjä huoltotöitä kaikille järjestelmämme komponenteille milloin tahansa - asiakkaiden huomaamatta. Siksi meillä on mahdollisuus sammuttaa tietokanta toiminnasta jakamalla kuorma uudelleen toiseen datakeskukseen.
Miten se kaikki toimii? — Siirrämme liikenteen toimivaan konesaliin - jos konesalissa tapahtuu onnettomuus, niin kokonaan, jos tämä on suunniteltu työ yhden tietokannan kanssa, niin siirrämme osan näitä asiakkaita palvelevasta liikenteestä toiseen konesaliin, keskeyttämällä sen replikointi. Jos web-sovelluksiin tarvitaan uusia koneita, koska toisen konesalikeskuksen kuormitus on kasvanut, ne käynnistyvät automaattisesti. Viimeistelemme työn, replikointi palautetaan ja palautamme koko kuorman takaisin. Jos meidän täytyy peilata joitakin töitä toisessa DC:ssä, esimerkiksi asentaa järjestelmäpäivityksiä tai muuttaa asetuksia toisessa tietokannassa, toistamme yleensä saman asian, vain toiseen suuntaan. Ja jos tämä on onnettomuus, teemme kaiken triviaalisti: käytämme tapahtumakäsittelijöiden mekanismia valvontajärjestelmässä. Jos useita tarkistuksia laukaistaan ja tila menee kriittiseksi, suoritamme tämän käsittelijän, käsittelijän, joka voi suorittaa tämän tai toisen logiikan. Määritämme jokaiselle tietokannalle, mikä palvelin on sen vikasietoinen palvelin, ja mihin liikennettä on vaihdettava, jos se ei ole käytettävissä. Historiallisesti käytämme nagiosia tai joitain sen haarukoista muodossa tai toisessa. Periaatteessa samanlaisia mekanismeja on lähes kaikissa valvontajärjestelmissä, emme vielä käytä mitään monimutkaisempaa, mutta ehkä joskus käytämme. Nyt seuranta käynnistyy epäkäytettävyyden vuoksi ja sillä on mahdollisuus vaihtaa jotain.
Olemmeko varanneet kaiken?
Meillä on monia asiakkaita Yhdysvalloista, monia asiakkaita Euroopasta, monia asiakkaita, jotka ovat lähempänä itää - Japani, Singapore ja niin edelleen. Tietysti suuri osa asiakkaista on Venäjällä. Eli työ ei ole yhdellä alueella. Käyttäjät haluavat nopean vastauksen, erilaisten paikallisten lakien noudattamista koskevia vaatimuksia on, ja kullakin alueella varaamme kaksi palvelinkeskusta sekä joitakin lisäpalveluita, jotka on jälleen kätevä sijoittaa yhdelle alueelle - asiakkaille, jotka ovat tämä alue toimii. REST-käsittelijät, valtuutuspalvelimet, ne ovat vähemmän kriittisiä asiakkaan toiminnalle kokonaisuutena, voit vaihtaa niiden läpi pienellä hyväksyttävällä viiveellä, mutta et halua keksiä pyörää uudelleen kuinka niitä seurataan ja mitä tehdä heidän kanssaan. Siksi pyrimme hyödyntämään olemassa olevia ratkaisuja mahdollisimman paljon sen sijaan, että kehitämme jonkinlaista osaamista lisätuotteisiin. Ja jossain käytämme triviaalisti vaihtoa DNS-tasolla ja määritämme palvelun eloisuuden samalla DNS:llä. Amazonilla on Route 53 -palvelu, mutta se ei ole vain DNS, johon voit tehdä merkintöjä, ja se on siinä – se on paljon joustavampi ja kätevämpi. Sen avulla voit rakentaa maantieteellisesti hajautettuja palveluita maantieteellisillä paikoilla, kun sen avulla määrität asiakkaan lähtökohdan ja annat hänelle tietyt tietueet - sen avulla voit rakentaa vikasietoarkkitehtuureja. Samat kuntotarkastukset on määritetty itse Route 53:ssa, asetat valvottavat päätepisteet, asetat mittareita, määrität mitkä protokollat määrittävät palvelun "elävyyden" - tcp, http, https; Aseta tarkastusten tiheys, joka määrittää, onko palvelu elossa vai ei. Ja itse DNS:ssä määrität mikä on ensisijaista, mikä toissijaista, mihin vaihtaa, jos kuntotarkastus laukeaa reitin 53 sisällä. Kaikki tämä voidaan tehdä joillain muilla työkaluilla, mutta miksi se on kätevää - asetamme sen kerran ja sitten älä ajattele sitä ollenkaan, kuinka teemme tarkastuksia, kuinka vaihdamme: kaikki toimii itsestään.
Ensimmäinen "mutta": miten ja millä varata itse reitti 53? Kuka tietää, mitä jos hänelle tapahtuu jotain? Emme onneksi koskaan astuneet tälle haravalle, mutta minulla on taas tarina edessä, miksi ajattelimme, että meidän oli vielä tehtävä varaus. Täällä asetimme oljet itsellemme etukäteen. Useita kertoja päivässä tyhjennämme kaikki reitillä 53 olevat vyöhykkeet. Amazonin API mahdollistaa niiden lähettämisen helposti JSON-muodossa, ja meillä on useita varmuuskopiopalvelimia, joissa muunnamme sen, lataamme sen asetusten muodossa ja meillä on karkeasti sanottuna varmuuskopiokokoonpano. Jos jotain tapahtuu, voimme ottaa sen nopeasti käyttöön manuaalisesti menettämättä DNS-asetustietoja.
Toinen "mutta": Mitä tässä kuvassa ei ole vielä varattu? Itse tasapainotin! Asiakkaiden jakautuminen alueittain on tehty hyvin yksinkertaiseksi. Meillä on verkkotunnukset bitrix24.ru, bitrix24.com, .de - nyt niitä on 13 erilaista, jotka toimivat useilla eri vyöhykkeillä. Päädyimme seuraavaan: jokaisella alueella on omat tasapainottajansa. Tämä helpottaa jakamista alueiden kesken sen mukaan, missä verkon huippukuormitus on. Jos tämä on vika yhden tasapainottimen tasolla, se yksinkertaisesti poistetaan käytöstä ja poistetaan dns:stä. Jos tasapainoimien ryhmässä on jokin ongelma, ne varmuuskopioidaan muille sivustoille ja niiden välillä vaihdetaan samaa reittiä53, koska lyhyen TTL:n vuoksi vaihto tapahtuu enintään 2, 3, 5 minuutin sisällä. .
Kolmas "mutta": Mitä ei ole vielä varattu? S3, oikein. Kun sijoitimme käyttäjille tallentamamme tiedostot s3:een, uskoimme vilpittömästi, että se oli panssarilävistys, eikä sinne tarvinnut varata mitään. Mutta historia osoittaa, että asiat tapahtuvat toisin. Yleisesti ottaen Amazon kuvailee S3:a peruspalveluksi, koska Amazon itse käyttää S3:a konekuvien, asetusten, AMI-kuvien, tilannekuvien tallentamiseen... Ja jos s3 kaatuu, kuten kerran näiden 7 vuoden aikana, niin kauan kuin olemme käyttäneet. bitrix24, se seuraa sitä kuin fani. Esiin tulee koko joukko asioita – virtuaalikoneiden kyvyttömyys käynnistää, API-virhe ja niin edelleen.
Ja S3 voi pudota - se tapahtui kerran. Siksi päädyimme seuraavaan kaavaan: Venäjällä ei vielä muutama vuosi sitten ollut vakavia julkisia esinevarastoja, ja mietimme vaihtoehtoa tehdä jotain omaa... Onneksi emme alkaneet tehdä tätä, koska olisimme olemme kaivanneet asiantuntemusta, jota meillä ei ole, ja luultavasti sekaisin. Nyt Mail.ru:lla on s3-yhteensopiva tallennustila, Yandexillä ja useilla muilla palveluntarjoajilla on se. Lopulta päädyimme ajatukseen, että halusimme ensinnäkin varmuuskopion ja toiseksi mahdollisuuden työskennellä paikallisten kopioiden kanssa. Erityisesti Venäjän alueella käytämme Mail.ru Hotbox -palvelua, joka on API-yhteensopiva s3:n kanssa. Emme tarvinneet suuria muutoksia sovelluksen sisällä olevaan koodiin, ja teimme seuraavan mekanismin: s3:ssa on laukaisuja, jotka laukaisevat objektien luomisen/poiston, Amazonilla on palvelu nimeltä Lambda - tämä on palvelimeton koodin käynnistäminen joka suoritetaan juuri kun tietyt liipaisimet laukeavat.
Teimme sen hyvin yksinkertaisesti: jos laukaisumme käynnistyy, suoritamme koodin, joka kopioi objektin Mail.ru-tallennustilaan. Jotta voimme aloittaa työskentelyn täysin paikallisten tietojen kopioiden kanssa, tarvitsemme myös käänteisen synkronoinnin, jotta venäläisen segmentin asiakkaat voivat työskennellä lähempänä olevan tallennustilan kanssa. Mail on suorittamassa triggerit tallennustilassaan - käänteinen synkronointi on mahdollista suorittaa infrastruktuuritasolla, mutta toistaiseksi teemme tämän oman koodimme tasolla. Jos näemme, että asiakas on lähettänyt tiedoston, asetamme tapahtuman kooditasolla jonoon, käsittelemme sen ja teemme käänteisen replikoinnin. Miksi se on huono: jos teemme jonkinlaista työtä esineidemme kanssa tuotteemme ulkopuolella, eli jollain ulkoisella keinolla, emme ota sitä huomioon. Siksi odotamme loppuun asti, kun triggerit ilmestyvät tallennustasolle, jotta riippumatta siitä, mistä suoritamme koodin, meille saapunut objekti kopioidaan toiseen suuntaan.
Kooditasolla rekisteröimme kummatkin varastot kullekin asiakkaalle: toista pidetään pääasiallisena, toista varamuistina. Jos kaikki on kunnossa, työskentelemme lähempänä olevan tallennustilan kanssa: eli Amazonissa olevat asiakkaamme työskentelevät S3:n kanssa ja Venäjällä työskentelevät Hotboxin kanssa. Jos lippu laukeaa, vikasieto on kytkettävä ja vaihdamme asiakkaat toiseen tallennustilaan. Voimme valita tämän ruudun itsenäisesti alueittain ja vaihtaa niitä edestakaisin. Emme ole vielä käyttäneet tätä käytännössä, mutta olemme varautuneet tähän mekanismiin ja uskomme, että jonain päivänä tarvitsemme juuri tätä kytkintä ja siitä on hyötyä. Tämä on tapahtunut jo kerran.
Ja Amazon juoksi karkuun...
Tänä huhtikuussa on vuosipäivä Telegramin eston alkamisesta Venäjällä. Eniten vaikuttanut palveluntarjoaja, joka kuului tämän piiriin, on Amazon. Ja valitettavasti venäläiset yritykset, jotka työskentelivät koko maailman hyväksi, kärsivät enemmän.
Jos yritys on globaali ja Venäjä on sille hyvin pieni segmentti, 3-5 % - no, tavalla tai toisella, voit uhrata heidät.
Jos tämä on puhtaasti venäläinen yritys - olen varma, että sen on sijaittava paikallisesti - no, se on yksinkertaisesti kätevä käyttäjille itselleen, mukava ja siinä on vähemmän riskejä.
Entä jos tämä on globaalisti toimiva yritys, jolla on suunnilleen yhtä paljon asiakkaita Venäjältä ja muualta maailmasta? Segmenttien liitettävyys on tärkeä, ja niiden on toimittava keskenään tavalla tai toisella.
Maaliskuun 2018 lopussa Roskomnadzor lähetti kirjeen suurimmille operaattoreille, että ne aikoivat estää useita miljoonia Amazon-IP:itä estääkseen... Zello-viestintälaitteen. Kiitos näille samoille palveluntarjoajille - he vuotivat kirjeen onnistuneesti kaikille ja ymmärsimme, että yhteys Amazonin kanssa voi hajota. Oli perjantai, juoksimme paniikissa kollegoillemme servers.ru:sta sanoen: "Ystävät, tarvitsemme useita palvelimia, jotka eivät sijaitse Venäjällä, ei Amazonissa, vaan esimerkiksi jonnekin Amsterdamissa", jotta jotta voisimme ainakin jotenkin asentaa sinne oman VPN:n ja välityspalvelimen joihinkin päätepisteisiin, joihin emme voi mitenkään vaikuttaa, esimerkiksi saman s3:n päätepisteisiin - emme voi yrittää nostaa uutta palvelua ja hankkia eri IP-osoitetta, meidän on vielä päästävä sinne. Muutamassa päivässä asensimme nämä palvelimet, saimme ne käyntiin ja yleensä valmistauduimme eston alkamishetkeen. On kummallista, että RKN katsoi meteliä ja paniikkia ja sanoi: "Ei, emme estä nyt mitään." (Mutta tämä on juuri siihen hetkeen asti, jolloin Telegramia alettiin estää.) Ohitustoiminnot asetettuamme ja tajuttuamme, että estoa ei ollut otettu käyttöön, emme kuitenkaan alkaneet selvittää koko asiaa. Kyllä, varmuuden vuoksi.
Ja vuonna 2019 elämme edelleen eston olosuhteissa. Katsoin eilen illalla: noin miljoona IP-osoitetta on edelleen estetty. Totta, Amazon oli lähes kokonaan vapautettu, huipussaan se saavutti 20 miljoonaa osoitetta... Yleisesti ottaen todellisuus on, että ei ehkä ole johdonmukaisuutta, hyvää koherenssia. Yhtäkkiä. Sitä ei ehkä ole olemassa teknisistä syistä - tulipaloista, kaivinkoneista, kaikesta muusta. Tai, kuten olemme nähneet, ei täysin teknisiä. Siksi joku iso ja iso, jolla on omat AS:t, voi luultavasti hoitaa tämän muilla tavoilla - suora yhteys ja muut asiat ovat jo l2-tasolla. Mutta yksinkertaisessa versiossa, kuten meillä tai jopa pienemmässä, voit varmuuden vuoksi saada redundanssin jonnekin muualle kasvatettujen palvelimien tasolla, jotka on määritetty etukäteen vpn-välityspalvelimella, ja voit vaihtaa kokoonpanon nopeasti niihin näissä segmenteissä. jotka ovat kriittisiä yhteyksillesi. Tästä oli meille hyötyä useammin kuin kerran, kun Amazonin esto alkoi, pahimmassa tapauksessa päästimme vain S3-liikenteen niiden läpi, mutta vähitellen kaikki tämä ratkesi.
Kuinka varata... koko palveluntarjoaja?
Tällä hetkellä meillä ei ole skenaariota siltä varalta, että koko Amazon kaatuu. Meillä on samanlainen skenaario Venäjälle. Venäjällä meitä isännöi yksi palveluntarjoaja, jolta valitsimme useita sivustoja. Ja vuosi sitten kohtasimme ongelman: vaikka kyseessä on kaksi palvelinkeskusta, voi jo palveluntarjoajan verkkokokoonpanon tasolla olla ongelmia, jotka vaikuttavat edelleen molempiin palvelinkeskuksiin. Ja emme ehkä ole käytettävissä molemmilla sivustoilla. Niin tietysti kävi. Päädyimme miettimään arkkitehtuuria uudelleen. Se ei ole juurikaan muuttunut, mutta Venäjällä meillä on nyt kaksi sivustoa, jotka eivät ole samalta toimittajalta, vaan kahdelta eri sivustolta. Jos toinen epäonnistuu, voimme vaihtaa toiseen.
Hypoteettisesti Amazonin osalta harkitsemme mahdollisuutta tehdä varaus toisen palveluntarjoajan tasolla; ehkä Google, ehkä joku muu... Mutta toistaiseksi olemme käytännössä havainneet, että vaikka Amazonissa sattuu onnettomuuksia yhden käytettävyysalueen tasolla, niin kokonaisen alueen tasolla onnettomuudet ovat melko harvinaisia. Siksi meillä on teoriassa ajatus, että saatamme tehdä "Amazon ei ole Amazon" -varauksen, mutta käytännössä näin ei vielä ole.
Muutama sana automaatiosta
Onko automaatio aina tarpeen? Tässä on aiheellista muistaa Dunning-Kruger-ilmiö. “X”-akselilla on saamamme tietomme ja kokemuksemme, ja “y”-akselilla luottamus toimintaamme kohtaan. Aluksi emme tiedä mitään emmekä ole ollenkaan varmoja. Sitten tiedämme vähän ja meistä tulee megavarmoja - tämä on niin kutsuttu "tyhmyyden huippu", jota havainnollistaa hyvin kuva "dementia ja rohkeus". Sitten olemme oppineet vähän ja olemme valmiita taisteluun. Sitten astumme megavakavien virheiden päälle ja joudumme epätoivon laaksoon, kun näytämme tietävän jotain, mutta itse asiassa emme tiedä paljon. Sitten kun saamme kokemusta, meistä tulee itsevarmempia.
Tämä kaavio kuvaa hyvin logiikkaamme erilaisista automaattisista kytkimistä tiettyihin onnettomuuksiin. Aloitimme - emme tienneet miten tehdä mitään, melkein kaikki työ tehtiin käsin. Sitten tajusimme, että voimme liittää automaation kaikkeen ja nukkua rauhassa. Ja yhtäkkiä astumme megaharavalle: väärä positiivinen laukeaa ja vaihdamme liikennettä edestakaisin, vaikka meidän ei olisi hyvällä tavalla pitänyt tehdä tätä. Tämän seurauksena replikaatio hajoaa tai jotain muuta - tämä on epätoivon laakso. Ja sitten tulemme ymmärtämään, että meidän on lähestyttävä kaikkea viisaasti. Eli on järkevää luottaa automaatioon, mikä mahdollistaa väärien hälytysten. Mutta! jos seuraukset voivat olla tuhoisat, niin se on parempi jättää päivystykseen, päivystykseen oleville insinööreille, jotka varmistavat ja valvovat, että onnettomuus todella tapahtuu, ja suorittavat tarvittavat toimenpiteet manuaalisesti...
Johtopäätös
Menimme 7 vuoden aikana siitä, että kun jokin putosi, tuli paniikki-paniikki, ymmärrykseen, että ongelmia ei ole olemassa, on vain tehtäviä, ne täytyy - ja voidaan - ratkaista. Kun rakennat palvelua, katso sitä ylhäältä, arvioi kaikki mahdolliset riskit. Jos näet ne heti, varaa etukäteen redundanssi ja mahdollisuus rakentaa vikasietoinen infrastruktuuri, koska mikä tahansa kohta, joka voi epäonnistua ja johtaa palvelun toimimattomuuteen, tekee niin varmasti. Ja vaikka sinusta näyttäisi, että jotkin infrastruktuurin elementit eivät varmasti epäonnistu - kuten sama s3, muista silti, että ne voivat. Ja ainakin teoriassa sinulla on käsitys siitä, mitä aiot tehdä niillä, jos jotain tapahtuu. Tee riskinhallintasuunnitelma. Kun ajattelet kaiken tekemistä automaattisesti tai manuaalisesti, arvioi riskit: mitä tapahtuu, jos automaatio alkaa kytkeä kaikkea - eikö tämä johda onnettomuuteen verrattuna vielä pahempaan tilanteeseen? Ehkä jossain on syytä käyttää järkevää kompromissia automaation käytön ja päivystävän insinöörin reaktion välillä, joka arvioi todellisen kuvan ja ymmärtää, pitääkö jotain vaihtaa paikan päällä vai "kyllä, mutta ei nyt".
Kohtuullinen kompromissi perfektionismin ja todellisen ponnistelun, ajan ja rahan välillä, jonka voit käyttää suunnitelmaan, joka sinulla lopulta on.
Tämä teksti on päivitetty ja laajennettu versio Alexander Demidovin raportista konferenssissa .
Lähde: will.com