Alla ricerca dell'ignoto sconosciuto

Meta offre un ecosistema di prodotti che vengono utilizzati da miliardi di utenti ogni giorno, che sia per le connessioni sociali o per le interazioni con l'azienda. Questi miliardi di utenti ci chiedono anche di fornire nuove funzionalità e miglioramenti ai nostri prodotti, a un ritmo costante e accelerato. In ragione dell'ampia base di utenti, forniamo migliaia di modifiche al codice ogni giorno per soddisfare tali aspettative.

Il rilascio continuo di un numero così elevato di miglioramenti ai prodotti implica il rischio di potenziali regressioni in termini di integrità dell'app, con conseguente peggioramento dell'esperienza utente. In Meta, disponiamo di una serie di sofisticati strumenti di prevenzione contro il rilascio di modifiche difettose ai prodotti. Questi strumenti di prevenzione monitorano vari segnali dei prodotti e rilevano le regressioni prima del rilascio delle app. Le tre aree cui fanno riferimento questi segnali sono le Prestazioni, la Resistenza (intesa come affidabilità funzionale e sistemica) e l'Efficienza. Collettivamente, si parla di "PRE" dei prodotti. La prevenzione inizia con varie tracce analitiche e di osservabilità rilevate dagli sviluppatori in fase di creazione del codice. Inoltre, gli strumenti di osservabilità e monitoraggio raccolgono dati dall'utilizzo interno dei prodotti negli ambienti di pre-produzione. Gli strumenti di controllo qualità sia manuali che automatizzati testano i prodotti in quegli ambienti di pre-produzione

e, sebbene questi meccanismi esistano per valutare la qualità delle modifiche al codice prima della fase di produzione, evitando così l'impatto sull'utente, può accadere che modifiche difettose passino in produzione e che debbano quindi essere rielaborate e mandate nuovamente in produzione. Per mitigare il rischio che si verifichi un problema con impatto su un pubblico esteso, utilizziamo diversi meccanismi di rilascio incrementale delle modifiche.

Quando c'è una deviazione dalla funzionalità che l'utente si aspetta, parliamo di regressione. Quando l'utente ci informa che qualcosa non sta funzionando come previsto, parliamo di segnale. Raccogliamo segnali di regressione nel minor tempo possibile a livello sistemico attraverso insight dei dati e codice instrumentato, quindi ci mettiamo al lavoro per ridurre l'impatto sugli utenti implementando le opportune correzioni. Nei casi in cui non riceviamo un segnale forte dai nostri strumenti, ci affidiamo alle segnalazioni degli utenti come segnale che si è verificata una regressione. Queste segnalazioni arrivano attraverso vari meccanismi, come l'azione di scuotere il telefono per segnalare un problema se, nel momento in cui questo si verifica, l'utente si trova nell'app.

Per garantire di soddisfare le esigenze dei clienti e di farlo il più rapidamente possibile, a volte entro lo stesso giorno, Meta ha investito molto in una serie di programmi e sistemi di affidabilità per consentire una significativa reattività su larga scala.

I segnali possono provenire dai nostri utenti pubblici (individui, aziende, gruppi, ecc.) o da utenti interni. Esaminiamo attentamente i segnali degli utenti interni per evitare che modifiche indesiderate arrivino in produzione. Tieni presente che i segnali sono aggregati; ad esempio, includono il numero di bug per milione di utenti. I segnali possono provenire anche da strumenti e scenari di test automatizzati, strumenti di sviluppo (avvertiamo gli sviluppatori di modifiche che potrebbero causare problemi di runtime), registri di sistema e molte altre fonti. Disponiamo inoltre di strumenti che sfruttano questi segnali in modo da individuare rapidamente le cause e le correzioni appropriate.

Una volta identificata una regressione, procediamo a trovare rapidamente gli ingegneri di competenza per applicare le correzioni e rilasciarle. A seconda della complessità della regressione, utilizziamo una serie di metodi per individuare gli ingegneri giusti, sfruttando anche le capacità di apprendimento automatico di Meta. Data la modalità di funzionamento dell'apprendimento automatico, per tenere il passo con il cambiamento costante, questo processo deve essere continuativo in fase di rilascio di nuove funzionalità e riaddestramento dei nostri modelli.

In sintesi, quello che facciamo è: rilevare le regressioni, mitigarle, prevenirle e contenerle in modo sostenibile. Nel processo, massimizziamo la reattività, il ritorno sull'investimento e l'efficienza.

Nella prossima sezione, vedremo più nel dettaglio come stabilire con certezza che si è verificata una regressione e, una volta individuata, come rispondere.

Tradurre gli aspetti sconosciuti in aspetti noti e quantificarli

Quando parliamo di aspetti sconosciuti, ci riferiamo ai bug riscontrati da un utente o da un sistema. Possiamo venire a conoscenza di un potenziale bug da una serie di risorse diverse.

• Test sintetici del corretto funzionamento delle nostre app e dei prodotti specifici al loro interno.
• Test svolti da utenti interni per il rilevamento di bug. Ciò può includere i nostri team di test dedicati o l'estesa base utenti all'interno di Meta.
• Problema riscontrato da utenti esterni con l'utilizzo della finestra di dialogo per la segnalazione di problemi nelle nostre app.

Questi bug sono sconosciuti fino a quando non vengono effettivamente contrassegnati come incidenti riscontrati dagli utenti. Quando il numero di queste segnalazioni raggiunge una certa soglia, le consideriamo un vero positivo, indice di un evento di regressione; in altre parole, una modifica del codice ha creato un nuovo bug e dobbiamo procedere rapidamente alla mitigazione. Esistono due tipi di segnalazioni principali:

• "L'ignoto conosciuto": quando un codice instrumentato rileva e segnala la regressione; abbiamo a disposizione una serie di strumenti in grado di produrre questo segnale
• "L'ignoto sconosciuto": quando la regressione non viene rilevata internamente, ma ci basiamo sulla segnalazione dell'utente

A loro volta, le regressioni sono suddivise in diverse categorie, ad esempio un bug del codice, qualcosa di più simile allo spam o qualche altra violazione della normativa sui contenuti. Il nostro focus è sulla prima area, in cui lavoriamo per gestire i problemi di esperienza utente relativi al codice. Come si fa con gli utenti che segnalano migliaia di problemi?

Generazione di segnali e insight

Per gestire l'elevato volume di segnalazioni, generiamo segnali specifici che contrassegnano i problemi per noi. Il primo tipo di segnale è quello che, con soglie opportunamente definite, ci informa che si è verificato un incidente o una regressione. Ricordiamo che è importante tenere presente che possono essersi verificati più eventi a seconda del tipo di regressione. Ad esempio, una regressione potrebbe interessare più prodotti a causa di una base di codice comune. Cerchiamo tali punti in comune e li gestiamo come un singolo incidente per allineare in modo ottimale le risorse. Il grafico sotto è un esempio di come appare visivamente l'allontanamento dalla linea di tendenza, a indicare una regressione.

Raccogliamo quindi ulteriori segnali, alcuni dei quali indicano il tipo di regressione che potrebbe essersi verificata. Questi segnali forniscono informazioni sui sintomi associati alla regressione e sono generati da algoritmi di apprendimento automatico ottimizzati per particolari prodotti Meta. Gli algoritmi analizzano le segnalazioni degli utenti per determinare cosa ha causato la regressione e quindi quale team di ingegneri può risolverla al meglio implementando una correzione del codice o un'altra misura.

Molti altri segnali vengono generati anche sulla base dei dati di log raccolti. Questi log diagnostici possono essere lato client o lato server raccolti, con il consenso dell'utente, per determinare la causa. Le app incorporano adeguati flussi di consenso per determinare se questo tipo di dati può essere raccolto in base alle autorizzazioni dell'utente. Consideriamo anche la longevità di questi dati per rispettare le normative applicabili.

La combinazione di segnali ci consente di concentrarci sulla regressione e assegnarla al team di prodotto corretto affinché provveda rapidamente a mitigare il problema e ripristinare l'esperienza dell'utente secondo le aspettative.

Gli insight derivano anche dai risultati in forma aggregata. Esaminiamo i dati in modo da trovare cause alla radice comuni e determinare se è necessario apportare modifiche per evitare che le regressioni si ripetano. Questo è un aspetto chiave per avere un approccio solido alla gestione dei problemi di esperienza utente in quanto ci aiuta a ridurre al minimo la superficie di regressione nel tempo.

Le nostre app mobili non solo includono percorsi di navigazione che consentono all'utente di segnalare un problema, ma forniscono anche la possibilità di indicare un problema scuotendo il dispositivo. In questo modo, è possibile raccogliere dati di telemetria nel contesto, i quali vengono ulteriormente migliorati tramite i segnali black box provenienti dall'app. La black box è come un registratore di volo che acquisisce automaticamente determinati log (come consentito dagli utenti) sui processi in corso nell'app nel momento in cui è stato segnalato il bug in modo da poter diagnosticare meglio il problema.

Tutti questi dati di telemetria sono inseriti in una serie di visualizzazioni della sequenza temporale per aiutare i team di ingegneri a determinare la causa del problema. Data la rapida cadenza di rilascio delle nostre app, nonché delle modifiche nei componenti delle app lato server, individuare il problema sarebbe difficile senza questa funzionalità. Avere a disposizione i dati di telemetria nel tempo ci aiuta a rilevare gli schemi nelle regressioni in modo tale da prevenirli in futuro.

Passaggio a superfici di prodotto meno estese

Poiché abbiamo migliorato la nostra capacità di generare più precisione nei nostri segnali, siamo in grado di attaccare una porzione maggiore della superficie di regressione, parti della quale in precedenza non sarebbero state rilevate. Una superficie rappresenta una particolare offerta all'interno di un prodotto, come la sezione Notizie o Reels. Questa è una vera e propria sfida dal momento che i prodotti non solo hanno molte funzioni granulari, ma vengono introdotte regolarmente nuove funzionalità. Quindi non solo la superficie di regressione è ampia, ma cresce anche nel tempo. Di conseguenza, le nostre strategie difensive e offensive devono adattarsi continuamente.

Per gestire questi numeri crescenti, ci sono diverse condizioni che devono essere soddisfatte:

1. Dobbiamo avere una copertura precisa e una corretta classificazione delle superfici di prodotto esistenti
2. Dobbiamo ridurre la superficie di regressione per i prodotti esistenti (leggi: prevenzione)
3. Dobbiamo espandere la portata dei nostri algoritmi a nuove superfici di prodotto

Se queste condizioni non sono soddisfatte, rischiamo di avere un sistema sovraccarico che non può essere gestito a causa delle dimensioni, della complessità e dell'imprecisione. Per questo motivo i nostri sforzi mirano a mantenere un equilibrio tra questi fattori e al contempo a gestire in modo efficiente le nostre operazioni quotidiane.

Oltre i bug

Mentre continuiamo a ridurre la superficie di regressione (senza abbassare la guardia), aumentiamo la nostra attenzione in altre aree importanti: prevenzione e usabilità.

La prevenzione riguarda:

1. Cosa possiamo apprendere dalle regressioni precedenti?
2. Quali difese implementiamo affinché queste regressioni non si ripetano?
3. Come possiamo garantire nel tempo che la superficie di regressione continui a diminuire?

Come abbiamo già spiegato, aggreghiamo i dati delle regressioni precedenti per imparare da essi. Questi apprendimenti possono tradursi in:

1. Inserimento nel nostro codice di marcatori che ci avvisino in futuro, mentre siamo ancora in ambiente di pre-produzione, in modo da poter impedire che una modifica indesiderata passi in produzione
2. Aumento della copertura dei test a vari livelli per rilevare tali regressioni
3. Modifica del prodotto stesso per la risoluzione di questi problemi

La prevenzione ci consente di spostare le regressioni sempre più a sinistra nella fase di sviluppo, con una conseguente riduzione dei costi. Questo è possibile grazie alla registrazione di segnali sufficientemente dettagliati nelle prime fasi del processo di sviluppo, a partire dalla creazione del codice e dai cicli di rilascio di pre-produzione. Ciò non solo migliora l'esperienza utente, ma riduce anche i costi di sviluppo e ci permette di dedicare maggiori risorse allo sviluppo di nuovi prodotti.

Ottimizzando la nostra capacità di gestire le regressioni in modo efficiente, possiamo concentrarci maggiormente sulla gestione dei problemi relativi a usabilità e poca chiarezza da parte degli utenti. Si tratta di preoccupazioni significative in quanto implicano il miglioramento dei prodotti anziché la loro riparazione. Nel tempo, il rapporto tra problemi di usabilità e regressioni dovrebbe aumentare e il numero totale di problemi di usabilità e regressioni dovrebbe diminuire.

In definitiva, ciò si traduce in un'esperienza utente che migliora continuamente sia in termini di funzionalità che di usabilità.

Questo articolo è stato scritto in collaborazione con Bijan Marjan, Technical Program Manager di Meta.