Artefato importante no Framework ProdOps para construir um ambiente informativo e guiar a jornada de observabilidade do produto. Peça fundamental para a atuação de um PRE (ProdOps Reliability Engineer, Engenheiro de Confiabilidade ProdOps).
Origem na Matriz de Resiliência do Shopify
Por volta de 2014, o Shopify apresentou a Matriz de Resiliência, uma ferramenta que utilizam para entregar uma operação eficiente na Black Friday.
A idéia a grosso modo é tabular as aplicações e dependências envolvidas na Black Friday e observar o impacto que uma peça causa quando está degradada ou indisponível na experiência de compra. Deste forma, todas as áreas envolvidas na operação podem tomar decisões rápidas e evitar prejuízos durante a atuação.
A visão do produto é completa quando se colocam todas as peças necessárias para a execução do serviço fim a fim em um mesmo desenho, independente de como foi pensada a divisão das aplicações entre as equipes de produto.
Desenho da Arquitetura Real do Produto
Utilizamos no Framework ProdOps para conquistar algo a mais que a resiliência, usamos também para mapear e entender o verdadeiro time envolvido no produto ou Value Stream.
Durante o trabalho prévio de mapeamento para a construção do Plano de Confiabilidade, extraímos as aplicações a partir de Service Blueprint para entender como funciona a jornada do cliente fim a fim.
Desta forma conseguimos entender que aplicações são dependentes na jornada, quando as vezes nem acesso direto entre APIs existem. O fluxo é maior do que o grafo de interdependências técnicas na infraestrutura.
Geralmente conhecemos o time que está dedicado a um tema, mas existe uma lacuna sobre as pessoas envolvidas e necessárias quando um incidente acontece ou uma demanda é necessária no Roadmap, esse mapeamento ajuda a preencher esses espaços.
Desenho de Arquitetura Preliminar
Na maior parte o trabalho não sai de uma só vez e definitivo, o entendimento da equipe técnica envolvida precisa de várias rodadas de mapeamento. O primeiro benefício é colocar as pessoas técnicas envolvidas para entenderem em conjunto qual o desenho correto, quase sempre vai perceber que a história entre dev, devops, infra e arquitetura tem nuances distintas que faltam entendimento em algum nível e a história sempre falta um pedaço.
DevOps conhece muito bem o desenho local das aplicações, mas não tem visibilidade do todo. Infra conhece o todo, mas não entende como os serviços são dispostos entre as aplicações. Dev na maior parte das vezes não tem a visibilidade de como funciona em produção. Desenho de arquitetura está sempre atrasado.
O desenho seguinte foi uma primeira rodada de mapeamento com os envolvidos no tema e o entendimento sobre o que chamavam de produto Retira na Loja. O produto na verdade é uma Value Stream distribuída na plataforma de Ecommerce, se percebe que o time não tem independencia nas publicações e é impactado no versionamento com as outras equipes envolvidas.
Expansão e Atualização Constante do Desenho de Arquitetura
Quando o desenho de arquitetura é realizado entendendo o todo, colocando as integrações necessárias para o serviço ser entregue, não apenas o produto fiuncionar, é que o time real do serviço aparece.
Numa segunda rodada de mapeamento já no Brainstorming sobre como observar essa Value Stream tratada como produto interno, o time descobre que faltam dependências que contém lógicas sobre o tema, quando há mudança de regra, é preciso interromper o Backlog de outra equipe. O desenho a seguir aumenta o escopo do “produto” e já demonstra que possui dois times quando um incidente for reportado.
A avaliação contínua é a abordagem para manter o desenho em constante evolução e garantir que todos os participantes conhecem sempre a história completa.
Usar APMs para facilitar o trabalho de mapeamento com funcionalidades de Service Discovery e Arch as a Code para extrair e manter o desenho atualizado são as técnicas que ajudam a potencializar a atualização. Utilizar e guiar IaC para ter todo o desenho, ajuda na construção da jornada de Onboarding tambem.
O desenho seguinte é um exemplo de uma visão completa, quando o time aplicou as integrações para o serviço funcionar deste a origem das informações até o resultado final ao cliente.
Desenho da Matriz
A partir do desenho de arquitetura, a técnica utilizada é colocar todas as aplicações que os times envolvidos com o tema fazem mudança de código numa linha de uma planilha.
Então repetimos as aplicações em linhas verticais e todas as dependências conhecidas no desenho.
A partir de cada coluna, observar a interseção direta que a coluna tem com a linha, no desenho seguinte o Ecommerce tem dependencia do Gateway de pagamento, ou seja, acessa diretamente. Assim como existe uma dependência que o Gateway também acessa diretamente o Ecommerce marcado na coluna seguinte.
A idéia é construir uma Dashboard a partir desta visão e acompanhar os indicadores de disponibilidade entre os componentes e aplicações com apelo visual e facilitar a identificação de consequências mais rápido.
Com o Dashboard completo, conseguimos atuar com mais eficiência, no desenho a seguir, nada há o que fazer pelo time de infraestrutura quando um serviço SaaS está degradado a não ser escalar com o fornecedor, enquanto isso a área de negócio, que possui acesso à mesma Dashboard, pode minimizar os impactos desabilitando temporariamente o meio de pagamento do fornecedor específico.
Evolução da Dashboard
Quando o desenho está pronto, se percebe que existem algumas linhas sem correlação direta com as colunas, aqui mora um grande perigo, é justamente nas dependências ocultas que sofremos com um tempo de atuação elevada, até identificar as pessoas necessárias para identificação correta da causa raiz, o negócio sofreu prejuízos enormes.
A seguir o time identifica dependências indiretas, quando um componente dá problema e o que é afetado como consequência da inconsistência de dados.
Desta forma, o acionamento se torna mais inteligente, já conseguimos criar escalas e geração automatizada de salas de incidentes com Reports e alertas adequados aos envolvidos do tema conforme nível de prioridades destes incidentes.
Escalas inteligentes com a Expansão da Matriz para Contextos de Negócios ou Integrações
Uma jornada inteligente de gestão de incidentes precisa ser bastante assertiva com o tempo de acionamento de quem deve atuar para garantir um MTTR (Mean Time To Restore) bem pequeno. Quanto maior o MTTR, maior pode ser o prejuízo.
Alguns desenhos focados em acionamento inteligente são identificados durante as iterações na Avaliação Contínua, na imagem a seguir o time ProdOps identificou o time necessário quando o problema for classificado como integração com o Mainframe.
Novas Matrizes de Confiabilidade a partir desses desenho de recorte são endereçadas para se tornarem Dashboards inteligentes para segmentos dos times de operação (e associados) para então criar os grupos de acionamento.
Agora com o apoio do ProdOps, podemos gerar visões de acionamento agrupadas por contextos lógicos entre partes do serviço diminuindo a fricção de interrupções, controlando quem deveria ser acionado e minimizando o ruído entre envolvidos e até não envolvidos impactados nesse acionamento.
A ferramenta Matriz de Confiabilidade é uma estratégia poderosa para conectar áreas de negócio, times de TI e áreas de suporte que geralmente são deixadas em segundo plano quando as propostas de mudanças são desdobradas no Delivery. Seguimos evoluindo o desenho para contemplar por exemplo, o serviço de Customer Experience e integrações necessárias para a melhor experiência do cliente final.
Deixe um comentário