Case Study Fintech: Da 40 Incident al Mese a 4

In questo articolo:

• La situazione prima della remediation
• Diagnosi: dove era concentrato il debito
• L’approccio alla remediation
• Risultati: incident scesi da 40 a 4 al mese
• Cosa ha fatto la differenza
• Conclusione

Questo case study sul debito tecnico documenta il lavoro di remediation che Eden Technologies ha condotto con una piattaforma fintech che stava vivendo 40 incident in produzione al mese. La piattaforma gestiva l’elaborazione dei pagamenti e la gestione dei conti per gli utenti finali. Al momento del coinvolgimento di Eden Technologies, il team di ingegneria stava trascorrendo la maggior parte del suo tempo a rispondere agli incident piuttosto che a costruire il prodotto. I deployment erano lenti, rischiosi e poco frequenti. Il team aveva smesso di fidarsi del codebase. Il risultato del lavoro è stata una riduzione da 40 incident al mese a 4, ottenuta attraverso un processo di remediation strutturato e incrementale che ha mantenuto la piattaforma operativa per tutto il tempo.

La Situazione Prima della Remediation

La piattaforma era in produzione da diversi anni ed era cresciuta attraverso una combinazione di rapido sviluppo di funzionalità e acquisizione di prodotti più piccoli. Il codebase rispecchiava questa storia: più stili architetturali coesistevano nello stesso repository, la logica di business era duplicata tra moduli che erano stati uniti senza riconciliazione e la test suite copriva circa il 15 percento del codice di produzione.

I 40 incident al mese non erano distribuiti in modo uniforme. Circa due terzi originarono da tre aree specifiche del codebase: il modulo di elaborazione delle transazioni, il servizio di notifica e il layer di sincronizzazione dei dati tra due prodotti che erano stati integrati senza un’interfaccia pulita.

Il team di ingegneria sapeva dove erano i problemi. L’ostacolo non era la conoscenza. Era la capacità. Ogni ora trascorsa a rispondere agli incident era un’ora non disponibile per correggere le cause principali. Il team aveva raggiunto uno stato in cui la risposta agli incident consumava abbastanza capacità da far sì che il lavoro generatore di debito continuasse per default.

Questa è la trappola del debito tecnico: il sistema produce abbastanza problemi da consumare la capacità che sarebbe necessaria per risolverlo. L’intervento esterno è spesso l’unica via d’uscita.

Diagnosi: Dove era Concentrato il Debito

Eden Technologies ha iniziato con una valutazione di software due diligence del codebase. Gli obiettivi erano identificare le aree a più alto rischio, quantificare il costo del debito esistente in termini di frequenza degli incident e tempo di consegna e definire una sequenza di remediation che avrebbe prodotto risultati misurabili abbastanza rapidamente da creare capacità per un lavoro più profondo.

La valutazione ha confermato ciò che il team di ingegneria aveva riferito. Il modulo di elaborazione delle transazioni era cresciuto fino a oltre 8.000 righe di codice senza struttura interna. Logica di business, accesso al database, chiamate API esterne e gestione degli errori erano mischiate ovunque. Non c’erano unit test. Il modulo era stato modificato da più di quindici sviluppatori nel corso di tre anni.

Il servizio di notifica aveva un problema diverso: era stato parzialmente riscritto due volte e le vecchie e nuove implementazioni funzionavano in parallelo, con logica di routing non chiaramente documentata. In pratica, alcune notifiche percorrevano un percorso e altre un altro, e le condizioni non erano sempre prevedibili.

Il layer di sincronizzazione dei dati era la terza area problematica principale. Era stato costruito per collegare due prodotti con modelli di dati diversi e utilizzava un meccanismo di polling che creava race condition sotto carico.

L’Approccio alla Remediation

La remediation era strutturata in tre fasi, progettate in modo che ogni fase riducesse la frequenza degli incident abbastanza da creare capacità aggiuntiva per la fase successiva.

Fase 1: Stabilizzazione. L’obiettivo immediato era ridurre rapidamente il tasso degli incident, senza ristrutturare il codice. Ciò ha comportato l’aggiunta di monitoraggio e alerting alle tre aree problematiche in modo che i fallimenti venissero rilevati più velocemente e il mean time to recovery migliorasse. Ha anche comportato la scrittura di characterization test per i percorsi più fragili nel modulo delle transazioni, non per migliorare il codice ma per documentarne il comportamento attuale e individuare le regressioni durante le modifiche successive.

Fase 2: Isolamento. L’implementazione parallela del servizio di notifica è stata risolta instradando tutto il traffico attraverso la nuova implementazione e rimuovendo il vecchio percorso. Questo ha richiesto una migrazione attenta con controllo tramite feature flag, testata in modo incrementale prima del cutover completo. Il layer di sincronizzazione dei dati è stato refactorizzato per utilizzare un approccio event-driven anziché il polling, il che ha eliminato le race condition che causavano la maggior parte degli incident di sincronizzazione.

Fase 3: Ristrutturazione. Il modulo di elaborazione delle transazioni è stato decomposto nel corso di sei settimane. La logica di business è stata estratta in un layer separato con unit test. L’accesso al database è stato consolidato dietro un pattern repository. Le chiamate API esterne sono state avvolte in adapter che potevano essere testati e monitorati in modo indipendente. Il refactoring è avvenuto in una sequenza di modifiche piccole e indipendentemente mergeable, ognuna delle quali manteneva il modulo in uno stato funzionante.

Risultati: Incident Scesi da 40 a 4 al Mese

Dopo le tre fasi, il tasso degli incident è sceso da 40 al mese a 4 al mese. I quattro incident rimanenti erano in aree al di fuori dei tre moduli che erano stati affrontati.

La riduzione non è stata immediata. Dopo la Fase 1, il tasso degli incident è sceso a circa 28 al mese, principalmente perché il rilevamento più rapido ha ridotto il tempo in cui i singoli incident rimanevano attivi ma non ne ha impedito il verificarsi. Dopo la Fase 2, il tasso è sceso a circa 12, perché gli incident di notifica e sincronizzazione sono stati in gran parte eliminati. Dopo la Fase 3, il tasso ha raggiunto 4.

Il tempo impiegato per incident è diminuito significativamente. Prima della remediation, gli incident nel modulo delle transazioni richiedevano ore per essere diagnosticati perché il codice era difficile da ragionare e il monitoraggio era scarso. Dopo il refactoring, la stessa classe di incident poteva essere diagnosticata in minuti perché il codice aveva confini chiari e il monitoraggio copriva i percorsi chiave.

Cosa ha Fatto la Differenza

Il sequenziamento del lavoro per impatto. Affrontare prima le tre aree con più incident ha prodotto risultati abbastanza rapidamente da giustificare la continuazione del lavoro.

Non fermare il feature work. La remediation era strutturata per procedere in parallelo allo sviluppo del prodotto. La Fase 1 richiedeva tempo ingegneristico minimo. Le Fasi 2 e 3 erano dimensionate per utilizzare la capacità liberata dalla riduzione degli incident.

Trattare gli incident come segnali di debito. Ogni incident è stato registrato con la sua area di causa principale durante il progetto. Questi dati hanno guidato la prioritizzazione e dimostrato i progressi in termini che il business comprendeva.

Chiara definizione del fatto per ogni fase. Le fasi avevano criteri di completamento espliciti: tipi specifici di incident eliminati, specifiche modifiche al codice distribuite, soglie specifiche di copertura dei test raggiunte.

Conclusione

Questo case study sul debito tecnico dimostra che la remediation strutturata produce risultati misurabili, anche in codebase con anni di debito accumulato. La chiave è iniziare con la diagnosi piuttosto che con la prescrizione, sequenziare il lavoro per impatto e mantenere la consegna durante tutto il processo.

Ridurre gli incident da 40 a 4 al mese non è stato ottenuto riscrivendo la piattaforma. È stato ottenuto affrontando i problemi strutturali specifici che generavano il maggior numero di incident, in una sequenza che permetteva a ogni fase di finanziare la successiva.

Hai un codebase con questi problemi? Parliamo del tuo sistema