QAOps é uma prática emergente para incorporar qualidade como parte integrante do ciclo de vida de desenvolvimento de software.
A abordagem complementa as existentes de DevOps, enfatizando a perspectiva da qualidade, desde o negócio até as operações.
Esta mesa redonda era dedicada ao tema “QAOps: Building an Observability Pipeline”, um conceito que combina a prática de monitoramento, alerta e engenharia de dados.
Agradeço a cada participante pela sua participação e contribuição:
- Eduardo Piairo, Diretor de Operações da Deeper Insights
- Ricardo Castro, SRE na Farfetch
- Pedro Esteves, Líder Técnico Sênior
- Luís Bastião Silva, CTO da BMD Software
Este artigo é o resumo dos pontos-chave identificamos durante o nosso compartilhamento,
Junte-se à QE Unit para aceder a mais conteúdo da comunidade.
Observabilidade, uma base do QAOps
O QAOps visa a melhorar o impacto da qualidade em todo o desenvolvimento do software. A parte “Ops” não restringe seu prisma ao aspecto operacional; começa da perspectiva do negócio e dos usuários, mesmo antes de programar. Então, onde se encaixa a observabilidade? Temos que começar com o porquê.
Como colaborador do negócio, nosso objetivo é criar mais valor. Portanto, a medição torna-se um requisito: “Não podemos melhorar o que não podemos medir”. Observabilidade é a prática de compreender um sistema a partir de seus pontos de dados externos, tornando-o “observável”.
Um aviso: existem muitos elementos que não podemos medir, infelizmente e de momento.
A observabilidade não funciona por si só, pelo menos por enquanto. Temos que criar os pontos de dados, coletá-los e torná-los valiosos. Essas três etapas são encontradas em arquiteturas de engenharia de dados, explicando o termo “Pipeline de Observabilidade”. Em nosso caso, coletamos e processamos uma variedade de métricas, logs e rastreamentos.
Quanto ao QAOps, a Observabilidade não é apenas sobre produção.
Observabilidade não é apenas os estados em produção
Naturalmente associamos Observabilidade a um painel de monitoramento, com caixas verdes e vermelhas aplicadas ao ambiente de produção. Essa associação é parcialmente verdadeira por dois motivos: a observabilidade se aplica a todos os ambientes e o status é uma das medidas possíveis.
O objetivo do pipeline de Observabilidade é medir áreas de negócios específicas e, ao mesmo tempo, apoiar o processo de desenvolvimento de software. Portanto, nossa observabilidade deve ser aplicada a todos os ambientes para manter uma perspectiva holística. Uma parte significativa das melhorias operacionais vem de melhorias anteriores.
A segunda perspectiva consiste em estender os dados observados. Estamos acostumados a olhar para estados, como OK / KO ou de valor absoluto. Isso é bom e é um primeiro passo. O fato é que nossos sistemas estão em movimento, então nossa Observabilidade deve fornecer visualização para um processo dinâmico. Value-Stream e Process Mining são técnicas que dão suporte a esses requisitos.
Podemos ficar bastante entusiasmados com todas essas possibilidades. No entanto, não há atalhos para a construção de um pipeline de Observabilidade.
A observabilidade é uma abordagem passo a passo
Começamos a compreender a complexidade da observabilidade. Uma abordagem incremental é uma forma de equilibrar a criação de valor e a gestão de risco, evitando uma outra iniciativa de efeito túnel. Um elemento essencial é manter nosso foco na criação de valor.
O nosso “Por quê” inicial ajuda a encontrar o valor das partes interessadas nos casos de uso. Nossa iniciativa deve fornecer vitórias iniciais que atendam às necessidades concretas de sobrevivência; devemos nos concentrar em incrementos de observabilidade de ponta a ponta. Uma abordagem de tecnologia isolada irá falhar mais cedo ou mais tarde, mesmo se as bases de tecnologia mantêm-se importantes.
“Escalar não é apenas uma questão de escala. Trata-se de criar mais valor com bases que suportam a escalabilidade com flexibilidade.”
Antoine Craske
Nossas primeiras iterações fornecerão valor em um conjunto limitado de aplicativos e complexidade. Uma vez que começamos a aumentar o perímetro dos dados, apenas fundações estruturadas podem suportar a expansão. Padrões compartilhados de formatos de dados, esquemas e governança são negligenciados; eles devem evoluir de forma colaborativa e incremental, em linha com a maturidade da nossa iniciativa de Observabilidade.
As fundações não são apenas técnicas e apresentam vários desafios.
Os desafios de um pipeline de observabilidade
Desenvolver a observabilidade por meio de nosso pipeline consiste em criar um ecossistema complexo de dados criando valor para suas partes interessadas. Encontramos um desafio significativo das organizações: as interações humanas.
Nossas primeiras interações começam com nossos stakeholders para identificar o porquê e, finalmente, convencê-los. Para atender às suas necessidades, exigimos a colaboração de outras equipes para criar nossas soluções de observabilidade. Para ter sucesso na expansão, temos que trabalhar na cultura, um pilar fundamental das práticas de engenharia de escala.
“A cultura é um pilar fundamental para escalar práticas de engenharia.”
Antoine Craske
Crescer envolve mais equipes para acelerar e aumentar a criação de valor. Enfrentamos um novo problema: precisamos integrar novos membros sem consumir as equipes existentes no treinamento. A documentação valiosa pode fazer a diferença em cima de um peer, apoiando um processo de integração escalonável e de autoatendimento. A dificuldade está na estrutura, nível de abstração e estabilidade da documentação em suas várias formas (geradas por código, wikis, vídeos).
As tecnologias também vêm com um conjunto de desafios. Uma forma de estruturar as bases é fornecer uma plataforma de desenvolvedor com padrões e modelos. A dificuldade está na adoção. Nossos clientes são os desenvolvedores; tradicionalmente, eles preferem seu próprio cozinheiro. Nossa adoção terá sucesso com um uso mais fácil, por um fator de 10. Além disso, uma miríade de soluções deve funcionar em conjunto para responder a necessidades exclusivas.
“Não existe uma ferramenta universal para atender a requisitos únicos.”
Eduardo Piairo
Lidar com sucesso com os desafios pode nos permitir passar para o próximo nível de valor, como apoiar uma iniciativa de Reliability.
Uma abordagem de Reliability necessita de Observability
Ricardo compartilhou conosco o foco em uma iniciativa de Reliability na Farfetch. O objetivo é estimular a organização a considerar experiências fiáveis em suas plataformas digitais. Novamente, a medição é um requisito, dependendo da observabilidade.
A confiabilidade se materializa em um conjunto de indicadores, como Indicadores de Nível de Serviço (Service Level Indicators, SLIs) e Objetivos de Nível de Serviço (Service Level Objectives, SLOs). Eles podem até ser um acordo contratual na forma de Acordos de Nível de Serviço (Service Level Agreements, SLAs). Um nível de serviço se traduz em um indicador de porcentagem absoluta. O paradigma “9” é um padrão de mercado, referido por exemplo como “quatro noves” para 99,99%.
A medição do serviço não se limita à sua disponibilidade ou tempo de atividade. A Google popularizou os quatro sinais de ouro, ou “Golden Signals”, da sua prática de SRE. Podemos encontrar a taxa de erro e a latência tão importantes quanto a disponibilidade. Padrões estão surgindo dentro do ecossistema para facilitar nossa escalabilidade, integração e interoperabilidade. O “SLOConf” é até uma conferência dedicada a esse tema dos SLOs.
Indicadores por causa de indicadores são de valor limitado. Podemos fazer melhor.
Um pipeline de Observabilidade para Qualidade com Velocidade
Temos que entender o “porquê” dessas medições. Contra-intuitivamente, seus principais motivadores não eram uma perspectiva contratual ligada a penalidades financeiras. Em vez disso, era uma forma de apoiar a aceleração e estabilidade das mudanças. Muitos temas humanos tratam de um equilíbrio de elementos contraditórios; isso se aplica à entrega de software por meio de “error budget”.
O conceito de “error budget” é um crédito que a equipe pode consumir enquanto introduzem mudanças que podem afetar o nível de serviço. Uma vez que o crédito é consumido, eles não podem mais entregar qualquer alteração até a próxima reinicialização do contador. Durante esse tempo, eles podem abordar as causas raízes da interrupção do serviço, melhorar seus aplicativos e reduzir a technical debt. A Google é um dos principais iniciadores dessas práticas para dimensionar e acelerar suas inovações a escala.
A combinação desses princípios é poderosa se tivermos sucesso com nosso pipeline de Observabilidade.
Quais diretrizes para iniciar um Pipeline de Observabilidade
Pedro estava se perguntando sobre as etapas para iniciar uma iniciativa de Observabilidade e de Qualidade. Como qualquer processo, os elementos contextuais são fundamentais, sustentados por um conjunto de boas práticas. Descrevemos etapas vitais.
Temos que encontrar o sentido, a razão, a motivação no “Porquê”. O “Porquê” deve estar ligado à criação de valor para alguém, o conceito de qualidade. O alguém não é apenas um; é necessário um amplo conjunto de partes interessadas: nossos usuários, clientes, patrocinadores até as diferentes equipes. Podemos articular uma proposição valiosa apenas pela compreensão de cada perspectiva; daí a importância do envolvimento.
“Comece com o “Porquê” e o “Para quem”. De seguida, concentre-se no patrocinador e na equipa de “early win”.
Antoine Craske
As várias partes interessadas precisam de envolvimento desde o início da iniciativa. O nível de interação varia dependendo de uma matriz tradicional de partes interessadas. No entanto, duas partes interessadas cruciais estão se estruturando: o patrocinador e a equipe de “early win”. Os patrocinadores são aqueles que investem, defendem e apoiam sua iniciativa se eles capturarem valor. A equipa “early win” é fundamental para alcançar resultados e embarcar o resto da organização mais tarde.
“Existem duas razões para investir: para ganhar ou parar de perder dinheiro.”
Eduardo Piairo
As etapas a seguir devem seguir uma abordagem iterativa para equilibrar a criação de valor e os riscos. Riscos significativos residem nos desafios de mudanças culturais, fundamentos e capacidade de dimensionamento que identificamos. O conteúdo de cada iteração depende do seu contexto, voltando ao valor, para quem e sua medição. “Comunicação, comunicação e comunicação” ficará fundamental.
A medição e a comunicação nos fizeram voltar à necessidade de observabilidade.
Observabilidade no centro do QAOps
Nossa conversa sobre a construção de um pipeline de Observabilidade leva à criação de valor, escalabilidade e organizações. Materializamos a necessidade de impulsionadores de negócios desde o início e durante toda a nossa iniciativa. É preciso coragem para sustentar tal dinâmica.
Precisamos de coragem para compartilhar e compreender as diferentes perspectivas das partes interessadas, ao mesmo tempo que alinhamos nossas bases de tecnologia. Precisamos de coragem para encontrar um patrocinador, promover uma cultura de engenharia que pode ser expandida e nos comunicarmos regularmente.
Precisamos de coragem para superar todos os contratempos que encontramos durante nossa jornada. A coragem também é necessária ao implementar os “error budget”, priorizando a sustentabilidade de médio prazo sobre a entrega de recursos de curto prazo.
O QAOps e o pipeline de observabilidade criam valor para as pessoas por meio da combinação de arquiteturas, organizações, produtos e tecnologias. Portanto, vamos manter uma perspectiva holística e incremental, sem esquecer o princípio do “First things first”.
Referências
Monitoramento prático: estratégias eficazes para o mundo real, Mike Julian https://www.amazon.com/Practical-Monitoring-Effective-Strategies-World/dp/1491957352
SLO Con, Conferência de objetivo de nível de serviço https: // www.sloconf.com
Implementando objetivos de nível de serviço: um guia prático para SLIs, SLOs e orçamentos de erro, Alex Hidalgo https://www.amazon.com/Implementing-Service-Level-Objectives-Practical/dp/1492076813
Sinais de ouro do Google e abordagem SRE https://sre.google/sre-book/table-of-contents/
https://blog.qatestlab.com/2019/04/16/trends-2019-qaops-in-software-testing/
https://speakerdeck.com/tylertreat/the-observability-pipeline https://cribl.io/blog/the-observability-pipeline/