Saltar para o conteúdo

Outsourcing de TI

Cloud e DevOps

Migração, automação de entrega, infraestrutura como código e controlo de custo em cloud.

O que é entregue

  • Infraestrutura descrita em código e versionada, não configurada à mão

  • Pipelines de entrega com reversão testada, não apenas planeada

  • Revisão de custo com medidas concretas e poupança medida

Porque é que infraestrutura em código não é opcional?

Porque infraestrutura configurada à mão não é reproduzível, e não ser reproduzível significa que ninguém sabe exactamente o que está em produção. Quando um ambiente precisa de ser recriado, e um dia precisa, a diferença entre uma tarde e três semanas é esta.

Também porque torna a alteração revista. Uma mudança de configuração feita numa consola não passa por revisão, não deixa justificação e não é reversível de forma fiável. A mesma mudança declarada em código é lida por outra pessoa antes de acontecer, e é isso que apanha a maior parte dos erros de configuração.

Onde encontramos infraestrutura manual, a migração é faseada e começa pelo que é mais frágil, não pelo que é mais fácil. Declarar primeiro o ambiente de desenvolvimento e deixar produção manual durante um ano é o caminho confortável e resolve exactamente o problema que não existia.

O que é que uma cadeia de entrega bem feita muda?

O tamanho da alteração. Quando levar uma mudança a produção é lento e arriscado, as equipas acumulam alterações e entregam lotes grandes, que são mais difíceis de diagnosticar quando falham. Quando é rápido e seguro, entregam pequeno, e a causa de uma falha é evidente por eliminação.

Muda também quem pode entregar. Uma cadeia que depende de uma pessoa específica para aprovar ou executar cria um estrangulamento que se manifesta em férias e em incidentes. Automatizar os controlos em vez de os concentrar numa pessoa é o que torna a operação resiliente.

E muda a relação com a reversão. Uma entrega que se reverte em dois minutos permite correr riscos pequenos com frequência; uma que demora uma tarde a reverter obriga a evitar riscos, o que na prática significa entregar menos e acumular mais em cada entrega.

Como é que a observabilidade é desenhada?

A partir das perguntas que é preciso responder durante um incidente, e não a partir do que a ferramenta consegue recolher. A ordem inversa produz painéis cheios e a incapacidade de responder à única pergunta que importa às três da manhã: o que mudou.

Com alertas ligados a sintomas observáveis pelo utilizador e não a métricas internas. Um alerta sobre utilização de processador acorda alguém para um facto que pode não ter consequência; um alerta sobre latência percebida acorda alguém para um problema real. Alertas que não exigem acção devem ser eliminados e não silenciados.

E com retenção suficiente para investigar. Registos com sete dias de retenção são inúteis para um problema intermitente que aparece de três em três semanas, e a descoberta de que a retenção é insuficiente acontece sempre durante a investigação, que é quando já não há nada a fazer.

Como se controla o custo de nuvem?

Com atribuição antes de optimização. Uma factura de nuvem sem etiquetagem consistente não é analisável, e a primeira intervenção é quase sempre estabelecer quem consome o quê, por equipa, por ambiente e por serviço. Sem isso, a optimização é adivinhação com autoridade.

Depois, pelos ganhos aborrecidos: ambientes de desenvolvimento desligados fora de horas, armazenamento em classes adequadas à frequência de acesso, recursos sobredimensionados ajustados às medições reais, e recursos órfãos removidos. Estes quatro cobrem a maior parte do desperdício na maior parte das contas.

E com um limite de alerta que dispara antes de a factura chegar. Descobrir um aumento de custo no fim do mês é descobri-lo com o custo já incorrido, e a maior parte dos aumentos inesperados são detectáveis no primeiro dia se alguém estiver a olhar.

Que requisitos de residência de dados se aplicam?

Para dados pessoais de titulares europeus, a região onde os dados residem importa e é uma escolha de configuração que frequentemente fica por fazer. Serviços geridos com componentes globais podem replicar metadados fora da região escolhida, e isso deve ser verificado por serviço e não assumido.

Para clientes do sector público português, a exigência é habitualmente mais estrita e aparece como requisito de exclusão em concurso. Desenhar a arquitectura com essa restrição desde o início custa pouco; adaptá-la depois de o concurso sair custa o concurso.

O acesso administrativo é a outra metade da questão, e a mais esquecida. Dados alojados na Europa e administrados por uma equipa fora do Espaço Económico Europeu continuam a envolver uma transferência, e o enquadramento aplica-se ao acesso e não apenas ao armazenamento.

Como é que a operação é entregue de volta?

Com tudo declarado em código e num repositório que é vosso desde o primeiro dia, não num que seja nosso e entregue no fim. É a diferença entre uma entrega e uma dependência, e é uma escolha que se faz no início e não se corrige depois.

Com documentação operacional escrita à medida que a operação corre e não reconstruída no fim, e com pelo menos um exercício em que a vossa equipa executa um procedimento crítico com o nosso acompanhamento, em vez de o ler.

O prazo e o custo da saída estão na proposta. Um fornecedor de infraestrutura que não quantifica a saída está a vender uma posição e não um serviço, e a pergunta deve ser feita antes de assinar e não quando a relação já azedou.

O que é que não recomendamos?

Migrar para nuvem sem medir primeiro. Uma carga de trabalho estável e previsível pode ser mais cara em nuvem pública do que em infraestrutura dedicada, e a migração paga-se apenas quando há elasticidade real a aproveitar. Dizemo-lo antes e não depois da factura.

E adoptar orquestração de contentores quando a operação não tem escala nem equipa para a manter. É uma escolha excelente acima de um certo tamanho e uma fonte de complexidade permanente abaixo dele, e a decisão deve ser tomada sobre a vossa dimensão e não sobre a prática comum.

Onde pode ser operado o cloud e devops

Nem todos os modelos de entrega servem todos os serviços. A tabela indica apenas os que fazem sentido para este trabalho, com a situação de residência de dados de cada um.

ModeloOndeQuando faz sentidoDados pessoais
Onshore PortugalLisboa, Porto, Braga, Coimbra, Aveiro, Faro, Funchal e Ponta DelgadaQuando os dados não podem sair do EEE, ou quando o cliente final é portuguêsPermanecem no EEE. Sem transferência.
Nearshore em PortugalLisboa e Porto, para compradores estrangeirosQuando precisa de uma base europeia multilingue sem constituir empresaPermanecem no EEE. Sem transferência.
Rede globalUzbequistão, Filipinas, Polónia, República Dominicana, México, Colômbia, Turquia e ÁfricaQuando precisa de cobertura contínua, de línguas específicas ou do menor custoA Polónia fica no EEE. Os restantes exigem cláusulas contratuais-tipo.

A coluna de dados é uma descrição do enquadramento aplicável e não aconselhamento jurídico. O detalhe está em transferências internacionais de dados.

Perguntas frequentes

Com que fornecedores de nuvem trabalham?

Com os principais fornecedores públicos e com infraestrutura própria quando a residência de dados o exige.

A infraestrutura fica declarada em código?

Fica, e num repositório que é vosso desde o primeiro dia. É a diferença entre uma entrega e uma dependência.

Podem reduzir a nossa factura de nuvem?

Normalmente sim, e começamos por atribuição e não por optimização, porque sem etiquetagem consistente a optimização é adivinhação.

Como desenham os alertas?

Ligados a sintomas observáveis pelo utilizador. Alertas que não exigem acção são eliminados e não silenciados.

Os dados ficam na Europa?

Fica quando configurado para isso, e verificamos por serviço em vez de assumir. O acesso administrativo conta como transferência.

Servem requisitos do sector público?

Servimos, e a restrição de residência entra na arquitectura desde o início porque adaptá-la depois custa o concurso.

Quanto tempo demora uma migração?

Depende do ponto de partida, e começamos pelo que é mais frágil e não pelo que é mais fácil.

Como funciona a saída?

Prazo e custo estão na proposta, com um exercício em que a vossa equipa executa um procedimento crítico em vez de o ler.

Vamos ver os números do seu caso

Diga-nos que processos quer externalizar, em que línguas e com que volumes. Devolvemos uma estimativa em euros e um desenho de operação, sem compromisso.

Respondemos em menos de 6 horas em dias úteis. Se preferir escrever: info@corpshore.solutions