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á. # Processo de patching Os principais usuários da solução de patches são as equipes de desenvolvimento e operações de aplicativos. Normalmente, cada aplicativo é implantado em vários ambientes, como desenvolvimento, teste (integração, aceitação do usuário, e etc.) e produção. As equipes de aplicativos precisam planejar os cronogramas de patches para cada ambiente, para que, quando um patch for aplicado ao ambiente de produção, ele já tenha sido testado e determinado que não tem efeitos adversos no aplicativo. O fluxo de trabalho a seguir fornece um exemplo de como você pode planejar janelas de patches para um aplicativo implantado em vários ambientes e como configurar tags. ![Patch management workflow](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patch-management-hybrid-cloud/images/patching-workflow.png) + **Etapa 1.** Cada equipe de aplicativos planeja suas janelas de manutenção para seus servidores em vários ambientes e configura adequadamente as tags que representam os grupos de patches e as janelas de manutenção dos servidores: + A tag **Grupo de Patch** representa os servidores em um ambiente de aplicativos que são os alvos de uma lista de referência de patches específica. Grupos de patches ajudam a garantir que as listas de referência de patches corretas sejam implantadas para corrigir o conjunto de instâncias. Grupos de patches também podem ajudar você a evitar a implantação de patches antes que eles tenham sido adequadamente testados. + Se os servidores de aplicativos incluírem vários sistemas operacionais, a equipe de aplicativos criará grupos de patches com base na combinação do ambiente e do sistema operacional. Um grupo de patches pode ser registrado em somente uma lista de referência de patches, e uma instância pode fazer parte de somente um grupo de patches. Por exemplo: `{{appname}}-DEV-WIN` e `{{appname}}-DEV-RHEL` + A tag **Janela de Manutenção** representa o cronograma de aplicação de patches nos servidores. **Todos os servidores em um grupo de patches devem estar na mesma janela de manutenção.** A tag da janela de manutenção deve seguir um formato consistente para expressões de cron e rate para que uma função do Lambda que você define possa analisar as expressões facilmente. (Neste guia, vamos nos referir a essa função do Lambda como `automate-patch`.) Por exemplo, .: `{{schedule-duration-cutoff-timezone}}` O `cron(0 2 ? * SAT#3 *)` representa às 02:00 da manhã do terceiro sábado de cada mês. Para obter mais informações sobre expressões de cron e rate, consulte a [documentação do Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html). + **Etapa 2.** O Systems Manager Patch Manager disponibiliza novos patches regularmente por meio de linhas de base de patches específicas do sistema operacional, com base nas configurações definidas. + Para cada sistema operacional, você pode definir uma lista de referência de patches personalizada que inclua as regras de aprovação e os patches que precisam ser aplicados às instâncias em todo o ambiente de nuvem. + **Etapa 3.** Seu código de automação personalizado configura o Patch Manager para configurar o patch com base nas tags **Grupo de Patch** e **Janela de Manutenção** e aplica os patches ao ambiente de desenvolvimento. + Após a conclusão da correção, as equipes de desenvolvimento e suporte do aplicativo testam o aplicativo e verificam se tudo funciona corretamente. + Se o aplicativo encontrar algum problema com o novo patch, as equipes de aplicativos solicitam que a equipe de serviços de nuvem interrompa a aplicação de patches em outros grupos de patches e outros ambientes, desativando as janelas de manutenção ou cancelando o registro da execução da tarefa do patch. + **Etapa 4.** Depois que o ambiente de desenvolvimento é corrigido com sucesso, o patch é implantado em qualquer outro ambiente que não seja de produção. Assim como no ambiente de desenvolvimento, o aplicativo é testado e verificado se está funcionando corretamente em todos os ambientes que não são de produção. Se houver algum problema, as equipes de aplicativos solicitam que a equipe de serviços em nuvem interrompa a aplicação de patches no ambiente de produção. + **Etapa 5.** Depois que todos os ambientes que não são de produção tiverem sido corrigidos com sucesso, os patches serão aplicados ao ambiente de produção.