{"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 sistema che si rialza rapidamente non viene considerato caduto\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ad oggi, il servizio \u00abBitrix24\u00bb non ha centinaia di gigabit di traffico n\u00e9 un enorme parco server (anche se, ovviamente, ce ne sono parecchi). Tuttavia, per molti clienti rappresenta uno strumento fondamentale per il lavoro in azienda, un'applicazione veramente business-critical. Quindi, cadere \u2014 \u00e8 fuori discussione. E se la caduta si fosse comunque verificata, ma il servizio \u00e8 \u00abresuscitato\u00bb cos\u00ec rapidamente che nessuno se ne \u00e8 accorto? E come riescono a implementare il failover senza perdere qualit\u00e0 del servizio e numero di clienti? Alexander Demidov, direttore della divisione dei servizi cloud di \u00abBitrix24\u00bb, ci ha raccontato nel nostro blog come nel corso di 7 anni di esistenza del prodotto si sia evoluto il sistema di riservazione.<\/p>\n

\"\u00abBitrix24\u00bb:
\n<\/a><\/noindex>
\nAbbiamo lanciato \"Bitrix24\" 7 anni fa in formato SaaS. La principale difficolt\u00e0, probabilmente, \u00e8 stata la seguente: prima del lancio pubblico come SaaS, questo prodotto esisteva semplicemente come soluzione software confezionata. I clienti lo acquistavano da noi, lo installavano sui propri server, creavano un portale aziendale \u2014 una soluzione generale per la comunicazione fra i dipendenti, l'archiviazione di file, la gestione delle attivit\u00e0, CRM, e cos\u00ec via. Fino al 2012 abbiamo deciso di lanciarlo come SaaS, gestendolo autonomamente e garantendo resilienza e affidabilit\u00e0. Abbiamo acquisito esperienza nel processo, poich\u00e9 fino ad allora non ne avevamo \u2014 eravamo solo produttori di software, non fornitori di servizi. <\/p>\n

Lanciando il servizio, sapevamo che l'aspetto principale era garantire resilienza, affidabilit\u00e0 e disponibilit\u00e0 costante del servizio, perch\u00e9 se hai un semplice sito web, un negozio ad esempio, e questo si blocca per un'ora, ne soffri solo tu, perdi ordini e clienti, ma per il tuo cliente non \u00e8 cos\u00ec critico. Pu\u00f2 sentirsi deluso, certo, ma andr\u00e0 a comprare altrove. Ma se si tratta di un'applicazione su cui si basa tutto il lavoro interno dell'azienda, le comunicazioni, le decisioni, allora \u00e8 fondamentale conquistare la fiducia degli utenti, cio\u00e8 non tradirli e non farli cadere. Perch\u00e9 tutto il lavoro pu\u00f2 fermarsi se qualcosa all'interno smette di funzionare.<\/p>\n

Bitrix24 come SaaS<\/h4>\n

\nIl primo prototipo \u00e8 stato realizzato un anno prima del lancio pubblico, nel 2011. \u00c8 stato assemblato in circa una settimana, l'abbiamo esaminato, ruotato \u2014 e funzionava gi\u00e0. Si poteva accedere alla schermata, inserire il nome del portale, e veniva creato un nuovo portale con un database utenti avviato. L'abbiamo valutato e poi ci siamo fermati, continuando a lavorarci per un anno. Avevamo un compito importante: non volevamo creare due diverse basi di codice, non volevamo mantenere un prodotto confezionato separato dalle soluzioni cloud \u2014 volevamo unificarli in un unico codice. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nUn'applicazione web tipica per quell'epoca era un singolo server su cui girava un codice PHP, con un database MySQL, file caricati, documenti e immagini memorizzati nella cartella upload \u2014 e funzionava. Purtroppo, non \u00e8 possibile avviare un servizio web critico in modo sostenibile su questo tipo di struttura. Non supporta un cache distribuito e la replica del database non \u00e8 prevista. <\/p>\n

Abbiamo definito i requisiti: \u00e8 fondamentale poter operare in diverse localit\u00e0, supportare la replicazione e, idealmente, trovarsi in data center geograficamente distribuiti. Separare la logica del prodotto dallo storage dei dati. Essere in grado di scalare dinamicamente in base al carico, esternalizzando completamente la parte statica. Da queste considerazioni sono emersi, appunto, i requisiti del prodotto che abbiamo sviluppato nel corso dell'anno. Durante questo periodo, abbiamo realizzato una piattaforma unica \u2014 per soluzioni on-premise, e per il nostro servizio interno \u2014 implementando il supporto per le funzionalit\u00e0 necessarie. Il supporto per la replicazione MySQL a livello di prodotto: il che significa che lo sviluppatore, scrivendo codice, non deve preoccuparsi di come verranno distribuite le sue query; usa la nostra API, e noi gestiamo correttamente la distribuzione delle query di scrittura e lettura tra master e slave. <\/p>\n

Abbiamo implementato il supporto per diversi storage object cloud a livello di prodotto: Google Storage, Amazon S3, oltre al supporto per OpenStack Swift. Questo rendeva tutto pi\u00f9 conveniente sia per noi come servizio che per gli sviluppatori che lavorano con la soluzione preconfezionata: se utilizzano semplicemente la nostra API per le operazioni, non devono preoccuparsi di dove verr\u00e0 salvato il file, localmente nel file system o in uno storage object.<\/p>\n

Alla fine, abbiamo deciso di prenotare a livello di intero data center. Nel 2012 ci siamo lanciati completamente su Amazon AWS, perch\u00e9 avevamo gi\u00e0 esperienza con questa piattaforma: il nostro sito era gi\u00e0 ospitato l\u00ec. Ci ha attratto il fatto che in ogni regione di Amazon ci sono diverse Availability Zone \u2014 fondamentalmente, (nella loro terminologia) pi\u00f9 data center che sono pi\u00f9 o meno indipendenti tra loro e ci permettono di prenotare a livello di un intero data center: se uno di essi si guasta, i database vengono replicati master-master, i server delle applicazioni web sono riservati e la staticit\u00e0 \u00e8 spostata nello storage oggetti s3. Il carico \u00e8 bilanciato \u2014 inizialmente con elb di Amazon, ma poco dopo abbiamo adottato i nostri bilanciatori, poich\u00e9 avevamo bisogno di una logica pi\u00f9 complessa. <\/p>\n

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

\nTutte le cose di base che volevamo garantire \u2014 la resilienza dei server, delle applicazioni web e dei database \u2014 funzionavano bene. Lo scenario pi\u00f9 semplice: se uno delle applicazioni web si guasta, \u00e8 facile \u2014 vengono esclusi dal bilanciamento. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nI server bilanciatori che hanno smesso di funzionare (all'epoca si trattava di ELB di Amazon) si segnano da soli come non sani, interrompendo il bilanciamento del carico su di essi. Ha funzionato l'auto-scalabilit\u00e0 di Amazon: quando il carico aumentava, venivano aggiunti nuovi server al gruppo di auto-scalabilit\u00e0 e il carico veniva distribuito sui nuovi server \u2014 tutto andava bene. Con i nostri bilanciatori, la logica \u00e8 sostanzialmente la stessa: se succede qualcosa con il server delle applicazioni, rimuoviamo le richieste, eliminando quei server, avviamo dei nuovi e continuiamo a lavorare. Lo schema \u00e8 cambiato un po' nel corso degli anni, ma continua a funzionare: \u00e8 semplice, chiaro e non ci sono complessit\u00e0 a riguardo. <\/p>\n

Operiamo in tutto il mondo, i picchi di carico dei clienti sono assolutamente diversi e, a dire il vero, dobbiamo avere la possibilit\u00e0 di eseguire 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, ridistribuendo il carico sul secondo centro dati. <\/p>\n

Come funziona tutto questo? \u2014 Devia il traffico verso il data center funzionante: in caso di un guasto del data center, viene deviatato completamente; se si tratta delle nostre operazioni programmate su un singolo database, deviamo una parte del traffico servito a quei clienti verso il secondo data center, sospendendo la replica. Se sono necessarie nuove macchine per le applicazioni web a causa di un aumento del carico nel secondo data center, esse vengono avviate automaticamente. Terminati i lavori, la replica viene ripristinata e riportiamo tutto il carico indietro. Se dobbiamo eseguire lavori speculari nel secondo DC, ad esempio installare aggiornamenti di sistema o modificare impostazioni in un secondo database, ripetiamo fondamentalmente tutto allo stesso modo, solo in direzione opposta. E se si tratta di un guasto, seguiamo semplicemente un processo banale: utilizziamo nel sistema di monitoraggio il meccanismo degli event-handlers. Se vengono attivate diverse verifiche e lo stato passa a critico, si attiva il handler, che pu\u00f2 eseguire la logica necessaria. Per ciascun database abbiamo definito quale server sia il failover, e dove deviare il traffico in caso di indisponibilit\u00e0. Storicamente, usiamo in un modo o nell'altro Nagios o alcune sue varianti. In linea di principio, meccanismi simili sono presenti in quasi tutti i sistemi di monitoraggio; al momento non utilizziamo nulla di pi\u00f9 complesso, ma potrebbe accadere in futuro. Ora il monitoraggio si attiva in caso di indisponibilit\u00e0 e ha la capacit\u00e0 di deviare il traffico.<\/p>\n

Abbiamo riservato tutto?<\/h4>\n

\nAbbiamo molti clienti dagli Stati Uniti, molti clienti dall'Europa, e molti clienti pi\u00f9 vicini all'Oriente \u2014 Giappone, Singapore e cos\u00ec via. Naturalmente, una grande parte dei clienti \u00e8 in Russia. Questo significa che operiamo in pi\u00f9 di una regione. Gli utenti desiderano risposte rapide e ci sono requisiti di conformit\u00e0 a diverse leggi locali; all'interno di ogni regione, riserviamo due data center, oltre ad alcuni servizi aggiuntivi che, di nuovo, \u00e8 conveniente posizionare in una sola regione \u2014 per i clienti che operano in quella regione. I gestori REST e i server di autorizzazione sono meno critici per il funzionamento del cliente complessivo; per loro \u00e8 possibile passare con un piccolo ritardo accettabile, ma non vogliamo reinventare la ruota su come monitorarli e cosa fare con loro. Pertanto, cerchiamo di sfruttare al massimo le soluzioni gi\u00e0 esistenti, piuttosto che sviluppare competenze su prodotti aggiuntivi. Talvolta utilizziamo semplicemente il trasferimento a livello DNS, e la vivacit\u00e0 del servizio \u00e8 determinata dallo stesso DNS. Amazon ha il servizio Route 53, ma non \u00e8 solo un DNS in cui si possono inserire registrazioni e via; \u00e8 molto pi\u00f9 flessibile e conveniente. Con questo servizio si possono costruire servizi geo-distribuiti con geolocalizzazioni, determinando da dove proviene il cliente e fornendogli le registrazioni appropriate \u2014 con il suo aiuto si possono realizzare architetture di failover. Anche i health check vengono impostati direttamente in Route 53; si impostano gli endpoint da monitorare, le metriche da considerare, e i protocolli per determinare la \"vivacit\u00e0\" del servizio \u2014 tcp, http, https; definire la frequenza dei controlli che determinano se il servizio \u00e8 attivo o meno. E nel DNS si specifica quale sar\u00e0 il primario, quale il secondario e dove dev'essere effettuato il passaggio se scatta un health check all'interno di Route 53. Tutto questo pu\u00f2 essere realizzato con altri strumenti, ma la comodit\u00e0 \u00e8 che una volta impostato, non dobbiamo pi\u00f9 pensare a come vengono eseguiti i controlli o come avviene il passaggio: tutto funziona da solo.<\/p>\n

Il primo \"ma\"<\/b>: come e con cosa riservare il proprio route 53? Potrebbe succedere qualcosa! Fortunatamente, non ci siamo mai trovati in questa situazione, ma ho una storia da raccontare su perch\u00e9 sia necessario mettere da parte delle risorse. Qui stiamo mettendo in sicurezza un po' il nostro sistema. Diverse volte al giorno, effettuiamo un'esportazione completa di tutte le zone che abbiamo nel route 53. L'API di Amazon ci consente di ottenere tranquillamente i dati in formato JSON, e abbiamo attivato diversi server di backup dove conversioni e configurazioni vengono esportate. In caso di necessit\u00e0, possiamo ripristinare manualmente questi dati senza perdere le impostazioni DNS.<\/p>\n

Il secondo \"ma\"<\/b>: che cosa non \u00e8 ancora riservato in questa immagine? Solo il bilanciatore! Abbiamo organizzato la distribuzione dei clienti per regioni in modo molto semplice. Abbiamo domini come bitrix24.ru, bitrix24.com, .de \u2014 attualmente ne abbiamo circa 13 diversi, che operano in vari ambiti. Siamo giunti alla seguente conclusione: in ogni regione ci sono i nostri bilanciatori. Questo facilita la distribuzione in base a dove si trova il picco del carico di rete. Se si verifica un guasto a uno di questi bilanciatori, viene semplicemente disattivato e rimosso dal DNS. Se ci sono problemi con un gruppo di bilanciatori, questi vengono riservati su altre piattaforme, e il passaggio tra di loro avviene tramite Route53, poich\u00e9 grazie a un TTL breve il passaggio avviene al massimo in 2, 3, 5 minuti. <\/p>\n

Il terzo \u00abma\u00bb<\/b>: che cos'altro non \u00e8 riservato? S3, giusto. Quando carichiamo file che conserviamo per gli utenti su S3, credevamo sinceramente che fosse a prova di proiettile e che non ci fosse bisogno di riservare nulla l\u00ec. Ma la storia mostra che le cose non stanno cos\u00ec. Infatti, Amazon descrive S3 come un servizio fondamentale, perch\u00e9 lo stesso Amazon utilizza S3 per memorizzare immagini delle macchine, configurazioni, immagini AMI, snapshot... E se S3 va in panne, come \u00e8 successo una volta in questi 7 anni in cui utilizziamo Bitrix24, porta con s\u00e9 un sacco di problemi \u2014 l'impossibilit\u00e0 di avviare macchine virtuali, guasti nell'API e cos\u00ec via. <\/p>\n

E se S3 dovesse crollare \u2014 \u00e8 accaduto una volta. Per questo motivo, siamo giunti al seguente piano: diversi anni fa, in Russia non c'erano seri archivi pubblici per oggetti, ed abbiamo considerato di crearne uno nostro... Per fortuna, non abbiamo iniziato a farlo, perch\u00e9 ci saremmo addentrati in un'esperienza per la quale non eravamo pronti e, senza dubbio, avremmo commesso errori. Oggi ci sono archivi compatibili con S3 offre Mail.ru, Yandex e altri provider. Alla fine, abbiamo concluso che volevamo avere, innanzitutto, un sistema di riserva e, in secondo luogo, la possibilit\u00e0 di lavorare con copie locali. Per la regione specificamente russa, utilizziamo il servizio Mail.ru Hotbox, che \u00e8 compatibile con S3 tramite API. Non abbiamo dovuto apportare modifiche significative al codice dell'applicazione, e abbiamo creato il seguente meccanismo: S3 ha dei trigger che si attivano alla creazione\/cancellazione di oggetti. Amazon dispone di un servizio chiamato Lambda \u2014 \u00e8 un sistema serverless per l'esecuzione di codice, che verr\u00e0 eseguito proprio al verificarsi di determinati trigger.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nAbbiamo semplificato il processo: quando scatta un trigger, eseguiamo il codice che copia l'oggetto nello storage di Mail.ru. Per avviare completamente il lavoro con le copie locali dei dati, abbiamo bisogno anche di una sincronizzazione inversa, in modo che 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 di infrastruttura eseguire la sincronizzazione inversa, mentre al momento lo facciamo a livello del nostro codice. Se vediamo che un cliente ha caricato un file, allora noi, a livello di codice, mettiamo un evento in coda, lo elaboriamo e effettuano la replica inversa. Il problema \u00e8 che se c'\u00e8 un'operazione con i nostri oggetti al di fuori del nostro prodotto, cio\u00e8 con strumenti esterni, non lo considereremo. Pertanto, stiamo aspettando che vengano implementati i trigger a livello di storage, in modo che indipendentemente da dove abbiamo eseguito il codice, l'oggetto che ci \u00e8 arrivato venga copiato dall'altra parte. <\/p>\n

A livello di codice, per ciascun cliente vengono configurati entrambi i storage: uno considerato principale e l'altro di backup. Se tutto va bene, lavoriamo con il storage pi\u00f9 vicino a noi: i nostri clienti che sono su Amazon utilizzano S3, mentre quelli che operano in Russia usano Hotbox. Se scatta il flag, dobbiamo attivare il failover e spostare i clienti su un altro storage. Possiamo impostare questo flag in modo indipendente per le regioni e fare switch bidirezionali. Nella pratica non lo abbiamo ancora utilizzato, ma abbiamo previsto questo meccanismo e pensiamo che prima o poi avremo bisogno di questo switching. \u00c8 gi\u00e0 successo una volta. <\/p>\n

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

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

Se un'azienda \u00e8 globale e la Russia rappresenta solo una piccola frazione, dal 3 al 5%, beh, in un modo o nell'altro, si possono sacrificare. <\/p>\n

Se si tratta di un'azienda esclusivamente russa, sono sicuro che sia necessario localizzarsi \u2014 semplicemente per il comfort degli utenti, sar\u00e0 pi\u00f9 comodo e ci saranno meno rischi. <\/p>\n

E se \u00e8 un'azienda che opera a livello globale, con clienti pi\u00f9 o meno equamente distribuiti tra la Russia e il resto del mondo? La connettivit\u00e0 tra i segmenti \u00e8 importante, e devono lavorare insieme in un modo o nell'altro. <\/p>\n

Alla fine di marzo 2018, il Roskomnadzor ha inviato una lettera ai maggiori operatori, informandoli che avevano intenzione di bloccare alcuni milioni di IP di Amazon per impedire\u2026 il messenger Zello. Grazie a questi stessi provider \u2014 hanno pubblicato la lettera a tutti, ed \u00e8 emersa la comprensione che la connettivit\u00e0 con Amazon potrebbe collassare. Era venerd\u00ec, e siamo corsi in panico dai colleghi di servers.ru, dicendo: \u00abAmici, abbiamo bisogno di alcuni server che non siano in Russia, non su Amazon, ma, ad esempio, da qualche parte ad Amsterdam\u00bb, per avere almeno la possibilit\u00e0 di mettere l\u00e0 i nostri server. vpn<\/a> e proxy per alcuni endpoint a cui 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 riuscire a contattarli. In pochi giorni abbiamo configurato e avviato questi server e, fondamentalmente, ci siamo preparati per l'inizio dei blocchi. Curiosamente, il RKN, dopo aver osservato il clamore e il panico generato, ha detto: \u00abNo, non bloccheremo nulla per ora\u00bb. (Ma questo fino al momento in cui hanno iniziato a bloccare Telegram.) Configurando le capacit\u00e0 di bypass e capendo che il blocco non \u00e8 stato imposto, tuttavia, non abbiamo smontato tutto. Cos\u00ec, per ogni evenienza. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nNel 2019 ci troviamo quindi a vivere in un contesto di blocchi. Ieri notte ho osservato che circa un milione di IP continuano a essere bloccati. Tuttavia, Amazon \u00e8 stata quasi completamente sbloccata; in alcuni momenti abbiamo raggiunto fino a 20 milioni di indirizzi. In breve, la realt\u00e0 \u00e8 che la connettivit\u00e0 \u2014 una buona connettivit\u00e0 \u2014 pu\u00f2 venire a mancare. All'improvviso. Pu\u00f2 mancare per motivi tecnici \u2014 incendi, escavatori, cose del genere. Oppure, come abbiamo visto, per ragioni non del tutto tecniche. Pertanto, qualcuno di grande e importante, con propri AS, pu\u00f2 probabilmente gestire la situazione in altri modi \u2014 direct connect e altri sistemi gi\u00e0 a livello L2. Ma per le situazioni pi\u00f9 semplici, come nel nostro caso o per altre aziende pi\u00f9 piccole, \u00e8 utile avere un piano di riserva a livello di server, attivati altrove, con VPN e proxy preconfigurati, in modo da poter rapidamente passare la configurazione su quei segmenti che sono critici per la connettivit\u00e0. Ci \u00e8 stato utile in numerose occasioni quando sono iniziati i blocchi di Amazon, abbiamo utilizzato questi server per instradare il traffico S3 nei momenti peggiori, ma alla fine la situazione si \u00e8 risolta.<\/p>\n

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

\nAttualmente non abbiamo uno scenario in caso di totale guasto di Amazon. Abbiamo uno scenario simile per la Russia. In Russia ci siamo appoggiati a un fornitore che ci ha permesso di scegliere tra pi\u00f9 sedi. Un anno fa ci siamo trovati di fronte a un problema: anche se si trattava di due data center, gi\u00e0 a livello di configurazione della rete del fornitore possono sorgere problemi che interessano entrambi i data center. Di conseguenza, possiamo avere disservizi in entrambe le sedi. Infatti, cos\u00ec \u00e8 stato. Alla fine abbiamo rivisto l'architettura interna. Non \u00e8 cambiata molto, ma per la Russia ora abbiamo due sedi, non della stessa compagnia, ma di due fornitori diversi. Se uno di essi avesse un problema, possiamo passare all'altro.<\/p>\n

Ipoteticamente, stiamo considerando di fare backup per Amazon a livello di un altro provider; che potrebbe essere Google, o qualcun altro... Ma finora abbiamo osservato nella pratica che se ci sono guasti in una availability zone di Amazon, i guasti a livello di intera regione sono fenomeni abbastanza rari. Pertanto, abbiamo un'idea teorica di ci\u00f2 che potremmo fare come riserva \"Amazon \u2013 non Amazon\", ma nella pratica non siamo ancora a quel punto. <\/p>\n

Due parole sull'automazione<\/h4>\n

\nServe sempre l'automazione? Qui vale la pena ricordare l'effetto Dunning-Kruger. Sull'asse \"x\" troviamo le nostre conoscenze e l'esperienza accumulata, mentre sull'asse \"y\" c'\u00e8 la fiducia nelle nostre azioni. All'inizio non sappiamo nulla e siamo del tutto insicuri. Poi iniziamo a sapere un po' di pi\u00f9 e diventiamo super sicuri di noi: questo \u00e8 il cosiddetto \"picco di stupidit\u00e0\", ben illustrato dall'immagine \"incompetenza e coraggio.\" Successivamente, impariamo un po' e ci sentiamo pronti a combattere. Poi inciampiamo in gravi problemi e ci troviamo nella valle della disperazione, quando sembra che sappiamo qualcosa, ma in realt\u00e0 non sappiamo molto. Con l'aumentare dell'esperienza, diventiamo pi\u00f9 sicuri.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nLa nostra logica sui vari switch automatici in caso di guasti \u00e8 ben spiegata da questo grafico. Siamo partiti \u2014 eravamo alle prime armi, praticamente tutto il lavoro veniva svolto manualmente. Poi abbiamo capito che si poteva automatizzare tutto e, in qualche modo, dormire sonni tranquilli. E improvvisamente ci troviamo ad affrontare un mega errore: un falso positivo si attiva e commutiamo il traffico avanti e indietro, quando, a rigor di logica, non avremmo dovuto farlo. Di conseguenza, la replicazione si guasta o qualcosa del genere \u2014 questa \u00e8 la vera valle della disperazione. E poi arriviamo a comprendere che \u00e8 necessario avvicinarsi a tutto con saggezza. Vale a dire che ha senso affidarsi all'automazione, prevedendo la possibilit\u00e0 di falsi feedback. Ma! se le conseguenze possono essere distruttive, \u00e8 meglio lasciare queste decisioni a un turno di guardia, a ingegneri di servizio, che verificheranno e si assicureranno che ci sia davvero una situazione di emergenza, e che le azioni necessarie vengano eseguite manualmente...<\/p>\n

Conclusione<\/h4>\n

\nIn sette anni, siamo passati da un'era di panico totale ogni volta che qualcosa andava storto a una comprensione che non ci sono problemi, solo compiti da affrontare e risolvere. Quando costruite un servizio, osservatelo dall'alto, valutate tutti i rischi potenziali che potrebbero verificarsi. Se li individuate subito, pianificate in anticipo le riserve e la possibilit\u00e0 di creare un'infrastruttura resiliente, perch\u00e9 ogni punto che pu\u00f2 guastarsi e portare alla non operativit\u00e0 del servizio, lo far\u00e0. Anche se pensate che alcuni elementi dell'infrastruttura non si guasteranno mai, come ad esempio s3, tenete presente che potrebbero farlo. E anche solo in teoria, dovete avere un'idea di cosa farete con loro in caso di problemi. Sviluppate un piano di gestione dei rischi. Quando pensate di automatizzare tutto o fare manualmente, valutate i rischi: cosa succede se l'automazione inizia a commutare tutto? Non creer\u00e0 una situazione anche peggiore rispetto a un guasto? Potrebbe essere necessario trovare un compromesso ragionevole tra l'uso dell'automazione e la reazione di un ingegnere di guardia che valuta la situazione reale e decide se \u00e8 il caso di cambiare qualcosa subito o \u00abs\u00ec, ma non ora\u00bb.<\/p>\n

Un compromesso ragionevole tra perfezionismo e le risorse reali, il tempo, il denaro che puoi spendere per lo schema che alla fine avrai.<\/p>\n

Questo testo \u00e8 una versione ampliata e arricchita della relazione di Alexander 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\"Bitrix24\": \"Un rapido ripristino non conta come un crollo\" | ProHoster","description":"Attualmente il servizio \"Bitrix24\" non dispone di centinaia di gigabit di traffico, n\u00e9 di un vasto parco server (anche se ce ne sono sicuramente molti). Ma per molti clienti \u00e8 uno strumento fondamentale per il lavoro aziendale, \u00e8 un'applicazione veramente business-critical. Pertanto, non pu\u00f2 assolutamente crollare. E se un crollo si verifica, ma il servizio \"si risolleva\" cos\u00ec rapidamente che nessuno se ne accorge.","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). \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","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}]}}