Arda Solutions s.r.l. | The Informal Blog

cartoon251

Di recente abbiamo parlato di automation come rimedio rapido a problemi che richiedono una soluzione veloce. Come detto è necessaria una buona dose di “cultura”, processi correttamente ingegnerizzati, e prodotti a supporto dell’automazione. Avremo quindi un infrastruttura in grado di reagire a problemi e modificare la propria configurazione in tempi rapidi. Ma cosa succede quando l’aggiornamento di appliance e device è direttamente responsabilità del vendor? Abbiamo il caso specifico della corsa ai ripari in seguito alla “scoperta” dell’heart bleed bug e la nostra odissea per supportare i clienti in fase di aggiornamento contro i “tempi biblici dei vendor” è, ahimè, appena iniziata

Il problema, in realtà, è più un problema di tempi che di effettivo patching. I vendor con cui siamo in contatto ci hanno già tutti assicurato che le patch saranno presto disponibili ma, il problema, è più che altro collegato al movimento improvviso di questi colossi che hanno normalmente tempi certi e vanno in estrema sofferenza a causa di eccezioni non previste.

Perfino i bug vengono stimati e pianificati nel ciclo di vita di un software e, facendo parte di questo di ciclo di vita, avranno già delle finestre temporali prestabilite, trovarsi di fronte ad un bug come questo che ha avuto un grosso impatto mediatico, pone questi vendor in seria difficoltà organizzativa.

Normalmente infatti, una società software di una certa serietà e complessità, di fronte ad un bug (o minor release) deve:

  • Tradurre il bug: operazione difficilissima, poiché molte volte il bug è descritto più o meno come segue: “Abbiamo scoperto che tutti ci possono rubare i dati, oddio che incompetenti, risolvete velocemente!!”
  • Trasformare i bisogni del cliente in specifiche tecniche
  • Inserire il codice nel prodotto
  • Attivare tutti i test opportuni
  • Visto poi che il bug, di fatto, “rompe il ciclo” è necessario coinvolgere anche gli step di Quality Assurance  per verificare che il codice che risolve il bug non abbia introdotto una regression (e, nel qual caso, ricominciare più o meno da capo)
  • Rilasciare la patch

Il problema è che il tempo dedicato al rilascio non è mai definito e di dominio pubblico! Già al secondo step dovrebbe essere ben chiaro a tutti quali saranno i tempi di rilascio e quando la patch sarà disponibile ed è qui il vero problema: i software vendor sono letteralmente terrorizzati dal dare una qualsiasi informazione riguardo  al momento del rilascio ed è da qui che molta dell’isteria dei clienti emerge.

Avere un SDLC ben strutturato è fondamentale quindi per far fronte ai ritmi necessari da reggere ma, questo processo, ha la necessità di avere tempi certi anche per quanto riguarda le eccezioni e le risoluzioni di problemi inaspettati.

Avere una buona visione del problema e definirne già i tempi di risoluzione è la chiave di volta per “legare al laccio” i problemi e risolverli senza causare ai propri clienti degli accidenti (o, peggio ancora, farseli lanciare addosso)

Dall’altro punto di vista bisogna capire anche chi è il vendor, se lo conosciamo e sappiamo che in passato ha lavorato bene, è necessario permettergli di fare un ottimo lavoro: avere una risoluzione di un bug che porta delle regressioni che ci faranno “rimpiangere” il bug è un altro problema da tenere in considerazione anche se, anche in questo caso, avere un tempo certo per il quale attendere può aiutare lo stato d’animo.

Leave a Reply