Revise e compare modelos operacionais de nuvem comuns

Os modelos operacionais são exclusivos e específicos para os negócios aos quais eles dão suporte, com base em seus requisitos e restrições atuais. Mas modelos operacionais não são flocos de neve. Há vários padrões comuns em modelos operacionais de clientes; este artigo descreve os quatro padrões mais comuns.

Comparação de modelo de operacional

A imagem a seguir mapeia modelos operacionais comuns com base no intervalo de complexidade, do menos complexo (descentralizado) para a mais complexa (operações globais). As tabelas a seguir comparam os mesmos modelos operacionais com base no valor relativo de alguns outros atributos.

Diagrama que mostra os graus de complexidade do modelo operacional.

Prioridades ou escopo

Um modelo operacional de nuvem é essencialmente orientado por dois fatores:

  • Prioridades estratégicas ou motivações
  • Escopo do portfólio a ser gerenciado
Operações descentralizadas (operações) Operações centralizadas (operações) Operações empresariais (operações) Operações distribuídas (operações)
Prioridades estratégicas ou motivações Inovação Control Democratização Integração
Escopo do portfólio Carga de trabalho Zona de destino Plataforma de nuvem Portfólio completo
Ambiente de carga de trabalho Complexidade alta Complexidade baixa Complexidade média Complexidade média ou variável
Zona de destino N/D Complexidade alta Complexidade média a baixa Complexidade baixa
Utilitários de fundação N/D N/A ou suporte baixo Centralizado e mais suporte Maior suporte
Base da nuvem N/D N/D Fundamentos híbridos, específicos do provedor ou especificações regionais Distribuído e sincronizado
  • Prioridades estratégicas ou motivações: cada modelo operacional oferece as motivações estratégicas típicas para a adoção da nuvem. Mas alguns modelos operacionais simplificam motivações específicas.

  • Escopo do portfólio: o escopo do portfólio identifica o maior escopo compatível com um design de modelo operacional específico. Por exemplo, operações centralizadas são projetadas para algumas zonas de destino. Mas a decisão do modelo operacional pode criar riscos operacionais para uma organização. Os riscos operacionais resultam ao tentar gerenciar um portfólio complexo grande. Esses portfólios podem exigir muitas zonas de destino ou complexidade variável no design da zona de destino.

Importante

A adoção da nuvem geralmente dispara a reflexão sobre o modelo operacional atual e pode levar a uma mudança de um modelo operacional comum para outro. Mas a adoção da nuvem não é o único gatilho. As prioridades de negócios e o escopo da adoção da nuvem podem alterar a forma como o portfólio precisa ter suporte. Além disso, pode haver outros turnos no modelo operacional alinhado mais adequadamente. Quando a diretoria, ou outras equipes executivas, desenvolvem planos de negócios de 5 a 10 anos, esses planos geralmente incluem um requisito (explícito ou implícito) para ajustar o modelo operacional. Os modelos operacionais são uma boa referência para as decisões de orientação. Esses modelos podem mudar ou precisam ser personalizados para atender aos seus requisitos e restrições.

Alinhamento da responsabilidade

Muitas equipes e indivíduos são responsáveis por dar suporte a funções diferentes. Mas cada modelo operacional comum atribui responsabilidade final para resultados de decisão a uma equipe ou indivíduo. Essa abordagem afeta como o modelo operacional é financiado e qual nível de suporte é fornecido para cada função.

Operações descentralizadas Operações centralizadas Operações empresariais Operações distribuídas
Alinhamento de negócios Equipe de carga de trabalho Estratégia de nuvem central CCoE Variável – forma uma ampla equipe de estratégia de nuvem?
Operações de nuvem Equipe de carga de trabalho Central de TI CCoE Com base na análise de portfólio – consulte Alinhamento de negócios e Compromissos comerciais
Governança de nuvem Equipe de carga de trabalho Central de TI CCoE Múltiplas camadas de governança
Segurança na nuvem Equipe de carga de trabalho SOC (Centro de Operações de Segurança) CCoE + SOC Misto - consulte Definição de uma estratégia de segurança
Automação de plataforma e DevOps Equipe de carga de trabalho TI central ou N/A CCoE Com base na análise de portfólio – consulte Alinhamento de negócios e Compromissos comerciais

Acelere a implementação do modelo operacional no Azure

Conforme discutido em Definir seu modelo operacional, cada metodologia da Cloud Adoption Framework fornece um caminho estruturado para o desenvolvimento de seu modelo operacional. Essas metodologias podem ajudá-lo a superar os bloqueadores que se originam de lacunas na adoção do modelo operacional em nuvem.

A tabela a seguir descreve maneiras de acelerar a implementação do modelo operacional.

Operações descentralizadas Operações centralizadas Operações empresariais Operações distribuídas
Ponto inicial Azure Well-Architected Framework (WAF) Zonas de destino do Azure: Opções de começar pequeno Zonas de destino do Azure: CAF em escala empresarial Alinhamento de negócios
Iterações Um foco nas cargas de trabalho permite que a equipe itere no WAF. A opção de começar pequeno requer mais iterações em cada metodologia, mas pode ser feita conforme os esforços de adoção de nuvem amadurecem. Conforme ilustrado pelas implementações de referência, as iterações futuras geralmente se concentram em adições de configuração secundárias. Examine as Opções de implementação da zona de destino do Azure para começar com a opção que melhor atende à sua linha de base de operações. Siga o caminho de iteração definido nos princípios de design dessa opção.

Operações descentralizadas

Operações descentralizadas

As operações são sempre complexas. Se você limitar o escopo de suas operações a uma carga de trabalho ou a uma pequena coleção de cargas de trabalho, controlará a complexidade. As operações descentralizadas são as menos complexas dos modelos operacionais comuns. Nessa forma de operações, todas as cargas de trabalho operam independentemente por equipes de carga de trabalho dedicadas.

  • Prioridades: sua equipe mede a inovação em relação ao controle centralizado ou à padronização em várias cargas de trabalho.
  • Vantagem distinta: maximize a velocidade da inovação colocando as equipes de carga de trabalho e negócios em controle total do design, da compilação e das operações.
  • Desvantagem distinta: redução na padronização entre cargas de trabalho, economias de escala por meio de serviços compartilhados e esforços de conformidade centralizada de governança.
  • Risco: essa abordagem apresenta risco ao gerenciar um portfólio de cargas de trabalho. As equipes de carga de trabalho podem ter equipes especializadas dedicadas a funções de centrais de TI. Esse modelo operacional é exibido como uma opção de alto risco por algumas organizações, especialmente as empresas que precisam seguir os requisitos de conformidade de terceiros.
  • Diretrizes: as operações descentralizadas são limitadas a decisões no nível da carga de trabalho. O Microsoft Azure Well-Architected Framework dá suporte às decisões tomadas dentro desse escopo. Os processos e as diretrizes dentro da estrutura de adoção de nuvem podem adicionar sobrecarga que não é exigida por operações descentralizadas.

Vantagens de operações descentralizadas

  • Gerenciamento de custos: o custo das operações é facilmente mapeado para uma única unidade de negócios. As operações específicas da carga de trabalho dão suporte a maior otimização de carga de trabalho.
  • Responsabilidades: normalmente, essa forma de operações é altamente dependente da automação para minimizar a sobrecarga. As responsabilidades tendem a se concentrar em DevOps e pipelines para o gerenciamento de liberações. Esse tipo de operação dá suporte a implantações mais rápidas e ciclos de comentários mais curtos durante o desenvolvimento.
  • Padronização: use um código-fonte e um pipeline de implantação para padronizar o ambiente da versão para a versão.
  • Suporte a operações: decisões que afetam as operações só se preocupam com as necessidades dessa carga de trabalho e simplificam as decisões de operações. Os membros da comunidade DevOps dizem que o suporte a operações é a forma mais pura de operações devido ao escopo operacional mais rígido.
  • Experiência: as equipes de DevOps e desenvolvimento são mais capacitadas por essa abordagem e experimentam o mínimo de resistência à condução de mudanças no mercado.
  • Design de zona de destino: nenhuma vantagem operacional específica.
  • Utilitários fundamentais: nenhuma vantagem operacional específica.
  • Separação de tarefas: nenhuma vantagem operacional específica.

Desvantagens das operações descentralizadas

  • Gerenciamento de custos: os custos empresariais são mais difíceis de calcular. A falta de equipes de governança centralizadas dificulta a implementação de controles de custo uniforme ou otimização. Em grande escala, esse modelo pode ser dispendioso, pois cada carga de trabalho pode ter duplicação em ativos implantados e atribuições de pessoal.
  • Responsabilidades: a falta de suporte centralizado significa que a equipe de carga de trabalho é inteiramente responsável por governança, segurança, operações e gerenciamento de alterações. A falta de suporte é problemática quando essas tarefas não foram automatizadas em pipelines de revisão e lançamento de código.
  • Padronização: a padronização em um portfólio de cargas de trabalho é variável e inconsistente.
  • Suporte a operações: as eficiências de escala geralmente são perdidas ao criar melhores práticas em várias cargas de trabalho.
  • Experiência: os membros da equipe têm uma maior responsabilidade de tomar decisões inteligentes e éticas sobre governança, segurança, operações e gerenciamento de alterações no design e na configuração do aplicativo. Consulte o Microsoft Azure Well-Architected Review e o Azure Well-Architected Framework com frequência para melhorar a experiência necessária.
  • Design de zona de destino: as zonas de destino não são específicas da carga de trabalho e não são consideradas nessa abordagem.
  • Utilitários fundamentais: alguns serviços fundamentais (se houver) são compartilhados entre cargas de trabalho, reduzindo a eficiência da escala.
  • Separação de tarefas: requisitos mais altos para devOps e equipes de desenvolvimento aumentam o uso de privilégios elevados dessas equipes. Se você precisar de separação de tarefas, talvez seja necessário investir muito na maturidade do DevOps para operar com essa abordagem.

Operações centralizadas

Operações centralizadas

Ambientes de estado estável podem não exigir foco na arquitetura ou em requisitos operacionais distintos das cargas de trabalho individuais. As operações centrais tendem a ser a norma para ambientes de tecnologia que consistem principalmente em cargas de trabalho de estado estável. Exemplos de operações de estado estável incluem coisas como aplicativos COTS (commercial off-the-shelf) ou aplicativos personalizados bem estabelecidos que têm uma cadência de versão lenta. Se uma taxa de alteração for orientada por atualizações regulares e patches, a centralização das operações poderá ser uma maneira eficaz de gerenciar seu portfólio.

  • Prioridades: as prioridades são o controle central da inovação e medem os processos operacionais existentes na mudança cultural para operações de nuvem modernas.
  • Vantagem distinta: a centralização introduz economias de escala, os melhores controles e as operações padronizadas e funciona melhor com o ambiente de nuvem. Esses ambientes precisam de configurações específicas para integrar operações de nuvem em processos e operações existentes. A centralização é mais vantajosa com um portfólio de algumas centenas de cargas de trabalho com complexidade e requisitos de conformidade de arquitetura modesto.
  • Desvantagem distinta: a colocação em escala para atender às demandas de um grande portfólio de cargas de trabalho pode colocar um esforço significativo em equipes centralizadas que tomam decisões operacionais para cargas de trabalho de produção. Se os ativos técnicos esperam escalar além de 1.000 VMs, aplicativos ou fontes de dados, você poderá considerar um modelo empresarial se ele estiver dentro de 18 a 24 meses.
  • Risco: essa abordagem limita a centralização a um número menor de assinaturas (geralmente uma assinatura de produção). Um risco significativo é envolvido na refatoração posteriormente em sua jornada de nuvem e pode interferir nos planos de adoção. Para evitar o retrabalho, tente se concentrar na segmentação, nos limites do ambiente, nas ferramentas de identidade e em outros elementos básicos.
  • Diretrizes: as opções de implementação de zona de destino do Azure que estão alinhadas à velocidade de desenvolvimento "Começar pequena e expandir" criam um ponto de partida de som. Você pode usar essas opções para acelerar os esforços de adoção. Mas, para ser bem-sucedido, estabeleça políticas claras para orientar os esforços de adoção precoce dentro de tolerâncias de risco aceitáveis. Controlar e gerenciar metodologias ajuda a criar processos para operações maduras em paralelo. Seguir essas etapas servem como as Gates de estágio que devem ser concluídas antes de permitir um maior risco conforme as operações amadurecerem.

Vantagens de operações centralizadas

  • Gerenciamento de custos: centralizar serviços compartilhados em várias cargas de trabalho cria economias de escala e elimina tarefas duplicadas. As equipes centrais podem implementar rapidamente reduções de custos por meio de otimizações de dimensionamento e escala em toda a empresa.
  • Responsabilidades: especialistas e padronização centralizados podem levar a uma maior estabilidade, melhor desempenho operacional e interrupções mínimas relacionadas à alteração. Essa abordagem reduz as amplas pressões de habilidades sobre as equipes focadas na carga de trabalho.
  • Padronização: em geral, a padronização e o custo das operações são os mais baixos com um modelo centralizado porque há menos sistemas duplicados ou tarefas.
  • Suporte a operações: reduzir a complexidade e centralizar operações facilita o suporte a operações de equipes de TI menores.
  • Experiência: Centralizar as equipes de suporte permite que especialistas em segurança, risco, governança e operações impulsionem decisões críticas para os negócios.
  • Design de zona de destino: a TI central reduz a complexidade, minimizando o número de zonas de aterrissagem e assinaturas. Os designs de zona de destino tendem a imitar os designs de datacenters anteriores, o que reduz o tempo de transição À medida que a adoção progride, os recursos compartilhados podem ser movidos para uma assinatura ou base de plataforma separada.
  • Utilitários fundamentais: você carrega designs de datacenter existentes para a nuvem resulta em serviços básicos e compartilhados que imitam ferramentas e operações locais. Quando as operações locais são seu modelo operacional primário, pode ser uma vantagem, mas cuidado com algumas desvantagens. As operações locais reduzem o tempo de transição, capitalizam as economias de escala e dão suporte a processos operacionais consistentes entre cargas de trabalho locais e hospedadas na nuvem. Essa abordagem pode reduzir a complexidade e o esforço de curto prazo e permitir que equipes menores dêem suporte a operações de nuvem com curvas de aprendizado reduzidas.
  • Separação de tarefas: a separação de tarefas é clara nas operações centrais. A TI central mantém o controle dos ambientes de produção e reduz a necessidade de permissões elevadas de outras equipes. Essa abordagem reduz as violações limitando o número de contas com privilégios elevados.

Desvantagens de operações centralizadas

  • Gerenciamento de custos: as equipes centrais nem sempre entendem arquiteturas de carga de trabalho para produzir otimizações de impacto no nível de carga de trabalho. Essa falta de compreensão limita a quantidade de economia de custos proveniente de operações de carga de trabalho bem ajustadas. Não entender totalmente a arquitetura da carga de trabalho pode afetar as otimizações de custo centralizado, que afetam o desempenho, a escala e outros pilares de uma carga de trabalho bem projetada. Antes de aplicar alterações de custo em toda a empresa a cargas de trabalho de alto perfil, sua equipe central de TI deve entender e concluir a Revisão de Well-Architected do Microsoft Azure.
  • Responsabilidades: centralizar o suporte e o acesso à produção coloca uma carga operacional alta em algumas pessoas e maior pressão em cada indivíduo. As pressões colocadas nesses indivíduos causam a necessidade de realizar revisões mais detalhadas das cargas de trabalho implantadas, que validam a adesão a requisitos de conformidade e governança de segurança detalhados.
  • Padronização: as abordagens de TI centrais tornam difícil escalar a padronização sem uma colocação em escala linear da equipe de TI central.
  • Suporte a operações: as melhores desvantagens dessa abordagem são associadas a escala e turnos significativos que medem a inovação.
  • Experiência: os desenvolvedores e DevOps especialistas estão em risco de serem subestimados ou muito restritos nesse tipo de ambiente.
  • Design de zona de destino: os designs de datacenter são baseados nas restrições de abordagens anteriores, que nem sempre são relevantes para a nuvem. Seguir essa abordagem reduz as oportunidades de reformular a segmentação de ambiente e capacitar oportunidades de inovação. A falta de segmentação da zona de destino aumenta o efeito potencial da violação, da complexidade da governança e da adesão à conformidade e pode criar bloqueadores para a adoção no percurso da nuvem. Consulte a seção de riscos acima.
  • Utilitários fundamentais: durante a transformação digital, a nuvem pode se tornar o modelo operacional principal. Ferramentas centrais, que são criadas para operações locais, reduzem oportunidades para modernizar operações e aumentar a eficiência operacional. Optar por não modernizar operações no início do processo de adoção também é uma opção. A modernização pode ser obtida criando uma assinatura de base de plataforma no percurso de adoção da nuvem. Esse esforço pode ser complexo, caro e demorado sem planejamento avançado.
  • Separação de tarefas: as operações centrais geralmente seguem um dos dois caminhos e ambas podem dificultar a inovação.
    • Opção 1: as equipes fora da TI central recebem acesso limitado a ambientes de desenvolvimento que imitam a produção. Essa opção prejudica a experimentação.
    • Opção 2: as equipes desenvolvem e testam em ambientes sem suporte. Essa opção prejudica os processos de implantação e reduz o teste de integração pós-implantação.

Operações corporativas

Operações corporativas

As operações empresarias são o estado de destino sugerido para todas as operações de nuvem. As operações empresarias equilibram a necessidade de controle e inovação simplificando decisões e responsabilidades. A IT Central é substituída por um centro de excelência em nuvem mais facilitador ou equipe de CCoE, que dá suporte a equipes de carga de trabalho. A equipe de CCoE, mantém as equipes de carga de trabalho responsáveis por decisões, em vez de controlar ou limitar suas ações. As equipes de carga de trabalho têm mais poder e mais responsabilidade para impulsionar a inovação, dentro de proteções bem definidas.

  • Prioridades: prioridades são a democratização de decisões técnicas. A democratização das decisões técnicas desloca as responsabilidades anteriormente mantidas pela TI central para as equipes de carga de trabalho. Para entregar essa mudança nas prioridades, as decisões tornam-se menos dependentes dos processos de revisão de executar humanos. Essa abordagem dá suporte à revisão automatizada, à governança e à imposição, usando ferramentas nativas de nuvem.
  • Vantagem distinta: a segmentação de ambientes e a separação de tarefas permitem o equilíbrio entre o controle e a inovação. As operações centralizadas mantêm cargas de trabalho que exigem maior conformidade e operações de estado estáveis ou representam maiores riscos de segurança. Por outro lado, essa abordagem dá suporte à redução do controle centralizado de cargas de trabalho e ambientes que exigem maior inovação. Portfólios maiores podem ter dificuldades com o equilíbrio entre controle e inovação. Essa flexibilidade facilita a escala de milhares de cargas de trabalho com reduções em problemas operacionais.
  • Desvantagem distinta: o que funcionou localmente pode não funcionar bem em operações de nuvem corporativa. Essa abordagem para operações requer alterações em muitas frentes. Mudanças culturais no controle e na responsabilidade geralmente são o maior desafio. As mudanças operacionais que seguem as mudanças culturais levam tempo e se comprometem com os esforços para implementar, amadurecer e estabilizar. Deslocamentos de arquitetura podem ser necessários em cargas de trabalho estáveis, enquanto turnos de ferramentas são necessários para capacitar e dar suporte às mudanças culturais, operacionais e de arquitetura. Esses turnos podem exigir compromissos com um provedor de nuvem primário. Os esforços de adoção feitos antes dessas alterações podem exigir um retrabalho significativo que vai além dos esforços típicos de refatoração.
  • Risco: essa abordagem requer compromisso executivo com a estratégia de alteração. Ele também requer o compromisso das equipes técnicas para superar as curvas de aprendizado e entregar a alteração necessária. A cooperação de longo prazo entre empresas, CCoE e TI central e equipes de carga de trabalho é necessária para ver benefícios a longo prazo.
  • Diretrizes: as opções de zona de destino do Azure são definidas como escala empresarial. Essas opções fornecem implementações de referência para demonstrar como as alterações técnicas são fornecidas usando ferramentas nativas de nuvem no Azure. A abordagem de escala empresarial orienta as equipes pelas mudanças operacionais e culturais necessárias para aproveitar ao máximo essas implementações. Essa mesma abordagem pode adaptar a arquitetura de referência para configurar o ambiente para atender às suas restrições de conformidade e estratégia de adoção. Quando você implementa a escala empresarial, as metodologias Controlar e Gerenciar podem ajudar a definir processos. Esses processos podem expandir seus recursos de conformidade e operações para atender às suas necessidades operacionais.

Vantagens das operações empresariais

  • Gerenciamento de custos: as equipes centrais atuam em otimizações entre portfólios e responsabilizam as equipes de carga de trabalho individuais por otimização mais profunda da carga de trabalho. As equipes focadas em carga de trabalho são capacitadas a tomar decisões e têm clareza quando essas decisões têm um efeito de custo negativo. As equipes centrais e de carga de trabalho compartilham a responsabilidade por decisões de custo no nível certo.
  • Responsabilidades: as equipes centrais usam ferramentas nativas de nuvem para definir, impor e automatizar as proteções. Os esforços da equipe de carga de trabalho são acelerados por meio de práticas e automação de CCoE. As equipes de carga de trabalho são capacitadas para impulsionar a inovação e tomar decisões dentro dessas proteções.
  • Padronização: as proteções centralizadas e os serviços fundamentais criam consistência em todos os ambientes.
  • Suporte a operações: cargas de trabalho que exigem suporte a operações centralizadas são segmentadas para ambientes com controles de estado estável. A segmentação e a separação de tarefas capacitam as equipes de carga de trabalho a levarem em conta o suporte operacional em seus próprios ambientes dedicados. Ferramentas nativas de nuvem automatizadas garantem uma linha de base de operações mínima para todos os ambientes com suporte operacional centralizado.
  • Experiência: centralizar os principais serviços, como segurança, risco, governança e operações, garante a experiência central adequada. Processos claros e proteção instruem e capacitam as equipes de carga de trabalho a tomar decisões mais detalhadas. Essas decisões expandem o efeito dos especialistas centralizados sem a necessidade de escalar a equipe linearmente com escala de tecnologia.
  • Design de zona de destino: o design da zona de destino replica as necessidades do portfólio, criando limites claros de segurança, governança e responsabilidade. Esses limites são necessários para operar cargas de trabalho na nuvem. É improvável que as práticas de segmentação se pareçam com as restrições criadas por designs de datacenter anteriores. Em operações empresariais, o design de zona de destino é menos complexo, permitindo uma escala mais rápida e barreiras reduzidas à demanda de autoatendimento.
  • Utilitários fundamentais: os utilitários fundamentais são hospedados em assinaturas controladas centralmente separadas, conhecidas como a base da plataforma. Em seguida, as ferramentas centrais são canalizadas para cada zona de destino como serviços utilitários. Separar utilitários fundamentais das zonas de destino maximiza a consistência e a economia de escala. Esses utilitários também criam distinções claras entre responsabilidades gerenciadas centralmente e responsabilidades de nível de carga de trabalho.
  • Separação de tarefas: limpar a separação de tarefas entre utilitários fundamentais e zonas de destino é uma das maiores vantagens na abordagem de operações. Ferramentas e processos nativos de nuvem dão suporte ao acesso e ao equilíbrio adequado de controle entre equipes centralizadas e equipes de carga de trabalho. Essa abordagem se baseia nos requisitos de zonas de destino individuais e cargas de trabalho hospedadas em segmentos de zona de destino.

Desvantagens das operações empresariais

  • Gerenciamento de custos: as equipes centrais dependem mais das equipes de carga de trabalho para fazer alterações de produção nas zonas de destino. Essa mudança cria um risco para possíveis estouros de orçamento e um dimensionamento correto mais lento dos gastos reais. Os processos de controle de custos, orçamentos limpos, controles automatizados e revisões regulares devem estar em prática no início para evitar surpresas de custo.
  • Responsabilidades: operações empresariais exigem requisitos culturais e operacionais maiores. Esses requisitos garantem clareza nas responsabilidades e a responsabilização entre as equipes centrais e de carga de trabalho.
  • Processos tradicionais de gerenciamento de alterações ou CABs (comitê de aconselhamento sobre mudanças), podem não manter o ritmo e o equilíbrio necessários nesse modelo operacional. Esses processos são refletidos na automatização de processos e procedimentos que dimensionam com segurança a adoção da nuvem.
  • A falta de compromisso com a mudança se materializa primeiro na negociação e no alinhamento das responsabilidades. A incapacidade de alinhar-se em turnos de responsabilidade é uma indicação de que modelos operacionais centrais de IT podem ser necessários durante os esforços de adoção de nuvem de curto prazo.
  • Padronização: a falta de investimento em proteções centralizadas ou automação cria riscos para a padronização, o que é mais difícil de superar por meio de processos de revisão manual. As dependências operacionais entre cargas de trabalho em zonas de destino e serviços compartilhados criam riscos maiores. Esses riscos se estendem da padronização durante ciclos de atualização ou versões futuras de utilitários fundamentais. Durante as revisões de base de plataforma, testes aprimorados ou até mesmo automatizados, é necessário de todas as zonas de destino com suporte e das cargas de trabalho hospedadas.
  • Suporte a operações: a linha de base de operações fornecida por meio de automação e operações centralizadas pode ser suficiente para cargas de trabalho de baixo impacto ou de baixa criticidade. Mas as equipes de carga de trabalho ou outras formas de operações dedicadas podem ser necessárias para cargas de trabalho complexas ou de alta criticalidade. Nesse caso, pode criar uma mudança nos orçamentos de operações, exigindo que as unidades de negócios forneçam despesas operacionais a essas formas de operações avançadas. Se a TI central for necessária para manter a responsabilidade exclusiva pelo custo das operações, as operações corporativas poderão ser difíceis de implementar.
  • Experiência: os membros da equipe de TI central podem ser obrigados a desenvolver experiência na automatização de controles centrais entregues anteriormente por meio de processos manuais. Além disso, essas equipes podem desenvolver proficiência para abordagens de infraestrutura como código para definir o ambiente e entender os pipelines de ramificação, mesclação e implantação. No mínimo, uma equipe de automação de plataforma pode precisar de habilidades de tomada de decisão para entender as decisões tomadas pelo centro de excelência de nuvem ou equipes de operações centrais. As equipes de carga de trabalho podem ser necessárias para desenvolver mais conhecimento relacionado aos controles e processos que regem suas decisões.
  • Design de zona de destino: o design da zona de destino depende dos utilitários fundamentais. As equipes de carga de trabalho devem entender o que está no design e o que é proibido de incluir. Essa compreensão pode ajudar a evitar a duplicação de esforços, erros ou conflitos. Para criar flexibilidade, você pode considerar os processos de exceção para seus designs de zona de destino.
  • Utilitários fundamentais: centralizar utilitários fundamentais leva tempo. Esses utilitários eventualmente consideram opções e desenvolvem soluções que podem ser dimensionadas para atender a vários planos de adoção. Atrasos nos esforços de adoção antecipados são possíveis. Os atrasos podem ser deslocados a longo prazo devido a acelerações e a evitação de bloqueador posteriormente no processo.
  • Separação de tarefas: garantir a separação clara de tarefas exige processos maduros de gerenciamento de identidade. Pode haver mais manutenção associada ao alinhamento adequado de usuários, grupos e atividades de integração e remoção. Talvez seja necessário adotar novos processos para acomodar o acesso just-in-time por meio de privilégios elevados.

Operações distribuídas

Operações distribuídas

O modelo operacional existente pode ser muito refinado para que toda a organização mude para um novo modelo operacional. Para outras, operações globais e vários requisitos de conformidade podem impedir que unidades de negócios específicas façam uma alteração. Nesse caso, pode exigir uma abordagem de operações de distribuição. Essa abordagem é de longe a mais complexa, pois requer a integração de um ou mais dos modelos operacionais mencionados anteriormente.

Embora seja muito desencorajado, essa abordagem de operações pode ser necessária para algumas organizações. A abordagem está relacionada principalmente a organizações que têm uma coleção flexível de unidades de negócios diferentes, uma base diversificada de segmentos de clientes ou operações regionais.

  • Prioridades: integrar vários modelos operacionais existentes.
  • Estado de transição com foco na movimentação de toda a organização para um dos modelos operacionais mencionados anteriormente.
  • A abordagem operacional de termo mais longo quando a organização é muito grande ou muito complexa para ser alinhada a um único modelo operacional.
  • Vantagem distinta: integre elementos comuns do modelo operacional de cada unidade de negócios. Essa abordagem cria um veículo para agrupar unidades operacionais em uma hierarquia que as ajuda a amadurecer operações usando processos repetíveis consistentes.
  • Desvantagem distinta: a consistência e a padronização em vários modelos operacionais é difícil de manter por períodos estendidos. Essa abordagem operacional requer uma profunda conscientização sobre o portfólio e como vários segmentos do portfólio de tecnologia operam.
  • Risco: a falta de compromisso com um modelo operacional primário pode levar à confusão entre as equipes. Use esse modelo operacional quando não houver como se alinhar a um único modelo operacional.
  • Diretrizes: comece com uma revisão completa do portfólio, que usa a abordagem descrita nos artigos de alinhamento de negócios. Tente agrupar o portfólio pelo modelo operacional de estado (descentralizado, centralizado ou empresarial).
  • Desenvolva uma hierarquia de grupo de gerenciamento que reflita os agrupamentos de modelo operacional. Essa disposição inclui outros padrões organizacionais para região, unidade de negócios ou outros critérios que mapeiam os clusters de carga de trabalho dos buckets menos comuns aos mais comuns.
  • Avalie o alinhamento das cargas de trabalho com os modelos operacionais para localizar o cluster de modelo operacional mais relevante com o qual começar. Siga as diretrizes que são mapeadas para o modelo operacional para todas as cargas de trabalho na hierarquia do grupo de nós e gerenciamento.
  • Use as metodologias Controlar e Gerenciar para encontrar políticas corporativas comuns, incluindo as práticas de gerenciamento operacional necessárias em vários pontos da hierarquia. Aplique políticas comuns do Azure para automatizar as políticas corporativas compartilhadas.
  • Ao testar as políticas do Azure com várias implantações, tente movê-las mais alto na hierarquia do grupo de gerenciamento. As políticas podem ser aplicadas a muitas cargas de trabalho, o que pode encontrar semelhanças e necessidades de operação distintas.
  • Ao longo do tempo, essa abordagem pode ajudá-lo a definir um modelo que pode ser dimensionado em vários modelos operacionais. Essa abordagem também pode unificar as equipes por meio de um conjunto de políticas e procedimentos comuns.

As vantagens e desvantagens dessa abordagem estão propositadamente em branco. Depois de concluir o alinhamento comercial do seu portfólio, consulte a seção modelo de operação predominante acima para obter clareza sobre as vantagens e desvantagens.

Próximas etapas

Saiba sobre a terminologia associada aos modelos operacionais. A terminologia ajuda você a entender como um modelo operacional se encaixa no maior tema do planejamento corporativo.

Saiba como as zonas de aterrissagem fornecem os blocos de construção básicos de qualquer ambiente de adoção da nuvem.