Per quanto riguarda le interruzioni di servizio credo che nessuno si sia meravigliato dei risultati, ma sicuramente \u00e8 interessante notare che l\u2019asticella delle aspettative sia sempre pi\u00f9 alta e le conseguenze dei downtime impattino sempre pi\u00f9 fortemente sui guadagni e sulla fiducia degli utenti. <\/p>\n\n\n\n
Il secondo punto, a mio avviso, ha a che fare con l\u2019utilizzo della tecnologia Cloud senza comprenderne fino a fondo le basi. Come dicevamo, il Cloud non \u00e8 magico, non basta mettere un workload in Cloud per aumentare l\u2019up-time. <\/p>\n\n\n\n
L\u2019articolo vuole essere un tentativo di spiegare come il Cloud ci abilita e cosa dobbiamo fare noi per ottenere fault-tolerance<\/strong>, migliorare l\u2019up-time<\/strong> e coprire alcuni degli aspetti di un piano strutturato di business continuity<\/strong>.<\/p>\n\n\n\n Se fossimo a scuola bisognerebbe partire dalla definizione:<\/p>\n\n\n\n la tolleranza al guasto, si riferisce alla capacit\u00e0 di un sistema o di un’applicazione di continuare a funzionare in modo affidabile anche quando si verificano guasti o malfunzionamenti in uno o pi\u00f9 dei suoi componenti<\/em>.<\/p>\n\n\n\n Riuscire ad essere tolleranti ai guasti \u00e8 importante per indirizzare molti degli obiettivi definiti nei piani di business continuity. Una buona progettazione di infrastrutture tolleranti al guasto ci porta a vantaggi come la riduzione del downtime, il miglioramento dell\u2019affidabilit\u00e0, la riduzione del rischio e il mantenimento della qualit\u00e0 di servizio. <\/p>\n\n\n\n \u00c9 doveroso fare subito chiarezza sul concetto di tolleranza ai guasti e come si differenzia da concetti come HA (Alta Affidabilit\u00e0), ridondanza e DR (Disaster Recovery) spesso usati erroneamente come sinonimi intercambiabili.<\/p>\n\n\n\n L’alta affidabilit\u00e0<\/strong> si riferisce alla capacit\u00e0 di un sistema di rimanere operativo, senza interruzioni apprezzabili, per periodi di tempo continuativi. Questo obiettivo pu\u00f2 essere raggiunto attraverso l’uso di monitoraggio continuo, ridondanza e altre misure. Un sistema ad alta affidabilit\u00e0 \u00e8 progettato per evitare guasti e garantire la disponibilit\u00e0 continua del servizio.<\/p>\n\n\n\n La ridondanza<\/strong> serve a migliorare l’affidabilit\u00e0 di un sistema. Progettare infrastrutture che comprendono componenti ridondanti significa che, se un componente dovesse guastarsi, un altro possa prendere il suo posto per evitare interruzioni. La ridondanza pu\u00f2 essere applicata sia a livello hardware che software. <\/p>\n\n\n\n Il Disaster Recovery<\/strong> \u00e8 un piano che mira a ripristinare un sistema o un’applicazione in caso di eventi catastrofici o guasti su larga scala. Questo coinvolge solitamente il backup dei dati, la pianificazione della continuit\u00e0 aziendale e procedure specifiche per ripristinare il sistema in un altro luogo o con risorse alternative.<\/p>\n\n\n\n L’alta affidabilit\u00e0, la ridondanza e il DR sono tutti componenti importanti per ottenere la tolleranza al guasto, ma da soli potrebbero non essere sufficienti per garantirla. La tolleranza ai guasti richiede una progettazione oculata che prenda in considerazione una vasta gamma di scenari e preveda misure adeguate per gestirli senza interruzioni significative.<\/p>\n\n\n\n La tolleranza al guasto \u00e8, quindi, una strategia di progettazione e implementazione che contribuisce in modo significativo a continuare a operare in modo affidabile arrivando cos\u00ec a proteggere la reputazione aziendale e a mantenere la fiducia dei clienti.<\/p>\n\n\n\n Chi si approccia al Cloud dovrebbe tenere ben presente che i provider non sono, non vogliono e non possono essere responsabili delle nostre applicazioni in toto. In pi\u00f9 a seconda del servizio o del building block che sfruttiamo per le nostre infrastrutture, il provider sposta l\u2019asticella della responsabilit\u00e0. Prendendo ad esempio AWS, come si evince dall\u2019immagine, servizi pi\u00f9 IaaS spostano la responsabilit\u00e0 verso Cliente, mentre servizi gestiti spostano di pi\u00f9 la responsabilit\u00e0 verso il provider.<\/p>\n\n\n\n <\/p>\n\n\n https:\/\/aws.amazon.com\/blogs\/industries\/applying-the-aws-shared-responsibility-model-to-your-gxp-solution\/<\/a><\/p>\n\n\n\n <\/p>\n\n\n\n Questo significa che nonostante il provider metta in campo ogni forma di ridondanza hardware e geografica, parte della responsabilit\u00e0 rimane comunque in capo al cliente. <\/p>\n\n\n\n AWS mette in luce queste due facce della medaglia distinguendo il provider, responsabile della resilienza del<\/strong> cloud, e il cliente, responsabile della resilienza nel<\/strong> cloud. AWS \u00e8 responsabile della protezione dell’infrastruttura su cui vengono eseguiti tutti i servizi offerti nel Cloud AWS. Questa infrastruttura include l’hardware, il software, le reti e le strutture su cui vengono eseguiti i servizi Cloud AWS. Mentre la responsabilit\u00e0 del cliente \u00e8 determinata dai servizi Cloud AWS che sceglie, in base alle configurazioni che deve fare e le attivit\u00e0 di gestione e progettazione. <\/p>\n\n\n\n Proviamo a mettere a terra tutti i discorsi fatti sulla Fault Tolerance. Nel caso di AWS dobbiamo partire capendo bene come \u00e8 stata implementata l\u2019infrastruttura fisica dei datacenter. \u00c8 necessario ribadire che AWS ci da gli strumenti per creare delle infrastrutture resilienti, ma sta a noi progettare e metterle in opera nella maniera pi\u00f9 corretta.<\/p>\n\n\n\n Partiamo dalle Availability Zones (A.Z.) che sono singoli data center o gruppi di essi, raggruppate logicamente in Region. <\/p>\n\n\n\n La ridondanza<\/strong> si ottiene sfruttando una singola A.Z., ma duplicando le istanze del servizio in uso all\u2019interno della stessa. Facciamo due esempi pratici. Posso creare due EC2 all\u2019interno delle quali installare MySql, metterle in cluster, active-standby ed essere robusti a fallimenti hardware del provider.<\/p>\n\n\n\n L’High Availability<\/strong> \u00e8 la capacit\u00e0 di mantenere i servizi in esecuzione senza interruzioni. In un contesto SaaS, significa avere sistemi ridondanti in modo che, se uno dei componenti fallisce, un altro prenda immediatamente il suo posto senza causare downtime. L\u2019HA \u00e8 fondamentale per garantire che i servizi SaaS siano sempre accessibili agli utenti.<\/p>\n\n\n\n L\u2019alta disponibilit\u00e0 la ottengo distribuendo il nostro database su due differenti Availability Zones. Importantissimo \u00e8 avere progettato, impostato e configurato l\u2019ambiente Cloud nella maniera pi\u00f9 corretta. Se non sapete di cosa sto parlando vi devo rimandare alla nostra serie di articoli sulla Landing Zone<\/a>.<\/p>\n\n\n\n Il Disaster Recovery<\/strong> \u00e8 il piano che un’azienda mette in atto per ripristinare le sue operazioni in seguito a un grave incidente o una catastrofe. In un contesto SaaS, questo significa avere copie di backup dei dati e dei servizi critici in un luogo sicuro e facilmente accessibile. Nel caso di un’emergenza, il DR consente di ripristinare rapidamente i servizi, minimizzando i tempi di inattivit\u00e0.<\/p>\n\n\n\n Il Disaster Recovery si ottiene sfruttando due diverse AWS Region nel mondo. Non esistono molti meccanismi automatici o servizi che ci permettono di ottenere il DR con basso sforzo implementativo. Il DR va ragionato e ci sono una miriade di aspetti da tenere ben presenti e anche su questi aspetti abbiamo creato una serie di articoli<\/a>.<\/p>\n\n\n\n Finora abbiamo affrontato il discorso solo dal punto di vista infrastrutturale, ma anche dal punto di vista dello sviluppo software questa tematica ha un impatto.<\/p>\n\n\n\n Ad esempio, \u00e8 buona pratica sfruttare il Cloud che \u00e8 un ambiente totalmente programmabile, per creare pi\u00fa ambienti di sviluppo su cui testare le modifiche prima di renderle effettive in produzione. <\/p>\n\n\n\n Lo sfruttamento di pi\u00fa ambienti in cui sperimentare, validare, e testare i propri workload porta a ridurre il rischio di errori umani creando un processo automatico, controllato e reversibile. <\/p>\n\n\n\n Anche nelle fasi di rilascio delle evoluzioni dei nostri prodotti o dei nostri portali al pubblico \u00e8 necessario tenere presente la fault-tolerance. Ad esempio, con il Blue-Green Deployment<\/strong>, due ambienti identici (blu e verde) vengono mantenuti in parallelo. Durante un aggiornamento, il traffico utente viene reindirizzato dall’ambiente “blu” a quello “verde”. Questa tecnica consente di effettuare aggiornamenti senza downtime, e in caso di problemi, \u00e8 possibile tornare rapidamente all’ambiente “blu”.<\/p>\n\n\n\n Il Blue-Green deployment \u00e8 affiancabile da pratiche come quelle definite nel Canary Deployment <\/strong>o quelle del Rolling deployment.<\/strong> Con queste tecniche l’aggiornamento viene distribuito solo a un piccolo sottoinsieme di utenti. Questi servono da indicatori per rilevare eventuali problemi e se non vengono riscontrati problemi, l’aggiornamento viene gradualmente esteso a un pubblico pi\u00f9 ampio, in caso contrario, viene bloccato l’aggiornamento dirottando i pochi utenti “tester” sul vecchio ambiente.<\/p>\n\n\n\n Tutti questi sono approcci di deployment graduali e controllati che riducono il rischio di incorrere in guasti in produzione e di garantire che le modifiche siano stabili e affidabili prima di essere esposte agli utenti finali. <\/p>\n\n\n\n (Per saperne di pi\u00f9 su Blue-Green Deployment, Canary Deployment e Rolling Deployment potete leggere questi articoli: Come creare una Pipeline di Continuous Deployment su AWS per il Deploy Blue\/Green su ECS<\/a> – Strategie di rilascio con Amazon ECS: il blue\/green deployment<\/a>)<\/em><\/p>\n\n\n\n Arrivati a questo punto, la domanda che sorge spontanea \u00e8: come verifico la mia tolleranza al guasto?<\/p>\n\n\n\n Il Chaos Engineering<\/strong> \u00e8 una pratica progettata per testare la resilienza e la tolleranza ai guasti di un sistema informatico in modo controllato e pianificato. L’obiettivo principale del chaos engineering \u00e8 identificare le debolezze e le vulnerabilit\u00e0 del sistema prima che possano causare problemi reali in produzione.<\/p>\n\n\n\n Uno degli esempi di strumenti che sono stati creati per verificare la robustezza degli ambienti \u00e8 la Chaos Monkey sviluppata da Netflix. Andate a vedere il progetto qui<\/a>. Questo strumento ha questo nome strano perch\u00e9 vuol fare in modo di simulare i comportamenti imprevedibili di una scimmia abbandonata all’interno di un data center. Cosa potrebbe mai accadere? Cavi staccati, bottoni premuti, rack distrutti ecc. <\/p>\n\n\n\n Se l’infrastruttura regge e non si verificano downtime, allora si pu\u00f2 finalmente dire di aver raggiunto la fault-tolerance. <\/p>\n\n\n\nCos\u2019\u00e8 la Fault Tolerance?<\/h2>\n\n\n\n
Shared Responsibility Model<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/11\/image1-1024x783.png\")
<\/figure><\/div>\n\n\nFault Tolerance su AWS<\/h2>\n\n\n\n
Fault Tolerance nei rilasci<\/h2>\n\n\n\n
Chaos Engineering<\/h2>\n\n\n\n
In conclusione<\/h2>\n\n\n\n