Come testare e ottimizzare quando non è possibile riprodurre l'ambiente?

In passato, ho lavorato in diversi ambienti. App desktop, giochi, contenuti incorporati, servizi Web, lavori da riga di comando, siti Web, creazione di report di database e così via. Tutti questi ambienti condividevano lo stesso tratto: non importava la loro complessità, non importava la loro dimensione, potevo sempre avere un sottoinsieme o una fetta dell'applicazione sulla mia macchina o in un ambiente di sviluppo da testare.

Oggi no. Oggi mi trovo in un ambiente il cui obiettivo principale è la scalabilità. La riproduzione dell'ambiente è proibitivamente costosa. Prendendo una fetta di ambiente, mentre plausibile (alcuni dei pezzi dovrebbero essere simulati o utilizzati in una modalità a istanza singola che non sono fatti per fare), un po 'sconfigge lo scopo poiché oscura la concorrenza e caricando che il sistema reale incontra. Anche un piccolo sistema "di prova" ha i suoi difetti. Le cose si comporteranno in modo diverso quando hai 2 nodi e quando hai 64 nodi.

Il mio solito approccio all'ottimizzazione (misurare, provare qualcosa, verificare la correttezza, misurare le differenze, ripetere) non funziona davvero qui poiché non riesco effettivamente a fare i passaggi 2 e 3 per le parti del problema che contano (solidità della concorrenza e prestazioni sotto caricare). Questo scenario non sembra unico però. Qual è l'approccio comune per svolgere questo tipo di attività in questo tipo di ambiente?

Ci sono alcune domande correlate:

• questa domanda ha a che fare con l'hardware (come analizzatori di spettro) non disponibile, che può essere (relativamente) facilmente emulato.
• questa domanda riguarda il rilevamento dei bug che esistono solo negli ambienti di produzione, il che è utile, ma un diverso tipo di attività.

In realtà è difficile, ma sono sicuro che in molte situazioni comparabili è principalmente un problema organizzativo. L'unico approccio praticabile è probabilmente una combinazione di misure combinate, non solo "un proiettile d'argento". Alcune cose che puoi provare:

• registrazione: come ho già scritto in un commento, il tempo eccessivo e la registrazione delle risorse (che è una sorta di profilazione) possono aiutarti a identificare i veri colli di bottiglia nella produzione. Questo potrebbe non dirti se un'implementazione alternativa funzionerà meglio, ma sicuramente ti aiuterà a evitare di ottimizzare la parte completamente sbagliata della tua applicazione.

• testare ciò che è possibile testare in anticipo - accuratamente, con molta pianificazione iniziale. Certo, le cose si comporteranno diversamente nella produzione, ma non tutte le cose. La correttezza di un'implementazione diversa spesso può essere verificata in anticipo - se un'implementazione si adatta bene, è una domanda diversa. Ma la pianificazione può aiutare molto. Pensa attentamente ai problemi che il tuo ambiente di test può risolvere per te e che non lo sono. Ci sono quasi sempre cose in cui credi a prima vista "non può essere testato in anticipo", ma se ci pensi due volte, spesso è più possibile.

• Lavora in gruppo. Quando provi un nuovo approccio o un'idea, discutilo con almeno un'altra persona della tua squadra. Quando si implementa un algo diverso, insistere sulle ispezioni del codice e sul QA. Più bug e problemi si possono evitare in anticipo, meno problemi si dovranno risolvere in produzione.

• Dal momento che non è possibile testare tutto in anticipo, aspettarsi problemi durante la produzione. Quindi cerca di preparare una strategia di fallback davvero buona quando porta in produzione un nuovo codice. Quando il tuo nuovo codice ha il rischio di essere più lento della soluzione precedente o se ha il rischio di arresti anomali, assicurati di poter passare alla versione precedente al più presto. Se ha il rischio di distruggere i dati di produzione, assicurarsi di disporre di un buon backup / ripristino. E assicurati di rilevare tali errori aggiungendo un meccanismo di validazione nel tuo sistema.

• tenere seriamente un diario di progetto o un registro delle soluzioni. Ogni giorno scopri qualcosa di nuovo sull'ambiente, scrivilo: storie di successo e storie di fallimento. Non fare lo stesso errore due volte.

Quindi l'essenza è: quando non puoi andare con tentativi ed errori, la tua migliore opzione sono conservative, la classica pianificazione anticipata e le tecniche di controllo qualità.

Se non riesci a riprodurre l'ambiente dal vivo, la scomoda realtà è che qualunque cosa tu faccia, non sarebbe stato sufficientemente testato.

Che cosa si può fare?

Bene, qualunque cosa debba ridimensionare, sia che si tratti di un processo, di un cluster di server o di un volume di database, dovrebbe essere testato tenendo conto della regola zero, one, infinity per capire dove potrebbero essere i potenziali colli di bottiglia / limitazioni: IO, CPU, carico della CPU, inter -processo di comunicazione ecc.

Una volta ottenuto questo, dovresti avere un'idea del tipo di test interessato. Se si tratta di test unitari, questo si colloca tradizionalmente con lo sviluppatore, se si tratta di test di integrazione / sistema, potrebbero esserci dei punti di contatto con altri team che potrebbero essere in grado di aiutare con ulteriori competenze o, meglio ancora, strumenti.

Parlando di strumenti, non è davvero compito dello sviluppatore caricare test di un sistema oltre a ciò che è possibile nel loro ambiente di sviluppo. Questo dovrebbe essere inviato al reparto test o ad altre terze parti.

L'elefante nella stanza ovviamente è che i sistemi non si adattano sempre in modo prevedibile!

In una vita precedente, ero un DBA per database di banche con miliardi di file e armato di piani di esecuzione che potevamo generalmente prevedere quanto tempo avrebbero impiegato le query su un database inattivo dati i volumi di input. Tuttavia, una volta che questi volumi hanno raggiunto una certa dimensione, il piano di esecuzione cambierebbe e le prestazioni peggiorerebbero rapidamente a meno che la query / il database non fossero ottimizzati.

Suggerirei esperimenti.

La registrazione troverà colli di bottiglia. È quindi possibile provare un'implementazione alternativa su alcune macchine, o anche su tutte le macchine con una certa probabilità, o per un periodo di tempo limitato. Quindi confrontare nuovamente i registri per verificare i miglioramenti.

È lo stesso ciclo di teoria-esperimento-misura a cui sei abituato, ma più costoso da impostare - poiché le ipotesi devono essere eseguite in produzione - e in base al tuo volume, anche ricevere dati significativi dalla produzione può essere lento.