Narrativa do cliente
No módulo Introdução, compartilhamos a narrativa da Tailwind Traders. A equipe de operações central e a equipe de plataforma da Tailwind Traders têm experiência no gerenciamento dos datacenters existentes da empresa. O projeto em andamento destinado a migrar dois datacenters para o Azure já está expondo algumas curvas de aprendizado críticas que os atuais conjuntos de habilidades da empresa não conseguem abordar.
Restrições importantes
Neste momento, a empresa atribuiu alta prioridade à migração e ao cumprimento das restrições de tempo para sair do datacenter. Devido a essa prioridade corporativa, as equipes de negócios e TI reduziram a prioridade dos requisitos de conformidade e segurança de longo prazo até que possam concluir o desenvolvimento de sua plataforma de nuvem principal.
Como a Tailwind Traders é nova na nuvem, poucos membros das equipes de operações, plataforma ou administração de TI têm experiência com a nuvem. A empresa quer avançar lentamente para ter operações, segurança e governança modernas, mas ainda precisa de uma base de nuvem que possa escalar para atender a essas necessidades à medida que elas se tornam mais importantes.
Historicamente, a Tailwind Traders tem operado puramente da perspectiva de operações centrais. Como resultado, as equipes de carga de trabalho não conseguem interagir com ambientes de produção. A empresa não tem uma forma fácil de mapear ativos (máquinas virtuais, dados e aplicativos) para cargas de trabalho definidas, de modo que os limites de cada carga de trabalho não ficam claros muitas vezes.
Alinhamento às zonas de destino do Azure
As equipes de operações e plataforma concordaram com o seguinte alinhamento:
- A arquitetura conceitual da zona de destino do Azure servirá como 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 de nuvem e configurar o ambiente de nuvem.
- As equipes usarão o acelerador de zona de destino do Azure para iniciar a configuração do ambiente.
- Se as equipes precisarem personalizar o ambiente no futuro, eles usarão uma das opções de implementações personalizadas que se alinham ou que estendem a implantação inicial baseada no acelerador.
Desvio das diretrizes padrão da zona de destino do Azure
A seguinte lista descreve como as restrições fizeram com que a Tailwind Traders se desviasse dos princípios de design de zonas de destino do Azure, juntamente com o impacto de cada decisão:
Governança controlada por políticas: historicamente, a Tailwind Traders não automatiza suas políticas corporativas. Devido à pressão para migrar rapidamente o datacenter, a empresa optou por minimizar a quantidade de governança, inclusive na implantação inicial de uma zona de destino.
A empresa também se comprometeu a concluir o módulo do Learn sobre a metodologia de controle do Cloud Adoption Framework depois de configurar o ambiente inicial. As limitações na equipe de TI dedicadas à migração na nuvem são um grande fator para esse desvio. Esse desvio se tornou ainda mais impositivo pela resistência dos setores de Negócios e TI à governança de nuvem total, ou às "Operações do Azure".
Democratização da assinatura: a equipe de operações central manterá a responsabilidade pelas operações de produção de todas as cargas de trabalho. A equipe raramente permitirá que uma equipe de carga de trabalho tenha acesso a um ambiente de produção, portanto, ela não está seguindo o princípio de design de democratização da assinatura.
Se uma equipe de carga de trabalho precisar de um desvio, a equipe central de operações considerará uma zona de destino dedicada para cargas de trabalho individuais caso a caso. Caso contrário, a Tailwind Traders está firmemente comprometida a manter as operações centrais e limitará as instâncias de cargas de trabalho em ambientes de produção isolados (ou zonas de destino do aplicativo).
Modelo de serviço centrado no aplicativo: processos relacionados a interrupções podem considerar cargas de trabalho, especialmente no caso de ativos que dão suporte a cargas de trabalho críticas. No entanto, além de interrupções, a equipe de operações central não diferencia cargas de trabalho e aplicativos nos processos de gerenciamento de operações. Os processos primários da equipe operam, gerenciam, fazem alterações e otimizam todos os recursos da mesma forma, independentemente dos limites ou da arquitetura da carga de trabalho. Considerando as restrições de tempo para essa migração, não é viável para a Tailwind Traders definir os limites do aplicativo nem estabelecer um modelo de serviço centrado no aplicativo.
Muitos dos termos da lista acima serão explicados em unidades posteriores deste módulo do Learn. Vários deles estarão refletidos em anotações para criar oportunidades de ensino.
Esses desvios não se afastam do contrato de alinhamento. No entanto, eles afetarão algumas opções na implantação do acelerador de zona de destino do Azure. Esses desvios também afetarão o design das zonas de destino de aplicativos individuais, que são implantadas quando você começar a migrar ativos para a nuvem.
Esses desvios também exigirão que as equipes da Tailwind Traders concluam 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 restrições adicionais a seguir podem afetar as decisões da Tailwind.
Operations
A equipe de operações central criou de maneira orgânica um conjunto de processos e controles para gerenciar o portfólio geral. A equipe depende do System Center Operations Manager e do Microsoft Configuration Manager para a linha de base de operações.
A equipe também integrou as melhores ferramentas da categoria para o gerenciamento de máquinas virtuais, acompanhamento de gerenciamento de configuração e incidentes, monitoramento de rede, operações de segurança, controles de governança, entre outras. A maioria dessas ferramentas tem integração interna com o Azure, o que influenciou na decisão de usar o Azure como o provedor de nuvem primário. A operação dessas ferramentas exige capital e mão de obra significativos.
Ferramentas de operações
O licenciamento para as ferramentas de gerenciamento de operações (incluindo hipervisores) consome mais de 20% dos custos fixos de orçamento de TI. A nova CIO (diretora de informações) desafiou a equipe a reavaliar essas ferramentas e processos a fim de encontrar alternativas de operações unificadas ou que priorizem a nuvem. A CIO estará atenta à redução das despesas de ferramentas como um indicador antecipado do sucesso dessa migração.
Processos de operações
O gerente de TI solicitou duas novas contratações para dar suporte à equipe de operações central. Ele ajudará a balancear a carga na equipe sobrecarregada. Em particular, eles darão suporte às práticas de BCDR (continuidade dos negócios e recuperação de desastres) e aos processos de conformidade do patch.
A empresa não está preparada para uma migração em escala total para operações nativas de nuvem, especialmente no caso de aplicativos críticos. A CIO acredita que algum investimento em ferramentas de operações nativas de nuvem ajudaria a reduzir a sobrecarga da equipe central de operações, transferindo algumas dessas responsabilidades para o provedor de nuvem.
A CIO estará atenta às mudanças operacionais para aprimorar a satisfação dos funcionários e a carga reduzida em toda a equipe de operações central. Ela também solicitará atualizações sobre como o plano de adoção afetará a BCDR e os esforços de aplicação de patch.
Contrato de nível de serviço
Apesar de todo o trabalho árduo e dos custos fixos associados às operações, algumas vezes a equipe não consegue atender ao SLA (Contrato de Nível de Serviço) de tempo de atividade de 90% para sistemas críticos no datacenter primário. Essa é uma preocupação muito importante para a CIO e o CEO (diretor executivo). O hardware desatualizado e um ciclo de atualização vencido no datacenter resultaram em interrupções frequentes e curtas.
Embora a empresa tenha aceitado esse SLA com insatisfação, a nova CIO não está impressionada. Independentemente da economia financeira, ela espera que a equipe de operações central forneça um SLA muito maior após a migração.
Inovação em varejo
Na narrativa do cliente do módulo Introdução, você conheceu a equipe de inovação de varejo interna da Tailwind Traders. Essa equipe era originalmente uma startup que foi adquirida pela Tailwind Traders. O CEO original da startup agora é o CTO (diretor de tecnologia) da Tailwind. O CTO ainda administra 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 novas inovações dessa equipe passem por um processo de lançamento. A equipe de operações central na TI examina a arquitetura quanto a questões de segurança, governança e gerenciamento de operações. Depois que a equipe estiver confortável com a solução, ela vai lançar a solução em um ambiente de produção gerenciado de maneira centralizada. Esse processo deve continuar na nuvem.
Gerenciamento de identidades
O Active Directory é o armazenamento de identidade e a ferramenta principal para autenticação e controle de acesso em todos os datacenters da Tailwind Traders. A empresa usou alguns dos melhores sistemas da categoria para estender a identidade para uma solução de autenticação multifator. Ela também tem identidades federadas para implantar a solução do Microsoft 365 dela. Porém, mesmo com isso, é com o Active Directory que a 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 em execução em uma infraestrutura de IaaS (infraestrutura como serviço). A equipe de operações central está buscando comparar opções e escolher a melhor solução de identidade para os planos de adoção de nuvem dela.
Topologia de rede e conectividade
A Tailwind Traders usa linhas MPLS (Multiprotocol Label Switching) para conectar os datacenters e armazenamentos físicos dela. Todo o tráfego da Internet é encaminhado pelo datacenter primário. Devido a conflitos de 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 por meio da rede privada virtual. Essa conectividade é limitada e não é recomendada.
Os datacenters primário e secundário têm esquemas de endereço IP consistentes que são mantidos e organizados com clareza. O terceiro datacenter inclui 50 blocos de IP diferentes, com pouca consistência e nenhum plano claro de organização ou segmentação. Os ciclos de inovação contínua estão limitados ao terceiro datacenter, mas podem apresentar problemas na definição da topologia de rede e do roteamento na nuvem.
Organização do recurso
A segmentação de recursos entre cada datacenter tratava cada coleção de cargas de trabalho como um grande bloco de ativos. Cada coleção era dividida por perfil de risco para criar segmentos isolados e controlados e 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 determinar quais ativos estão associados a quais cargas de trabalho. Os proprietários de carga de trabalho e as cadeias de escalonamento de incidentes são bem definidos para cargas de trabalho críticas, mas não estão definidos 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. O mapeamento de configuração geralmente faz referência a máquinas virtuais que foram encerradas. Da mesma forma, mais de 30% dos ativos com suporte não são claramente mapeados para uma carga de trabalho. A empresa precisará de prática durante a migração para garantir uma análise de dependências e uma organização de recursos adequada.