Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
OPS05-BP08 Utilizzo di più ambienti
Utilizza più ambienti per sperimentare, sviluppare e testare il carico di lavoro. Applica livelli crescenti di controlli man mano che gli ambienti si avvicinano alla fase di produzione per avere la certezza che il carico di lavoro funzioni come previsto una volta implementato.
Risultato desiderato: disponi di più ambienti che riflettono le tue esigenze di conformità e governance. Testi e promuovi il codice negli ambienti lungo il tuo percorso verso la produzione.
-
L'organizzazione esegue queste operazioni attraverso la creazione di una zona di destinazione, che fornisce governance, controlli, automazioni degli account, rete, sicurezza e osservabilità operativa. Gestisci queste funzionalità di zona di destinazione utilizzando più ambienti. Un esempio comune è un'organizzazione sandbox per lo sviluppo e il test delle modifiche apportate a una zona di destinazione basata su AWS Control Tower
, che include AWS IAM Identity Center e policy quali le policy di controllo dei servizi. Tutti questi elementi possono avere un impatto significativo sull'accesso e sul funzionamento degli Account AWS all'interno della zona di destinazione. -
Oltre a questi servizi, i team possono estendere le capacità delle zone di destinazione con soluzioni pubblicate da AWS e dai partner AWS o come soluzioni personalizzate sviluppate all'interno dell'organizzazione. Esempi di soluzioni pubblicate da AWS includono Customizations for AWS Control Tower (CfCT)
e AWS Control Tower Account Factory for Terraform (AFT). -
L'organizzazione applica gli stessi principi di test, promozione del codice e modifiche alle policy per la zona di destinazione attraverso gli ambienti nel percorso verso la produzione. Questa strategia fornisce un ambiente di zona di destinazione stabile e sicuro per i team delle applicazioni e dei carichi di lavoro.
Anti-pattern comuni:
-
Stai sviluppando in un ambiente di sviluppo condiviso e un altro sviluppatore sovrascrive le tue modifiche al codice.
-
I controlli di sicurezza restrittivi nell'ambiente di sviluppo condiviso impediscono di sperimentare nuovi servizi e funzionalità.
-
Esegui test di carico sui tuoi sistemi di produzione e causa un'interruzione per i tuoi utenti.
-
Si è verificato un errore critico che ha causato la perdita di dati nella produzione. Nel tuo ambiente di produzione tenti di ricreare le condizioni che portano alla perdita di dati in modo da poter identificare come si è verificata e impedire che si ripeta. Per evitare un'ulteriore perdita di dati durante il test, devi rendere l'applicazione non disponibile per i tuoi utenti.
-
Stai operando un servizio multi-tenant e non sei in grado di supportare la richiesta di un cliente per un ambiente dedicato.
-
Ogni volta che esegui un test, lo fai nel tuo ambiente di produzione.
-
Ritieni che la semplicità di un singolo ambiente prevalga sulla portata dell'impatto che possono avere modifiche all'interno dell'ambiente.
-
Aggiorni una funzionalità chiave della zona di destinazione ma la modifica compromette la capacità del team di vendere gli account per nuovi progetti o per i carichi di lavoro esistenti.
-
Applichi nuovi controlli agli Account AWS, ma la modifica ha un impatto sulla capacità del team del carico di lavoro di implementare le modifiche all'interno dei propri Account AWS.
Vantaggi dell'adozione di questa best practice: quando distribuisci più ambienti, puoi supportare più ambienti di sviluppo, test e produzione simultanei senza creare conflitti tra sviluppatori o community di utenti. Per funzionalità complesse come le zone di destinazione, riduce in modo significativo il rischio di modifiche, semplifica il processo di miglioramento e riduce il rischio di aggiornamenti critici dell'ambiente. Le organizzazioni che utilizzano le zone di destinazione beneficiano naturalmente di più account nel loro ambiente AWS, con struttura dell'account, governance, rete e configurazioni di sicurezza. Nel corso del tempo, con la crescita dell'organizzazione, la zona di destinazione può evolvere per proteggere e organizzare i carichi di lavoro e le risorse.
Livello di rischio associato se questa best practice non fosse adottata: medio
Guida all'implementazione
Utilizza più ambienti e fornisci agli sviluppatori ambienti sandbox con controlli minimi per incoraggiare la sperimentazione. Fornisci ambienti di sviluppo individuali per facilitare il lavoro in parallelo, incrementando l'agilità dello sviluppo. Implementa controlli più rigorosi negli ambienti che si avvicinano alla produzione per consentire agli sviluppatori di innovare. Utilizza l'approccio Infrastructure as code e sistemi di gestione delle configurazioni per distribuire ambienti configurati in modo coerente con i controlli presenti in produzione per assicurare che i sistemi funzionino nel modo previsto quando vengono distribuiti. Quando gli ambienti non vengono utilizzati, disattivali per evitare costi associati alle risorse inattive, ad esempio i sistemi di sviluppo nelle ore serali e nei fine settimana. Durante i test di carico, è necessario implementare ambienti equivalenti a quelli di produzione per migliorare la validità dei risultati.
Team come l'ingegneria della piattaforma, la rete e le operazioni di sicurezza spesso gestiscono le funzionalità a livello di organizzazione con requisiti distinti. La sola separazione degli account non è sufficiente a fornire e mantenere ambienti separati per la sperimentazione, lo sviluppo e i test. In questi casi, crea istanze separate di AWS Organizations.
Risorse
Documenti correlati:
