BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Como a ITV autoescalou para aguentar picos de audiência

Como a ITV autoescalou para aguentar picos de audiência

Favoritos

Tom Clark, produtor comercial e locutor da ITV, situada no Reino Unido, deu uma palestra no DevOps Enterprise Summit London, intitulada "Melhor, Mais Rápido, Mais Barato, Mais Feliz" baseada na história evolucionária da plataforma de infraestrutura única na qual é responsável.

A ITV produz dez mil horas de conteúdo por ano, gerando três bilhões de libras em receita e empregando seis mil funcionários, dos quais trezentos estão em equipes de tecnologia. O início da plataforma única foi em 2015, quando a organização estava lidando com um programa de modernização. Nas palavras de Clark:

Existiam diversas coisas que faziam com que a ITV, nossa força vital, ficasse travada: vendas ao vivo eram impossíveis e muito perigosas de serem alteradas, as mudanças nas vendas de conteúdo demoravam oito semanas, isso se tivéssemos sorte, e os pagamentos dos artistas estavam sendo executados em um mainframe virtualizado da ICL escrito em Cobol e a disponibilidade de ambas as partes e as habilidades estavam ficando cada vez menores.

O programa de modernização levou a uma série de mudanças: de projeto para produto, de cascata para ágil, de infra-estrutura local para a nuvem, de ETL para API, do manual para o automatizado, de algo sob medida para padrão, de monolito para microservices, de compartilhado para algo comum à todos, de proprietário para código aberto e rápido, de grande para pequeno, do CAPEX para OPEX, de desenvolvimento e operações para DevOps, de centralizado para envolvimento, de comando e controle para a confiança e medição, do MTBF para o MTTR, de terceirizados para internalizados, e de algo com baixa frequência para algo com muita frequência. Clark explicou que, ao criar várias equipes de novos produtos que estariam formando e atacando, estavam preocupados que teriam muitas decisões a tomar:

Estávamos preocupados em virarmos um faroeste selvagem além da preocupação em relação aos desenvolvedores ficarem focados em reinventar a roda de maneira desnecessária, criando fluxos de bits sem motivos ao invés de estarem pensando em registrar, monitorar, integrar e entregar de maneira contínua (CI/CD). Se tudo fosse único, artesanal e personalizado, as interações complexas e múltiplas das equipes aumentariam na organização, causando sobrecarga.

A ideia por trás da plataforma única era cuidar do "fluxo" para que as equipes não precisassem se preocupar. Infraestrutura, registros, métricas, auditoria e conformidade com a segurança deveriam ser tratados de maneira separada para que os times tivessem mais tempo hábil para gerar valor comercial para a organização. Clark explicou que os membros da equipe da plataforma única precisam ser inteligentes, ter um alto QI, para acompanhar a velocidade com que a tecnologia mudava, e também precisavam ser gentis, ter um alto EQ (Inteligência Emocional). Na opinião do palestrante, os engenheiros da plataforma se encontram na interseção dessas duas qualidades.

Existem dois tipos de engenheiros na equipe. O primeiro, são os engenheiros da plataforma principal, fazem a curadoria e desenvolvem padrões para as outras equipes em ferramentas, como o Puppet e o Terraform, incubam novas contratações e atuam como "patos de borracha profissionais", fornecendo uma "segunda opinião como serviço". Podem ser transferidos para outras áreas se houver uma restrição emergencial de recursos e fornecem pesquisas e desenvolvimento, garantindo que a plataforma seja "perene".

Os engenheiros de plataforma de campo estão integrados nas equipes de desenvolvimento de produtos, juntamente com um proprietário de produto, gerentes de entrega, desenvolvedores e engenheiros de plataforma. Possuem uma responsabilidade operacional, treinando as equipes, porém muitos dos desenvolvedores não tinham visto a produção anteriormente e estavam receosos quanto a isso. Eles realizam a "multiplicação da força" e são responsáveis pela influência da qualidade em termos de testes não funcionais.

Houve vários problemas com a equipe inicial da plataforma única. Primeiramente, haviam engenheiros solitários que estavam por conta própria com as equipes de desenvolvimento de produto. Ao selecionar os melhores produtos e juntá-los com a ITV, tornaram-se uma plataforma sob medida com uma curva de aprendizagem acentuada, embora inicialmente fosse destinado a ser um autoatendimento. Os desenvolvedores acharam difícil fazer o que queriam e os engenheiros de plataforma eram gentis e prestativos, mudando a dinâmica de "eu posso fazer isso" para "o engenheiro de plataforma pode fazer isso", resultando em uma situação descrita por Clark como Engenheiro de Plataforma como Serviço (Platform Engineer as a Service - PEaaS), multiplicação forçada e influência na qualidade tolerada. Os desenvolvedores tinham pouca experiência com os tempos de ciclo de 15 minutos do CI/CD, considerados muito longos, embora isso tenha sido uma melhoria em relação às oito semanas iniciais. Ter vinte equipes de produtos, mas apenas quatro engenheiros, significava que a pesquisa e o desenvolvimento eram prejudicados. Clark comenta:

A ITV gosta de pensar que são seguidores rápidos na adoção de tecnologia, mas é preciso um esforço constante para continuar em movimento. Se pararmos, tirando o pé do acelerador, começamos a ir para trás, e foi o que aconteceu. Estávamos utilizando uma tecnologia do passado. Aprendemos a fazer algo quando podemos, não quando não podemos. Se estamos reagindo a isso, provavelmente já é tarde demais. Percebemos que a plataforma comum era o que precisávamos, mas não o que queríamos, porque, em última análise, a plataforma que queríamos não existia.

Junto com essa percepção veio uma outra, de que ninguém estava feliz, nem os desenvolvedores, nem os engenheiros de plataforma. E assim uma intervenção foi pensada, a equipe de plataforma única veio com um roteiro para os visitantes de todos os sites com três elementos base, uma retrospectiva clássica do StoStaKee, uma pergunta ao estilo Net Promoter Score (NPS) "Você recomendaria essa plataforma a um amigo?" e solicitações de recursos. As pessoas pediam mais transparência e visibilidade, mais empoderamento e autosserviço, o que era irônico, já que essa era a intenção original. O NPS foi de 3,1 que não foi de recomendação nem de não recomendação. As pessoas também queriam implantações mais rápidas e escalonamento automático, porém, estavam sendo executados em instâncias do Amazon EC2 com o Puppet implantado por meio de uma AMI, que levava quinze minutos para serem inicializados, portanto tinham que "esquentar os motores" das VMs para lidar com picos. Por conseguinte, o escalonamento automático não era uma possibilidade.

Uma equipe em particular tinha um grande interesse no escalonamento automático e gerenciamento de picos de tráfego. O reality show da ITV, Love Island, é o terceiro em popularidade no canal de jogos da Copa do Mundo de Futebol, com um público de mais de três milhões de telespectadores só no episódio de abertura deste ano. Quase um milhão de pessoas assistem ao Simulcast, assistindo em dispositivos ao vivo, junto com o que está sendo transmitido na televisão. Ao contrário do futebol, quando o público tende a sintonizar durante um período de trinta a sessenta minutos antes do início do jogo, o comportamento demográfico do público da Love Island faz com que o sistema tenha vinte vezes mais carga nos dez minutos que antecedem o programa. Clark explicou:

Este foi o "novo normal" para a ITV. Queríamos que o Love Island continuasse como de costume, só não queríamos ter que fazer qualquer aquecimento antecipado ou pré-planejamento. Queríamos ser capazes de lidar com essa carga sempre que acontecesse. Sendo assim, os parceiros online definiram um objetivo e um resultado-chave (OKR), um serviço de escalonamento infinito em execução até março. Então alinhei o MVP (Minimum Viable Product) da Plataforma Única, Versão 2 (CPV2) a este OKR.

A equipe de Clark criou um backlog do roteiro (já existia um, mas não tinha sido compartilhado), um canal do Slack, um grupo de colaboradores que definiu a visão, "Fornecer uma plataforma de hospedagem e desenvolvimento brilhante". Como o tempo era essencial, a data de entrega era de três meses. A equipe se concentrou na evolução, não na revolução e na atualização, muito menos em refazer a plataforma. Consideraram a Mudança Mínima Viável (Minimum Viable Change, MVC) para limitar o risco. Decidiram que a maior oportunidade de ganhar era atualizar o tempo de execução/agendador das instâncias do EC2 para os containers. Como a plataforma de nuvem da ITV é a AWS, identificaram duas opções, Fargate e Elastic Kubernetes Services (EKS) e então desenvolveram uma lista de pontuação ponderada e a EKS foi identificada como sendo a melhor solução. Usando uma abordagem em fases, adicionaram as equipes em incrementos. De acordo com Clark:

Também seguimos uma nova regra, "otimizar para o caso comum" ao invés de tentarmos acomodar todos os casos específicos. Nosso objetivo era convenção mais que configuração, porque toda vez que adicionamos novos parâmetros de configuração a um arquivo ocorre uma nova carga cognitiva em qualquer um que tenha que examiná-lo.

A equipe criou algumas personas de desenvolvedores e descobriu que a maioria delas não se importava se a tecnologia usada era Kubernetes ou não, só queriam saber dos resultados, queriam que as coisas funcionassem. Clark se refere a estas personas como, "80% queriam o modo mais fácil". Os outros 20% se preocuparam com os gráficos de Helm e YAML, e receberam uma experiência de desenvolvedor diferente. Usaram a palavra grega para o simples, 'Aplo' para descrever o modo simples onde todo o YAML acontece em segundo plano.

A equipe conseguiu entregar o MVP, o serviço de autoescala em produção, antes do final de março, e foi recompensada com adesivos de missão (stickers) para colarem nos laptops. Clark mandou colocar o adesivo da missão em um bolo comemorativo, "motivação assada". Houve uma série de benefícios que a ITV viu como resultado desse esforço, os desenvolvedores podem autoatender mais, o tempo de ciclo é dez vezes mais rápido, noventa segundos, há menos implantações com falha e é 30% mais eficiente ao executar, o que é visto como um adicional de capacidade injetada, além de poderem escalonar automaticamente em milissegundos. Um desenvolvedor chefe, Dave Smith, enviou um email para a equipe de desenvolvimento dizendo o seguinte sobre o CPV2:

O desempenho é melhor, é mais barato de executar, a configuração é melhor, os tempos de implantação são um deleite e o dimensionamento é sublime!

Uma hora antes do início da transmissão do premier de Love Island, no canal Slack, um fluxo de 500 erros foi reportado. Foi feita uma alteração que reclassificou um erro 400 para um erro 500, de modo que não houve impacto real no usuário, mas estava causando ruído indesejado em um canal que gostariam de mantê-lo limpo naquele momento. A equipe discutiu isso no Slack e concordou em alterar e seguir em frente, minutos antes do maior evento do ano. A correção foi implantada com sucesso e concluída dentro de trinta minutos após ser localizada. Clark disse:

Foi um teste de fogo para a plataforma, mas na verdade é um exemplo da maturidade de engenharia que temos em nossas equipes hoje, já que isso era uma coisa óbvia a ser feita. Não foi assustador, não houve medo na mudança. Está tudo tão tranquilo que agora essas mudanças são entediantes e na verdade as pessoas não estão mais vendo as estatísticas no Slack como sendo algo usual para o negócio.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT