A Bitrix24 szolgáltatás ma már nem rendelkezik több száz gigabites forgalommal, és hatalmas szerverflottával sem rendelkezik (bár persze van jó néhány meglévő). De sok ügyfél számára ez a vállalati munka fő eszköze, ez egy igazi üzletkritikus alkalmazás. Ezért nincs mód elesni. Mi van, ha az összeomlás megtörténik, de a szolgáltatás olyan gyorsan „helyre állt”, hogy senki sem vett észre semmit? És hogyan valósítható meg a feladatátvétel a munka minőségének és az ügyfelek számának elvesztése nélkül? Alexander Demidov, a Bitrix24 felhőszolgáltatásokért felelős igazgatója blogunknak beszélt arról, hogyan fejlődött a foglalási rendszer a termék 7 éves fennállása alatt.
„Hét évvel ezelőtt elindítottuk a Bitrix24-et SaaS-ként. A fő nehézség valószínűleg a következő volt: mielőtt SaaS néven nyilvánosan megjelent, ez a termék egyszerűen dobozos megoldás formájában létezett. Az ügyfelek megvásárolták tőlünk, üzemeltették a szervereiken, létrehoztak egy vállalati portált – általános megoldás az alkalmazottak kommunikációjára, fájltárolásra, feladatkezelésre, CRM-re, ez minden. 7-re pedig úgy döntöttünk, hogy SaaS-ként szeretnénk elindítani, saját magunk adminisztrálva, biztosítva a hibatűrést és a megbízhatóságot. Útközben tapasztalatot szereztünk, mert addig egyszerűen nem volt – csak szoftvergyártók voltunk, nem szolgáltatók.
A szolgáltatás elindításakor megértettük, hogy a legfontosabb a hibatűrés, a megbízhatóság és a szolgáltatás állandó elérhetősége biztosítása, mert ha van egy egyszerű hétköznapi weboldalad, például egy üzleted, és az rád esik és ott ül Egy óra, csak te szenvedsz, rendeléseket veszítesz, ügyfeleket veszítesz, de az ügyfele számára ez nem túl kritikus. Természetesen ideges volt, de elment és megvette egy másik oldalon. És ha ez egy olyan alkalmazás, amelyre a cégen belüli minden munka, kommunikáció, döntések kötődnek, akkor a legfontosabb, hogy elnyerjük a felhasználók bizalmát, vagyis ne hagyjuk cserben és ne essünk el. Mert minden munka leállhat, ha belül valami nem működik.
Bitrix.24 SaaS néven
Az első prototípust egy évvel a nyilvános bemutató előtt, 2011-ben állítottuk össze. Körülbelül egy hét alatt összeraktuk, megnéztük, megforgattuk – még működött is. Vagyis be lehetne lépni az űrlapba, oda beírni a portál nevét, megnyílik egy új portál, és létrejön egy felhasználói bázis. Megnéztük, elvileg felmértük a terméket, leselejteztük, és egy teljes évig folytattuk a finomítást. Mert nagy feladatunk volt: nem akartunk két különböző kódbázist készíteni, nem akartunk külön csomagolt terméket, különálló felhőmegoldásokat támogatni – mindezt egy kódon belül akartuk megtenni.
Egy tipikus webalkalmazás akkoriban egy szerver volt, amin fut valami PHP kód, mysql adatbázis, fájlokat töltenek fel, dokumentumokat, képeket a feltöltési mappába raknak - nos, minden működik. Sajnos ezzel lehetetlen kritikusan stabil webszolgáltatást elindítani. Ott az elosztott gyorsítótár nem támogatott, az adatbázis-replikáció nem támogatott.
Megfogalmaztuk a követelményeket: ez a különböző helyeken való elhelyezés képessége, a replikáció támogatása, és ideális esetben a különböző földrajzilag elosztott adatközpontokban való elhelyezés. Válasszuk szét a terméklogikát és tulajdonképpen az adattárolást. Legyen képes dinamikusan skálázni a terhelésnek megfelelően, és teljesen elviseli a statikát. Ebből a megfontolásból tulajdonképpen a termékkel szemben támasztott követelmények alakultak ki, amelyeket az év során finomítottunk. Ezalatt az egységesnek bizonyult platformon - dobozos megoldásokhoz, saját szolgáltatásunkhoz - támogattuk azokat a dolgokat, amelyekre szükségünk volt. A mysql replikáció támogatása magának a terméknek a szintjén: vagyis a kódot író fejlesztő nem gondolkodik azon, hogyan oszlik el a kérései, a mi api-nkat használja, mi pedig tudjuk, hogyan kell helyesen elosztani az írási és olvasási kéréseket a mesterek között. és rabszolgák.
Termékszintű támogatást nyújtottunk a különféle felhőobjektum-tárolókhoz: google storage, amazon s3, valamint a nyílt verem swift támogatása. Ezért ez nekünk, mint szolgáltatásnak és a csomagolt megoldással dolgozó fejlesztőknek is kényelmes volt: ha csak a mi API-nkat használják munkára, akkor nem gondolnak bele, hogy végül hova mentik a fájlt, lokálisan a fájlrendszeren, ill. az objektumfájl tárolójában.
Ennek hatására azonnal úgy döntöttünk, hogy a teljes adatközpont szintjén foglalunk. 2012-ben teljes egészében az Amazon AWS-en indítottuk el, mert már volt tapasztalatunk ezzel a platformmal – saját webhelyünk is ott volt. Az vonzott minket, hogy az Amazon minden régióban több rendelkezésre állási zónával rendelkezik - sőt (az ő terminológiájukban) több adatközpont, amelyek többé-kevésbé függetlenek egymástól, és lehetővé teszik, hogy egy teljes adatközpont szintjén lefoglaljunk: Ha hirtelen meghiúsul, az adatbázisok master-master formátumban replikálódnak, a webalkalmazás-kiszolgálókról biztonsági mentés készül, és a statikus adatok átkerülnek az s3 objektumtárolóba. A terhelés kiegyenlített - akkoriban az Amazon elb, de kicsit később jöttünk a saját terheléselosztóinkhoz, mert bonyolultabb logikára volt szükség.
Amit akartak, azt kapták...
Minden alapvető dolog, amit biztosítani akartunk - maguknak a szervereknek a hibatűrése, webes alkalmazások, adatbázisok - minden jól működött. A legegyszerűbb forgatókönyv: ha valamelyik webalkalmazásunk meghibásodik, akkor minden egyszerű - kikapcsolják az egyensúlyozást.
A kiegyensúlyozó (akkoriban az Amazon könyöke volt) egészségtelennek jelölte az üzemképtelen gépeket, és kikapcsolta rajtuk a terheléselosztást. Az Amazon automatikus skálázása működött: amikor a terhelés nőtt, új gépek kerültek az automatikus skálázási csoportba, a terhelést elosztották az új gépekre - minden rendben volt. A kiegyenlítőinknél a logika megközelítőleg ugyanaz: ha valami történik az alkalmazásszerverrel, eltávolítjuk onnan a kéréseket, kidobjuk ezeket a gépeket, újakat indítunk és tovább dolgozunk. A séma kissé változott az évek során, de továbbra is működik: egyszerű, érthető, és nincs vele nehézség.
A világ minden táján dolgozunk, a vevőterhelési csúcsok teljesen eltérőek, és meghitt módon bármikor - az ügyfelek észrevétlenül - el tudjunk végezni bizonyos szervizmunkákat rendszerünk bármely elemén. Ezért lehetőségünk van kikapcsolni az adatbázist a működésből, újraosztva a terhelést egy második adatközpontba.
Hogyan működik mindez? — Működő adatközpontra állítjuk a forgalmat - ha az adatközpontban baleset történik, akkor teljes egészében, ha ez a tervezett munkánk egy adatbázissal, akkor az ezeket az ügyfeleket kiszolgáló forgalom egy részét egy második adatközpontra állítjuk, felfüggesztve. azt replikáció. Ha új gépekre van szükség a webalkalmazásokhoz, mert megnőtt a második adatközpont terhelése, azok automatikusan elindulnak. Befejezzük a munkát, a replikáció helyreáll, és visszaküldjük a teljes betöltést. Ha tükröznünk kell néhány munkát a második DC-ben, például telepíteni kell a rendszerfrissítéseket vagy módosítani kell a beállításokat a második adatbázisban, akkor általában megismételjük ugyanazt, csak a másik irányba. Ha pedig balesetről van szó, akkor mindent triviálisan csinálunk: az eseménykezelő mechanizmust használjuk a felügyeleti rendszerben. Ha több ellenőrzés is aktiválódik, és az állapot kritikussá válik, akkor ezt a kezelőt futtatjuk, egy olyan kezelőt, amely képes végrehajtani ezt vagy azt a logikát. Minden adatbázisnál megadjuk, hogy melyik szerver legyen a feladatátvétel, és hol kell a forgalmat átkapcsolni, ha az nem elérhető. Történelmileg a nagios-t vagy egyes villáit használjuk ilyen vagy olyan formában. Elvileg szinte minden monitorozó rendszerben léteznek hasonló mechanizmusok, ennél bonyolultabbat még nem használunk, de egyszer talán lesz. Most a figyelést az elérhetetlenség váltja ki, és képes valamit váltani.
Mindent lefoglaltunk?
Sok ügyfelünk van az USA-ból, sok ügyfelünk Európából, sok ügyfelünk, akik közelebb vannak Kelethez – Japánhoz, Szingapúrhoz stb. Természetesen az ügyfelek nagy része Oroszországban van. Vagyis a munka nem egy régióban folyik. A felhasználók gyors választ akarnak kapni, megkövetelik a különféle helyi törvények betartását, és régiónként két adatközpontot tartunk fenn, valamint van néhány további szolgáltatás is, amelyeket ismét kényelmes egy régión belül elhelyezni - azon ügyfelek számára, akik ez a régió működik. REST kezelők, jogosultság szerverek, ezek kevésbé kritikusak a kliens egészének működése szempontjából, kis elfogadható késéssel át lehet váltani rajtuk, de nem akarod újra feltalálni a kereket, hogyan figyeld és mit csinálj velük. Ezért igyekszünk a meglévő megoldásokat maximálisan kihasználni, nem pedig valamiféle kompetenciát fejleszteni további termékekben. És valahol triviálisan használjuk a DNS-szintű váltást, és ugyanaz a DNS határozza meg a szolgáltatás élénkségét. Az Amazon rendelkezik egy Route 53 szolgáltatással, de ez nem csak egy DNS, amelybe bejegyzéseket írhat, és ennyi – sokkal rugalmasabb és kényelmesebb. Rajta keresztül földrajzilag elosztott szolgáltatásokat építhet geolokációkkal, amikor ennek segítségével meghatározza, hogy honnan érkezett a kliens, és megadhat neki bizonyos rekordokat - segítségével feladatátvételi architektúrákat építhet. Ugyanezek az állapot-ellenőrzések vannak beállítva magában az 53-as útvonalon is, beállítja a figyelt végpontokat, beállítja a mérőszámokat, beállítja, hogy mely protokollok határozzák meg a szolgáltatás „élőképességét” - tcp, http, https; állítsa be az ellenőrzések gyakoriságát, amelyek meghatározzák, hogy a szolgáltatás él-e vagy sem. Magában a DNS-ben pedig megadja, hogy mi legyen az elsődleges, mi a másodlagos, hol kell váltani, ha az 53-as útvonalon belül aktiválódik az állapot-ellenőrzés. Mindez más eszközökkel is megtehető, de miért kényelmes - mi állítjuk be. egyszer fel, és akkor egyáltalán ne gondolj arra, hogyan ellenőrizzük, hogyan váltunk: minden működik magától.
Az első "de": hogyan és mivel lehet lefoglalni magát az 53-as utat? Ki tudja, mi van, ha valami történik vele? Szerencsére soha nem léptünk rá erre a gereblyére, de megint előttem lesz egy sztorim, hogy miért gondoltuk úgy, hogy még foglalnunk kell. Itt előre szívószálat raktunk ki magunknak. Naponta többször elvégezzük az összes zónánk teljes kiürítését az 53-as úton. Az Amazon API-ja lehetővé teszi, hogy egyszerűen elküldjük őket JSON-ban, és több tartalék szerverünk is van, ahol konvertáljuk, konfigurációk formájában feltöltjük, és durván szólva biztonsági mentési konfigurációval is rendelkezünk. Ha valami történik, gyorsan telepíthetjük manuálisan anélkül, hogy elveszítené a DNS-beállítási adatokat.
A második "de": Mi a képen még nincs lefoglalva? Maga a kiegyenlítő! Ügyfeleink régiónkénti elosztása nagyon egyszerű. Nálunk a bitrix24.ru, bitrix24.com, .de domainek vannak – jelenleg 13 különböző van, amelyek különböző zónákban működnek. A következőkre jutottunk: minden régiónak megvannak a maga egyensúlyozói. Ez kényelmesebbé teszi a régiók közötti elosztást, attól függően, hogy hol van a hálózat csúcsterhelése. Ha ez egyetlen kiegyenlítő szintjén hiba, akkor egyszerűen kivonják a forgalomból és eltávolítják a dns-ből. Ha valamilyen probléma adódna a balanszerek csoportjával, akkor más oldalakon biztonsági mentésre kerül, és a közöttük való váltás ugyanazon az útvonalon53 történik, mivel a rövid TTL miatt a váltás maximum 2, 3, 5 percen belül megtörténik. .
A harmadik "de": Mi nincs még lefoglalva? S3, helyes. Amikor az s3-ban elhelyeztük azokat a fájlokat, amelyeket a felhasználók számára tárolunk, őszintén hittük, hogy páncéltörő, és nem kell ott semmit lefoglalni. De a történelem azt mutatja, hogy a dolgok másként történnek. Általánosságban elmondható, hogy az Amazon alapvető szolgáltatásként írja le az S3-at, mert maga az Amazon használja az S3-at a gépi képek, konfigurációk, AMI képek, pillanatképek tárolására... És ha az s3 összeomlik, ahogy ez egyszer megtörtént ezalatt a 7 év alatt, addig, amíg mi használjuk. A bitrix24, úgy követi, mint egy rajongó. Egy csomó dolog felmerül – virtuális gépek indításának képtelensége, API-hiba stb.
És az S3 leeshet – egyszer megtörtént. Ezért a következő sémához jutottunk: néhány évvel ezelőtt még nem voltak komoly közcélú tárgytárolók Oroszországban, és fontolóra vettük a lehetőséget, hogy saját kezűleg csináljunk valamit... Szerencsére nem kezdtük el, mert megtennénk. beleástak abba a szakértelembe, amivel nem rendelkezünk, és valószínűleg elrontanánk. Most a Mail.ru rendelkezik s3-kompatibilis tárhellyel, a Yandex rendelkezik vele, és számos más szolgáltató rendelkezik vele. Végül arra az ötletre jutottunk, hogy egyrészt biztonsági másolatot akarunk készíteni, másrészt lehetőségünk van helyi másolatokkal dolgozni. Az orosz régióban kifejezetten a Mail.ru Hotbox szolgáltatást használjuk, amely API-kompatibilis az s3-mal. Az alkalmazáson belüli kódon nem volt szükségünk jelentős módosításokra, és a következő mechanizmust hajtottuk végre: s3-ban vannak triggerek, amelyek kiváltják az objektumok létrehozását/törlését, az Amazonnak van egy Lambda nevű szolgáltatása - ez egy szerver nélküli kódindítás. amely csak bizonyos triggerek aktiválásakor kerül végrehajtásra.
Nagyon egyszerűen csináltuk: ha a triggerünk elindul, akkor olyan kódot hajtunk végre, amely átmásolja az objektumot a Mail.ru tárhelyre. Az adatok helyi másolataival való munka teljes körű elindításához fordított szinkronizálásra is szükségünk van, hogy az orosz szegmensben lévő ügyfelek a hozzájuk közelebbi tárolóval dolgozhassanak. A Mail hamarosan befejezi a triggereket a tárhelyén - infrastruktúra szinten lesz lehetőség fordított szinkronizálásra, de ezt egyelőre saját kódunk szintjén tesszük. Ha azt látjuk, hogy egy kliens elhelyezett egy fájlt, akkor kódszinten sorba helyezzük az eseményt, feldolgozzuk és fordított replikációt hajtunk végre. Miért rossz: ha valamilyen munkát a termékünkön kívül, azaz valamilyen külső eszközzel végzünk tárgyainkkal, akkor azt nem vesszük figyelembe. Ezért megvárjuk a végét, amikor a triggerek megjelennek a tárolás szintjén, hogy akárhonnan hajtjuk végre a kódot, a hozzánk érkezett objektum a másik irányba másolódik.
Kódszinten mindkét tárolót regisztráljuk minden klienshez: az egyiket a fő, a másikat tartaléknak tekintjük. Ha minden rendben van, akkor a hozzánk közelebbi tárhellyel dolgozunk: vagyis az Amazonon tartózkodó ügyfeleink S3-mal, az Oroszországban dolgozók pedig Hotbox-al dolgoznak. Ha a jelző aktiválódik, akkor át kell kapcsolni a feladatátvételt, és átkapcsoljuk a klienseket egy másik tárolóra. Ezt a jelölőnégyzetet régiónként függetlenül is bejelölhetjük, és oda-vissza kapcsolhatjuk őket. Ezt a gyakorlatban még nem alkalmaztuk, de biztosítottuk ezt a mechanizmust, és úgy gondoljuk, hogy egyszer szükségünk lesz erre a kapcsolóra, és jól fog jönni. Ez már egyszer megtörtént.
Ja, és az Amazon megszökött...
Idén áprilisban van az oroszországi Telegram-blokkolás kezdetének évfordulója. A leginkább érintett szolgáltató, amely ez alá tartozott, az Amazon. És sajnos az orosz cégek, amelyek az egész világnak dolgoztak, többet szenvedtek.
Ha a cég globális és Oroszország nagyon kicsi szegmens neki, 3-5% - hát így vagy úgy, fel lehet áldozni őket.
Ha ez egy tisztán orosz cég - biztos vagyok benne, hogy helyben kell elhelyezkednie -, akkor egyszerűen kényelmes lesz a felhasználók számára, kényelmes, és kevesebb a kockázat.
Mi van akkor, ha ez egy olyan vállalat, amely globálisan működik, és megközelítőleg azonos számú ügyféllel rendelkezik Oroszországból és valahol a világból? A szegmensek összekapcsolhatósága fontos, és így vagy úgy együtt kell működniük egymással.
2018. március végén a Roszkomnadzor levelet küldött a legnagyobb szolgáltatóknak, amelyben azt írták, hogy több millió Amazon IP blokkolását tervezik, hogy blokkolják... a Zello messengert. Ugyanezeknek a szolgáltatóknak köszönhetően sikeresen kiszivárogtatták a levelet mindenkinek, és megértették, hogy az Amazonnal való kapcsolat megszakadhat. Péntek volt, pánikszerűen futottunk a servers.ru kollégáinkhoz, mondván: „Barátaim, több szerverre van szükségünk, amelyek nem Oroszországban, nem az Amazonon, hanem például valahol Amszterdamban lesznek” ahhoz, hogy legalább valamilyen módon telepíthessük a saját VPN-t és a proxyt néhány végponthoz, amelyet semmilyen módon nem tudunk befolyásolni, például ugyanazon s3 végpontjaihoz - nem próbálhatunk meg új szolgáltatást létrehozni és másik ip-t kapni, még mindig el kell jutnunk oda. Alig néhány nap alatt beállítottuk ezeket a szervereket, elindítottuk, és általában felkészültünk a blokkolás kezdetére. Érdekes, hogy az RKN a felhajtást és a pánikot nézve azt mondta: "Nem, most nem fogunk blokkolni semmit." (De ez egészen addig a pillanatig tart, amikor elkezdték blokkolni a Telegramot.) Miután beállítottuk a bypass képességeket, és rájöttünk, hogy a blokkolást nem vezették be, nem kezdtük el az egész ügy rendezését. Igen, minden esetre.
2019-ben pedig még mindig a blokkolás körülményei között élünk. Tegnap este megnéztem: körülbelül egymillió IP továbbra is le van tiltva. Igaz, az Amazont szinte teljesen feloldották, a csúcson elérte a 20 milliós címet... Általánosságban elmondható, hogy a valóság az, hogy lehet, hogy nincs koherencia, jó koherencia. Hirtelen. Lehetséges, hogy technikai okok miatt nem létezik – tüzek, kotrógépek, minden ilyesmi. Illetve, mint láttuk, nem teljesen technikailag. Ezért valaki nagy és nagy, a saját AS-jeivel valószínűleg más módon tudja ezt kezelni - a közvetlen kapcsolat és egyéb dolgok már l2 szinten vannak. De egy egyszerű verzióban, mint a miénk, vagy még kisebb, minden esetre redundáns lehet valahol máshol felállított szerverek szintjén, előre konfigurálva vpn, proxy, azzal a lehetőséggel, hogy ezekben a szegmensekben gyorsan átkapcsolható a konfiguráció rájuk. amelyek kritikusak a kapcsolat szempontjából. Ez nem egyszer jól jött nekünk, amikor elkezdődött az Amazon blokkolása, legrosszabb esetben csak az S3 forgalmat engedtük át rajtuk, de fokozatosan mindez megoldódott.
Hogyan lehet lefoglalni... egy teljes szolgáltatót?
Jelenleg nincs forgatókönyvünk arra az esetre, ha az egész Amazon lezuhanna. Hasonló forgatókönyvünk van Oroszországgal kapcsolatban. Oroszországban egy szolgáltató fogadott minket, akitől több webhelyet választottunk. Egy éve pedig szembesültünk egy problémával: bár két adatközpontról van szó, már a szolgáltató hálózati konfigurációjának szintjén lehetnek olyan problémák, amelyek továbbra is mindkét adatközpontot érintik. És előfordulhat, hogy mindkét oldalon nem leszünk elérhetők. Természetesen ez történt. Végül átgondoltuk a belső építészetet. Nem sokat változott, de Oroszország számára immár két oldalunk van, amelyek nem ugyanattól a szolgáltatótól, hanem két különbözőtől származnak. Ha az egyik nem sikerül, átválthatunk a másikra.
Hipotetikusan az Amazon esetében mérlegeljük egy másik szolgáltató szintjén történő foglalás lehetőségét; talán a Google, esetleg valaki más... De eddig a gyakorlatban azt tapasztaltuk, hogy míg az Amazon egy elérhetőségi zóna szintjén történik baleset, addig egy egész régió szintjén elég ritkák. Ezért elméletileg az az elképzelésünk, hogy tehetünk egy „Amazon nem Amazon” foglalást, de a gyakorlatban ez még nem így van.
Néhány szó az automatizálásról
Mindig szükség van az automatizálásra? Itt érdemes felidézni a Dunning-Kruger effektust. Az „x” tengelyen a megszerzett tudásunk és tapasztalataink, az „y” tengelyen pedig a tetteinkbe vetett bizalom áll. Először semmit sem tudunk, és egyáltalán nem vagyunk biztosak benne. Aztán egy keveset tudunk, és mega magabiztossá válunk - ez az úgynevezett „hülyeség csúcsa”, amelyet jól illusztrál a „demencia és bátorság” kép. Aztán tanultunk egy kicsit, és készen állunk a csatára. Aztán rálépünk néhány megakomoly hibára, és a kétségbeesés völgyében találjuk magunkat, amikor úgy tűnik, tudunk valamit, de valójában nem tudunk sokat. Aztán ahogy tapasztalatokat szerezünk, egyre magabiztosabbak leszünk.
Ez a grafikon nagyon jól leírja az egyes balesetekre való különféle automatikus kapcsolási logikánkat. Elkezdtük - nem tudtuk, hogyan csináljunk semmit, szinte minden munkát kézzel végeztünk. Aztán rájöttünk, hogy mindenhez automatizálást köthetünk, és nyugodtan aludhatunk. És hirtelen mega-rake-re lépünk: téves pozitív üzenet indul, és oda-vissza váltjuk a forgalmat, amikor a jó értelemben ezt nem kellett volna. Következésképpen a replikáció megszakad, vagy valami más – ez a kétségbeesés völgye. És akkor arra a megértésre jutunk, hogy mindent bölcsen kell megközelíteni. Vagyis érdemes az automatizálásra támaszkodni, biztosítva a téves riasztások lehetőségét. De! ha a következmények pusztítóak lehetnek, akkor jobb, ha ezt az ügyeleti műszakra, az ügyeletes mérnökökre bízzuk, akik megbizonyosodnak és figyelemmel kísérik, hogy valóban baleset történt-e, és a szükséges intézkedéseket manuálisan elvégzik...
Következtetés
7 év alatt eljutottunk onnan, hogy amikor valami leesett, pánik-pánik volt, eljutottunk abba, hogy a problémák nem léteznek, csak feladatok vannak, azokat meg kell - és lehet is - megoldani. Amikor egy szolgáltatást épít, nézze meg felülről, mérje fel az összes előforduló kockázatot. Ha azonnal látja őket, akkor előre gondoskodjon a redundanciáról és a hibatűrő infrastruktúra kiépítésének lehetőségéről, mert minden olyan pont, amely meghibásodhat és a szolgáltatás működésképtelenségéhez vezethet, mindenképpen megteszi. És még ha úgy tűnik is, hogy az infrastruktúra egyes elemei biztosan nem fognak meghibásodni – például ugyanaz az s3, akkor is tartsa szem előtt, hogy megtehetik. És legalább elméletben legyen elképzelése arról, mit fog tenni velük, ha valami történik. Legyen kockázatkezelési terved. Amikor azon gondolkodik, hogy mindent automatikusan vagy manuálisan csináljon, mérje fel a kockázatokat: mi lesz, ha az automatika elkezd mindent átkapcsolni - nem vezet ez még rosszabb helyzethez egy balesethez képest? Talán valahol ésszerű kompromisszumot kell kötni az automatizálás alkalmazása és az ügyeletes mérnök reakciója között, aki értékeli a valós képet, és megérti, hogy valamit a helyszínen kell-e kapcsolni, vagy „igen, de nem most”.
Ésszerű kompromisszum a perfekcionizmus és a valódi erőfeszítés, idő és pénz között, amelyet elkölthet arra a programra, amely végül meglesz.
Ez a szöveg Alexander Demidov konferencián készült jelentésének frissített és bővített változata .
Forrás: will.com