{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"\u00abBitrix24\u00bb: \u00abUn rapido ripristino non \u00e8 considerato una caduta\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Al giorno d'oggi, il servizio \u00abBitrix24\u00bb non dispone di centinaia di gigabit di traffico, n\u00e9 di un enorme parco server (anche se ce ne sono di esistenti, naturalmente). Ma per molti clienti \u00e8 lo strumento principale di lavoro nell'azienda, \u00e8 una vera applicazione business-critical. Pertanto, non ci si pu\u00f2 permettere di cadere. E se una caduta si \u00e8 comunque verificata, ma il servizio si \u00e8 \u00abrialzato\u00bb cos\u00ec rapidamente che nessuno se n'\u00e8 accorto? E come si riesce a implementare il failover senza perdita di qualit\u00e0 del lavoro e numero di clienti? Alexander Demidov, direttore della direzione dei servizi cloud di \u00abBitrix24\u00bb, ha parlato per il nostro blog di come nel corso di 7 anni di esistenza del prodotto sia evoluto il sistema di riserva.<\/p>\n

\"\u00abBitrix24\u00bb:
\n<\/a><\/noindex>
\n\u00abIn formato SaaS abbiamo lanciato 'Bitrix24' 7 anni fa. La principale difficolt\u00e0, probabilmente, era la seguente: prima del lancio pubblico in formato SaaS, questo prodotto esisteva semplicemente come soluzione confezionata. I clienti lo acquistavano da noi, lo installavano sui propri server, creavano un portale aziendale - una soluzione comune per la comunicazione tra i dipendenti, la conservazione dei file, la gestione dei compiti, CRM, insomma, tutto questo. E nel 2012 abbiamo deciso di voler lanciare questo come SaaS, amministrando autonomamente, garantendo tolleranza ai guasti e affidabilit\u00e0. Durante il processo abbiamo accumulato esperienza, perch\u00e9 fino a quel momento non ne avevamo - eravamo solo produttori di software, non fornitori di servizi. <\/p>\n

Lanciando il servizio, sapevamo che la cosa pi\u00f9 importante era garantire tolleranza ai guasti, affidabilit\u00e0 e disponibilit\u00e0 costante del servizio, perch\u00e9 se hai un semplice sito web, un negozio, ad esempio, e un giorno smette di funzionare per un'ora - ne soffri solo tu, perdi ordini, perdi clienti, ma per il tuo cliente non \u00e8 molto critico. Certo, sar\u00e0 deluso, ma andr\u00e0 a comprare su un altro sito. Ma se si tratta di un'applicazione di cui dipende tutto il lavoro all'interno dell'azienda, comunicazioni e decisioni, la cosa pi\u00f9 importante \u00e8 guadagnare la fiducia degli utenti, cio\u00e8 non deluderli e non andare in crash. Perch\u00e9 tutto il lavoro potrebbe fermarsi se qualcosa all'interno non funziona.<\/p>\n

Bitrix24 come SaaS<\/h4>\n

\nIl primo prototipo lo abbiamo assemblato un anno prima del lancio pubblico, nel 2011. \u00c8 stato assemblato in circa una settimana, lo abbiamo esaminato, girato \u2014 funzionava anche. Cio\u00e8, era possibile accedere al modulo, inserire l\u00ec il nome del portale, si apriva un nuovo portale, veniva creata una base di utenti. Lo abbiamo osservato, valutato sostanzialmente il prodotto, chiuso, e abbiamo continuato a lavorarci per un intero anno. Perch\u00e9 avevamo un grande compito: non volevamo creare due basi di codice differenti, non volevamo supportare separatamente un prodotto confezionato e soluzioni cloud, \u2014 volevamo fare tutto questo all'interno di un unico codice. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nUn'app web tipica all'epoca era un server su cui girava un qualche codice php, un database mysql, i file venivano caricati, i documenti, le immagini venivano messi nella cartella upload \u2013 e tutto questo funzionava. Purtroppo, non \u00e8 possibile avviare un servizio web critico su questo. Non viene supportata la cache distribuita, la replica dei database non \u00e8 supportata. <\/p>\n

Abbiamo formulato i requisiti: la capacit\u00e0 di essere ospitati in diverse localit\u00e0, supportare la replica, idealmente essere ospitati in diversi data center geograficamente distribuiti. Separare la logica del prodotto e, appunto, lo storage dei dati. Essere in grado di scalare dinamicamente in base al carico, spostare completamente la parte statica. Da queste considerazioni si sono formati, sostanzialmente, i requisiti per il prodotto, che abbiamo elaborato nel corso dell'anno. In questo periodo, nella piattaforma, che \u00e8 diventata unitaria \u2014 per le soluzioni confezionate, per il nostro servizio \u2014 abbiamo implementato il supporto per le cose di cui avevamo bisogno. Supporto per la replicazione mysql a livello di prodotto: cio\u00e8, lo sviluppatore che scrive codice \u2014 non si preoccupa di come saranno distribuite le sue richieste, utilizza la nostra api, e noi sappiamo distribuire correttamente le richieste di scrittura e lettura tra master e slave. <\/p>\n

Abbiamo creato supporto a livello di prodotto per vari storage oggetti nel cloud: google storage, amazon s3, \u2014 inoltre, supporto open stack swift. Pertanto, \u00e8 stato conveniente sia per noi come servizio, sia per gli sviluppatori che lavorano con la soluzione confezionata: se utilizzano semplicemente la nostra api per lavorare, non si preoccupano di dove alla fine verr\u00e0 salvato il file, se localmente nel file system o se finir\u00e0 nello storage di oggetti.<\/p>\n

Alla fine abbiamo subito deciso che ci saremmo riservati a livello di intero data center. Nel 2012 ci siamo lanciati completamente su Amazon AWS, perch\u00e9 avevamo gi\u00e0 esperienza con questa piattaforma, essendo il nostro sito gi\u00e0 ospitato l\u00ec. Ci attraeva il fatto che in ogni regione di Amazon ci sono pi\u00f9 zone di disponibilit\u00e0 \u2014 in sostanza, (nella loro terminologia) diversi data center che sono pi\u00f9 o meno indipendenti l'uno dall'altro e ci permettono di riservarci a livello di intero data center: se uno di essi dovesse guastarsi, i database si replicano in modalit\u00e0 master-master, i server delle applicazioni web sono riservati e la staticit\u00e0 \u00e8 trasferita nell'archiviazione a oggetti s3. Il carico \u00e8 bilanciato \u2014 in quel momento da elb di Amazon, ma poco dopo siamo passati ai nostri bilanciatore, perch\u00e9 avevamo bisogno di una logica pi\u00f9 complessa. <\/p>\n

Quel che volevamo, l'abbiamo ottenuto...<\/h4>\n

\nTutte le cose di base che volevamo garantire \u2014 l'affidabilit\u00e0 dei server stessi, delle applicazioni web, dei database \u2014 funzionavano bene. Lo scenario pi\u00f9 semplice: se una delle nostre applicazioni web smette di funzionare, qui tutto \u00e8 semplice \u2014 vengono esclusi dal bilanciamento. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nLe macchine guaste venivano contrassegnate come non funzionanti dal bilanciatore (all'epoca era l'elb di Amazon), il quale smetteva di distribuire il carico su di esse. Funzionava l'auto-scalaggio di Amazon: quando il carico aumentava, nuove macchine venivano aggiunte al gruppo di auto-scalaggio, il carico veniva distribuito su nuove macchine \u2014 tutto andava bene. Con i nostri bilanciatore la logica \u00e8 approssimativamente la stessa: se succede qualcosa a un server delle applicazioni, rimuoviamo le richieste, scartiamo queste macchine, avviamo di nuove e continuiamo a lavorare. La \u0441\u0445\u0435\u043c\u0430 \u00e8 cambiata un po' nel corso degli anni, ma continua a funzionare: \u00e8 semplice, comprensibile e non ci sono complessit\u00e0. <\/p>\n

Lavoriamo in tutto il mondo, i picchi di carico dei clienti sono assolutamente diversi, e, in pratica, dovremmo avere la possibilit\u00e0 di effettuare alcuni lavori di manutenzione su qualsiasi componente del nostro sistema in qualsiasi momento \u2013 senza che i clienti se ne accorgano. Pertanto, abbiamo la possibilit\u00e0 di disattivare il database, redistribuendo il carico su un secondo data center. <\/p>\n

Come funziona tutto questo? \u2014 Reindirizziamo il traffico su un data center funzionante: se si tratta di un incidente nel data center, lo facciamo completamente. Se sono lavori pianificati su un particolare database, reindirizziamo solo una parte del traffico che serve quei clienti su un secondo data center, interrompendo la replicazione. Se servono nuove macchine per le applicazioni web, poich\u00e9 il carico \u00e8 aumentato nel secondo data center, queste si avviano automaticamente. Concludiamo i lavori, ripristiniamo la replicazione e riportiamo tutto il carico indietro. Se dobbiamo eseguire dei lavori speculari nel secondo DC, ad esempio installare aggiornamenti di sistema o modificare le impostazioni nel secondo database, in sostanza ripetiamo tutto lo stesso, ma al contrario. In caso di incidente, seguiamo una procedura semplice: nel sistema di monitoraggio utilizziamo il meccanismo degli event-handler. Se pi\u00f9 controlli vengono attivati e lo stato passa a critico, avviamo questo handler, un elaboratore che pu\u00f2 eseguire una logica specifica. Abbiamo definito per ogni database quale server \u00e8 il suo failover e dove reindirizzare il traffico in caso di inaccessibilit\u00e0. Storicamente, utilizziamo nagios o alcuni dei suoi fork. In genere, meccanismi simili sono presenti praticamente in ogni sistema di monitoraggio; finora non utilizziamo nulla di pi\u00f9 complesso, ma potrebbe succedere in futuro. Attualmente, il monitoraggio attiva in caso di inaccessibilit\u00e0 e ha la possibilit\u00e0 di reindirizzare il traffico.<\/p>\n

Abbiamo riservato tutto?<\/h4>\n

\nAbbiamo molti clienti negli Stati Uniti, molti clienti in Europa e molti clienti pi\u00f9 vicini all'Oriente, come Giappone, Singapore e cos\u00ec via. Naturalmente, una parte significativa dei clienti si trova in Russia. Questo significa che lavoriamo in pi\u00f9 di una regione. Gli utenti desiderano risposte rapide, ci sono requisiti per il rispetto di diverse leggi locali e all'interno di ogni regione riserviamo due data center, oltre ad avere alcuni servizi aggiuntivi che \u00e8 comodo collocare all'interno di una sola regione per i clienti che operano in quella regione. I gestori REST e i server di autorizzazione sono meno critici per il funzionamento generale del cliente; si pu\u00f2 passare a loro con un certo ritardo accettabile, ma non vogliamo reinventare la ruota, monitorandoli e decidendo cosa fare con loro. Pertanto, cerchiamo di usare il pi\u00f9 possibile soluzioni gi\u00e0 esistenti, piuttosto che sviluppare competenze interne su prodotti aggiuntivi. In alcune situazioni, utilizziamo semplicemente il passaggio a livello DNS, e la disponibilit\u00e0 del servizio viene definita dallo stesso DNS. In Amazon c'\u00e8 il servizio Route 53, ma non \u00e8 solo un DNS in cui \u00e8 possibile inserire record e basta; \u00e8 molto pi\u00f9 flessibile e conveniente. Attraverso di esso, \u00e8 possibile costruire servizi geo-distribuiti con geolocalizzazioni, quando si determina da dove proviene il cliente e si offrono i vari record; \u00e8 possibile costruire architetture di failover. Gli stessi health-checks sono impostati all'interno di Route 53, si definisce l'endpoint da monitorare, le metriche da utilizzare e i protocolli per determinare se il servizio \u00e8 \u201cvivo\u201d o meno: tcp, http, https; si definisce la periodicit\u00e0 dei controlli per stabilire se il servizio \u00e8 attivo o meno. E nel DNS si specifica quale sar\u00e0 il primary, quale sar\u00e0 il secondary e dove passare se il health-check all'interno di Route 53 si attiva. Tutto questo pu\u00f2 essere realizzato con altri strumenti, ma la comodit\u00e0 \u00e8 che lo si configura una volta e poi non si deve pi\u00f9 pensare a come vengono eseguiti i controlli o come avviene il passaggio: tutto funziona in automatico.<\/p>\n

Il primo \"ma\"<\/b>: come possiamo e con cosa riservare il route 53? Chiss\u00e0, potrebbe succedere qualcosa. Fortunatamente, non ci \u00e8 mai capitato, ma ho una storia che spiega perch\u00e9 riteniamo sia necessario riservare. Qui stiamo preparando il terreno in anticipo. Pi\u00f9 volte al giorno facciamo un'esportazione completa di tutte le zone che abbiamo in route 53. L'API di Amazon consente di restituirle facilmente in JSON e abbiamo attivato diversi server di riserva, dove le convertiamo, esportiamo come configurazioni e abbiamo, in sostanza, una configurazione di backup. In caso di necessit\u00e0, possiamo rapidamente ripristinarla manualmente senza perdere le impostazioni DNS.<\/p>\n

Il secondo \"ma\"<\/b>: cosa non \u00e8 ancora riservato in questo scenario? Il bilanciatore stesso! La nostra distribuzione dei clienti per regioni \u00e8 molto semplice. Abbiamo i domini bitrix24.ru, bitrix24.com, .de \u2014 ora sono circa 13 diversi, che operano in varie zone. Siamo giunti alla seguente conclusione: in ogni regione ci sono i propri bilanciatori. \u00c8 pi\u00f9 conveniente distribuirli per regioni, a seconda di dove si trova il picco di carico di rete. Se c'\u00e8 un guasto a livello di un singolo bilanciatore, lo si esclude semplicemente dal funzionamento e lo si rimuove dal DNS. Se si verifica un problema con un gruppo di bilanciatori, vengono riservati su altre piattaforme e il passaggio tra di essi avviene tramite route53, poich\u00e9 grazie a un TTL breve il cambio avviene al massimo in 2, 3, 5 minuti. <\/p>\n

Il terzo \"ma\"<\/b>: cosa non \u00e8 ancora riservato? S3, giusto. Noi, mentre archiviavamo i file che conserviamo per gli utenti su S3, eravamo convinti che fosse infallibile e che non ci fosse bisogno di riservare nulla. Ma la storia dimostra che le cose vanno diversamente. In generale, Amazon descrive S3 come un servizio fondamentale, perch\u00e9 Amazon stesso utilizza S3 per memorizzare le immagini delle macchine, le configurazioni, le immagini AMI, gli snapshot\u2026 E se S3 si guasta, come \u00e8 successo una volta in questi 7 anni in cui abbiamo utilizzato bitrix24, porta con s\u00e9 una moltitudine di problemi: l\u2019indisponibilit\u00e0 dell\u2019avvio delle macchine virtuali, guasti nel funzionamento dell'API e cos\u00ec via. <\/p>\n

E S3 pu\u00f2 cadere \u2014 \u00e8 successo una volta. Pertanto, siamo giunti al seguente schema: qualche anno fa, in Russia non c'erano pubblici storage oggettivi seri, e stavamo considerando l'idea di creare qualcosa di nostro... Per fortuna non abbiamo iniziato a farlo, perch\u00e9 ci saremmo impantanati in quella expertise che non possediamo, e probabilmente avremmo sbagliato. Ora ci sono storage compatibili con s3 di Mail.ru, di Yandex e di altri fornitori. Alla fine, siamo giunti alla conclusione che vogliamo avere, in primo luogo, un sistema di riserva e, in secondo luogo, la possibilit\u00e0 di lavorare con copie locali. Per la specifica regione russa, utilizziamo il servizio Mail.ru Hotbox, che \u00e8 compatibile con s3 tramite l'api. Non ci sono serviti grossi adattamenti al codice all'interno dell'applicazione e abbiamo creato il seguente meccanismo: in s3 ci sono trigger che si attivano alla creazione\/rimozione di oggetti, Amazon ha un servizio del tipo Lambda \u2014 \u00e8 un'esecuzione serverless di codice che verr\u00e0 eseguita proprio all'attivazione di quei trigger.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nAbbiamo fatto tutto molto semplicemente: se un trigger viene attivato, eseguiamo un codice che copia l'oggetto nello storage di Mail.ru. Per avviare correttamente il lavoro con le copie locali dei dati, abbiamo bisogno anche di una sincronizzazione inversa, affinch\u00e9 i clienti nel segmento russo possano lavorare con uno storage a loro pi\u00f9 vicino. Mail sta per completare i trigger nel proprio storage \u2014 sar\u00e0 possibile gi\u00e0 a livello infrastrutturale eseguire la sincronizzazione inversa, nel frattempo lo facciamo a livello del nostro codice. Se vediamo che un cliente ha caricato un file, mettiamo un evento nella coda a livello di codice, lo elaboriamo e facciamo una replica inversa. Qual \u00e8 il problema: se svolgiamo qualche lavoro con i nostri oggetti al di fuori del nostro prodotto, cio\u00e8 con strumenti esterni, non lo considereremo. Pertanto, stiamo aspettando fino a quando non appariranno i trigger a livello di storage, affinch\u00e9, indipendentemente da dove eseguiamo il codice, l'oggetto che ci raggiunge venga copiato nella direzione opposta. <\/p>\n

A livello di codice, per ciascun cliente definiamo entrambi gli archivi: uno \u00e8 considerato principale, l'altro di backup. Se tutto funziona correttamente, lavoriamo con l'archivio che ci \u00e8 pi\u00f9 vicino: i nostri clienti in Amazon utilizzano S3, mentre quelli in Russia usano Hotbox. Se scatta un flag, dobbiamo attivare il failover e trasferire i clienti a un altro archivio. Possiamo impostare questo flag indipendentemente per regione e possiamo fare cambiamenti. In pratica non ne abbiamo ancora avuto bisogno, ma abbiamo previsto questo meccanismo e crediamo che prima o poi ci servir\u00e0 questo cambio. \u00c8 gi\u00e0 successo una volta. <\/p>\n

Oh, ma il vostro Amazon \u00e8 scappato...<\/h4>\n

\nQuesto aprile segna l'anniversario dell'inizio del blocco di Telegram in Russia. Il provider pi\u00f9 colpito da questa situazione \u00e8 stato Amazon. Sfortunatamente, le aziende russe che operano a livello globale hanno subito maggiori danni. <\/p>\n

Se l'azienda \u00e8 globale e la Russia rappresenta solo un piccolo segmento, 3-5% \u2014 in un modo o nell'altro, si possono sacrificare. <\/p>\n

Se si tratta di un'azienda puramente russa, sono certo che \u00e8 necessario operare localmente \u2014 sarebbe pi\u00f9 comodo e sicuro per gli utenti stessi. <\/p>\n

E se si tratta di un'azienda che opera a livello globale e ha un numero simile di clienti russi e nel resto del mondo? La connessione tra i segmenti \u00e8 importante, e devono lavorare insieme in un modo o nell'altro. <\/p>\n

Alla fine di marzo 2018, Roskomnadzor ha inviato una lettera ai maggiori operatori, informandoli che pianificano di bloccare milioni di indirizzi IP di Amazon per bloccare\u2026 il messenger Zello. Grazie a questi provider, sono riusciti a diffondere la lettera, e si \u00e8 compresa la possibilit\u00e0 che la connessione con Amazon potesse interrompersi. Era venerd\u00ec, e in preda al panico ci siamo affrettati dai colleghi di servers.ru, dicendo: \u00abAmici, abbiamo bisogno di alcuni server che non siano in Russia, non in Amazon, ma ad esempio ad Amsterdam\u00bb, per poter avere almeno un modo per mettere l\u00ec i nostri vpn<\/a> e proxy per alcuni endpoint sui quali non possiamo influire, ad esempio gli endpoint dello stesso S3 \u2014 non possiamo provare a lanciare un nuovo servizio e ottenere un altro IP, dobbiamo comunque accedere. In pochi giorni abbiamo configurato e avviato questi server e, in generale, ci siamo preparati per l'inizio delle blocchi. \u00c8 curioso che il Roskomnadzor, dopo aver visto il trambusto e il panico, abbia dichiarato: \u00abNo, adesso non bloccheremo niente\u00bb. (Ma ci\u00f2 \u00e8 durato finch\u00e9 non hanno iniziato a bloccare Telegram.) Dopo aver impostato le possibilit\u00e0 di bypass e capendo che non era stata introdotta alcuna restrizione, comunque non abbiamo smontato tutto questo. Cos\u00ec, per sicurezza. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nE cos\u00ec, nel 2019 viviamo chiaramente in un contesto di blocchi. Ieri notte stavo osservando: circa un milione di IP continuano a essere bloccati. In verit\u00e0, Amazon \u00e8 stato quasi interamente sbloccato, e ai picchi si arrivava a 20 milioni di indirizzi... In generale, la realt\u00e0 \u00e8 che la connettivit\u00e0, una buona connettivit\u00e0 \u2014 potrebbe non esserci. All'improvviso. Potrebbe non esserci per motivi tecnici \u2014 incendi, escavatori, tutto il resto. Oppure, come abbiamo visto, non proprio per motivi tecnici. Pertanto, qualcuno grande e importante, con propri AS, probabilmente pu\u00f2 gestire la situazione in altri modi \u2014 direct connect e altre cose gi\u00e0 a livello l2. Ma nel semplice caso, come noi o altre aziende pi\u00f9 piccole, \u00e8 utile avere delle riserve a livello di server, attivati altrove, configurati in anticipo con VPN, proxy, con la possibilit\u00e0 di switchare rapidamente la configurazione in quei segmenti critici per la connettivit\u00e0. Questo ci \u00e8 stato utile pi\u00f9 volte quando sono iniziati i blocchi su Amazon, utilizzavamo per lo pi\u00f9 il traffico S3, ma lentamente tutto si \u00e8 sistemato.<\/p>\n

E come riservare... un intero provider?<\/h4>\n

\nAttualmente non abbiamo uno scenario per un guasto totale di Amazon. Abbiamo uno scenario simile per la Russia. In Russia ci siamo appoggiati a un fornitore, da cui abbiamo scelto di avere diverse sedi. Un anno fa ci siamo imbattuti in un problema: anche se ci sono due data center, gi\u00e0 a livello di configurazione di rete del fornitore possono verificarsi problemi che colpiscono entrambi i data center. E possiamo avere downtime in entrambe le sedi. Naturalmente, \u00e8 proprio quello che \u00e8 successo. In definitiva, abbiamo rivisto l'architettura interna. Non \u00e8 cambiata molto, ma per la Russia ora abbiamo due sedi, che non sono dello stesso fornitore, ma di due diversi. Se uno avesse un guasto, possiamo passare all'altro.<\/p>\n

Ipoteticamente stiamo considerando per Amazon la possibilit\u00e0 di riservare a livello di un altro fornitore; forse Google, forse qualcun altro... Ma finora abbiamo visto nella pratica che se ci sono problemi su un'area di disponibilit\u00e0 di Amazon, i guasti a livello di un'intera regione sono abbastanza rari. Pertanto, teoricamente abbiamo un'idea di farlo come riservazione \"Amazon - non Amazon\", ma nella pratica ci\u00f2 non \u00e8 ancora avvenuto. <\/p>\n

Qualche parola sull'automazione<\/h4>\n

\nL'automazione \u00e8 sempre necessaria? Qui \u00e8 opportuno ricordare l'effetto Dunning-Kruger. Sull'asse \"x\" ci sono le nostre conoscenze e l'esperienza che acquisiremo, e sull'asse \"y\" \u2014 la fiducia nelle nostre azioni. All'inizio non sappiamo nulla e non siamo affatto sicuri. Poi sappiamo un po' e diventiamo super sicuri: questo \u00e8 il cosiddetto \"picco dell'ignoranza\", ben illustrato dall'immagine \"follia e coraggio\". Successivamente, abbiamo gi\u00e0 imparato un po' e siamo pronti a combattere. Poi inciampiamo in qualche grave insidia e cadiamo nella valle della disperazione, quando sembra che sappiamo qualcosa, ma in realt\u00e0 non sappiamo molto. Poi, man mano che accumuliamo esperienza, diventiamo pi\u00f9 sicuri.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nLa nostra logica riguardo ai vari passaggi automatici per diverse emergenze \u00e8 ben descritta da questo grafico. Siamo partiti da zero \u2014 non sapevamo fare nulla, praticamente tutto era eseguito manualmente. Poi abbiamo capito che potevamo automatizzare tutto e, in un certo senso, stare tranquilli. Ma all'improvviso ci siamo trovati di fronte a grosse complicazioni: abbiamo ricevuto un falso positivo e ci siamo trovati a spostare il traffico da una parte all'altra, quando, a dire il vero, non sarebbe stato necessario. Di conseguenza, la replicazione si interrompe o qualcosa del genere \u2014 ecco la famosa valle dell'angoscia. Poi abbiamo capito che bisogna affrontare tutto con discernimento. Questo significa che ha senso affidarsi all'automazione, prevedendo la possibilit\u00e0 di falsi allarmi. Ma! se le conseguenze possono essere devastanti, \u00e8 meglio lasciare la gestione a un turno di guardia, a ingegneri di turno, che verificheranno, controlleranno che ci sia realmente un'emergenza e che le azioni necessarie vengano eseguite manualmente...<\/p>\n

Conclusione<\/h4>\n

\nIn 7 anni siamo passati da una situazione in cui, quando qualcosa andava in crisi, c'era panico totale, alla consapevolezza che non esistono problemi, solo compiti che devono essere \u2014 e possono essere \u2014 risolti. Quando costruite un servizio, osservatelo dall'alto, valutate tutti i rischi potenziali. Se li vedete subito \u2014 prevedete in anticipo il back-up e la possibilit\u00e0 di costruire un'infrastruttura resistente ai guasti, perch\u00e9 qualsiasi punto che pu\u00f2 guastarsi e causare l'inefficienza del servizio \u2014 lo far\u00e0 sicuramente. E anche se vi sembra che alcuni elementi dell'infrastruttura non possano guastarsi \u2014 come lo s3, ricordate comunque che \u00e8 possibile. E quantomeno in teoria, siate pronti a sapere cosa fare con loro se qualcosa dovesse succedere. Avete un piano per gestire i rischi. Quando vi preparate a fare tutto in automatico o manualmente, valutate i rischi: cosa succeder\u00e0 se l'automazione inizia a fare cambiamenti \u2014 porter\u00e0 a una situazione ancora peggiore rispetto a quella di emergenza? Potrebbe essere necessario trovare un compromesso ragionevole tra l'uso dell'automazione e la reazione di un ingegnere di turno, che valuter\u00e0 la situazione reale e decider\u00e0 se \u00e8 necessario cambiare qualcosa immediatamente o<\/p>\n

Un compromesso ragionevole tra perfezionismo e le reali forze, tempo e denaro che puoi investire nello schema che avrai alla fine.<\/p>\n

Questo testo \u00e8 una versione ampliata e arricchita della relazione di Aleksandr Demidov alla conferenza Uptime giorno 4<\/a><\/noindex>.<\/i>
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00abBitrix24\u00bb: \u00abCi\u00f2 che \u00e8 stato sollevato rapidamente non \u00e8 considerato caduto\u00bb | ProHoster","description":"A oggi, il servizio \u00abBitrix24\u00bb non dispone di centinaia di gigabit di traffico, n\u00e9 di un enorme parco server (anche se ce ne sono sicuramente molti).","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e).","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}