Narrativa do cliente

Concluído

No módulo Prepare-se para a adoção bem-sucedida da nuvem, compartilhámos a narrativa sobre a Tailwind Traders. A equipe central de operações e a equipe de plataforma da Tailwind Traders têm experiência em gerenciar os datacenters existentes da empresa. O projeto em curso para migrar dois dos datacenters para o Azure já está expondo algumas curvas de aprendizado críticas que os conjuntos de habilidades atuais da empresa não podem abordar.

Restrições importantes

Neste momento, a empresa colocou uma alta prioridade na migração e no cumprimento das restrições de tempo para sair do datacenter. Devido a essa prioridade de negócios, as equipes de negócios e de TI despriorizaram os requisitos de segurança e conformidade de longo prazo até que possam concluir o desenvolvimento de sua plataforma de nuvem principal.

Como o Tailwind Traders é novo na nuvem, poucos membros das equipes de administração de operações, plataforma ou TI têm experiência com a nuvem. A empresa quer avançar lentamente para operações, segurança e governança modernas, mas ainda precisa de uma base de nuvem que possa ser dimensionada para atender a essas necessidades à medida que elas se tornam mais importantes.

Historicamente, a Tailwind Traders tem operado puramente a partir da perspetiva de operações centrais. Como resultado, as equipes de carga de trabalho não podem interagir com os ambientes de produção. A empresa não tem uma maneira fácil de mapear ativos (máquinas virtuais, dados e aplicativos) para cargas de trabalho definidas, portanto, os limites de cada carga de trabalho podem não ser claros às vezes.

Alinhamento com zonas de aterrissagem do Azure

As equipes de operações e plataforma concordaram com o seguinte alinhamento:

• A arquitetura conceitual das zonas de aterrissagem do Azure servirá como a visão de longo prazo para o estado futuro do ambiente de nuvem. Todas as equipes afetadas usarão essa arquitetura como base para desenvolver habilidades em nuvem e configurar seu ambiente de nuvem.
• As equipes usarão o acelerador de zona de pouso do Azure para começar com sua configuração ambiental.
• Se as equipes precisarem personalizar seu ambiente no futuro, usarão uma das opções de implementação personalizadas que se alinham ou estendem a implantação inicial baseada em acelerador.

Desvio da orientação padrão da zona de aterrissagem do Azure

A lista a seguir descreve como as restrições fizeram com que os Tailwind Traders se desviassem dos princípios de design para zonas de pouso do Azure, juntamente com o impacto de cada decisão:

• Governança orientada por políticas: a Tailwind Traders historicamente não automatizou suas políticas corporativas. Devido à pressão para migrar o datacenter rapidamente, a empresa optou por minimizar a quantidade de governança, inclusive na implantação inicial de uma zona de pouso.

  A empresa também se comprometeu a concluir o módulo Learn sobre a metodologia Govern do Cloud Adoption Framework depois de configurar o ambiente inicial. As limitações na equipe de TI dedicada à migração para a nuvem são um grande impulsionador para esse desvio. Esse desvio é ainda mais imposto pela resistência dos negócios e da TI à governança total da nuvem ou "Azure Ops".

• Democratização da assinatura: a equipe central de operações manterá a responsabilidade pelas operações de produção para todas as cargas de trabalho. Essa equipe raramente permitirá que uma equipe de carga de trabalho tenha acesso a um ambiente de produção, portanto, não está seguindo o princípio de design da democratização da assinatura.

  Se uma equipe de carga de trabalho exigir um desvio, a equipe central de operações considerará uma zona de pouso dedicada para cargas de trabalho individuais caso a caso. Caso contrário, a Tailwind Traders está firmemente comprometida em manter as operações centrais e terá instâncias limitadas de cargas de trabalho em ambientes de produção isolados (ou zonas de aterrissagem de aplicativos).

• Modelo de serviço centrado em aplicativos: os processos relacionados à interrupção podem considerar cargas de trabalho, especialmente para ativos que suportam cargas de trabalho de missão crítica. No entanto, além das interrupções, a equipe central de operações não diferencia entre cargas de trabalho e aplicativos para processos de gerenciamento de operações. Os principais processos da equipe operam, gerenciam, fazem alterações e otimizam todos os recursos da mesma maneira, independentemente dos limites da carga de trabalho ou da arquitetura. Dadas as restrições de tempo para essa migração, não é viável para a Tailwind Traders definir limites de aplicativos e estabelecer um modelo de serviço centrado em aplicativos.

Muitos dos termos da lista anterior serão explicados em unidades posteriores deste módulo Aprender. Vários deles refletem-se em notas para criar oportunidades de ensino.

Esses desvios não tiram o acordo de alinhamento. No entanto, esses desvios afetarão algumas opções na implantação do acelerador de zona de aterrissagem do Azure. Esses desvios também afetarão o design de zonas de aterrissagem de aplicativos individuais, que são implantadas depois que você começa a migrar ativos para a nuvem.

Esses desvios também exigirão que as equipes da Tailwind Traders concluam os módulos do Learn sobre gerenciamento, segurança e governança no Cloud Adoption Framework após a implantação do ambiente inicial.

Restrições adicionais

As seguintes restrições adicionais podem afetar as decisões da Tailwind.

Operações

A equipa de operações centrais criou organicamente um conjunto de processos e controlos para gerir o portfólio geral. A equipe depende do System Center Operations Manager e do Microsoft Configuration Manager para sua linha de base de operações.

A equipe também integrou as melhores ferramentas para gerenciamento de máquinas virtuais, rastreamento de gerenciamento de incidentes e configurações, monitoramento de rede, operações de segurança e controles de governança, entre outras ferramentas. A maioria dessas ferramentas tem integração interna com o Azure, o que influenciou a decisão de usar o Azure como o principal provedor de nuvem da empresa. Operar essas ferramentas requer pessoas, poder e capital significativos.

Ferramentas de operações

O licenciamento das ferramentas de gestão das operações (incluindo os hipervisores) consome mais de 20% do orçamento de custos tangíveis para TI. O novo Chief Information Officer (CIO) desafiou a equipe a reavaliar essas ferramentas e processos para encontrar alternativas de operações unificadas ou baseadas na nuvem. O CIO observará a redução das despesas com ferramentas como um indicador precoce de sucesso nessa migração.

Processos de operações

O gerente de TI solicitou duas novas contratações para apoiar a equipe central de operações. Eles ajudarão a equilibrar a carga sobre a equipe sobrecarregada. Em particular, eles darão suporte a práticas de continuidade de negócios e recuperação de desastres (BCDR) e processos de conformidade de patches.

A empresa não está pronta para uma mudança em grande escala para operações nativas da nuvem, especialmente para aplicativos de missão crítica. O CIO acredita que algum investimento em ferramentas de operações nativas da nuvem ajudaria a reduzir a pressão sobre a equipe central de operações, transferindo algumas dessas responsabilidades para o provedor de nuvem.

O CIO observará os turnos operacionais para melhorar a satisfação dos funcionários e reduzir a carga em toda a equipe central de operações. O CIO também solicitará atualizações frequentes sobre como o plano de adoção afeta o BCDR e os esforços de patching.

Contrato de nível de serviço

Apesar de todo o trabalho árduo e custos associados às operações, a equipe periodicamente não consegue cumprir o contrato de nível de serviço (SLA) de 90% de tempo de atividade para sistemas de missão crítica no datacenter principal. Esta é uma preocupação dispendiosa para o CIO e para o diretor executivo (CEO). O hardware desatualizado e o ciclo de atualizações atrasado no datacenter resultaram em falhas breves, mas frequentes.

Embora a empresa tenha aceitado a contragosto esse SLA, o novo CIO não está impressionado. Independentemente da economia financeira, o CIO espera que a equipe central de operações entregue um SLA muito maior após a migração.

Inovação no retalho

A equipe de inovação de varejo foi originalmente uma startup que a Tailwind Traders adquiriu. O CEO original da startup é agora o Chief Technology Officer (CTO) da Tailwind. O CTO ainda dirige essa divisão como uma startup, priorizando a experimentação e a inovação.

Os processos atuais de gerenciamento de operações exigem que todas as inovações dessa equipe passem por um processo de liberação. A equipa de operações centrais do departamento de TI revê a arquitetura quanto a questões de segurança, governação e gestão de operações. Depois que a equipe se sente confortável com a solução, ela a libera em um ambiente de produção gerenciado centralmente. Espera-se que este processo continue na cloud.

Gestão de identidades

O Ative Directory é o armazenamento de identidades e a principal ferramenta para autenticação e controle de acesso nos datacenters da Tailwind Traders. A empresa usou alguns dos melhores sistemas para estender a identidade em uma solução de autenticação multifator. A empresa também tem identidades federadas para implantar sua solução Microsoft 365. Mas mesmo com isso, o Ative Directory é como o Tailwind Traders gerencia a identidade.

Na nuvem, a empresa agora tem mais opções, como o Microsoft Entra ID ou o Microsoft Entra Domain Services rodando em uma infraestrutura de infraestrutura como serviço (IaaS). A equipe central de operações está lutando para comparar opções e escolher a melhor solução de identidade para seus planos de adoção de nuvem.

Topologia e conectividade de rede

A Tailwind Traders usa linhas MPLS (Multiprotocol Label Switching) para conectar seus datacenters e lojas físicas. Todo o tráfego da Internet é encaminhado através do datacenter principal. Devido a conflitos de Protocolo Internet (IP) entre dois dos datacenters, o tráfego é isolado e o roteamento depende de tabelas de roteamento complexas. A conectividade externa com o datacenter ou escritório corporativo é fornecida via rede privada virtual. Essa conectividade é limitada e desencorajada.

Os datacenters primário e secundário têm esquemas de endereços IP consistentes que são mantidos e organizados claramente. O terceiro datacenter inclui 50 blocos IP diferentes com pouca consistência e nenhuma organização clara ou plano de segmentação. Os ciclos de inovação contínua são limitados ao terceiro datacenter, mas podem apresentar problemas com a definição da topologia de rede e roteamento na nuvem.

Organização de recursos

A segmentação dos recursos entre cada datacenter tratou cada coleção de cargas de trabalho como um grande bloco de ativos. Cada coleta foi então dividida por perfil de risco para criar segmentos isolados e controlados para permitir um fluxo de rede limitado entre cargas de trabalho. As cargas de trabalho que exigem qualquer conexão de rede de entrada de qualquer rede desprotegida são isoladas em um ou mais segmentos de rede de perímetro de cada datacenter.

Além dessa organização básica, há inconsistências no banco de dados de gerenciamento de configuração, portanto, é difícil dizer quais ativos estão associados a quais cargas de trabalho. Os proprietários de carga de trabalho e as cadeias de escalonamento de incidentes estão bem definidos para cargas de trabalho de missão crítica, mas estão ausentes para a maioria das outras cargas de trabalho.

Para cargas de trabalho menos críticas, é comum que o proprietário identificado seja um ex-funcionário da Tailwind Traders. Muitas vezes, o mapeamento da configuração referencia máquinas virtuais que foram terminadas. Da mesma forma, mais de 30% dos ativos suportados não são claramente mapeados para uma única carga de trabalho. A empresa exigirá prática durante a migração para garantir a análise de dependência e a organização adequada dos recursos.