particles.io

11/05/2021

La prima cosa da fare in seguito ad un incidente è individuarne le cause, per due motivi fondamentali e uno eticamente opportuno:
- Capire cosa è successo
- Evitare che si ripeta
- [Informare gli utenti dei problemi tecnici affrontati = trasparenza al 100%]

Al giorno d'oggi, riuscire a tracciare tutti i dati e le metriche di ogni componente e micro servizio non è una cosa banale e scontata come collezionare i log e tenerli archiviati da qualche parte per, poi, analizzarli con calma.

Si tratta di combinare molteplici strumenti, molteplici metriche e log in vari formati, da incrociare nel momento opportuno per risalire alle radici del problema e fornire una soluzione, pratica e analitica.

Quindi no, non bastano i log applicativi e "di sistema" per rimettere insieme i pezzi del puzzle ed avere una visione di insieme nel momento del bisogno, soprattutto perchè, nella maggior parte dei casi, è necessario attivarsi in tempi molto rapidi e fornire spiegazioni sensate sullo stato dell'incidente.

Avere un quadro preciso e il più dettagliato possibile su cosa stia accadendo nello stack applicativo, dal monitoraggio della risorsa in Cloud fino alla profilazione dei componenti software, consente di prepararsi ad affrontare qualsiasi situazione e di migliorare la resilienza del software.

08/05/2021

Uno dei temi più importanti da affrontare insieme al team, che spesso non viene affrontato a dovere o peggio, non viene del tutto considerato, è la preparazione al disastro.

La preparazione al disastro consente di affrontare ogni situazione critica con le giuste contromisure, una serie di attività da mettere in pratica per ripristinare e recuperare un servizio non più disponibile.

Per evitare di trovarsi impreparati durante un incidente critico e lasciare al caso il susseguirsi degli eventi, si possono pianificare delle procedure da eseguire periodicamente e da integrare nel proprio flusso di lavoro:

* Enumerare tutte le possibili cause di un incidente
* Associare le cause dei possibili incidenti ai servizi, interni ed esterni
* Stimare RPO e RTO per ognuna delle cause individuate
* Formulare un piano di recupero e ripristino per ognuna delle cause individuate
* Enumerare le soluzioni di backup adottate per ognuno dei servizi che compongono l'infrastruttura
* Testare ciclicamente le soluzioni di ripristino

Queste attività devono essere elaborate insieme al team di sviluppo, la cultura si basa proprio su questo principio, eliminare le barriere comunicative tra i vari team condividendo la conoscenza e le attività pratiche al fine di raggiungere un obiettivo comune.

31/03/2021

Happy Birthday Docker!
8 years... and almost all of them together.
https://www.docker.com/birthday

20/01/2021

[DEVOPS]
In questo breve articolo un'introduzione ad un nuovo progetto a cui sto lavorando in queste settimane. L'obiettivo è quello di realizzare un cluster di istanze su GCP in grado di processare migliaia di immagini, in parallelo, e classificarle tramite dei modelli di ML.

Stranamente non uso Docker, ormai è un caso veramente raro, ma in questo progetto si fa largo uso di GPU Nvidia e non ho ancora preso confidenza con Docker su GPU. Sicuramente mi prenderò il tempo per lavorarci quando il team di AI sarà operativo con la prima release e ci sarà una stabilità generale nei processi di deployment.

In questo progetto sto lavorando su GCP con la combinazione di alcuni dei miei tool preferiti:

In parallelo sto realizzando un wrapper in Ansible per migliorare l'esperienza di interazione con GCP, spostando la configurazione delle risorse di GCP dai rispettivi task nel Playbook alla definizione delle variabili direttamente su AWX.

In queste settimane sto lavorando ad un nuovo progetto che prevede la creazione di un cluster dinamico di istanze GCP con il compito di elaborare una sequenza di migliaia di immagini e classificarle in base a dei modelli definiti attraverso un processo di machine learning (ML). Lo sviluppo del proge

23/10/2020

[LOL]
Happy Friday to all of our supporters!

20/10/2020

Quanto vale una copia di backup di cui non si è mai verificata la consistenza e l’integrità?
Zero!
O meglio, un valore variabile di riuscita, di un'eventuale operazione di recovery, che oscilla tra lo 0 e il 100%.
Quindi è un po' come affidarsi al caso durante una procedura di disaster recovery, non certo una bella sensazione, soprattutto per chi deve garantire disponibilità e affidabilità di un'intera infrastruttura, dove tutto ruota intorno ai dati.
Ecco perchè ritengo sempre di fondamentale importanza definire e pianificare, a intervalli regolari, delle procedure di verifica della consistenza e validità dei backup, soprattutto del database.

Affidarsi alle magie dei vari tool in grado di automatizzare e ottimizzare la procedure di backup è facile, sentirsi sicuri che tutto sia pronto e funzioni senza errori per un eventuale recupero di emergenza è tutt'altra cosa.

Appunto per questo suddivido sempre le procedure di backup in 2 fasi, la prima è quella in cui viene eseguito fisicamente il backup sullo storage di archiviazione (DONE) e, la seconda, è quella in cui viene verificata la consistenza e integrità dei dati (DONE-DONE) attraverso tecniche e modalità differenti in base al tipo di dato copiato.

Questa soluzione di verifica, schedulata nel tempo, porta con sé una serie di vantaggi in termini operativi e di affidabilità, tra cui:
- Verifica della consistenza dei dati
- Verifica della procedura di recovery
- Statistiche sui tempi di recovery del DB di produzione (RTO)
- Procedura integrabile in diversi contesti: testing o recovery (anche in produzione)

13/10/2020

[G Suite]
Google introduce un nuovo brand con un'esperienza d'uso del prodotto rinnovata e un insieme di offerte mirate a fornire strumenti migliori.

G Suite diventa Google Workspace.

Una suite integrata di applicazioni per la produttività e la collaborazione native per la cloud e sicure, con la tecnologia IA di Google. Include Gmail, Documenti, Drive, Calendar, Meet e altro ancora.

09/10/2020

First design stage of the new release deployments in a Blue-Green architecture. Jenkins is the main deployments orchestrator and all "infrastructure as code" is stored on GitLab. Some of the tasks are supported by AWX/Ansible to run critical jobs like DB replication or DB restoring in case of disaster recovery.

Blue-Green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green. At any time, only one of the environments is live, with the live environment serving all production traffic.

10/07/2020

Would you like to try Ansible on Docker but don't have time to read documentation or figure out how it works?

Don't worry, check this Gist bash script and play with Ansible in few seconds.

Bash script to run Ansible tasks or playbooks in a Docker container - docker-ansible.sh