Oghje, u serviziu Bitrix24 ùn hà micca centinaie di gigabits di trafficu, nè ùn hà una flotta enormi di servitori (ancu se, sicuru, ci sò uni pochi esistenti). Ma per parechji clienti hè u principale strumentu per travaglià in a cumpagnia; hè una vera applicazione critica per l'affari. Dunque, ùn ci hè manera di cascà. E se u crash hè accadutu, ma u serviziu "recuperatu" cusì rapidamente chì nimu hà nutatu nunda? E cumu hè pussibule implementà u failover senza perde a qualità di u travagliu è u numeru di clienti? Alexander Demidov, direttore di servizii di nuvola in Bitrix24, hà parlatu per u nostru blog nantu à cumu u sistema di riservazione hà evolutu annantu à l'anni 7 di l'esistenza di u pruduttu.
"Avemu lanciatu Bitrix24 cum'è SaaS 7 anni fà. A principal difficultà era probabilmente a seguente: prima ch'ella sia stata lanciata publicamente cum'è SaaS, stu pruduttu esisteva solu in u formatu di una suluzione boxed. I clienti l'hanu compru da noi, l'ospitu in i so servitori, creanu un portale corporativu - una soluzione generale per a cumunicazione di l'impiegati, l'almacenamiento di schedari, a gestione di u travagliu, CRM, questu hè tuttu. È da u 2012, avemu decisu chì vulemu lancià cum'è SaaS, amministràlu noi stessi, assicurendu a tolleranza di difetti è affidabilità. Avemu acquistatu sperienza in u caminu, perchè finu à allora ùn l'avemu micca - eramu solu pruduttori di software, micca fornitori di servizii.
Quandu lanciamu u serviziu, avemu capitu chì u più impurtante hè di assicurà a tolleranza di difetti, affidabilità è a dispunibilità constante di u serviziu, perchè s'è vo avete un situ web ordinariu simplice, una tenda, per esempiu, è cade nantu à voi è si mette quì per una ora, solu soffrenu, perde ordini, perde clienti, ma per u vostru cliente stessu, questu ùn hè micca assai criticu per ellu. Hè stata dispiaciuta, sicuru, ma andò è compru in un altru situ. E s'ellu hè una applicazione nantu à quale tuttu u travagliu in l'impresa, cumunicazioni, decisioni hè ligatu, allura u più impurtante hè di guadagnà a fiducia di l'utilizatori, vale à dì, per ùn lassà micca è micca fallu. Perchè tuttu u travagliu pò piantà se qualcosa dentru ùn funziona micca.
Bitrix.24 cum'è SaaS
Avemu riunitu u primu prototipu un annu prima di u lanciu publicu, in 2011. L'avemu assemblatu in circa una settimana, l'avemu guardatu, girava - era ancu travagliatu. Questu hè, pudete andà in a forma, inserite u nome di u portale quì, un novu portale s'apre, è una basa d'utilizatori seria creata. L'avemu guardatu, evaluatu u pruduttu in principiu, scrapped it, è cuntinuò à raffinà per un annu sanu. Perchè avemu avutu un grande compitu: ùn vuliamu micca fà dui basi di codice diffirenti, ùn vuliamu micca sustene un pruduttu imballatu separatu, solu solu solu nuvola - vulemu fà tuttu in un codice.
Una applicazione web tipica à quellu tempu era un servitore nantu à quale alcuni codice PHP corre, una basa di dati mysql, i schedari sò caricati, i documenti, i ritratti sò posti in u cartulare di carica - bè, tuttu funziona. Alas, hè impussibile di lancià un serviziu web criticamente stabile cù questu. Quì, a cache distribuita ùn hè micca supportata, a replicazione di basa di dati ùn hè micca supportata.
Avemu formulatu i requisiti: questu hè a capacità di esse situatu in diverse lochi, sustene a replicazione, è idealmente esse situatu in diversi centri di dati distribuiti geograficamente. Separate a logica di u produttu è, in fattu, u almacenamentu di dati. Esse capaci di scala dinamicamente secondu a carica, è tollerà a statica in tuttu. Da queste considerazioni, in fattu, emergenu i requisiti per u pruduttu, chì avemu rifinitu annantu à u cursu di l'annu. Duranti stu tempu, in a piattaforma, chì hè stata unificata - per suluzioni boxed, per u nostru propiu serviziu - avemu fattu supportu per quelli cose chì avemu bisognu. Supportu per a replicazione di mysql à u livellu di u pruduttu stessu: vale à dì, u sviluppatore chì scrive u codice ùn pensa micca à cumu e so dumande seranu distribuite, usa a nostra api, è sapemu cumu distribuisce currettamente e dumande di scrittura è lettura trà i maestri. e schiavi.
Avemu fattu un supportu à u livellu di u produttu per diversi almacenamenti di oggetti in nuvola: google storage, amazon s3, più supportu per open stack swift. Per quessa, questu era cunvenutu sia per noi cum'è serviziu sia per i sviluppatori chì travaglianu cù una soluzione imballata: s'ellu usanu solu a nostra API per u travagliu, ùn pensanu micca à induve u schedariu serà finalmente salvatu, in u locu in u sistema di fugliale o in u almacenamentu di u schedariu d'ughjettu.
In u risultatu, avemu immediatamente decisu chì avemu riservà à u livellu di tuttu u centru di dati. In u 2012, avemu lanciatu interamente in Amazon AWS perchè avemu digià avutu una sperienza cù sta piattaforma - u nostru situ web hè stata ospitata quì. Semu stati attratti da u fattu chì in ogni regione Amazon hà parechje zoni di dispunibilità - in fattu, (in a so terminologia) parechji centri di dati chì sò più o menu indipindenti di l'altri è permettenu di riservà à u livellu di un centru di dati sanu: s'ellu fallisce di colpu, e basa di dati sò replicate master-master, i servitori di l'applicazioni web sò backed up, è i dati statici sò spustati in u s3 object storage. A carica hè equilibrata - à quellu tempu da Amazon elb, ma un pocu dopu avemu ghjuntu à i nostri propri balancers di carica, perchè avemu bisognu di una logica più cumplessa.
Ciò chì vulianu hè ciò chì anu avutu ...
Tutte e cose basi chì vulemu assicurà - a tolleranza di difetti di i servitori stessi, applicazioni web, basa di dati - tuttu hà travagliatu bè. U scenariu più simplice: se una di e nostre applicazioni web falla, allora tuttu hè simplice - sò disattivati da l'equilibriu.
U balancer (à quellu tempu era l'elb di Amazon) hà marcatu e macchine chì eranu fora di ordine cum'è malsane è disattivava a distribuzione di carica nantu à elli. L'autoscaling d'Amazon hà travagliatu: quandu a carica cresce, novi machini sò stati aghjuntu à u gruppu di autoscaling, a carica hè stata distribuita à novi machini - tuttu era bè. Cù i nostri balancers, a logica hè apprussimatamente a listessa: se qualcosa succede à u servitore di l'applicazioni, sguassate e dumande da ellu, scaccià queste macchine, cuminciamu novi è cuntinuemu à travaglià. U schema hà cambiatu un pocu annantu à l'anni, ma cuntinueghja à travaglià: hè simplice, cumprendi, è ùn ci hè micca difficultà cun ellu.
Travagliemu in u mondu sanu, i picchi di carica di i clienti sò cumplettamente sfarente, è, in modu amichevule, duvemu esse capace di fà un certu travagliu di serviziu nantu à qualsiasi cumpunenti di u nostru sistema in ogni mumentu - inosservatu da i clienti. Dunque, avemu l'uppurtunità di disattivà a basa di dati da u funziunamentu, ridistribuendu a carica à un secondu centru di dati.
Cumu funziona tuttu? - Cambiamu u trafficu à un centru di dati di travagliu - se ci hè un accidentu in u centru di dati, allora cumpletamente, se questu hè u nostru travagliu pianificatu cù una basa di dati, allora cambiemu una parte di u trafficu chì serve questi clienti à un secondu centru di dati, suspendendu a replicazione. Se novi machini sò necessarii per l'applicazioni web perchè a carica nantu à u sicondu centru di dati hà aumentatu, cumincianu automaticamente. Finitemu u travagliu, a replicazione hè restaurata, è vultemu a carica sana. Se avemu bisognu di specchià qualchì travagliu in a seconda DC, per esempiu, installate l'aghjurnamenti di u sistema o cambià i paràmetri in a seconda basa di dati, allora, in generale, ripetemu a stessa cosa, solu in l'altra direzione. È s'ellu hè un accidentu, allora facemu tuttu trivially: usemu u mecanismu di gestione di l'avvenimenti in u sistema di surviglianza. Se parechji cuntrolli sò attivati è u statutu passa à criticu, allora eseguimu stu handler, un handler chì pò eseguisce questa o quella logica. Per ogni basa di dati, specificamu quale servitore hè u failover per ellu, è induve u trafficu deve esse cambiatu s'ellu ùn hè micca dispunibule. Stòricamente, usemu nagios o alcuni di i so furchetti in una forma o l'altru. In principiu, meccanismi simili esistenu in quasi ogni sistema di monitoraghju; ùn avemu micca aduprà nunda di più cumplessu, ma forse un ghjornu avemu da fà. Avà u monitoraghju hè attivatu da indisponibilità è hà a capacità di cambià qualcosa.
Avemu riservatu tuttu ?
Avemu parechji clienti da l'USA, assai clienti da l'Europa, assai clienti chì sò più vicinu à l'Est - Giappone, Singapore è cusì. Di sicuru, una grande parte di i clienti sò in Russia. Questu hè, u travagliu ùn hè micca in una regione. L'utilizatori volenu una risposta rapida, ci sò esigenze per rispettà diverse liggi lucali, è in ogni regione riservemu dui centri di dati, in più ci sò qualchi servizii supplementari, chì, di novu, sò cunvenuti per mette in una regione - per i clienti chì sò in sta regione travaglia. I gestori REST, i servitori d'autorizazione, sò menu critichi per u funziunamentu di u cliente cum'è un sanu, pudete passà per elli cun un picculu ritardu accettabile, ma ùn vulete micca reinventà a rota nantu à cumu monitorà è ciò chì fà. cun elli. Per quessa, circhemu d'utilizà solu suluzione esistenti à u massimu, piuttostu chè di sviluppà una certa cumpetenza in prudutti supplementari. È in un locu trivially usemu u cambiamentu à u livellu DNS, è determinamu a vivacità di u serviziu da u stessu DNS. Amazon hà un serviziu Route 53, ma ùn hè micca solu un DNS in quale pudete fà entrate è questu hè - hè assai più flexible è cunvene. Per mezu di ellu pudete custruisce servizii geo-distribuiti cù geolocazioni, quandu l'utilizate per determinà induve u cliente hè vinutu è dà certi registri - cù u so aiutu pudete custruisce architetture di failover. I stessi cuntrolli di salute sò cunfigurati in a Route 53 stessu, stabilisce l'endpoints chì sò monitorati, stabilisce metriche, stabilisce quale protokolli per determinà a "liveness" di u serviziu - tcp, http, https; stabilisce a freccia di cuntrolli chì determinanu se u serviziu hè vivu o micca. È in u DNS stessu specificate ciò chì serà primariu, ciò chì serà secundariu, induve cambià se u cuntrollu di salute hè attivatu in a strada 53. Tuttu chistu pò esse fattu cù qualchi altri strumenti, ma perchè hè cunvenutu - avemu stabilitu. su una volta è poi ùn pensate micca à tuttu cumu facemu i cuntrolli, cumu cambiamu: tuttu funziona da sè stessu.
U primu "ma": cumu è cù chì riservà a strada 53 stessu ? Quale sà, è s'ellu ci succede qualcosa ? Fortunatamente, ùn avemu mai pisatu nantu à questu rake, ma dinò, aghju avutu una storia prima di perchè avemu pensatu chì avemu sempre bisognu di fà una riservazione. Quì avemu stallatu paglia per noi in anticipu. Diversi volte à ghjornu facemu un scaricamentu cumpletu di tutte e zone chì avemu in a strada 53. L'API d'Amazon vi permette di mandà facilmente in JSON, è avemu parechji servitori di salvezza induve u cunvertemu, u caricate in forma di cunfigurazione è avè, in generale, una cunfigurazione di salvezza. Se qualcosa succede, pudemu implementà rapidamente manualmente senza perde i dati di paràmetri DNS.
Secondu "ma": Ciò chì in sta stampa ùn hè ancu statu riservatu ? L'équilibreur lui-même ! A nostra distribuzione di i clienti per regione hè fatta assai simplice. Avemu i duminii bitrix24.ru, bitrix24.com, .de - avà ci sò 13 sfarenti, chì operanu in una varietà di zoni. Simu ghjunti à i seguenti: ogni regione hà i so equilibri. Questu rende più còmuda di distribuisce in e regioni, secondu induve hè a carica di punta nantu à a reta. S'ellu hè un fallimentu à u livellu di un balancer unicu, allora hè simplicemente pigliatu da u serviziu è sguassatu da u dns. Se ci hè qualchì prublema cù un gruppu di balancers, allora sò salvati in altri siti, è u cambiamentu trà elli hè fattu cù a listessa strada53, perchè per via di u TTL curtu, u cambiamentu hè in un massimu di 2, 3, 5 minuti. .
Terzu "ma": Chì ùn hè ancu riservatu ? S3, currettu. Quandu avemu piazzatu i schedari chì avemu guardatu per l'utilizatori in s3, avemu sinceramente cridutu chì era armatura-piercing è ùn ci era micca bisognu di riservà qualcosa quì. Ma a storia mostra chì e cose passanu di manera diversa. In generale, Amazon descrive S3 cum'è un serviziu fundamentale, perchè Amazon stessu usa S3 per almacenà l'imaghjini di a macchina, i cunfigurazioni, l'imaghjini AMI, i snapshots ... E se s3 crashes, cum'è accadutu una volta durante questi 7 anni, finu à chì avemu usatu. bitrix24, u seguita cum'è un fan Ci hè una mansa di cose chì venenu - incapacità di inizià e macchine virtuali, fallimentu di l'API, è cusì.
È S3 pò falà - hè accadutu una volta. Dunque, avemu ghjuntu à u schema seguente: uni pochi d'anni fà ùn ci era micca strutture di almacenamentu di l'ughjettu publicu seriu in Russia, è avemu cunsideratu l'opzione di fà qualcosa di u nostru propiu ... Fortunatamente, ùn avemu micca cuminciatu à fà questu, perchè avemu avutu. anu scavatu in l'expertise chì ùn avemu micca, è probabilmente sguassate. Avà Mail.ru hà almacenamentu s3-compatibile, Yandex hà, è una quantità di altri fornituri l'anu. Avemu eventualmente ghjuntu à l'idea chì vulemu avè, prima, copia di salvezza, è secondu, a capacità di travaglià cù copie lucali. Per a regione russa specificamente, usemu u serviziu Mail.ru Hotbox, chì hè API compatible cù s3. Ùn avemu micca bisognu di alcuna mudificazione maiò à u codice in l'applicazione, è avemu fattu u mekanismu seguente: in s3 ci sò triggers chì attivanu a creazione / eliminazione di l'uggetti, Amazon hà un serviziu chjamatu Lambda - questu hè un lanciu di codice senza servitore. chì serà eseguitu ghjustu quandu certi triggers sò attivati.
L'avemu fattu assai simplice: se u nostru attivatore spara, eseguimu codice chì copià l'ughjettu à l'almacenamiento Mail.ru. Per lancià cumplettamente u travagliu cù e copie lucali di dati, avemu ancu bisognu di a sincronizazione inversa per chì i clienti chì si trovanu in u segmentu russu pò travaglià cù l'almacenamiento chì hè più vicinu à elli. U mail hè per compie i triggers in u so almacenamentu - serà pussibule di realizà a sincronizazione inversa à u livellu di l'infrastruttura, ma per avà facemu questu à u livellu di u nostru codice. Se vedemu chì un cliente hà publicatu un schedariu, allora à u nivellu di codice pusemu l'avvenimentu in una fila, u processà è fà a replicazione inversa. Perchè hè male: se facemu qualchì travagliu cù i nostri ogetti fora di u nostru pruduttu, vale à dì, per certi mezi esterni, ùn avemu micca pigliatu in contu. Dunque, aspittemu finu à a fine, quandu i triggers appariscenu à u livellu di almacenamento, perchè ùn importa micca induve eseguisce u codice, l'ughjettu chì hè ghjuntu à noi hè copiatu in l'altra direzione.
À u livellu di codice, registremu i dui almacenamenti per ogni cliente: unu hè cunsideratu u principale, l'altru hè cunsideratu una copia di salvezza. Se tuttu hè bè, avemu travagliatu cù l'almacenamiento chì hè più vicinu à noi: questu, i nostri clienti chì sò in Amazon, travaglianu cù S3, è quelli chì travaglianu in Russia, travaglianu cù Hotbox. Se a bandiera hè attivata, allora u failover deve esse cunnessu, è cambiemu i clienti à un altru almacenamentu. Pudemu cuntrollà sta casella indipindentamente per regione è pudemu cambià avanti è avanti. Ùn avemu micca usatu questu in pratica ancu, ma avemu furnitu stu mecanismu è pensemu chì un ghjornu averemu bisognu di questu cambiatu assai è vene in utile. Questu hè digià accadutu una volta.
Oh, è Amazon scappò...
Questu Aprile marca l'anniversariu di u principiu di u bloccu di Telegram in Russia. U fornitore più affettatu chì hè cascatu sottu à questu hè Amazon. E, sfurtunatamenti, l'imprese russi chì anu travagliatu per u mondu sanu anu patitu più.
Se a cumpagnia hè glubale è a Russia hè un segmentu assai chjucu per questu, 3-5% - bè, in una manera o l'altru, pudete sacrificà.
S'ellu hè una cumpagnia puramente russa - sò sicuru chì deve esse situatu in u locu - bè, serà simplicemente cunvene per l'utilizatori stessi, cunfortu, è ci saranu menu risichi.
E s'ellu hè una sucietà chì opera in u mondu è hà apprussimatamente uguali numeri di clienti da Russia è in qualchì parte di u mondu? A cunnessione di i segmenti hè impurtante, è anu da travaglià cù l'altri in una manera o l'altra.
À a fine di marzu 2018, Roskomnadzor hà mandatu una lettera à i più grandi operatori chì dicenu chì pensanu à bluccà parechji milioni di IP Amazon per bluccà ... u messenger Zello. Grazie à questi stessi fornituri - anu filtratu cù successu a lettera à tutti, è ci era una cunniscenza chì a cunnessione cù Amazon puderia fallu. Era u venneri, avemu in panicu à i nostri culleghi da servers.ru, dicendu: "Amici, avemu bisognu di parechji servitori chì ùn saranu micca in Russia, micca in Amazon, ma, per esempiu, in un locu in Amsterdam", in ordine. per pudè, almenu in qualchì modu, installà a nostra propria VPN è proxy quì per certi punti finali chì ùn pudemu micca influenzà in alcuna manera, per esempiu endponts di u stessu s3 - ùn pudemu micca pruvà à elevà un novu serviziu è uttene un ip diversu, avemu sempre bisognu à ghjunghje. In pocu di ghjorni, avemu stallatu questi servitori, l'avemu in funziunamentu, è, in generale, preparatu per u mumentu chì u bloccu principia. Hè curiosu chì RKN, fighjendu u scontru è u panicu, hà dettu: "No, ùn avemu micca bluccà nunda avà". (Ma questu hè esattamente finu à u mumentu chì Telegram hà cuminciatu à esse bluccatu.) Dopu avè stabilitu e capacità di bypass è rializendu chì u bloccu ùn era micca statu introduttu, noi, però, ùn avemu micca cuminciatu à risolve tutta a materia. Iè, solu in casu.
È in 2019, campemu sempre in cundizioni di bloccu. Aghju guardatu a notte scorsa: circa un milione di IP cuntinueghjanu à esse bluccati. True, Amazon hè stata guasi cumplettamente sbloccata, à u so piccu hà ghjuntu à 20 milioni d'indirizzi... In generale, a realità hè chì ùn ci pò micca esse cuerenza, bona cuerenza. Di colpu. Pò esse micca per ragioni tecniche - incendi, excavators, tuttu ciò. O, cum'è avemu vistu, micca cumpletamente tecnicu. Dunque, qualcunu grande è grande, cù u so propiu AS, pò prubabilmente gestisce questu in altri modi - cunnessione diretta è altre cose sò digià à u livellu l2. Ma in una versione simplice, cum'è a nostra o ancu più chjuca, pudete, solu in casu, avè redundanza à u livellu di i servitori alzati in un altru locu, cunfigurati in anticipu vpn, proxy, cù a capacità di cambià rapidamente a cunfigurazione in quelli segmenti. chì sò critichi per a vostra cunnessione. Questu hè stata utile per noi più di una volta, quandu u bluccatu di Amazon hà iniziatu; in u peghju scenariu, avemu permessu solu u trafficu S3 per elli, ma gradualmente tuttu questu hè statu risoltu.
Cumu riservà... un fornitore sanu ?
Avà ùn avemu micca un scenariu in casu chì tutta l'Amazonia cade. Avemu un scenariu simili per a Russia. In Russia, eramu ospitu da un fornitore, da quale avemu sceltu per avè parechji siti. È un annu fà avemu affruntatu un prublema: ancu s'ellu si tratta di dui centri di dati, pò esse prublemi digià à u livellu di a cunfigurazione di a rete di u fornitore chì anu sempre affettatu i dui centri di dati. È pudemu finisce micca dispunibile in i dui siti. Di sicuru hè ciò chì hè accadutu. Avemu finitu per cunsiderà l'architettura in l'internu. Ùn hè micca cambiatu assai, ma per a Russia avemu avà dui siti, chì ùn sò micca da u stessu fornitore, ma da dui sfarenti. Se unu falla, pudemu cambià à l'altru.
Ipoteticamente, per Amazon avemu cunsideratu a pussibilità di riservazione à u livellu di un altru fornitore; forsi Google, forsi qualcunu altru... Ma finu à avà avemu osservatu in pratica chì mentre Amazon hà accidenti à u livellu di una zona di dispunibilità, l'accidenti à u livellu di una regione sana sò abbastanza rari. Dunque, in teoria, avemu l'idea chì pudemu fà una riservazione "Amazon ùn hè micca Amazon", ma in pratica ùn hè micca ancu u casu.
Uni pochi parolle nantu à l'automatizazione
L'automatizazione hè sempre necessaria? Quì hè apprupriatu à ricurdà l'effettu Dunning-Kruger. Nantu à l'assi "x" hè a nostra cunniscenza è l'esperienza chì avemu guadagnatu, è nantu à l'assi "y" hè a fiducia in i nostri azzioni. À u principiu ùn sapemu nunda è ùn simu micca sicuru. Allora sapemu un pocu è diventate mega-confidenti - questu hè u chjamatu "piccu di stupidità", ben illustratu da a stampa "demenza è curagiu". Allora avemu amparatu un pocu è simu pronti per andà in battaglia. Allora andemu nantu à qualchì sbagliu mega-seriu è truvamu in una valle di dispirazioni, quandu paremu sapè qualcosa, ma in fattu ùn sapemu micca assai. Allora, cum'è acquistemu sperienza, diventemu più cunfidenti.
A nostra logica nantu à i vari cambiamenti automatichi à certi accidenti hè assai ben descritta da stu graficu. Avemu principiatu - ùn sapemu micca fà nunda, quasi tuttu u travagliu era fattu da a manu. Allora avemu capitu chì pudemu aghjunghje l'automatizazione à tuttu è, cum'è, dorme tranquillamente. È di colpu avemu un passu nantu à un mega-rake: un falsu pusitivu hè attivatu, è cambiamu u trafficu avanti è avanti quandu, in una bona manera, ùn duvemu micca fà questu. In cunseguenza, a replicazione si rompe o qualcosa d'altru - questu hè a stessa valle di a disperazione. È tandu ghjunghjemu à a cunniscenza chì duvemu avvicinà tuttu cun prudenza. Questu hè, hè sensu di cunfidassi di l'automatizazione, chì furnisce a pussibilità di falsi alarmi. Ma! se e cunsequenze ponu esse devastanti, allora hè megliu lascià à u turnu di u duvere, à l'ingegneri di turnu, chì s'assicuraranu è monitoranu chì ci hè veramente un accidente, è effettueranu l'azzioni necessarii manualmente ...
cunchiusioni
In u corsu di 7 anni, andemu da u fattu chì quandu qualcosa hè cascatu, ci era u panicu-panicu, à a cunniscenza chì i prublemi ùn esistenu micca, ci sò solu compiti, devenu - è ponu esse risolti. Quandu site custruendu un serviziu, fighjate da sopra, valutate tutti i risichi chì ponu accade. Se li vede subitu, allora furnisce a redundancy in anticipu è a pussibilità di custruisce una infrastruttura tolerante à i difetti, perchè ogni puntu chì pò fallu è guidà à l'inoperabilità di u serviziu certamenti farà cusì. E ancu s'ellu vi pare chì certi elementi di l'infrastruttura certamenti ùn falla micca - cum'è u stessu s3, sempre tenite in mente chì ponu. È almenu in teoria, avete un'idea di ciò chì fate cun elli se qualcosa succede. Avè un pianu di gestione di risicu. Quandu pensate à fà tuttu in autumàticu o manualmente, valutate i risichi: chì succederà se l'automatizazione cumencia à cambià tuttu - questu ùn porta micca à una situazione ancu peghju paragunatu à un accidente? Forse in un locu hè necessariu di utilizà un cumprumissu ragiunate trà l'usu di l'automatizazione è a reazione di l'ingegnere di turnu, chì valuterà a vera stampa è capisce s'ellu ci vole à cambià qualcosa in u locu o "sì, ma micca avà".
Un cumprumissu raghjone trà u perfeccionismu è u sforzu veru, u tempu, i soldi chì pudete gastru nantu à u schema chì avete eventualmente.
Stu testu hè una versione aghjurnata è ampliata di u rapportu di Alexander Demidov à a cunferenza .
Source: www.habr.com