Rollback Strategy (was: Sentirsi Burioni)

La shitstorm sull'operato di Microsoft/CrowdStrike/Chiunque continua, e da persone diverse mi arrivano informazioni diverse, di significati diversi. Non so se questo scattering delle informazioni potrebbe anche essere voluto – per motivi di damage control – oppure potrebbe contenere pezzi di realta'. Andiamo un attimo ad esaminare alcune delle cose piu' competenti – o meno stravaganti che ho sentito, da persone che conosco come competenti.

1. Rollback Strategy

Chiunque abbia lavorato su sistemi enterprise si sara' trovato ad eseguire un upgrade di qualcosa in un sistema di produzione. Avra' notato che, qualsiasi processo si segua (Il CAB di ITIL, o la “Go/NoGo meeting”, o qualsiasi altra cosa si faccia, si discute comunque di qualcosa: la strategia di Rollback.

Anche questa si puo' chiamare in tanti modi, ma la domanda che sta dietro e': dal momento che Murphy e' inarrestabile, cosa facciamo se passa da queste parti e l'upgrade fallisce? Bella domanda.

A seconda di come funzioni il sistema le risposte sono molteplici. Negli ultimi tempi, quasi tutti gli orchestratori, da quelli del cloud a quelli come Kubernetes, e altri, lavorano col concetto di “artifact”: significa che eseguire un upgrade significa passare dalla versione x.y.Z ad una superiore, ma pur sempre versionata. L'artifact e' un concetto estendibile, che puo' anche indicare una VM, o la sua immagine.

E la domanda e' “se X.y.10 , come rimettiamo online X.y.09”? A quel punto, a seconda se il sistema e' dichiarativo o meno, pensiamo semplicemente a prendere la vecchia versione salvata e riportare tutto alla condizione in cui funzionava. BAsta sempre? Beh . no: se da qualche parte c'era, per esempio, un database che il solo avvio della nuova versione ha modificato, e i programmatori sono abbastanza imbecilli, potrebbero esserci dei problemi anche cosi'.

In generale,le strategie di Rollback possono diventare complesse, includere un dump dei dati da recuperare, includere uno snapshot, eccetera eccetera. Sino alla versione piu' estesa, che comprende un ambiente di Disaster Recovery, cioe' una copia di tutto, ma proprio di tutto, da cui ripristinare una situazione funzionante.

Ma volendolo fare in maniera “Devops”, in genere l'orchestratore stesso sa come fare il rollback, riportando il vecchio “artifact” in esecuzione.

Il compito principale di un team di operation, di fronte ad un casino, e' di ripristinare le precedenti condizioni di operativita'.

Durante un incidente di questa dimensione, Operations non investiga, o investiga solo se strettamente necessario. C'e' uno SLA da rispettare, cioe' il disservizio ha una durata massima contrattuale, se non si capisce subito cosa diavolo succeda si ripristina il sistema precedente, si salvano le immagini malfunzionanti, e si parla di analisi “post-mortem”.

Ma per quante voci contrastanti io senta, tutto questo non sembra essere successo. Questi , se e' vero quanto si dice, iniettavano aggiornamenti senza nessuna rollback strategy. E' vero quello che si dice? E perche' questa pratica non ha generato la dovuta diffidenza? Quando facevano i loro CAB, o qualsiasi riunione facessero per autorizzare l'upgrade, cosa si dicevano nel discutere la strategia di Rollback? Se e' vero quello che si dice, ovviamente, si stava facendo qualcosa che in ambiente enterprise non e' decisamente una buona pratica, specialmente se il servizio e' mission critical.

Sinora, qualsiasi cosa io senta dire, l'unica cosa evidente e' che la strategia di rollback e' lunga, e deve essere eseguita manualmente. E causa un outage, una mancanza di servizio.

2. “Non sarebbe successo con Linux/*BSD

Uhm. LA risposta e' “ni”.

No, perche' se io me ne frego e inietto moduli a freddo nel kernel, coi dovuti privilegi , posso causare un bel kernel dump anche in un sistema operativo UNIX-like.

E posso scrivere codice che mandi in panico il kernel? Certo che si'. Nelle condizioni in cui operava CrowdStrike, cioe' di completa fiducia e con la capacita' di sovrascrivere parti dell' OS a runtime, posso crashare qualsiasi cosa.

Ma la risposta e' anche un po' “no”, nel senso che questi sistemi “invitano” a fare le cose nella maniera giusta. Se volessi fare quello che fa CrowdStrike usando linux, non perderei tempo a reimplementare la ruota. Userei qualcosa che c'e' gia' in Linux, che e' eBPF. E siccome funziona molto bene e c'e' gia' del codice scritto, molte aziende preferiranno spendere meno soldi in programmatori, non reinventare la ruota e usare eBPF. E' il caso di moltissimi altri provider di cybersecurity sul mercato.

Anche i BSD hanno il loro BPF, ad onor del vero il BPF originale e' nato du uno unix BSD, ma quello di linux e' completamente diverso.

Allora basta? eBPF risolve tutto? Usa quello e sta zitto? Uhm. E' vero che usando un compilatore jit , eBPF implica qualche check preliminare, e siccome offre anche strumenti di trace in userland, allora “invita” a non reinventare la ruota e usare quelli. Molto bene.

MA d'altro canto, parliamo di XDG? LA possibilita' di scrivere pezzetti di codice in C, linguaggio non molto safe, e iniettarli allo stesso livello del driver, cioe' del kernel, un pochino riporta il rischio di spaccare tutto.

Quindi: non sarebbe successo con Linux/*BSD? La risposta e' “dipende”. Posso pensare che succeda meno perche' sono sistemi che contengono gia' strumenti di trace e ktrace, e quindi “invitano” le aziende a risparmiare soldi e usare quelli.

Non mi allargherei piu' di tanto, insomma.

3. MA che diavolo hanno iniettato, alla fine?

Qui sento di tutto. Da file “pieni di zeri” a “file corrotti”, a “file pieni di bit a caso”. Ora, le checksum esistono ormai da 40 anni, e non capisco proprio come si faccia ad ottenere un effetto come “il mio file si e' corrotto nel download”. Le firme digitali anche, e gli eseguibili formati pure: sembra difficile che sia successo. Sembra piu' una spiegazione a portata di Aranzulla, ma difficilmente succedera' su un sistema moderno. Se e' vero quello che si sente dire.

Il concetto di “bit senza senso” mi lascia a sua volta perplesso. Ho lavorato su appliance di Juniper, dove e' possibile programmare (come si fa con XDG) delle specifiche schede hardware per sniffare il traffico e cercare dei pattern, e se osservate questi pezzi di roba binaria, possono sembrare delle sequenze senza senso. In alcune applicazioni scienfifiche si caricano anche dati random, cioe' numeri casuali venduti da aziende che di lavoro vendono numeri DAVVERO casuali.

E' difficile capire cosa si intenda per “numeri a casaccio”, e siccome tutti parlano per sentito dire, sarei molto propenso al dubbio.

Come dicevo, e' tutto in caciara. L'unica cosa certa e' che qualcuno ha fatto l'upgrade di qualcosa, e non aveva una strategia di rollback.

Sinora, e' l'unica cosa certa.

Uriel Fanelli

Il blog e' visibile dal Fediverso facendo il follow a:

@uriel@keinpfusch.net

Contatti: