Rever e comparar modelos operacionais comuns da cloud

Os modelos operacionais são exclusivos e específicos da empresa que suportam, com base nos requisitos e restrições atuais. Mas os modelos operacionais não são flocos de neve. Existem vários padrões comuns nos modelos operacionais do cliente; este artigo descreve os quatro padrões mais comuns.

Comparação de modelos operacionais

A imagem seguinte mapeia modelos operacionais comuns com base no intervalo de complexidade, desde menos complexos (descentralizados) até às operações mais complexas (operações globais). As tabelas seguintes 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 âmbito

Um modelo operacional na cloud é essencialmente impulsionado por dois fatores:

  • Prioridades ou motivações estratégicas
  • Âmbito do portefólio a ser gerido
Operações descentralizadas (operações) Operações centralizadas (operações) Operações empresariais (operações) Operações distribuídas (operações)
Prioridades ou motivações estratégicas Inovação Controlar Democratização Integração
Âmbito do portefólio Carga de trabalho Zona de destino Plataforma da cloud Portefólio completo
Ambiente de carga de trabalho Elevada complexidade Baixa complexidade Complexidade média Complexidade média ou variável
Zona de destino N/D Elevada complexidade Complexidade média a baixa Baixa complexidade
Utilitários de fundação N/D N/D ou baixo suporte Suporte centralizado e mais Maior parte do suporte
Cloud Foundation N/D N/D Bases híbridas, específicas do fornecedor ou regionais Distribuído e sincronizado
  • Prioridades ou motivações estratégicas: cada modelo operacional fornece as motivações estratégicas típicas para a adoção da cloud. Mas alguns modelos operacionais simplificam motivações específicas.

  • Âmbito do portefólio: o âmbito do portefólio identifica o maior âmbito suportado por um modelo operacional específico. Por exemplo, as operações centralizadas foram concebidas para algumas zonas de destino. Contudo, a decisão do modelo operacional pode criar riscos operacionais para uma organização. Os riscos operacionais resultam ao tentar gerir um portefólio complexo de grandes dimensões. Estes portefólios podem exigir muitas zonas de destino ou complexidade variável na conceção da zona de destino.

Importante

A adoção da cloud aciona frequentemente uma reflexão sobre o modelo operacional atual e pode levar a uma mudança de um modelo operacional comum para outro. No entanto, a adoção da cloud não é o único acionador. As prioridades empresariais e o âmbito da adoção da cloud podem alterar a forma como o portefólio tem de ser suportado. Além disso, podem existir outras mudanças no modelo operacional mais adequado. Quando o conselho de administração, ou outras equipas executivas, desenvolvem planos de negócios de 5 a 10 anos, esses planos incluem frequentemente um requisito (explícito ou implícito) para ajustar o modelo operacional. Os modelos operacionais são uma boa referência para orientar decisões. Estes modelos podem ser alterados ou têm de ser personalizados para satisfazer os seus requisitos e restrições.

Alinhamento da responsabilidade

Muitas equipas e indivíduos são responsáveis por suportar diferentes funções. Mas cada modelo operacional comum atribui a responsabilidade final pelos resultados da decisão a uma equipa ou a um indivíduo. Esta abordagem afeta a forma como o modelo operacional é financiado e o nível de suporte fornecido para cada função.

Operações descentralizadas Operações centralizadas Operações empresariais Operações distribuídas
Alinhamento comercial Equipa de carga de trabalho Estratégia de cloud central CCoE Variable – formar uma ampla equipa de estratégia da cloud?
Operações da cloud Equipa de carga de trabalho TI central CCoE Com base na análise de portefólio – veja Alinhamento empresarial e Compromissos empresariais
Governação da cloud Equipa de carga de trabalho TI central CCoE Várias camadas de governação
Segurança da cloud Equipa de carga de trabalho Centro de operações de segurança (SOC) CCoE + SOC Misto - veja Definir uma estratégia de segurança
Automatização da cloud e DevOps Equipa de carga de trabalho TI Central ou N/D CCoE Com base na análise de portefólio – veja Alinhamento empresarial e Compromissos empresariais

Acelerar a implementação do modelo operacional no Azure

Conforme abordado em Definir o seu modelo operacional, cada metodologia do Cloud Adoption Framework fornece um caminho estruturado para desenvolver o seu modelo operacional. Estas metodologias podem ajudá-lo a superar os bloqueadores que decorrem de lacunas na adoção do modelo operacional da cloud.

A tabela seguinte descreve formas de acelerar a implementação do modelo operacional.

Operações descentralizadas Operações centralizadas Operações empresariais Operações distribuídas
Ponto de partida Azure Well-Architected Framework (WAF) Zonas de destino do Azure: opções de início pequeno Zonas de destino do Azure: dimensionamento empresarial do CAF Alinhamento comercial
Iterações Um foco nas cargas de trabalho permite que a equipa itere dentro da WAF. A opção start-small requer mais iteração em cada metodologia, mas pode ser feita à medida que os esforços de adoção da cloud amadurecem. Conforme ilustrado pelas implementações de referência, as iterações futuras normalmente focam-se em pequenas adições de configuração. Reveja as opções de implementação da zona de destino do Azure para começar com a opção que melhor cumpre a linha de base de operações. Siga o caminho de iteração definido nos princípios de estrutura dessa opção.

Operações descentralizadas

Operações descentralizadas

As operações são sempre complexas. Se limitar o âmbito das suas operações a uma carga de trabalho ou a uma pequena coleção de cargas de trabalho, controla a complexidade. As operações descentralizadas são as menos complexas dos modelos operacionais comuns. Nesta forma de operações, todas as cargas de trabalho operam de forma independente pelas equipas de cargas de trabalho dedicadas.

  • Prioridades: a sua equipa mede a inovação sobre o controlo centralizado ou a uniformização em várias cargas de trabalho.
  • Vantagem distinta: maximize a velocidade de inovação ao colocar a carga de trabalho e as equipas empresariais no controlo total da conceção, compilação e operações.
  • Desvantagem distinta: redução da uniformização entre cargas de trabalho, economias de dimensionamento através de serviços partilhados e esforços consistentes de conformidade centralizada de governação.
  • Risco: esta abordagem introduz riscos ao gerir um portefólio de cargas de trabalho. As equipas de carga de trabalho podem ter equipas especializadas dedicadas a funções de TI centrais. Este modelo operacional é visto como uma opção de alto risco por algumas organizações, especialmente empresas que são obrigadas a seguir os requisitos de conformidade de terceiros.
  • Orientação: as operações descentralizadas estão limitadas a decisões ao nível da carga de trabalho. O Microsoft Azure Well-Architected Framework suporta as decisões tomadas nesse âmbito. Os processos e a documentação de orientação no Cloud Adoption Framework podem adicionar custos gerais que não são necessários para operações descentralizadas.

Vantagens das operações descentralizadas

  • Gestão de custos: o custo das operações é facilmente mapeado para uma única unidade de negócio. As operações específicas da carga de trabalho suportam uma maior otimização da carga de trabalho.
  • Responsabilidades: normalmente, esta forma de operações é altamente dependente da automatização para minimizar a sobrecarga. As responsabilidades tendem a focar-se no DevOps e nos pipelines para a gestão de versões. Este tipo de operações suporta implementações mais rápidas e ciclos de feedback mais curtos durante o desenvolvimento.
  • Uniformização: utilize um código fonte e um pipeline de implementação para uniformizar o ambiente de versão para lançamento.
  • Suporte de operações: as decisões que afetam as operações só se preocupam com as necessidades dessa carga de trabalho e com a simplificação das decisões de operações. Os membros da comunidade de DevOps dizem que o suporte de operações é a forma mais pura de operações devido ao âmbito operacional mais apertado.
  • Conhecimentos: o DevOps e as equipas de desenvolvimento são mais capacitados por esta abordagem e experimentam a menor resistência a impulsionar a mudança de mercado.
  • Design da zona de destino: nenhuma vantagem operacional específica.
  • Utilitários fundamentais: nenhuma vantagem operacional específica.
  • Separação de deveres: nenhuma vantagem operacional específica.

Desvantagens das operações descentralizadas

  • Gestão de custos: os custos empresariais são mais difíceis de calcular. A falta de equipas de governação centralizadas dificulta a implementação de controlos de custos ou otimização uniformes. Em escala, este modelo pode ser dispendioso, uma vez que cada carga de trabalho pode ter duplicações em recursos implementados e atribuições de pessoal.
  • Responsabilidades: a falta de suporte centralizado significa que a equipa de carga de trabalho é inteiramente responsável pela gestão da governação, segurança, operações e alterações. A falta de suporte é problemática quando essas tarefas não foram automatizadas em pipelines de revisão e versão de código.
  • Uniformização: a uniformização num portefólio de cargas de trabalho é variável e inconsistente.
  • Suporte de operações: muitas vezes, as eficiências de dimensionamento são perdidas ao criar as melhores práticas em várias cargas de trabalho.
  • Conhecimentos: os membros da equipa têm uma maior responsabilidade de tomar decisões sábias e éticas sobre governação, segurança, operações e gestão de alterações na estrutura e configuração da aplicação. Consulte frequentemente o Microsoft Azure Well-Architected Review e o Azure Well-Architected Framework para melhorar os conhecimentos necessários.
  • Design da zona de destino: as zonas de destino não são específicas da carga de trabalho e não são consideradas nesta abordagem.
  • Utilitários fundamentais: poucos (se existirem) serviços fundamentais são partilhados entre cargas de trabalho, o que reduz a eficiência de dimensionamento.
  • Separação de deveres: os requisitos mais elevados para o DevOps e as equipas de desenvolvimento aumentam a utilização de privilégios elevados dessas equipas. Se necessitar de separação de deveres, poderá ter de investir fortemente na maturidade do DevOps para operar com esta abordagem.

Operações centralizadas

Operações centralizadas

Os ambientes de estado estáveis podem não exigir foco na arquitetura ou requisitos operacionais distintos das cargas de trabalho individuais. As operações centrais tendem a ser a norma para ambientes tecnológicos que consistem principalmente em cargas de trabalho de estado estável. Exemplos de operações de estado estável incluem coisas como aplicações de fora da prateleira (COTS) ou aplicações personalizadas bem estabelecidas que têm uma cadência de lançamento lenta. Se uma taxa de alteração for impulsionada por atualizações e patches regulares, a centralização das operações poderá ser uma forma eficaz de gerir o seu portefólio.

  • Prioridades: as prioridades são o controlo central sobre a inovação e medem os processos operacionais existentes sobre a mudança cultural para operações na cloud modernas.
  • Vantagem distinta: a centralização introduz economias de escala, melhores controlos de raça e operações padronizadas e funciona melhor com o ambiente da cloud. Estes ambientes precisam de configurações específicas para integrar operações na cloud em operações e processos existentes. A centralização é muito vantajosa com um portfólio de algumas centenas de cargas de trabalho com requisitos de conformidade e complexidade arquitectónica modestos.
  • Desvantagem distinta: o dimensionamento para satisfazer as exigências de um grande portefólio de cargas de trabalho pode colocar uma pressão significativa nas equipas centralizadas que tomam decisões operacionais para cargas de trabalho de produção. Se os recursos técnicos esperarem dimensionar para além de 1000 VMs, aplicações ou origens de dados, poderá considerar um modelo empresarial se estiver dentro de 18 a 24 meses.
  • Risco: esta abordagem limita a centralização a um número menor de subscrições (muitas vezes uma subscrição de produção). Está envolvido um risco significativo ao refatorizar mais tarde no seu percurso na cloud e pode interferir com os seus planos de adoção. Para evitar a reformulação, tente focar-se na segmentação, nos limites do ambiente, nas ferramentas de identidade e noutros elementos fundamentais.
  • Orientação: as opções de implementação da zona de destino do Azure alinhadas com a velocidade de desenvolvimento "começar pequeno e expandir" criam um ponto de partida sonoro. Pode utilizar estas 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. As metodologias de governação e gestão ajudam a criar processos para melhorar as operações em paralelo. Seguir estes passos serve como portas de fase que têm de ser concluídas antes de permitir um risco acrescido à medida que as operações amadurecem.

Vantagens das operações centralizadas

  • Gestão de custos: centralizar serviços partilhados em muitas cargas de trabalho cria economias de dimensionamento e elimina tarefas duplicadas. As equipas centrais podem implementar rapidamente reduções de custos através de otimizações de dimensionamento e dimensionamento a nível empresarial.
  • Responsabilidades: os conhecimentos centralizados e a uniformização podem levar a uma maior estabilidade, melhor desempenho operacional e interrupções mínimas relacionadas com alterações. Esta abordagem reduz as grandes pressões de qualificação nas equipas focadas na carga de trabalho.
  • Uniformização: em geral, a uniformização e o custo das operações são mais baixos com um modelo centralizado porque existem menos sistemas ou tarefas duplicados.
  • Suporte de operações: reduzir a complexidade e centralizar as operações facilita o suporte de operações por parte das equipas de TI mais pequenas.
  • Conhecimentos: Centralizar as equipas de suporte permite que especialistas em segurança, risco, governação e operações impulsionem decisões críticas para a empresa.
  • Design da zona de destino: as TI centrais reduzem a complexidade ao minimizar o número de zonas de destino e subscrições. Os designs de zona de destino tendem a imitar os designs de datacenter anteriores, o que reduz o tempo de transição. À medida que a adoção progride, os recursos partilhados podem ser movidos para uma base de plataforma ou subscrição separada.
  • Utilitários fundamentais: os designs de datacenters existentes para a cloud resultam em serviços partilhados fundamentais que imitam ferramentas e operações no local. Quando as operações no local são o seu modelo operacional principal, pode ser uma vantagem, mas tenha em atenção algumas desvantagens. As operações no local reduzem o tempo de transição, capitalizam-se em economias de escala e suportam processos operacionais consistentes entre cargas de trabalho alojadas no local e na cloud. Esta abordagem pode reduzir a complexidade e o esforço a curto prazo e permitir que equipas mais pequenas suportem operações na cloud com curvas de aprendizagem reduzidas.
  • Separação de deveres: a separação de deveres é clara nas operações centrais. A TI Central mantém o controlo dos ambientes de produção e reduz a necessidade de permissões elevadas de outras equipas. Esta abordagem reduz as falhas de segurança ao limitar o número de contas com privilégios elevados.

Desvantagens das operações centralizadas

  • Gestão de custos: as equipas centrais nem sempre compreendem as arquiteturas de cargas de trabalho para produzir otimizações com impacto ao nível da carga de trabalho. Esta falta de compreensão limita a quantidade de poupanças de custos provenientes de operações de carga de trabalho bem ajustadas. Não compreender totalmente a arquitetura da carga de trabalho pode afetar as otimizações de custos centralizadas, que afetam o desempenho, o dimensionamento e outros pilares de uma carga de trabalho bem arquitetizada. Antes de aplicar alterações de custos a nível empresarial a cargas de trabalho de alto perfil, a sua equipa de TI central deve compreender e concluir o Microsoft Azure Well-Architected Review.
  • Responsabilidades: centralizar o apoio e o acesso à produção coloca uma carga operacional elevada sobre algumas pessoas e uma maior pressão sobre cada indivíduo. As pressões colocadas sobre estes indivíduos fazem com que seja necessário efetuar revisões mais aprofundadas das cargas de trabalho implementadas, que validam a adesão aos requisitos detalhados de governação e conformidade de segurança.
  • Uniformização: as abordagens de TI centrais dificultam a uniformização de dimensionamento sem um dimensionamento linear do pessoal de TI central.
  • Suporte de operações: as maiores desvantagens desta abordagem estão associadas a escalas e mudanças significativas que medem a inovação.
  • Conhecimentos especializados: Os especialistas em Programadores e DevOps estão em risco de serem subva valorizados ou demasiado restritos neste tipo de ambiente.
  • Design da zona de destino: as estruturas do Datacenter baseiam-se nas restrições das abordagens anteriores, que nem sempre são relevantes para a cloud. Seguir esta abordagem reduz as oportunidades de repensar a segmentação do ambiente e capacitar oportunidades de inovação. A falta de segmentação de zonas de destino aumenta o efeito potencial de violação, complexidade da conformidade e governação e pode criar bloqueadores para adoção no percurso da cloud. Veja a secção de riscos acima.
  • Utilitários fundamentais: durante a transformação digital, a cloud pode tornar-se o modelo operacional principal. As ferramentas centrais, criadas para operações no local, reduzem as oportunidades para modernizar as operações e aumentar a eficiência operacional. Optar por não modernizar as operações no início do processo de adoção também é uma opção. A modernização pode ser conseguida ao criar uma subscrição de base de plataforma no percurso de adoção da cloud. Esse esforço pode ser complexo, dispendioso e moroso sem planeamento avançado.
  • Separação de deveres: geralmente, as operações centrais seguem um de dois caminhos e ambos podem dificultar a inovação.
    • Opção 1: as equipas fora da TI central têm acesso limitado a ambientes de desenvolvimento que imitam a produção. Esta opção dificulta a experimentação.
    • Opção 2: o Teams desenvolve e testa em ambientes não suportados. Esta opção dificulta os processos de implementação e atrasa os testes de integração pós-implementação.

Operações empresariais

Operações empresariais

As operações empresariais são o estado de destino sugerido para todas as operações na cloud. As operações empresariais equilibram a necessidade de controlo e inovação ao simplificar as decisões e as responsabilidades. As TI centrais são substituídas por um centro de excelência da cloud mais facilitador ou equipa CCoE, que suporta equipas de cargas de trabalho. A equipa do CCoE responsabiliza as equipas de cargas de trabalho por decisões, em vez de controlar ou limitar as suas ações. As equipas de carga de trabalho têm mais poder e mais responsabilidade para impulsionar a inovação, dentro de proteções bem definidas.

  • Prioridades: as prioridades são a democratização das decisões técnicas. A democratização das decisões técnicas muda as responsabilidades anteriormente detidas pelas TI centrais para as equipas de cargas de trabalho. Para cumprir esta mudança de prioridades, as decisões tornam-se menos dependentes dos processos de revisão de execução humana. Esta abordagem suporta a revisão, governação e imposição automatizadas através de ferramentas nativas da cloud.
  • Vantagem distinta: a segmentação de ambientes e a separação de deveres permitem o equilíbrio entre o controlo e a inovação. As operações centralizadas mantêm cargas de trabalho que exigem uma maior conformidade e operações de estado estáveis ou representam maiores riscos de segurança. Por outro lado, esta abordagem suporta a redução do controlo centralizado das cargas de trabalho e dos ambientes que exigem uma maior inovação. Portefólios maiores podem lutar com o equilíbrio entre o controlo e a inovação. Esta flexibilidade torna mais fácil dimensionar milhares de cargas de trabalho com reduções nas dores operacionais.
  • Desvantagem distinta: o que funcionou no local pode não funcionar bem nas operações da cloud empresarial. Esta abordagem às operações requer alterações em muitas frentes. As mudanças culturais no controlo e na responsabilidade são muitas vezes o maior desafio. As mudanças operacionais que se seguem às mudanças culturais demoram tempo e comprometem esforços para implementar, amadurecer e estabilizar. As mudanças arquitectónicas podem ser necessárias em cargas de trabalho estáveis, enquanto as mudanças de ferramentas são necessárias para capacitar e apoiar as mudanças culturais, operacionais e arquitetónicas. Estes turnos podem exigir compromissos para um fornecedor de cloud principal. Os esforços de adoção realizados antes destas alterações podem exigir uma reformulação significativa que vai além dos esforços típicos de refatorização.
  • Risco: esta abordagem requer um compromisso executivo com a estratégia de mudança. Também requer alocação das equipas técnicas para superar as curvas de aprendizagem e proporcionar a alteração necessária. A cooperação a longo prazo entre empresas, CCoE e TI central e equipas de cargas de trabalho é necessária para ver benefícios a longo prazo.
  • Orientação: as opções de zona de destino do Azure são definidas como à escala empresarial. Estas opções fornecem implementações de referência para demonstrar como as alterações técnicas são fornecidas com ferramentas nativas da cloud no Azure. A abordagem à escala empresarial orienta as equipas através das mudanças operacionais e culturais necessárias para tirar o máximo partido dessas implementações. Essa mesma abordagem pode adaptar a arquitetura de referência para configurar o ambiente para cumprir as restrições de conformidade e estratégia de adoção. Quando implementa metodologias de escala empresarial, as metodologias Governação e Gestão podem ajudar a definir processos. Estes processos podem expandir as suas capacidades de conformidade e operações para satisfazer as suas necessidades operacionais.

Vantagens das operações empresariais

  • Gestão de custos: as equipas centrais atuam em otimizações entre portefólios e responsabilizam as equipas de cargas de trabalho individuais pela otimização mais profunda da carga de trabalho. As equipas focadas na carga de trabalho têm capacidade para tomar decisões e fornecer clareza quando essas decisões têm um efeito de custo negativo. As equipas centrais e de carga de trabalho partilham a responsabilidade pelas decisões de custos no nível certo.
  • Responsabilidades: as equipas centrais utilizam ferramentas nativas da cloud para definir, impor e automatizar proteções. Os esforços da equipa de carga de trabalho são acelerados através da automatização e práticas do CCoE. As equipas de cargas de trabalho têm poderes para impulsionar a inovação e tomar decisões dentro dessas proteções.
  • Uniformização: proteções centralizadas e serviços fundamentais criam consistência em todos os ambientes.
  • Suporte de operações: as cargas de trabalho que necessitam de suporte de operações centralizadas são segmentadas em ambientes com controlos de estado estável. A segmentação e a separação de deveres permitem que as equipas de cargas de trabalho assumam a responsabilidade pelo suporte operacional nos seus próprios ambientes dedicados. As ferramentas nativas da cloud automatizadas garantem uma linha de base de operações mínima para todos os ambientes com suporte operacional centralizado.
  • Conhecimentos especializados: a centralização de serviços essenciais, como segurança, risco, governação e operações, garante conhecimentos centrais adequados. Processos limpos e proteções educam e capacitam as equipas de cargas de trabalho para tomarem decisões mais detalhadas. Estas decisões expandem o efeito dos peritos centralizados sem precisarem de dimensionar o pessoal linearmente com a escala tecnológica.
  • Design da zona de destino: o design da zona de destino replica as necessidades do portefólio, criando limites claros de segurança, governação e responsabilidade. Estes limites são necessários para operar cargas de trabalho na cloud. É pouco provável que as práticas de segmentação se assemelhem às restrições criadas pelas estruturas do datacenter anteriores. Nas operações empresariais, a conceção de zonas de destino é menos complexa, o que permite dimensionar mais rapidamente e reduzir as barreiras à procura self-service.
  • Utilitários fundamentais: os utilitários fundamentais são alojados em subscrições separadas controladas centralmente, conhecidas como base da plataforma. Em seguida, as ferramentas centrais são encaminhadas para cada zona de destino como serviços utilitários. Separar os utilitários fundamentais das zonas de destino maximiza a consistência e a economia de escala. Estes utilitários também criam distinções claras entre responsabilidades geridas centralmente e responsabilidades ao nível da carga de trabalho.
  • Separação de deveres: a separação clara dos deveres entre os utilitários fundamentais e as zonas de destino é uma das maiores vantagens na abordagem de operações. As ferramentas e processos nativos da cloud suportam o acesso e o equilíbrio adequado do controlo entre equipas centralizadas e equipas de carga de trabalho. Esta abordagem baseia-se nos requisitos de zonas de destino individuais e cargas de trabalho alojadas em segmentos de zona de destino.

Desvantagens das operações empresariais

  • Gestão de custos: as equipas centrais dependem mais das equipas de carga de trabalho para efetuar alterações de produção nas zonas de destino. Esta mudança cria um risco para potenciais ultrapassagens orçamentais e um dimensionamento mais lento da direita dos gastos reais. Os processos de controlo de custos, orçamentos claros, controlos automatizados e revisões regulares têm de estar em vigor mais cedo para evitar surpresas de custos.
  • Responsabilidades: as operações empresariais requerem maiores requisitos culturais e operacionais. Estes requisitos garantem clareza nas responsabilidades e responsabilidades entre as equipas centrais e de cargas de trabalho.
  • Os processos tradicionais de gestão de alterações ou os conselhos consultivos (cabs) podem não manter o ritmo e o equilíbrio necessários neste modelo operacional. Esses processos refletem-se na automatização de processos e procedimentos que dimensionam em segurança a adoção da cloud.
  • A falta de compromisso com a mudança materializa-se primeiro na negociação e no alinhamento das responsabilidades. A incapacidade de alinhar em turnos de responsabilidade é uma indicação de que podem ser necessários modelos operacionais de TI centrais durante os esforços de adoção da cloud de curto prazo.
  • Uniformização: a falta de investimento em proteções centralizadas ou automatização cria riscos para a uniformização, o que é mais difícil de ultrapassar através de processos de revisão manual. As dependências operacionais entre cargas de trabalho em zonas de destino e serviços partilhados criam maiores riscos. Estes riscos vão desde a uniformização durante ciclos de atualização ou versões futuras de utilitários fundamentais. Durante as revisões da base da plataforma, testes melhorados ou até automatizados, são necessárias todas as zonas de destino suportadas e as cargas de trabalho que alojam.
  • Suporte de operações: a linha de base de operações fornecida através da automatização e das operações centralizadas pode ser suficiente para cargas de trabalho de baixa afeção ou de baixa importância. Contudo, as equipas de carga de trabalho ou outras formas de operações dedicadas podem ser necessárias para cargas de trabalho complexas ou de elevada importância. Se assim for, poderá criar uma mudança nos orçamentos de operações, exigindo que as unidades de negócio atribuam despesas operacionais a essas formas de operações avançadas. Se for necessária uma TI central para manter a responsabilidade exclusiva pelo custo das operações, as operações empresariais poderão ser difíceis de implementar.
  • Conhecimentos: os membros da equipa de TI central podem ser obrigados a desenvolver conhecimentos especializados na automatização de controlos centrais anteriormente fornecidos através de processos manuais. Além disso, estas equipas podem desenvolver proficiência para abordagens de infraestrutura como código para definir o ambiente e compreender os pipelines de ramificação, intercalação e implementação. No mínimo, uma equipa de automatização de plataforma pode precisar de competências de tomada de decisão para compreender as decisões tomadas pelo centro de excelência da cloud ou pelas equipas de operações centrais. As equipas de cargas de trabalho podem ser obrigadas a desenvolver mais conhecimentos relacionados com os controlos e processos que regem as suas decisões.
  • Design da zona de destino: a conceção da zona de destino depende de utilitários fundamentais. As equipas de cargas de trabalho devem compreender o que está na estrutura e o que é proibido de incluir. Este entendimento pode ajudar a evitar a duplicação de esforços, erros ou conflitos. Para criar flexibilidade, pode considerar os processos de exceção para os designs de zona de destino.
  • Utilitários fundamentais: centralizar os utilitários fundamentais demora algum tempo. Estes utilitários eventualmente consideram opções e desenvolvem soluções que podem ser dimensionadas para cumprir vários planos de adoção. São possíveis atrasos nos esforços de adoção precoce. Os atrasos podem ser compensados a longo prazo devido a acelerações e prevenção do bloqueador mais tarde no processo.
  • Separação de deveres: garantir uma separação clara dos deveres requer processos de gestão de identidades maduros. Poderá haver mais manutenção associada ao alinhamento adequado de utilizadores, grupos e atividades de integração e exclusão de integração. Poderá ter de adotar novos processos para acomodar o acesso just-in-time através de privilégios elevados.

Operações distribuídas

Operações distribuídas

O modelo operacional existente pode estar demasiado incorporado para que toda a organização mude para um novo modelo operacional. Para outras pessoas, as operações globais e vários requisitos de conformidade podem impedir que unidades empresariais específicas façam uma alteração. Neste caso, pode exigir uma abordagem de operações de distribuição. Esta abordagem é de longe a mais complexa, pois requer a integração de um ou mais dos modelos operacionais mencionados anteriormente.

Embora fortemente desencorajada, esta abordagem de operações pode ser necessária para algumas organizações. A abordagem está relacionada principalmente com organizações que têm uma coleção de unidades de negócio diferentes, uma base diversificada de segmentos de clientes ou operações regionais.

  • Prioridades: integre vários modelos operacionais existentes.
  • Estado de transição com foco em mover toda a organização para um dos modelos operacionais mencionados anteriormente.
  • Abordagem operacional a longo prazo quando a organização é demasiado grande ou demasiado complexa para se alinhar com um único modelo operacional.
  • Vantagem distinta: integre elementos comuns do modelo operacional de cada unidade de negócio. Esta abordagem cria um veículo para agrupar unidades operacionais numa hierarquia que as ajuda a amadurecer operações através de processos repetíveis consistentes.
  • Desvantagem distinta: a consistência e a uniformização em vários modelos operacionais é difícil de manter durante longos períodos. Esta abordagem operacional requer uma profunda consciência do portefólio e do funcionamento de vários segmentos do portefólio de tecnologia.
  • Risco: a falta de compromisso com um modelo operacional principal pode causar confusão entre as equipas. Utilize este modelo operacional quando não existir forma de alinhar com um único modelo operacional.
  • Orientação: comece com uma revisão detalhada do portefólio, que utiliza a abordagem descrita nos artigos de alinhamento empresarial . Tente agrupar o portefólio pelo modelo operacional de estado (descentralizado, centralizado ou empresarial).
  • Desenvolva uma hierarquia de grupo de gestão que reflita os agrupamentos de modelos operacionais. Esta disposição inclui outros padrões organizacionais para região, unidade de negócio ou outros critérios que mapeiam os clusters de cargas de trabalho do menos comum aos registos mais comuns.
  • Avalie o alinhamento das cargas de trabalho com os modelos operacionais para encontrar o cluster de modelos operativos mais relevante para começar. Siga as orientações mapeadas para o modelo operacional para todas as cargas de trabalho na hierarquia do grupo de gestão e nó.
  • Utilize metodologias de Governação e Gestão para encontrar políticas empresariais comuns, incluindo práticas de gestão operacional necessárias em vários pontos da hierarquia. Aplique políticas comuns do Azure para automatizar as políticas empresariais partilhadas.
  • À medida que testa as políticas do Azure com várias implementações, tente movê-las para um nível superior na hierarquia do grupo de gestão. As políticas podem ser aplicadas a muitas cargas de trabalho, que podem encontrar commonalidades e necessidades de operação distintas.
  • Ao longo do tempo, esta abordagem pode ajudá-lo a definir um modelo que é dimensionado em vários modelos operacionais. Esta abordagem também pode unificar as equipas através de um conjunto de políticas e procedimentos comuns.

As vantagens e desvantagens desta abordagem estão propositadamente em branco. Depois de concluir o alinhamento empresarial do seu portefólio, veja a secção de modelo operacional predominante acima para obter clareza sobre as vantagens e desvantagens.

Passos seguintes

Conheça a terminologia associada aos modelos operacionais. A terminologia ajuda-o a compreender como um modelo operacional se enquadra no tema mais importante do planeamento empresarial.

Saiba como uma zona de destino proporciona o bloco modular básico para qualquer ambiente de adoção da cloud.