Come interrompere i servizi UAT / QA / Test utilizzati in un ambiente di produzione

Davidb, proverò a indagare su quale sia il problema.

eCommerce colleagues update their production/live environments to use this UAT service without my or my teams knowledge (obvious communication problem I know).

Qui non c'è nessun problema per te . Perché ti importa cosa stanno facendo con il loro ambiente?

something has changed in UAT which breaks the service and eCommerce complain.

Probabilmente questo è il motivo per cui ti interessa, giusto? Aspetta un attimo. Se la decisione di utilizzare i servizi UAT nella produzione porta a problemi di produzione, il dipartimento e-commerce dovrebbe presentare un reclamo a .... a chi? A coloro che hanno preso questa decisione - al dipartimento eCommerce! Non ne sei affatto coinvolto.

Il problema ha una soluzione che non riguarda le tecnologie, è necessario cambiare il tuo atteggiamento personale. Non accettare reclami di questo tipo da eCommerce , non sei responsabile per questo.

In un mondo perfetto, il tuo codice non saprebbe se è in fase di test o di produzione. In quello stesso mondo perfetto, i tuoi colleghi saprebbero meglio che usare un servizio per la produzione prima che sia pronto.

Dato che il mondo non è perfetto, è necessario rendere il tuo servizio meno appetibile finché non è in produzione.

Alcune idee:

• Come suggerito da @BartvanIngenSchenau in un commento, è possibile ripristinare il database una volta alla settimana. Poiché si tratta di un ambiente di test, ciò sarebbe perfettamente ragionevole e probabilmente necessario. Per definizione, non ci sono dati di produzione in un ambiente di test in modo che tu abbia i tuoi diritti di fare ciò che desideri.

• Considera di interrompere il servizio quando non lo collaudi attivamente.

• Chiedi al tuo servizio "filigrana" come prodotto. Aggiungi "TEST" a molte delle stringhe che produci.

• Parla con le persone del tuo servizio di rete circa il possibile accesso ai filtri IP per l'ambiente.

Ecco un paio di opzioni con qualche sovrapposizione a quanto suggerito da Dan Pichelman:

• Segmentazione della rete. Prevenire le chiamate dall'attraversamento tra produzione e test. Questa è anche una buona idea nella direzione opposta per vari motivi
• Certificati client. Se utilizzi certificati client per l'autenticazione, saprai quale host si connette al tuo servizio.

Idealmente, fai entrambe le cose. Il primo è probabilmente più affidabile. Il secondo funziona, ma se possono cambiare i server nel proprio ambiente di produzione, possono giocarci. Sarebbe un dolore per loro, specialmente quando arriverà il prossimo round di test. I certificati client dovrebbero essere abbastanza semplici se si dispone di una CA interna.

In realtà questo mi sembra un problema di gestione delle modifiche. Quel gruppo non dovrebbe essere in grado di controllare la configurazione dell'ambiente di produzione se non possono farlo correttamente. Se non lo fanno direttamente e qualcuno sta facendo questo sulla loro richiesta, dovresti contattare quel gruppo e far notare che in questo modo stanno violando le politiche che presumo tu debba avere. Ci sono tutti i tipi di problemi di sicurezza con questo. Puoi usarlo per spaventare le persone. Fagli capire che se qualcosa va storto, tornerà da loro.

Firewall e / o VLAN.

Dovrebbe esserci un firewall tra l'ambiente di produzione e gli ambienti Dev / QA / UAT, in modo tale che un servizio di produzione non possa connettersi a un'istanza Dev / QA / UAT, per nulla. In alternativa, i servizi di produzione vengono distribuiti sulla VLAN di produzione, senza accesso alle VLAN Dev o alle VLAN QA.

Sì, può essere un problema lavorare, ma risolve questo tipo di problemi impedendo che si verifichino.

Penso che ci sia un problema generale con le pratiche di rilascio e distribuzione all'interno della tua organizzazione.

Quando il tuo team sviluppa un servizio, passerà attraverso:

• Build
• Packaging

Come parte di Packaging viene creato un pacchetto di distribuzione. Il pacchetto viene quindi utilizzato per la distribuzione in ambienti diversi. Ogni ambiente avrà la sua configurazione specifica.

Quindi, supponiamo tu abbia il pacchetto X che è stato creato da una build dal 13/01/2017.

• Pacchetto X - Configurazione UAT
• Pacchetto X - PROD Config

Non si dovrebbe mai indicare PROD per indicare UAT. Promuovi il pacchetto (in questo caso X) da distribuire alla produzione che utilizzerà la configurazione PROD.

Le configurazioni puntano a URL, database, ecc. diversi per evitare l'attraversamento dei confini ambientali.

I pacchetti vengono promossi in ambienti, non un ambiente puntato su un servizio.

Una scelta potrebbe essere quella di creare un pannello di controllo amministratore, con l'autorizzazione appropriata potresti avere un gruppo di opzioni di scorrimento per attivare / disattivare i servizi con codice back-end appropriato per implementare l'accessibilità.

Disclaimer: al mio attuale datore di lavoro facciamo un'integrazione continua, quindi il mio consiglio proviene da quel tipo di ambiente. Spero che ci sia qualcosa che puoi usare.

Hai considerato l'UAT più granulare? Se ogni cambiamento subisce UAT separatamente, ci sarà una moltitudine di ambienti UAT di breve durata, che richiedono la differenziazione dei loro url. Usiamo una combinazione del nome della caratteristica e dell'ID di istanza, che è in effetti casuale.

Non abbiamo mai avuto un problema con le persone che collegano il codice UAT al database di produzione, ma se qualcuno si è messo in testa di farlo, e in qualche modo è riuscito a ottenere le autorizzazioni per apportare le modifiche richieste, trovare un obiettivo stabile sarebbe essere impossibile - quando c'è anche un obiettivo da trovare per loro.