Alterando a estrutura
De todas as unidades deste módulo, essa é certamente uma das mais importantes. Nesta unidade, vamos considerar algumas ideias que podem mudar nossa compreensão sobre o que é importante monitorar e por quê. Para algumas pessoas, isso pode mudar radicalmente tudo o que eles pensam sobre o monitoramento como forma de melhorar a confiabilidade.
Reestruturação nº 1: Confiabilidade segundo a perspectiva do cliente
Anteriormente, discutimos aspectos da confiabilidade que devemos pensar em monitorar, mas isso só pareceu expandir o conjunto de coisas possíveis a serem monitoradas. Aqui está uma ideia que pode ajudar você a repensar do zero o que devemos monitorar para melhorar a confiabilidade:
A confiabilidade deve ser medida segundo a perspectiva do cliente e não do componente.
Isso é muito importante. Talvez seja interessante ler novamente, tamanha a importância dessa ideia. No passado, as pessoas defenderiam “monitorar todas as coisas!”. Se podemos ler um contador, grafar uma estatística ou colocar em um dashboard, achamos que devemos monitorar. "Medir segundo a perspectiva do cliente" é uma abordagem muito mais específica.
Vamos examinar um breve cenário que demonstra esse ponto de vista e o torna natural.
Cenário
Você é responsável por gerenciar o site de comércio eletrônico da sua empresa. Você tem um Web farm com 100 instâncias de servidor. De repente, 14 dessas 100 instâncias param de funcionar devido a uma falha no sistema operacional, atualização de software, oscilação de energia ou outro evento inesperado. Com isso, essas 14 instâncias ficam totalmente fora de serviço.
Revisando: 86 instâncias de servidor estão funcionando, 14 instâncias de servidor não estão funcionando.
Qual das opções a seguir é verdadeira nessa situação?
A: Não é nada grave. Você pode lidar com o problema em algum momento, quando tiver tempo para solucioná-lo.
B: Trata-se de uma questão grave. Você deve parar tudo o que está fazendo e colocar as 14 instâncias de servidor de volta em operação o mais rápido possível.
C: Trata-se de uma crise existencial para os negócios. Você deve notificar os executivos sêniores e convocar todos os funcionários para trabalhar a fim de resolver a situação o mais rápido possível, mesmo que para isso seja preciso acordar eles no meio da noite.
Reserve um tempo para pensar nesse cenário com atenção antes de responder e prosseguir. Você acha que é a opção A, B ou C?
A resposta correta não é A, B e nem C. E sim “depende”. Mais precisamente, “depende de como essa interrupção está sendo para os clientes”.
Se você houver projetado o site de tal forma que nenhum cliente sequer tenha notado os back-ends inoperantes e que as outras 86 instâncias de servidor estejam sustentando a carga sem problemas, então não há crise. O problema pode ser tratado como um incidente de gravidade 3 ou 4, ou talvez apenas um tíquete de suporte.
Se a interrupção parar toda a sua empresa e você estiver perdendo muito dinheiro a cada minuto de inatividade desses servidores, então, provavelmente, há motivo para acionar seu plano de emergência e mobilizar todos. Também pode haver um meio termo em que a resposta correta seria a opção “B”.
Novamente: a confiabilidade deve ser medida segundo a perspectiva do cliente e não do componente. É por isso que a informação de contagem de componentes que indicava "14 computadores inoperantes de um total de 100", embora absolutamente precisa, não era a informação mais importante nesse cenário, do ponto de vista da confiabilidade.
Essa ideia se aplica mesmo quando se trata do monitoramento mais tradicional baseado em componentes. Se você descobrir que o servidor de banco de dados está operando com 50% da carga de CPU, isso é bom ou ruim? Se ele chegar a 90%, isso é melhor ou pior? Se o serviço estiver funcionando bem e os usuários estiverem satisfeitos, 90% pode ser excelente, pois significa que aumentou consideravelmente a utilização de recursos. Mas se os usuários já estavam reclamando da lentidão do aplicativo quando operava com 50% de carga de CPU, se chegar em 90% será pior.
Reestruturação nº 2: Níveis apropriados de confiabilidade
Para definir essa ideia corretamente, devemos dar uma rápida olhada em sua origem. Essa ideia vem da SRE (Engenharia de Confiabilidade do Site). Podemos extrair várias ideias úteis (inclusive a ideia dessa seção) apenas examinando com atenção a definição de SRE:
Observação
a Engenharia de Confiabilidade do Site é uma disciplina de engenharia dedicada a ajudar as organizações a alcançarem de maneira sustentável o nível de confiabilidade apropriado nos sistemas, serviços e produtos.
Há três palavras importantes nesta definição:
Confiabilidade: falamos bastante sobre a importância da confiabilidade na unidade introdutória. Portanto, não entraremos em detalhes sobre esse ponto aqui.
Sustentável: nesse contexto, “sustentável” se refere à função das pessoas em tudo isso. É crucial criar uma prática de operações sustentável. Sistemas, serviços e produtos confiáveis são criados por pessoas. Se não adotarmos medidas para garantir que o trabalho seja sustentável, se acordarmos os colaboradores às 3h da madrugada, se eles não puderem passar tempo com suas famílias, se eles não tiverem tempo para cuidarem de si mesmos, então não podemos esperar que eles criem sistemas confiáveis. A SRE determina que é fundamental implementar uma prática de operações que seja sustentável ao longo do tempo, para que os colaboradores possam dar o melhor de si no trabalho.
Apropriado: esta é a palavra que pode fazer toda diferença para algumas pessoas. Em outra época, no mundo das operações, nossa meta era garantir que tudo permanecesse ativo 24 horas de horas, 7 dias por semana. Tentávamos manter tudo operando o dia todo, a semana toda, o mês todo, o ano todo. Nunca era aceitável que algo ficasse inoperante. Uma das coisas que a engenharia de confiabilidade do site trouxe para a discussão de operações foi a noção de que devemos nos esforçar para manter um nível apropriado de confiabilidade.
Vamos nos aprofundar nessa ideia. Um ponto importante aqui é observar que 100% de confiabilidade quase nunca é a meta correta. Exceto em determinados casos excepcionais, como em equipamentos médicos ou na aviação, geralmente não precisamos que as coisas sejam 100% confiáveis. Na verdade, 100% de confiabilidade nem sempre é possível.
Esse é um exemplo de algo que “nem sequer seria possível”: hoje em dia, todos executamos sistemas que dependem de outros sistemas para funcionar. Suponha que você esteja executando um software que precise ligar para um processador de pagamentos ou para um sistema de autenticação. Se o processador de pagamentos ou o sistema de autenticação não for 100% confiável, será muito difícil manter o seu sistema com 100% de confiabilidade.
A outra dificuldade da meta de 100% de confiabilidade é que ela exige um tempo de inatividade igual a zero. Isso também significa zero chance de fazer alterações que impliquem na possibilidade de gerar tempo de inatividade. Assim você não tem nenhuma reserva dinâmica, algo que você provavelmente vai precisar.
É útil começar a pensar sobre isso da perspectiva de “qual é o nível apropriado de confiabilidade?” para algo específica que você está tentando operar. Para voltar ao tópico em questão, nosso monitoramento precisará apoiar essa meta.
Com essas duas estruturas em mente, vamos colocar em prática e buscar ferramentas que nos ajudem a cumprir nossas metas.