Esqueça o tempo de atividade. Um MTTR baixo é o novo '5 9s' para TI
As interrupções são caras. Não é tão relevante se eles são, em última análise, o resultado de um ataque ou de uma falha no software ou hardware. Os custos por minuto de inatividade estão aumentando, graças à crescente dependência de APIs e aplicativos da web da economia digital moderna.
Para alguns, esses custos são assustadores. Estima-se que os 40 minutos de inatividade da Amazon em 2013 custaram US$ 2,64 milhões. Isso equivale a US$ 1.100 por segundo para aqueles que não estão dispostos a fazer as contas. Se você acha isso assustador, pense no Google, cujo tempo de inatividade de 5 minutos no mesmo ano custou US$ 109 mil por minuto. (ou US$ 1.816,67 por segundo) para um total impressionante de US$ 545 mil. Por 5 minutos. Tecnicamente, se isso foi tudo o que eles sofreram, esses são os alardeados “5 9s” que a TI tem a tarefa de alcançar.
Com que frequência ocorrem interrupções? Aparentemente, com muita frequência. Se você nunca viu isso, dê uma olhada no mapa de interrupções ao vivo do pingdom . Ele foi criado a partir de dados coletados de mais de 700.000 usuários globais. Este mapa morbidamente fascinante exibe as interrupções que ocorreram na última hora em todo o mundo. Os flashes brilhantes que mostram as interrupções são um toque agradável; eles realmente destacam o impacto que causam entre os usuários.
Ou seja, algo indesejado.
A economia digital agrava esse problema. No início deste ano, uma interrupção do S3 na Amazon derrubou uma série de aplicativos e sites de clientes. Mas para não culpar os provedores de nuvem pública por esse problema, uma rápida olhada no site builtwith.com acabará com essa crença. As porcentagens de sites que aproveitam CDNs e APIs talvez sejam assustadoramente altas se você considerar a dependência que isso gera do tempo de atividade de outra pessoa . É difícil encontrar um site que não dependa de pelo menos uma API ou serviço externo, o que aumenta a possibilidade de tempo de inatividade porque se esse serviço externo estiver inativo, você também estará.
Basicamente, a TI decidiu usar “5 9s” porque é impossível atingir 100% de disponibilidade. A chave hoje, quando os custos por segundo estão disparando graças à mudança da economia para o mundo digital, é minimizar o tempo de inatividade. Em outras palavras, definir metas que exijam um tempo médio de resolução (MTTR) baixo é tão crítico – talvez mais – do que tentar eliminar o tempo de inatividade.
Uma das principais medidas de “organizações de alto desempenho” no Relatório State of DevOps de 2016 da Puppet Labs é o MTTR, definido como o tempo necessário para restaurar o serviço quando ocorre um incidente de serviço (por exemplo, interrupção não planejada ou comprometimento do serviço). As organizações de melhor desempenho (com base na avaliação do relatório) levam menos de uma hora , enquanto organizações de desempenho médio e baixo levam “menos de um dia”. “Em outras palavras”, observa o relatório, “os de alto desempenho tiveram MTTR 24 vezes mais rápido do que os de baixo desempenho”.
Você notará que a pergunta não era "se" há um incidente de serviço. Era “quando” há um incidente de serviço. A suposição é que um incidente ocorrerá e, portanto, a chave é minimizar o tempo de resolução. Uma pesquisa de 2016 realizada pelo IHS relatou que "em média, os entrevistados vivenciam 5 eventos de inatividade por mês, e 27 horas de inatividade por mês" custam à organização média de médio porte US$ 1 e às suas contrapartes maiores até US$ 60 milhões.
Se assumirmos que a Lei de Murphy ainda preside Moore e Conway, a resposta é tentar minimizar o MTTR para reduzir o tempo (e os custos) associados ao inevitável tempo de inatividade.
Isso significa que a visibilidade é fundamental, o que significa monitoramento. Muito e muito monitoramento. Mas não apenas o site, ou o aplicativo web, ou a API – precisamos monitorar a pilha completa . Da rede aos serviços de aplicativos e ao aplicativo em si. Isso é algo que nem todo mundo faz e, quando o faz, parece que o faz de forma inconsistente.
Considere a pesquisa xMatters|Atlassian DevOps Maturity de 2017, na qual 50% dos entrevistados declararam que “esperam que as operações declarem um incidente grave” antes de responder. Um assustador 1/3 das empresas “ficam sabendo de interrupções de serviço por meio de seus clientes”.
Em uma economia digital, cada segundo importa. Não apenas porque custa dinheiro, mas também porque impacta negativamente as receitas futuras . A diminuição do valor da marca e da confiança dos clientes resulta em menos compras, usuários e, eventualmente, estagnação do crescimento. Essa não é uma direção que as organizações devem seguir.
O monitoramento é o primeiro passo para detectar problemas que causam interrupções. Mas o monitoramento por si só não ajuda no MTTR. A comunicação sim. Alertar as partes interessadas relevantes o mais rápido possível e equipá-las com as informações necessárias para solucionar o problema ajudará a acelerar o tempo de resolução. Isso significa que o compartilhamento – um dos quatro pilares principais do DevOps – é essencial para melhorar o MTTR. Mesmo que você ainda não esteja adotando outros aspectos do DevOps em nível corporativo, o compartilhamento é uma iniciativa que você deve considerar elevar a um nível mais alto. Seja por meio do ChatOps ou e-mail, um aplicativo móvel ou uma página wiki atualizada dinamicamente, é fundamental que as informações coletadas por meio do monitoramento sejam amplamente compartilhadas em toda a organização.
Um problema em um switch ou servidor pode parecer inofensivo, mas se não for resolvido, pode acabar derrubando metade dos serviços dos quais um aplicativo crítico depende. No estudo State of the Network de 2017, conduzido pela Viavi , 65% dos administradores de rede e sistemas citam “determinar se o problema é causado pela rede, sistema ou aplicativos” como seu principal desafio ao solucionar problemas de aplicativos. Maior visibilidade e monitoramento completo são uma maneira de abordar esse desafio, garantindo que os responsáveis por encontrar a causa raiz tenham em mãos o máximo de informações possível sobre o status e a integridade de todos os componentes no caminho de dados .
A visibilidade é fundamental para o futuro da TI. Sem ela, não podemos atingir o nível de automação necessário para corrigir interrupções antes que elas ocorram. Sem visibilidade não podemos reduzir o MTTR de forma significativa. Sem ela, realmente não conseguiremos manter o negócio crescendo em um ritmo sustentável.
A visibilidade, assim como a segurança, deve ser um cidadão de primeira classe na pilha de estratégias que impulsionam a TI. Porque interrupções acontecem, e é a visibilidade que permite que as organizações se recuperem de forma rápida e eficiente, com o mínimo de danos possível à sua marca e aos seus resultados financeiros.