# Representações 2 por 2 do modelo operacional As representações 2 por 2 do modelo operacional são ilustrações para ajudar a compreender as relações entre as equipes em seu ambiente. Esses diagramas têm como foco quem faz o quê e nos relacionamentos entre as equipes, mas também discutiremos a governança e tomada de decisões no contexto desses exemplos. Suas equipes podem ter responsabilidades em várias partes de diversos modelos, dependendo das workloads para as quais elas oferecem suporte. Talvez você queira separar áreas de disciplina mais especializadas do que as de alto nível descritas. Existem possibilidades infinitas de variação nesses modelos com base na forma como você separa ou agrega atividades ou sobrepõe equipes e fornece detalhes mais específicos. Talvez você identifique que tem recursos sobrepostos ou não reconhecidos em equipes que podem fornecer vantagem adicional ou resultar em eficiências. Você também pode identificar necessidades não atendidas na sua organização e que você planeja atender no futuro. Ao avaliar a mudança organizacional, examine as diferenças entre modelos, onde suas equipes individuais residem nos modelos (agora e depois da mudança), como o relacionamento e as responsabilidades das equipes mudarão e se os benefícios compensam o impacto na sua organização. Você pode obter êxito ao usar cada um dos quatro modelos operacionais a seguir. Alguns modelos são mais apropriados para casos de uso específicos ou em pontos específicos do seu desenvolvimento. Alguns desses modelos podem fornecer vantagens em relação aos modelos atualmente usados no seu ambiente. **Topics** + [Modelo operacional totalmente separado](fully-separated-operating-model.md) + [DevOps com provedor de serviços gerenciados na nuvem](devops-with-cloud-managed-service-provider.md) + [Operações e capacitação da plataforma na nuvem (COPE)](cloud-operations-and-platform-enablement.md) + [DevOps distribuído](distributed-devops.md) + [DevOps descentralizado](decentralized-devops.md) + [Evoluir seu modelo operacional](evolving-your-ops-model.md) # Modelo operacional totalmente separado No diagrama a seguir, no eixo vertical, há "Aplicações" e "Plataforma". "Aplicações" referem-se à workload que atende a um resultado comercial e podem ser software personalizado desenvolvido ou comprado. "Infraestrutura" refere-se à infraestrutura física e virtual e a outros softwares compatíveis com essa workload. No eixo horizontal, temos "Engenharia" e "Operações". "Engenharia" refere-se ao desenvolvimento, à criação e ao teste de aplicações e infraestrutura. "Operações" abrange a implantação, a atualização e o suporte contínuo a aplicações e à infraestrutura. ![\[Diagrama de modelo tradicional\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png) Historicamente, as organizações adotaram estruturas como ITIL ou padrões como ISO e moldaram suas atividades operacionais em torno delas, o que geralmente resultava em uma topologia totalmente separada. Nesse modelo, as atividades em cada quadrante são realizadas por uma equipe separada O trabalho é transmitido entre equipes por meio de mecanismos como solicitações de trabalho, filas, tíquetes ou um sistema de gerenciamento de serviços de TI (ITSM). A transição de tarefas para ou entre equipes aumenta a complexidade e cria gargalos e atrasos. As solicitações podem ser atrasadas até que sejam uma prioridade. Os defeitos identificados com atraso podem exigir retrabalho significativo e talvez precisem passar novamente pelas mesmas equipes e suas funções. Se houver incidentes que exijam ação das equipes de engenharia, suas respostas serão atrasadas pela atividade de entrega. Há um risco maior de desalinhamento quando as equipes de negócios, desenvolvimento e operações são organizadas em torno das atividades ou funções executadas. Isso pode fazer com que as equipes se concentrem em responsabilidades específicas, em vez de buscarem alcançar resultados empresariais. As equipes podem ter especialização limitada e podem estar isoladas em nível físico ou lógico, o que dificulta a comunicação e a colaboração. # DevOps com provedor de serviços gerenciados na nuvem O modelo de DevOps com provedor de serviços gerenciados na nuvem segue a metodologia *você cria, você executa* para equipes de aplicações. No entanto, sua organização pode não ter as habilidades ou os membros da equipe necessários para oferecer suporte a uma equipe dedicada de engenharia e operações de plataforma, ou talvez você não esteja em uma posição de investir tempo e esforços para isso. Como alternativa, você pode ter uma equipe de plataforma focada na criação de recursos que diferenciam a sua empresa, mas deseja transferir para terceiros as operações diárias que não geram diferenciação. Provedores de serviços gerenciados como o [AWS Managed Services](https://aws.amazon.com/managed-services/) ou os provedores na [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) fornecem especialização na implementação de ambientes de nuvem e ajudam a atender os seus requisitos de segurança e conformidade e objetivos de negócios. ![\[DevOps com provedor de serviços gerenciados na nuvem\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png) Para essa variação, tratamos a governança como centralizada e gerenciada pela equipe de plataforma, com a criação de contas e políticas gerenciadas com o AWS Organizations e o AWS Control Tower. Esse modelo exige que você modifique seus mecanismos para trabalhar com os mecanismos do seu provedor de serviços. Ele não aborda os gargalos e atrasos criados pela transição de tarefas entre equipes, incluindo seu provedor de serviços, ou o possível retrabalho relacionado à identificação tardia de defeitos. Você obtém a vantagem dos padrões, das práticas recomendadas, dos processos e da experiência dos seus provedores. Também obtém os benefícios do desenvolvimento contínuo das ofertas de serviços deles. A adição de serviços gerenciados ao seu modelo operacional pode economizar tempo e recursos, além de permitir que você mantenha as equipes internas reduzidas e focadas em resultados estratégicos que diferenciarão seus negócios, em vez de desenvolver novas habilidades e recursos. Isso também pode fornecer tempo para você criar e amadurecer seus próprios recursos de plataforma sem retardar seus programas de migração para a nuvem. # Operações e capacitação da plataforma na nuvem (COPE) Esse modelo de operações e capacitação da plataforma na nuvem (COPE) busca estabelecer uma metodologia *você cria, você executa* para apoiar as equipes de aplicações na realização das atividades de engenharia e operações de suas workloads por meio da adoção de uma cultura de DevOps. Suas equipes de aplicações podem ter a tarefa de migrar, adotar a nuvem ou modernizar suas workloads, mas talvez não tenham as habilidades existentes para oferecer suporte adequado à arquitetura e às operações da nuvem. Essa falta de capacidade e familiaridade da equipe de aplicações provavelmente diminuirá a agilidade da sua organização e afetará os resultados comerciais. Para resolver essa preocupação, use a experiência operacional existente da sua organização para apoiar as equipes de aplicações em sua jornada para as operações na nuvem. Isso pode ser uma equipe dedicada de especialistas ou uma equipe virtual com participantes selecionados de toda a organização. No entanto, a meta permanece a mesma, que é fornecer suporte operacional que desenvolva a capacidade da equipe da workload, usando os primeiros princípios de automação da nuvem, removendo o trabalho pesado indiferenciado, fornecendo padrões padronizados e promovendo autonomia. O objetivo é criar maturidade suficiente em todos os recursos da nuvem e reduzir a barreira das responsabilidades operacionais para que as equipes de aplicações não precisem mais de suporte adicional. O modelo COPE foca o nível da workload. Se essa abordagem for necessária em várias equipes ao mesmo tempo, se você estiver executando um projeto de migração complexo, de grande escala e plurianual ou se estiver criando uma plataforma para apoiar essas iniciativas, considere usar um Centro de Excelência da Nuvem (CCoE). Esse é um mecanismo que muitos consideraram bem-sucedido ao buscar acelerar suas migrações para a nuvem e transformar amplamente sua organização. ![\[Operações e capacitação da plataforma na nuvem (COPE)\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png) Sua equipe de engenharia de plataforma cria uma fina camada dos principais recursos da plataforma compartilhada, que se baseiam em padrões predefinidos para as equipes de aplicações adotarem e são fornecidos pela equipe de COPE. A equipe de engenharia da plataforma codifica as arquiteturas e os padrões de referência corporativos que são fornecidos às equipes de aplicações por meio de um mecanismo de autoatendimento. Usando um serviço como oAWS Service Catalog, as equipes de aplicações podem implantar arquiteturas, padrões, serviços e configurações de referência aprovados, compatíveis por padrão com os padrões centralizados de governança e segurança. A equipe de engenharia de plataforma também fornece um conjunto padronizado de serviços (por exemplo, ferramentas de desenvolvimento, ferramentas de observabilidade, ferramentas de backup e recuperação e rede) para a equipe de aplicações. A equipe de COPE gerencia e oferece suporte aos serviços padronizados e fornece assistência às equipes de aplicações que estabelecem sua presença na nuvem com base nas arquiteturas e padrões de referência. Eles trabalham com as equipes de aplicações para ajudá-las a estabelecer operações básicas. Durante esse processo, as equipes de aplicações assumem progressivamente mais responsabilidade por seus sistemas e recursos ao longo do tempo. A equipe de COPE promove a melhoria contínua junto com a equipe de engenharia da plataforma e atua como proponente das equipes de aplicações. As equipes de aplicações recebem assistência na configuração de ambientes, pipelines de CI/CD, gerenciamento de alterações, observabilidade e monitoramento e no estabelecimento de processos de gerenciamento de incidentes e eventos, com a equipe de COPE integrada conforme necessário. A equipe de COPE participa com as equipes de aplicações na execução dessas atividades operacionais, eliminando gradualmente o engajamento da equipe de COPE ao longo do tempo à medida que as equipes de aplicações assumem a responsabilidade. A equipe de aplicações obtém o benefício das habilidades da equipe de COPE e das lições aprendidas pela organização. Elas são protegidas pelas grades de proteção estabelecidas por meio de governança centralizada. A equipe de aplicações se baseia em sucessos reconhecidos e obtém o benefício do desenvolvimento contínuo dos padrões organizacionais adotados. Eles obtêm mais informações sobre a operação de sua workload por meio do processo de estabelecer observabilidade e monitoramento e são mais capazes de entender o impacto das mudanças que fazem em suas workloads. A equipe de COPE também pode reter o acesso necessário para apoiar as atividades operacionais, fornecer uma visão das operações corporativas abrangendo as equipes de aplicações e oferecer suporte ao gerenciamento de incidentes críticos. A equipe de COPE mantém a responsabilidade pelas atividades consideradas como levantamento de peso indiferenciado, que eles satisfazem por meio de soluções padrão suportadas em grande escala. Eles também continuam gerenciando atividades operacionais programáticas e automatizadas bem compreendidas para as equipes de aplicações para que possam se concentrar em diferenciar suas aplicações. Você obtém a vantagem dos padrões, das práticas recomendadas, dos processos e da experiência da sua organização derivados do sucesso de suas equipes. Você estabelece um mecanismo para replicar esses padrões bem-sucedidos para novas equipes que estão adotando ou se modernizando na nuvem. Esse modelo enfatiza a capacidade da equipe de COPE de ajudar as equipes de aplicações a estabelecer e fazer a transição de conhecimentos e artefatos. Isso reduz a carga operacional das equipes de aplicações mediante o risco de as equipes de aplicações deixarem de se tornar independentes. Ele estabelece relacionamentos entre as equipes de engenharia de plataforma, COPE e aplicações, criando um ciclo de feedback para apoiar futuras evoluções e inovações. Estabelecer suas equipes de engenharia de plataforma e COPE, ao mesmo tempo que define os padrões de toda a organização, pode facilitar a adoção da nuvem e apoiar os esforços de modernização. Ao fornecer o suporte adicional de uma equipe de COPE atuando como consultora e parceira de suas equipes de aplicações, você pode remover as barreiras do nível de workload que retardam a adoção de recursos de nuvem benéficos pela equipe de aplicações. # DevOps distribuído O modelo de DevOps distribuído separa (ou distribui) as responsabilidades das operações de engenharia de aplicações e das operações de engenharia de infraestrutura entre as equipes de engenharia, seguindo a [metodologia COPE](cloud-operations-and-platform-enablement.md). Seus engenheiros de aplicações executam a engenharia e a operação de workloads. Da mesma forma, seus engenheiros de infraestrutura executam a engenharia e a operação das plataformas usadas para oferecer suporte às equipes de aplicações. ![\[Diagrama do modelo de DevOps distribuído\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png) Neste exemplo, tratamos a governança como centralizada em outros lugares na organização. Os padrões são distribuídos, fornecidos ou compartilhados com as equipes de aplicações e plataforma. Use ferramentas ou serviços que ajudem a controlar centralmente seus ambientes em várias contas, como o [AWS Organizations](https://aws.amazon.com/organizations/). Serviços como o [AWS Control Tower](https://aws.amazon.com/controltower/features/) expandem esse recurso de gerenciamento ajudando você a definir esquemas (compatíveis com modelos operacionais) para a configuração de contas, aplicar governança contínua usando o AWS Organizations e automatizar o provisionamento de novas contas. A metologia *você cria, você executa* não significa que a equipe de aplicações é responsável pela pilha completa, pela cadeia de ferramentas e pela plataforma. A equipe de engenharia de plataforma também fornece um conjunto padronizado de serviços (por exemplo, ferramentas de observabilidade, ferramentas de monitoramento, ferramentas de backup e recuperação e rede) para a equipe de aplicações. A equipe de plataforma também pode fornecer à equipe de aplicações acesso a serviços de provedor de nuvem aprovados, configurações específicas ou ambos. Mecanismos que fornecem um recurso de autoatendimento para implantar serviços e configurações aprovados, como o Service Catalog, podem ajudar a limitar os atrasos associados às solicitações de atendimento e, ao mesmo tempo, impor a governança. A equipe de plataforma proporciona visibilidade da pilha completa para que as equipes de aplicações possam diferenciar problemas em seus componentes de aplicações e os serviços e componentes de infraestrutura que as aplicações consomem. A equipe de plataforma também pode fornecer assistência para configurar esses serviços e orientações sobre como melhorar as operações da equipe de aplicações. Como discutido anteriormente, é essencial que existam mecanismos para que a equipe de aplicações solicite adições, alterações e exceções aos padrões de suporte às atividades e à inovação de suas aplicações. O modelo de DevOps distribuído proporciona bons ciclos de comentários para as equipes de aplicações. As operações diárias de uma workload aumentam o contato com os clientes por interação direta ou indireta por meio de solicitações de suporte e recursos. Essa visibilidade aumentada permite que as equipes de aplicações solucionem problemas mais rapidamente. O envolvimento mais profundo e o relacionamento mais próximo fornecem informações sobre as necessidades dos clientes e criam uma inovação mais rápida. Tudo isso também vale para a equipe da plataforma que oferece suporte às equipes de aplicações, pois a equipe da plataforma deve encarar essas equipes de aplicações como seus clientes. Os padrões adotados podem ser pré-aprovados para uso, reduzindo a quantidade de análise necessária para entrar em produção. O consumo de padrões compatíveis e testados fornecidos pela equipe da plataforma pode reduzir a frequência de problemas com esses serviços. A adoção de padrões permite que as equipes de aplicações se concentrem em diferenciar suas workloads. # DevOps descentralizado O modelo de DevOps descentralizado é uma variação da metodologia *você cria, você executa*, na qual as operações estão principalmente sob a responsabilidade das equipes de workload. Seus engenheiros e desenvolvedores de aplicações executam a engenharia e a operação de workloads. Da mesma forma, seus engenheiros de infraestrutura executam a engenharia e a operação das plataformas usadas para oferecer suporte às equipes de aplicações. ![\[Diagrama de DevOps descentralizado\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png) Neste exemplo, vamos tratar a governança como descentralizada. Os padrões ainda são distribuídos, fornecidos ou compartilhados com equipes de aplicações pela equipe de plataforma, mas as equipes de aplicações podem projetar e operar novos recursos de plataforma para apoiar a workload. Nesse modelo, há menos restrições para a equipe de aplicações, mas isso gera um aumento significativo nas responsabilidades. É preciso ter habilidades adicionais (e possivelmente mais membros da equipe) para oferecer suporte aos recursos adicionais da plataforma. O risco de retrabalho significativo aumentará se os conjuntos de habilidades não forem adequados e se os defeitos não forem reconhecidos com antecedência. Aplique políticas que não sejam especificamente delegadas às equipes de aplicações. Use ferramentas ou serviços que ajudem a controlar centralmente seus ambientes em várias contas, como o [AWS Organizations](https://aws.amazon.com/organizations/). Serviços como o [AWS Control Tower](https://aws.amazon.com/controltower/features/) expandem esse recurso de gerenciamento ajudando você a definir esquemas (compatíveis com modelos operacionais) para a configuração de contas, aplicar governança contínua usando o AWS Organizations e automatizar o provisionamento de novas contas. É benéfico ter mecanismos para que a equipe de aplicações solicite adições e alterações em padrões. Eles podem colaborar com novos padrões que ofereçam benefícios a outras equipes de aplicações. As equipes de plataforma podem decidir que fornecer suporte direto para esses recursos adicionais é um suporte eficaz para resultados empresariais. Esse modelo reduz as restrições de inovação com requisitos significativos de habilidades e membros da equipe. Ele aborda muitos dos gargalos e atrasos criados pela transição de tarefas entre equipes e, ao mesmo tempo, promove o desenvolvimento de relacionamentos eficazes entre equipes e clientes. # Evoluir seu modelo operacional Os modelos fornecidos avançam progressivamente em direção a uma maior autonomia no nível da workload, o que está de acordo com o princípio de equipes de duas pizzas. É importante entender que essa jornada de uma abordagem tradicional ao DevOps descentralizado (como base para a evolução contínua para um modelo de equipe de duas pizzas) provavelmente levará tempo e exigirá o desenvolvimento de maturidade para vários capacidades. Portanto, fornecemos um exemplo de como você pode fazer a transição entre os modelos à medida que sua equipe e organização avançam na jornada de transformação corporativa. Em cada mudança ou modelo, você está evoluindo para uma equipe mais autônoma, mas ainda alinhada à organização. ![\[Diagrama de evolução do modelo operacional em nuvem, desde on-premises a fluxos e processos de valor automatizados\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png) Ao avaliar como sua equipe pode oferecer suporte à evolução da sua organização, examine as compensações entre os modelos, onde suas equipes individuais existem dentro dos modelos (conforme elas fazem a transição e evoluem), como o relacionamento e as responsabilidades da sua equipe podem mudar e se os benefícios justificam o impacto na sua organização. Lembre-se de que a mudança nunca é linear. Alguns modelos são mais apropriados para casos de uso ou pontos específicos da jornada, e alguns desses modelos podem oferecer vantagens sobre os do seu ambiente.