Cuidar da operação faz parte da gestão de produtos!

Acredito que algumas pessoas irão se assustar com essa afirmação, principalmente aquelas que pensam que analisar incidentes, acompanhar monitores/alertas, gerar métricas de disponibilidade são atribuições do “time de infra” (SRE, plataformas, infraestrutura, DevOps, operações, etc) e que a um time de Engenharia cabe apenas o lançamento de features e mais features em produção.

Se você é uma dessas pessoas, digo que na minha opinião você está redondamente enganada! Essa responsabilidade é sua e do seu time, Gestor(a) de Engenharia! Afinal, como disse Werner Voegls, ex CTO da Amazon “you build it, you run it”.

E é com o objetivo de demonstrar esse meu ponto de vista e também dando continuidade à série de artigos em que desdobro as dimensões de KPIs de Tecnologia, que te convido a descobrir ao longo deste artigo quais são os principais indicadores de Operação para um time de tecnologia.

Qual é a importância de cuidar da Operação para a gestão de  Produtos?‍

A Gestão da Operação é uma parte fundamental da gestão de um produto, pois ela complementa a visão da real situação em que seu produto se encontra, em conjunto e em igualdade de condições com os direcionamentos da Diretoria, análises do(a) PM - product manager -, pesquisas feitas por UX researchers, NPS, feedbacks de usuários, etc.

É através de uma gestão operacional bem feita e baseada em indicadores, que podemos entender se a “dor” que está prestes a ser resolvida por aquela nova feature é de fato maior do que a “dor” que uma pessoa está tendo “lá na ponta” ao ter atritos durante o uso do seu produto.

Não estou dizendo aqui que a Operação deve ditar os rumos do produto e ter um peso maior, mas sim que se a priorização do seu produto não estiver levando em conta essa dimensão, ela está enviesada e incompleta e quem pagará por isso é o(a) usuário(a)!
‍

“Ok, mas não seria o time de infra o responsável por detectar esses problemas, repassar os detalhes para eu criar um bug para resolver depois”?

Não. Na minha visão, não. E trago alguns motivos para isso:

• Você e seu time só terão uma visão completa do produto se conhecerem a fundo seu comportamento em produção, que é onde ele passa o maior tempo do ciclo de vida. Fases de desenvolvimento, staging, homologação, pré-produção, etc são apenas uma pequena parte da “vida” do seu produto;
  
  
• Não existe forma melhor de aprender do que entender e solucionar problemas. E não será a mesma coisa se algum outro time fizer essa análise para você;
  
  
• O time passa a ter muito mais propriedade para discutir melhorias com eventuais fornecedores que atuem em partes tecnológicas do produto;
  
  
• A qualidade do produto tende a aumentar. Afinal você não vai querer parar o que está fazendo ou acordar de madrugada para resolver um problema que você mesmo poderia ter evitado, não é mesmo?
  
  
• O impacto financeiro de indisponibilidades para as pessoas usuárias pode ser muito maior do que o retorno esperado de uma nova feature. Nada melhor do que PMs e times de desenvolvimento terem essas informações “na ponta língua” no momento de priorizar iniciativas. Além disso, aumenta-se a empatia e sinergia entre PMs e a equipe de Engenharia;
  
  
• O seu “time de infra” (como disse, aqui pode ser SRE, plataformas, infraestrutura, devops, operações, etc) terá mais tempo para trabalhar em aspectos estruturais de todos os produtos da empresa e, principalmente, gerar e melhorar produtos que facilitem a sua experiência como pessoa desenvolvedora.

Está vendo o círculo virtuoso aqui? E, aí sim nesse caso, a gestão da operação desses produtos estruturantes e/ou voltados para a melhoria da experiência do desenvolvedor (DevEx) é de responsabilidade desses times transversais.

Agora, reforçando um ponto importante: quando digo que a operação é responsabilidade do time, não considero apenas as pessoas desenvolvedoras e suas respectivas lideranças.

O(a) PM também tem sua parcela de atenção. É claro, ele(a) não vai necessariamente entender todos os detalhes da operação e atuar nos incidentes, mas é super importante que essa pessoa tenha a consciência da importância dessa dimensão para a evolução do produto e esteja sempre junto, apoiando e garantindo que o time de desenvolvimento tenha condições de evoluir e manter essa operação saudável.

Por último, fecho aqui com o trecho mais completo da fala de Werner Voegls, de 2006, mas ainda muito relevante:

"Atribuir responsabilidades operacionais aos desenvolvedores melhorou muito a qualidade dos serviços, tanto do ponto de vista do cliente quanto da tecnologia. O modelo tradicional consiste em levar seu software até a parede que separa o desenvolvimento e as operações, jogá-lo fora e depois esquecê-lo. Não na Amazon, aqui "you build it, you run it."

Para quem é da área de Tecnologia, entendo que não é simples ter uma visão mais ampliada da gestão de Produtos, contudo como destaco aqui ambas as áreas precisam estar conectadas para que os KPIS alinhem-se aos objetivos do negócio.

Muitos CTOs e Gestores de Tecnologia já fizeram a Mentoria CPO da IFTL, justamente, para aprenderem a construir esse link entre Gestão de Produtos e Tecnologia.

Conheça mais sobre a Mentoria CPO e candidate-se para a próxima turma.

Agora que espero ter lhe convencido da importância de incluir a Gestão Operacional no conjunto de atividades que os times de Engenharia/Produto devem atuar, seguiremos nas próximas seções a detalhar algumas métricas e indicadores que entendo serem imprescindíveis para que você e seu time tenham domínio sobre a operação de seus produtos.

Mas, antes alguns conceitos básicos que facilitarão o entendimento desses KPIs.

Termos usados para Gestão Operacional: Incidente, Crise e Problema

‍A ITIL, Information Technology Infrastructure Library, como o nome diz, é uma “biblioteca” de boas práticas relacionadas à gestão dos serviços de TI. E é através dela que irei me basear para explicar alguns conceitos:

• Um incidente, é uma interrupção ou degradação de um serviço de TI. O “serviço” aqui, pode ser um feature, um produto, um ambiente, ou seja,  qualquer componente tecnológico em que através dele uma ou mais pessoas realizam e/ou recebem uma entrega de valor;
  ‍
• Quando temos um incidente de maior impacto ao usuário final, chamamos de crise e, normalmente, temos processos específicos para tratá-las, diferentes de como tratamos um incidente comum;
  ‍
  
• Já um problema é a causa ou uma possível causa de um ou mais incidentes. Aqui o principal termo utilizado é “causa raiz”.

É super importante que sua empresa tenha processos sólidos de registro e gestão desses eventos, idealmente em alguma ferramenta de ITSM - IT Service Management, ferramenta de tickets, de gestão de tarefas, etc.

Caso sua empresa esteja começando, não há problema em registrar incidentes diretamente como bugs. O essencial é manter um controle, mesmo que em uma planilha simples, com informações chave dos incidentes que afetaram um número significativo de usuários (segundo o seu critério de relevância):

• Produto/Componente afetado: nome do produto, feature, componente de infraestrutura afetado;
• Data/hora de início do incidente: idealmente coletada a partir da sua ferramenta de monitoramento que registrou a falha, logs da aplicação ou, em último caso, o registro da primeira reclamação no CS (em último caso mesmo, pois uma operação de excelência deve detectar uma falha antes do usuário final);
• Data/hora de identificação do incidente: ou seja, o momento em que alguém do time de desenvolvimento responsável tomou ciência que uma falha estava ocorrendo, seja vendo o alerta gerado por sua ferramenta de monitoria ou, novamente, em último caso, quando viu alguém reclamando do problema;
• Data/hora de mitigação do incidente: o momento em que foi possível aplicar alguma solução paliativa que tenha reduzido o impacto do incidente, porém não o eliminou por completo, ou seja, o time segue mobilizado para resolver em definitivo. Como “solução paliativa”, pode ser a inclusão de novas máquinas em um cluster, desativação de uma feature flag para isolar a feature com falha;
  
  
• Data/hora de finalização do incidente: quando o time deu a crise/incidente por encerrado, confirmou que o usuário final não está mais sendo impactado e voltou às suas atividades normais;
  
  
• Foi um incidente recorrente? Super importante registrar se essa mesma falha já ocorreu anteriormente para entender se as soluções têm sido eficazes. Em algumas ferramentas de ITSM, essa correlação já é feita de forma automatizada, exibindo os tickets semelhantes, mas na planilha basta registrar um “Sim/Não”;
• Foi um incidente decorrente de uma mudança? Esta é outra informação bem relevante para entender se o incidente foi causado por um deploy/mudança que o próprio time realizou. É um baita insumo para ações de melhoria de processos de qualidade e implantação. Novamente, em ferramentas de mercado e em empresas de maior porte, é possível correlacionar o ticket do incidente e o ticket/PR da mudança. Porém, também vale, inicialmente, optar por uma solução mais simples  e registrar um “Sim/Não” na planilha;
  ‍
• Causa Raiz: Identifique a causa principal do incidente. Isso não só orienta a solução para prevenir reincidências, mas também revela a frequência com que certas causas ocorrem, auxiliando na criação de medidas mais eficazes. Para isso, basta definir um conjunto de causas padrão para facilitar a análise. Esses valores variam de acordo com o cenário, mas algumas descrições indicadas são: "Falha em Banco de Dados", "Ataque", "Erro no componente X da infraestrutura", "Bug", "Problema com o fornecedor Y", entre outras, e inclua um espaço para detalhes adicionais quando necessário.

Agora que temos informações suficientes, vamos detalhar os principais indicadores para uma gestão básica de sua operação.

Principais indicadores e métricas da Gestão Operacional

1. Disponibilidade

Refere-se ao período em que o produto/componente esteve operacional durante o período analisado. Por “Operacional” você pode definir como sendo a porcentagem de usuários que estão utilizando normalmente, por exemplo. Já o “período” normalmente é avaliado em meses.

Vale ressaltar que esse indicador, especificamente, não é extraído diretamente de uma ferramenta de monitoramento, que vai avaliar por exemplo o número de requests de erro dividido pelos requests totais. Mostrarei posteriormente outro KPI que levará em consideração essas informações “diretamente da fonte”.

Para essa análise, o ideal é ter um indicador que avalie diretamente a experiência do usuário final. Digo isso, porque em alguns casos, um bug pode fazer com que muitos usuários fiquem presos em um fluxo do produto, impedindo o uso adequado. Contudo, essa situação pode não ser evidente se olharmos apenas para os requests, que podem parecer bem-sucedidos, mas na realidade estão levando o usuário a uma tela sem saída. Logo, o problema não será levado em consideração nesse outro indicador.

Perceba, então, que esse indicador terá um resultado de disponibilidade inferior à disponibilidade aferida diretamente nas ferramentas de monitoramento.

E como chegamos neste valor? Uma vez que temos todas as informações dos incidentes ocorridos, conforme explicado na seção anterior, calculamos as seguintes métricas que ao final nos darão a disponibilidade do produto em um determinado mês.

• MTTR (horas): Mean Time do Recovery, ou Tempo Médio de Recuperação, uma das famosas DORA metrics, criadas pelo programa de pesquisas em DevOps,  mede o tempo médio para a restauração de um determinado produto/componente após incidentes. Como registramos a duração total de cada incidente (data/hora finalização - data/hora início), basta dividirmos a soma dessas durações (tempo incidentes) pelo número de incidentes ocorridos naquele mês.

• MTBF (dias): Mean Time Between Failures ou Tempo Médio entre Falhas, é o que mede, com base no histórico, o tempo médio em que um produto/componente opera normalmente até que ocorra um incidente. Ele é calculado pela fórmula abaixo, onde “tempo total” é o período analisado:

• ‍Disponibilidade (%): finalmente chegamos ao valor da disponibilidade daquele produto/componente no mês, calculada através da fórmula:

• Tempo médio para a detecção -  MTTD (horas)‍

O MTTD, Mean Time do Detection, mede o tempo médio em que o time leva para detectar que um incidente está ocorrendo em um determinado produto/componente. Informação super importante, ajuda a validar se o arcabouço de ferramentas de monitoramento, detecção, geração de alertas e escalas de plantões estão funcionando de forma adequada.

Para seu cálculo, basta identificarmos a (data/hora identificação - data/hora início) de cada incidente daquele produto/componente no mês e tirarmos o valor médio. É interessante esse registro mensal para vermos o resultado de ações de melhoria executadas nesses processos.

• Tempo médio para mitigação (horas)‍

Esta é uma variação do MTTR, que serve para entendermos o tempo médio que levamos para empregar ações de mitigação em um determinado produto/componente para reduzir, ao menos, o impacto de uma falha até que se resolva os incidentes por completo. Conforme dito anteriormente, ajuda a entendermos se a criação de fluxos de fallback, feature flags, etc têm sido efetivas. 

• % de incidentes por causa raiz ‍

Uma contabilização básica da porcentagem de incidentes por cada tipo de causa raiz elencada. Ajuda a direcionar planos de ação para priorizar as causas que geram a maior quantidade de incidentes por produto/componente.

• % de incidentes recorrentes ‍

Mede o quanto as ações de solução de causas raiz têm sido efetivas, uma vez que se um determinado incidente se repete para um mesmo produto/componente é um bom indicativo que você e seu time devem se debruçar um pouco mais na avaliação de uma ação que evite que aquele incidente volte a ocorrer. É medido pelo:

• % de incidentes decorrentes de mudanças ‍

Mede a quantidade de incidentes cuja causa raiz está relacionada com uma mudança realizada no ambiente. Nos ajuda a entender se nossos processos de garantia de qualidade e liberação de features estão adequados. É medido pelo:

• APDEX (Application Performance Index)‍

Como disse anteriormente, existem outras formas de se medir disponibilidade e algumas delas são baseadas nas próprias ferramentas de monitoramento. Um dos indicadores que recomendo é o APDEX, Application Performance Index, uma forma simplificada de medir a satisfação com o desempenho da aplicação/produto. disponível nas ferramentas de monitoramento mais utilizadas no mercado, como New Relic, Datadog, Dynatrace, dentre outras.

Basicamente, o APDEX parte da definição de um tempo limite T para o qual uma requisição atendida é considerada como satisfatória. A partir desse valor, define-se múltiplos dele para indicar o que seria uma requisição tolerada e uma requisição frustrada, por exemplo:

• Satisfatória (T): 2 seg de tempo de resposta
• Tolerada: 2x T
• Frustrada: 4x T. 

Uma vez definidos esses limiares, calcula-se o APDEX para um conjunto x de requisições durante um período de tempo, como:

O resultado do APDEX será um valor entre 0 e 1, sendo que 1 é um produto funcionando plenamente.

O ponto interessante desse indicador é que mesmo não fazendo parte diretamente do seu cálculo, além do tempo de resposta e do throughput de requisições, ele também é influenciado pela taxa de erros desses requests (reduzindo o número de requisições satisfatórias e toleráveis da fórmula). Ou seja, ele é de fato uma forma inteligente de se convergir várias métricas que dão indícios da disponibilidade do produto em apenas uma bem mais assertiva.

‍2. Indicadores de Atendimento  

Temos no mercado inúmeros indicadores para mensurar atendimento aos usuários (externos ou internos), utilizados por centrais de serviço, CS, operações, engenharia, etc. Porém, para “começar pequeno”, sugiro os seguintes:

• % de tickets resolvidos dentro do prazo: uma vez estipulado um SLA (Service Level Agreement) do tempo máximo para a resolução de um ticket de incidente ou bug, basta mensurar a porcentagem daqueles que foram encerrados em um prazo menor desse limite, dividido pelo total de tickets. Essa análise pode ser feita englobando todo o fluxo, desde a abertura do ticket, seus encaminhamentos por times internos (ou mesmo fornecedores externos) até a solução, ou estabelecendo SLO (Service Level Objectives) que seriam prazos máximos os quais cada time da cadeia de atendimento tem para realizar sua tarefa, sem que o tempo total do SLA seja atingido.

• % de tickets resolvidos em primeiro atendimento: sabemos que muitos incidentes não são resolvidos pelo time que faz o primeiro contato com o usuário final (ex. CS, Service Desk, etc). Eles fazem uma primeira triagem, tentam algum procedimento de solução e, caso não obtenham sucesso, repassam o atendimento para níveis mais especializados: operações, suporte, até chegar na Engenharia. Uma vez que o principal propósito de um time de CS é o atendimento ao usuário, quanto mais possibilidades esse time tiver para resolver o problema sem envolver outros times na cadeia, melhor: melhor para o usuário que tem sua situação contornada mais rápido; e melhor para o time de Engenharia que pode se manter concentrado em outras atividades. Porém, para que o nível de assertividade do CS seja o maior possível, (o que é o objetivo desse indicador de % de tickets resolvidos em primeiro atendimento) é necessário que os times mais especializados, como o de Engenharia, invistam parte do tempo em montar automações e gerar documentações que dêem autonomia ao time de atendimento. 

6 dicas para realizar a Gestão Operacional de TI 

Espero que esse conjunto de indicadores auxilie a você, pessoa gestora de tecnologia, a  trazer mais visibilidade para você, seu time, PMs e demais stakeholders sobre a fase de maior duração do ciclo de vida do produto, da operação, e como ela pode fornecer insights para a evolução de soluções - tanto quanto outra ferramenta de discovery.

Além disso, espero que com essas informações você consiga dimensionar times e priorizar melhorias técnicas. E para que isso seja possível, aqui vão algumas dicas finais:

1. Ter uma boa ferramenta, processos de monitoramento e disparo de alertas é imprescindível: Quanto antes seu time detectar uma falha, menos usuários serão impactados por ela. E, é preciso ter persistência e disciplina para manter os monitores bem calibrados, sem falso positivos. Realize reuniões periódicas com o time para analisar as últimas ocorrências de alertas e fazer ajustes;

2. Dissemine o conhecimento de como interpretar os alertas e soluções: Procure estabelecer uma rotina de documentação de procedimentos e troca de conhecimento entre as pessoas do time para que todas possam ser capazes de resolver qualquer tipo de emergência;

3. Rotacione a responsabilidade pelo acompanhamento dos monitores: Como disse no tópico anterior, é sempre bom ter todo o time pronto para analisar os alertas e atuar, porém vale rotacionar. Eleja uma pessoa para ser responsável direta por isso a cada semana. Isso não deixa dúvidas de que pelo menos alguém irá atuar, além de garantir a disseminação de conhecimento que comentei acima. Ah, e  pessoa desenvolvedora frontend também atende à operação, viu? Pode não ser a especialidade dela, visto que a operação ocorre muito no backend, mas é uma excelente oportunidade da pessoa diversificar seu conhecimento;

4. Estabeleça e cobre SLAs do seu time e de seus fornecedores internos e externos:  Isso vai garantir a excelência no cumprimento de todas as metas de SLAs;

5. Após incidentes/crises, crie documentos de “postmortem”: A criação e compartilhamento desses documentos são uma excelente forma de repassar aprendizados, além de ajudar na coleta das informações necessárias para gerar os dados das métricas acima (ex.: data/hora início do incidente, causa raiz, recorrência, etc);

6. Crie um ambiente saudável para permitir evolução do time a partir das métricas: Dei diversas dicas sobre o tema nesse outro artigo que produzi para o portal Tech Hub. Confira para entender a importância de sempre dar contexto às métricas apuradas e evitar utilizá-las para gerar cobrança e medo no time. Novamente, indicadores são mecanismos para evoluir ambientes.‍