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

In realtà è dura, ma sono sicuro che in molte situazioni simili è principalmente un problema organizzativo. L'unico approccio praticabile è probabilmente una combinazione di misure combinate, non solo "una pallottola 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) può aiutare 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.

• prova ciò che puoi testare in anticipo - accuratamente, con un sacco di pianificazione anticipata. Certo, le cose si comportano diversamente nella produzione, ma non quelle tutte . 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 bene ai problemi che l'ambiente di test può risolvere per te e quali no. Ci sono quasi sempre cose in cui credi a prima vista "non può essere testato in anticipo", ma se ci pensi due volte, c'è spesso più possibilità.

• Lavora come squadra. Quando provi un nuovo approccio o idea, parlane con almeno un'altra persona della tua squadra. Quando implementi un algo diverso, insisti sulle ispezioni del codice e sul controllo qualità. Più bug e problemi si possono evitare in anticipo, i problemi meno gravi che dovrai risolvere in produzione.

• Dato che non è possibile testare tutto in anticipo, si aspettano problemi di visualizzazione in produzione. Quindi cerca di preparare una strategia di fallback davvero valida quando inserisci un nuovo codice nella produzione. Quando il tuo nuovo codice ha il rischio di essere più lento della vecchia soluzione, o se ha il rischio di crash, assicurati di poter passare alla versione precedente APPENA POSSIBILE. Se ha il rischio di distruggere i dati di produzione, assicurati di avere un buon backup / ripristino sul posto. Assicurati di rilevare tali errori aggiungendo alcuni meccanismi di convalida nel tuo sistema.

• mantieni sul serio un diario di progetto o un log di soluzione. Ogni giorno scopri qualcosa di nuovo sull'ambiente, scrivilo - storie di successo e storie di insuccessi. Non fare lo stesso errore due volte.

Quindi il succo è - quando non puoi andare con try-and-error, la tua opzione migliore sono le tecniche di pianificazione anticipata classica e tradizionale e le tecniche di controllo qualità.

Se non riesci a riprodurre l'ambiente dal vivo, la realtà scomoda è che qualunque cosa tu faccia, non sarà stata sufficientemente testata.

Quindi, cosa puoi fare?

Bene, qualunque cosa debba essere scalata, che si tratti di un processo, un cluster di server o un volume di database dovrebbe essere testato con zero, uno, infinito regola in mente per scoprire dove i potenziali colli di bottiglia / limitazioni sono IO, CPU, carico della CPU, comunicazione tra processi, ecc.

Una volta che hai questo, dovresti avere un'idea di che tipo di test è interessato. Se si tratta di test unitari, questo si verifica tradizionalmente con lo sviluppatore, se si tratta di test di integrazione / sistema, potrebbero esserci punti di contatto con altri team che potrebbero essere in grado di fornire assistenza con competenze aggiuntive o strumenti ancora migliori.

Parlando di strumenti, non è proprio compito dello sviluppatore caricare il test di un sistema oltre quanto è possibile nel loro ambiente di sviluppo. Questo dovrebbe essere inserito nel reparto test o in un'altra parte di terze parti.

L'elefante nella stanza, naturalmente, è che i sistemi non sempre scalano in modi prevedibili!

In una vita precedente, ero un DBA per database bancari con miliardi di righe e armato di piani di esecuzione, in genere potevamo prevedere quanto tempo le query avrebbero richiesto 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 si deteriorerebbero rapidamente a meno che la query / database non fosse stata ottimizzata.

Suggerirei esperimenti.

La registrazione troverà i 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 confronta nuovamente i log per verificare i miglioramenti.

È lo stesso ciclo di teoria-esperimento-misura a cui sei abituato, ma più costoso da configurare, dal momento che le ipotesi devono essere eseguite in produzione e, a seconda del volume, anche la ricezione di dati significativi dalla produzione può essere lenta .