Best practice per la fase di build

I consigli contenuti in questa sezione aiutano a garantire una fase di build più fluida per il progetto. La fase di build comprende attività di codice, sviluppo, distribuzione e implementazione. Spesso consiste in una sessione di revisione e approvazione del progetto, una riunione iniziale per allinearsi su ciò che viene creato, sulla tempistica e sui criteri di uscita. Questa è la fase in cui il codice viene scritto, sottoposto a revisione paritaria e distribuito per tutti i servizi. AWS

Le seguenti raccomandazioni riguardano anche le attività di test o verifica.

Organizza stand-up meeting quotidiani

Assicurati di organizzare stand-up meeting quotidiani, indipendentemente dalla metodologia di progetto che stai utilizzando. Sebbene gli stand-up quotidiani siano associati a metodologie agili, sono anche meccanismi di connessione tra team estremamente utili per altre metodologie, incluso il modello a cascata. Potresti persino utilizzare un framework di progetto ibrido che utilizza le best practice di varie metodologie.

Considerazioni:

• Usa qualcosa di leggero come le bacheche Jira per creare storie per ogni attività. Queste bacheche saranno la tua guida per i tuoi stand-up quotidiani. Se il tuo team dispone della larghezza di banda e delle competenze necessarie, puoi anche utilizzare la metodologia Scaled Agile Framework () SAFe e creare epic. Tuttavia, la maggior parte dei team di infrastruttura non vuole il sovraccarico amministrativo legato alla gestione di bacheche scrum complesse, quindi ti consigliamo uno strumento leggero. Disporre di una bacheca consente inoltre di generare report sul lavoro svolto dal team e offre meccanismi per controllarne l'ambito.

• In un progetto SAP greenfield, non è raro che vengano aggiunte molte applicazioni SAP o limitrofe dopo aver bloccato l'ambito. Se non si dispone di un buon meccanismo per controllare, stabilire le priorità e fornire visibilità all'ambito del progetto, sarà difficile richiedere risorse aggiuntive o ridefinire le priorità del lavoro per mantenere il progetto sulla buona strada.

Utilizzo di un foglio delle specifiche di compilazione unificato

Utilizza un unico foglio di calcolo con le specifiche di compilazione per tutti gli ambienti e i paesaggi. Questo crea un unico documento che può essere facilmente individuato e cercato. Ti consigliamo di abilitare la gestione delle versioni per eseguire facilmente il ripristino in caso di problemi. Crea un formato in collaborazione con il team di SAP Basis. Il team Basis tiene traccia dei dettagli relativi ai sistemi SAP e, disponendo di un'unica specifica, garantisce che il team cloud interno possa rapidamente assumersi la responsabilità e visualizzare tutti i metadati in un unico posto dopo il completamento del progetto.

Ecco un esempio di un modello utilizzato per acquisire i metadati della build del server di chiavi con un unico requisito di server di esempio.

Fai attenzione alle quote di servizio AWS

Esistono quote sul numero di CPUs (vCPUs) virtuali che puoi fornire per le istanze di Amazon Elastic Compute Cloud EC2 (Amazon). Quando distribuisci un' EC2 istanza, richiede un certo numero di vCPUs, a seconda del tipo di istanza. EC2 Ogni AWS account ha un limite flessibile al numero di v CPUs che possono essere assegnati per esso. Man mano che si distribuiscono EC2 le istanze, il limite flessibile aumenta automaticamente di circa 100-150 v. CPUs Tuttavia, se si tenta di distribuire più EC2 istanze (ad esempio 20) contemporaneamente, è possibile superare il limite consentito. Se pensi di poter riscontrare questa limitazione, invia una richiesta per aumentare la quota prima di distribuire EC2 le istanze. Ciò ti consentirà di evitare di raggiungere i limiti delle Service Quotas durante l'implementazione.

Sviluppa una strategia di rotazione chiave per la sicurezza

AWS Key Management Service (AWS KMS) consente ai clienti di creare e gestire facilmente chiavi crittografiche e controllarne l'utilizzo in un'ampia gamma di AWS servizi e in varie applicazioni. Per le implementazioni SAP, le AWS KMS chiavi vengono utilizzate per crittografare i dati inattivi archiviati nei volumi Amazon Elastic Block Store (Amazon EBS) e vengono utilizzate per i file binari SAP e i file system SAP HANA. Le chiavi KMS vengono utilizzate anche per i dati archiviati nei bucket Amazon Simple Storage Service (Amazon S3) per contenere supporti software e backup e nei file system Amazon Elastic File System (Amazon EFS) per e. /usr/sap/trans /sapmnt AWS KMS ti offre la flessibilità di utilizzare chiavi AWS gestite o chiavi gestite dal cliente. Ti consigliamo di documentare e condividere la strategia e le decisioni di gestione delle chiavi di sicurezza all'inizio della fase di build. Le modifiche alle politiche di sicurezza durante il progetto, come il passaggio da chiavi gestite dal cliente a chiavi AWS gestite, possono richiedere una ricostruzione completa degli ambienti SAP, con un impatto sulle tempistiche del progetto.

Ottieni il consenso di tutte le parti interessate alla sicurezza sull'utilizzo e sulla rotazione delle chiavi. Prendi in considerazione le policy di rotazione delle chiavi esistenti per gli ambienti cloud o on-premise e modificale per utilizzarle su AWS. Se hai difficoltà a ottenere il consenso sulla tua strategia di gestione delle chiavi, organizza corsi di formazione per i responsabili delle decisioni, per aiutarli a comprendere i principi di base della sicurezza e la definizione dei livelli. Prendere decisioni chiave sulla rotazione prima della compilazione degli ambienti è fondamentale. Ad esempio, se dovessi passare da chiavi gestite dal cliente a chiavi AWS gestite, incontreresti un problema con Amazon EBS, che non consente modifiche alle chiavi di crittografia online. I volumi EBS devono essere ricompilati con nuove chiavi. Ciò richiede la ricompilazione delle istanze SAP, il che non è uno scenario ideale.

Allo stesso modo, se il tuo progetto utilizza soluzioni esterne per la gestione delle chiavi, come Vormetric, e importa il materiale chiave AWS KMS, assicurati che i responsabili delle decisioni in materia di sicurezza siano consapevoli delle differenze di rotazione delle chiavi tra chiavi KMS esterne e AWS KMS chiavi (rotazione automatica). Quando utilizzi e ruoti una chiave KMS esterna in base alla tua policy di sicurezza, non solo il materiale delle chiavi ma anche il nome della risorsa Amazon (ARN) della chiave cambia, il che significa che i volumi EBS dovranno essere ricreati e l'intero sistema SAP dovrà essere sottoposto a una piccola migrazione. D'altra parte, se abiliti la rotazione automatica per le chiavi gestite dal cliente o le chiavi AWS gestite in AWS KMS ingresso, il materiale chiave cambia ma l'ARN chiave rimane lo stesso, il che significa che i volumi EBS non sono interessati. Per ulteriori informazioni sulla rotazione dei tasti, consulta Rotazione dei AWS KMS tasti nella documentazione. AWS KMS

Un altro approccio alla sicurezza consiste nell'utilizzare AWS Secrets Manager la rotazione delle password del database e del sistema operativo, disponibile tramite una dashboard standard. Inoltre, assicurati che i ruoli AWS Identity and Access Management (IAM) per l'ambiente di disaster recovery siano isolati dall'ambiente di produzione per proteggere gli ambienti da attività dannose.

Dismissione dei server inutilizzati

Si consiglia di disattivare i server Proof of Concept (PoC) immediatamente dopo il termine della loro utilità. L'esecuzione di server inutilizzati può essere costosa. È importante tenere traccia di tutti i server creati per la tua implementazione SAP Greenfield e arrestare e dismettere i server che non utilizzi attivamente durante la fase di build. Prima di disattivare un server, puoi effettuare un backup Amazon Machine Image (AMI) dell' EC2 istanza. Puoi quindi ripristinare il backup se è necessario avviare esattamente lo stesso server in futuro.

La dismissione dei server non dovrebbe essere un'operazione che si limita alla fine del progetto di implementazione. È necessario monitorare l'utilizzo, interrompere ed eventualmente distruggere i server inutilizzati per tutta la durata del progetto e dopo il completamento dell'implementazione, nelle fasi di manutenzione o operative. Assicurati di impostare una procedura all'inizio per insegnare ai membri del team SAP Basis a disattivare questi server, perché i costi si accumuleranno rapidamente.