Práticas recomendadas para a fase de criação - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Práticas recomendadas para a fase de criação

As recomendações nesta seção ajudam a garantir uma fase de construção mais tranquila para seu projeto. A fase de construção abrange atividades de código, desenvolvimento, implantação e implementação. Ela muitas vezes consiste em uma sessão de revisão e aprovação do projeto, uma reunião inicial para alinhar o que está sendo construído, o cronograma e os critérios de saída. Essa é a fase em que o código é escrito, revisado por pares e implantado em todos os serviços. AWS

As recomendações a seguir também abrangem atividades de teste ou verificação.

Organize reuniões diárias de stand-up

Certifique-se de organizar reuniões diárias, independentemente da metodologia de projeto que esteja usando. Embora os stand-ups diários estejam associados a metodologias ágeis, eles também são mecanismos de conexão de equipe extremamente úteis para outras metodologias, incluindo o modelo em cascata. É possível até mesmo usar uma estrutura de projeto híbrida que usa as práticas recomendadas de várias metodologias.

Considerações:

  • Use algo leve, como painéis do Jira, para criar histórias para cada tarefa. Esses painéis serão seu guia para seus stand-ups diários. Se sua equipe tem a largura de banda e a experiência, você também pode usar a metodologia Scaled Agile Framework (SAFe) e criar épicos. No entanto, a maioria das equipes de infraestrutura não quer a sobrecarga administrativa de gerenciar painéis scrum complexos. Por isso, recomendamos uma ferramenta leve. Ter um painel também permite gerar relatórios sobre o trabalho que sua equipe está fazendo e fornece mecanismos para controlar o escopo.

  • Em um projeto greenfield de SAP, não é incomum que muitos aplicações SAP ou de limite sejam adicionadas após o bloqueio do escopo. Se você não tiver um bom mecanismo para controlar, priorizar e dar visibilidade ao escopo do projeto, será difícil solicitar recursos adicionais ou repriorizar o trabalho para manter o projeto em andamento.

Usar uma folha de especificações de construção unificada

Use uma única folha de especificações de construção para todos os ambientes e cenários. Isso cria um único documento que pode ser facilmente localizado e pesquisado. Recomenda-se habilitar o gerenciamento de versões para facilitar a recuperação de infortúnios. Crie um formato em cooperação com a equipe SAP Basis. A equipe Basis acompanha os detalhes dos sistemas SAP, e ter uma única especificação garante que a equipe interna de nuvem possa rapidamente assumir o controle e ver todos os metadados em um só lugar após a conclusão do projeto.

Aqui está um exemplo de um modelo usado para capturar os principais metadados de criação do servidor com um exemplo de requisito de servidor.

Crie uma especificação para capturar metadados do servidor para um projeto SAP on AWS greenfield.

Esteja ciente das cotas AWS de serviço

Há cotas no número de instâncias virtuais CPUs (vCPUs) que você pode provisionar para instâncias do Amazon Elastic Compute Cloud EC2 (Amazon). Quando você implanta uma EC2 instância, ela exige um certo número de vCPUs, dependendo do tipo de EC2 instância. Cada AWS conta tem um limite mínimo no número de v CPUs que podem ser provisionados para ela. Conforme você implanta EC2 instâncias, o limite flexível aumenta automaticamente em cerca de 100-150 v. CPUs No entanto, se você tentar implantar várias (digamos, 20) EC2 instâncias ao mesmo tempo, poderá exceder o limite flexível. Se você acha que pode encontrar essa limitação, envie uma solicitação para aumentar a cota antes de implantar EC2 instâncias. Isso permitirá que você evite atingir os limites de cota de serviço no meio da implantação.

Desenvolva uma estratégia de rotação de chaves para segurança

AWS Key Management Service (AWS KMS) facilita que os clientes criem e gerenciem chaves criptográficas e controlem seu uso em uma ampla variedade de AWS serviços e em vários aplicativos. Para implementações do SAP, AWS KMS as chaves são usadas para criptografar dados em repouso que são armazenados nos volumes do Amazon Elastic Block Store (Amazon EBS) e são usados para binários SAP e sistemas de arquivos SAP HANA. As chaves KMS também são usadas para dados armazenados em buckets do Amazon Simple Storage Service (Amazon S3) para armazenar mídias e backups de software, e nos sistemas de arquivos Amazon Elastic File System (Amazon EFS) para e. /usr/sap/trans /sapmnt AWS KMS oferece a flexibilidade de usar chaves AWS gerenciadas ou chaves gerenciadas pelo cliente. Recomendamos documentar e compartilhar sua estratégia e decisões de gerenciamento de chaves de segurança no início da fase de construção. Mudanças na política de segurança no meio do projeto, como a mudança de chaves gerenciadas pelo cliente para chaves AWS gerenciadas, podem exigir reconstruções completas dos ambientes SAP, o que pode afetar os cronogramas do projeto.

Obtenha a adesão de todas as partes interessadas em segurança quanto ao uso e à alternância de chaves. Considere suas políticas de alternância de chaves existentes para ambientes em nuvem ou on-premises e modifique essas políticas para uso na AWS. Caso enfrente dificuldades para obter consenso sobre sua estratégia de gerenciamento de chaves, forneça treinamento aos tomadores de decisões para ajudá-los a entender as considerações básicas e de definição de níveis de segurança. Tomar as decisões de alternância de chaves antes da construção dos ambientes é crucial. Por exemplo, se você mudasse de chaves gerenciadas pelo cliente para chaves AWS gerenciadas, você encontraria um problema com o Amazon EBS, que não permite alterações nas chaves de criptografia on-line. Os volumes do EBS precisam ser reconstruídos com novas chaves. Isso exige a reconstrução de suas instâncias do SAP, o que não é um cenário ideal.

Da mesma forma, se seu projeto usa soluções externas de gerenciamento de chaves, como a Vormetric, e importa o material da chave AWS KMS, certifique-se de que seus tomadores de decisão de segurança estejam cientes das diferenças de rotação de chaves entre chaves KMS externas e AWS KMS chaves (rotação automática). Quando você usa e alterna uma chave do KMS externa de acordo com sua política de segurança, não apenas o material da chave, mas também o nome do recurso da Amazon (ARN) da chave muda, o que significa que os volumes do EBS precisarão ser recriados e todo o sistema SAP precisará passar por uma pequena migração. Por outro lado, se você ativar a rotação automática para chaves gerenciadas pelo cliente ou chaves AWS gerenciadas em AWS KMS, o material da chave muda, mas o ARN da chave permanece o mesmo, o que significa que os volumes do EBS não são afetados. Para obter mais informações sobre rotação de AWS KMS chaves, consulte Chaves rotativas na AWS KMS documentação.

Outra abordagem de segurança é usar a rotação AWS Secrets Manager de senhas do banco de dados e do sistema operacional, que está disponível por meio de um painel padrão. Além disso, certifique-se de que as funções AWS Identity and Access Management (IAM) do ambiente de recuperação de desastres estejam isoladas do ambiente de produção para ajudar a proteger os ambientes contra atividades maliciosas.

Descomissionar servidores não utilizados

Recomendamos que você desative os servidores de prova de conceito (PoC) imediatamente após o término de sua utilidade. Executar servidores que não estão em uso pode ser caro. É importante acompanhar todos os servidores que você cria para sua implementação greenfield do SAP e interromper e descomissionar os servidores que não estão sendo usados ativamente durante a fase de criação. Antes de descomissionar um servidor, você pode fazer um backup da Amazon Machine Image (AMI) da EC2 instância. Em seguida, você poderá restaurar o backup se precisar ativar exatamente o mesmo servidor no futuro.

O descomissionamento de servidores não deve ser deixado para o final do projeto de implementação. Monitore o uso, interrompa e, em algum momento, destrua os servidores não utilizados ao longo de toda a vida útil do seu projeto e depois de concluir a implementação, nas fases de manutenção ou operacional. Certifique-se de configurar um processo no início para ensinar os membros da equipe do SAP Basis a descomissionar esses servidores, pois as cobranças se acumularão rapidamente.