quinta-feira, 16 de janeiro de 2014

Runbooks - Solução ou Problema?

Eu não tenho nenhuma estatística oficial, mas na maioria das organizações de TI que visitei no Brasil nos ultimos dois anos, o runbook vem sendo utilizado da forma mais medíocre possível. Os conceitos são mal entendidos, arquitetados e efetivados. O seu uso pode ser incrivelmente melhorado se existir o entendimento que é preciso menos falácia e modismo e mais planejamento e ação. Não é porque a organização de TI tem acesso a um novo martelo que tudo deve ser visto como prego. Não tem sentido algum usar um runbook quando a central de serviços precisa de um roteiro.

Não é porque esta sendo utilizado um runbook que acabou a necessidade de documentação. A base de conhecimento e inteligencia coletiva exige documentaçao. Eu conheço vários casos de pessoas que estão escrevendo runbooks que são apenas uma lista de ações para criar um operador virtual do sistema. Se por qualquer motivo existir uma falha não prevista e o processo fracassar não existe espaço para uma decisão humana. O pensamento inteligente pode evitar o aumento da gravidade e impacto do problema. O runbook está sendo utilizado nestes casos apenas um roteiro que esta sendo lido e executado por uma máquina sem inteligencia alguma.

Tipicamente os roteiros exigem a inteligencia de uma pessoa para que as coisas não vão de mal à pior. Quando um trem sai dos trilhos, as decisões e escolhas precisam da inteligência humana. As tecnologias são desenvolvidas para que as pessoas sejam mais produtivas. Não tem sentido algum converter uma açao mecânica que pode ser facilmente realizada por um script ou programa simples em uma tarefa informatizada que precisa de novos dispositivos. Não existe relação favorável entre o custo e o beneficio.

A automação do runbooks é um estratagema viável economicamente para a automatização do Service Desk quando os alertas de exceção explodem nos olhos de uma pessoa e as decisões são processadas por um cérebro humano e apoiadas pela infraestrutura. É evidente que os técnicos da central vão perder com o runbooks uma parte da execução de suas atividades desejadas do trabalho diário. Em alguns mais críticos vão aparecer problemas para reter os talentos mais proeminentes pela transformação de enfrentar um desafio profissional de solução de uma necessidade do negócio em um mero apertar de um botão. É de fato um problema motivacional concreto que muitas organizações de TI vão ter que enfrentar nos próximos anos. Em vários casos, o estratagema de manter a inteligência do processo e posicionar decisões no lugar correto é a melhor solução.

 

Isto significa que a automatizaçao dos processos da central precisa ser planejada com a visão da engenharia que endereça a necessidade dentro do prazo. A atuação de supetão que quer enfrentar um problema estrutural durante uma crise sem planejamento algum faz o negócio perder dinheiro e clientes. À improvisação em cima de improvisação nas crises gera blecautes graves, pois a falta de planejamento e documentação fazem com que o time de operadores não exerguem as soluções simples e fáceis. São diversos casos de fracassos onde o óbvio não foi feito e a recuperação automatizada não minimizou o impacto dos erros.


O sistema de monitoraçao dos processos precisa ser inteligente e dizer o que está errado. As exceções pela dificuldade dos computadores de contextualizar as informações derivadas de uma mudança do perfil do desempenho das aplicaçoes precisam de tratamento manual. Um exemplo clássico deste tipo de situação é a variação do número de visitantes em uma página de internet de um dia para outro. As visitas na página podem crescer centenas de vezes de um dia para outro por causa de uma reportagem no jornal ou televisão. É evidente que o tempo de resposta será completamente diferente. Apenas a capacidade de análise de um ser humano será capaz de capturar corretamente o entendimento da diferença de desempenho, compreender os motivos e trabalhar em um caminho eles de controle de danos. Todas as medidas da automação do runbooks vão ser ineficientes e ineficazes neste tipo de situação porque não foram previstas na automatizaçao destes processos.

Isto significa que em todas as monitorações são necessários olhos humanos, pois as pessoas conseguem ler os gráficos de desempenho muito melhor que os computadores. É a capacidade analitica delas de descobrir porque as coisas estão ocorrendo de forma diferente do planejado que gera a vantagem competitiva da monitoração assistida. As melhores monitorações da infraestrutura de TI são feitas pela vigilância das metricas de negócio como vendas projetadas ou quantidades de entregas. As metricas de baixo nível dos sistemas dificilmente conseguem explicar a totalidade do fenômeno e não servem como indicadores de previsão.

Infelizmente existem milhares de casos onde o runbook foi erradamente interpretado e desenvolvido. Sem a correta integração dos processos de negócio com o sistema de monitoração a utilidade da automação é muito baixa. As respostas do runbook precisam da inteligência humana para formar um poderoso sistema de compreensão dos problemas. Este caminho permite que os engenheiros da operação fiquem focados em descobrir o desconhecido do desconhecido em vez de gastar tempo em fazer o óbvio. Cada vez em que são descobertos os critérios de desempenho que sinalizam corretamente um problema é possível usar um runbook para monitor as condições automaticamente. Os modelos estatísticos podem ser usados para as análises de regressão e previsão para apresentar as alternativas do esforço de solução.

Os sistemas precisam adquirir urgentemente a capacidade de auto recuperação. É preciso que cada componente dos sistemas estejam integrados com a arquitetura de alta disponibilidade para que os administrativos e engenheiros construam uma infraestrutura correta sem repetição dos erros e fracassos passados. Em outras palavras o esforço do desenvolvimento de um código mais confiável do sistema exige ações que assegurem que o problema nunca aconteça. É evidente que existem falhas de prevenção difícil, por isto o começo deve ser com as falhas que podem ser fácilmente descobertas onde o sistema pode ser recuperado com muita traquilidade de forma automática. Em geral é o caso onde a maioria dos fatores e variáveis estão sob controle. Para os casos de causas complexos das falhas vai ser preciso estabelecer um processo interativo de melhoria continua entre correções e problemas para corrigir todas as falhas e eliminar todos os erros. Basicamente é um estratagema onde são eliminadas em primeiro lugar as situações onde ocorrem os problemas e depois é feito um esforço para eliminar os erros. Um sistema com indisponibilidade baixa para 80% dos casos tem disponibilidade total maior que um sistema com disponibilidade de 100% para 60% dos casos.

Este tipo de situação mostra que a central de serviços efetiva é capaz de escolher o melhor local para disputar as suas batalhas. Em todas as organizações de TI existem pendências e soluções de contorno para a causa raiz do problema.  As pessoas precisam ser motivadas para manter a operação para o usuário usando sempre que necessário uma fita adesiva e grampo nas soluções seguras. Não é errado trabalhar ao redor de uma situação específica para resolver de forma segura e estável e sustentável um problema. É sem sombra de dúvida um estratagema válido para manter a aplicação disponível. O problema em sí pode ser tratado em outra oportunidade com melhor relação entre o custo e o benefício.

A maioria das pessoas não acredita na idéia de sistemas com autorecuperaçao das falhas. Infelizmente existem muitos gestores que acreditam que a sua infraestrutura de TI é tão evoluída que as indisponibilidades por causas óbvias nunca vão acontecer com eles. Na prática não existe tal situação de evolução. Isto significa que a engenharia precisa ser criativa para manter o menor nível possível de indisponibilidade. A realidade dos erros e falhas é expressa no SLA formal ou informal. É o melhor mecanismo para comunicar a expectativa do nível de qualidade de um serviço.

É preciso entender que o controle das aplicações passa pelo usuário. Um exemplo clássico ocorre na plataforma do servidor da rede IIS da Microsoft plataforma. Existem situações de erros no gerenciamento das aplicaçoes porque o clássico ASP não é perfeito na liberaçao dos recursos utilizados se a codificaçao não for absolutamente precisa. Muitas vezes não é possível controlar o código dos programas adquiridos de terceiros, no entanto é possível monitorar os programas e reiniciar o gerenciamento das aplicaçoes quando os erros específicos na liberação dos recursos começarem a aparecer.

Vários sistemas operacionais, como Solaris e Windows resolvem automaticamente os erros. Sempre que um serviço falha ele é reiniciado. Se ele falha mais do que X vezes o serviço é indisponibilizado para que o administrador intervenha. É uma óbvia solução para alta disponibilidade. A automatizaçao da limpeza ou uso de técnica de otimização dos registros mais antigos do sistema de arquivo quando ele esta próximo da sua capacidade máxima é uma forma inteligente de usar o runbook para o autodiagnostico e antecipação da resolução do problema da grande quantidade de informações do volume. Também é possível trabalhar com tentativas controladas e automatizadas para subir os serviços que falharam por problemas na rede ao invés de esperar por uma nova tentativa no boot de amanhã.

A automação é muito útil quando é preciso explorar a facilidade das aplicações de registrar as mensagens de erro específicas no log e automaticamente identificar a falha e o problema e conseguir consertar e iniciar o serviço sem a intervenção humana.

Todas as organizações de tecnologia têm falhas comuns e repetitivas na sua infraestrutura. Nem todas estas falhas vão causar indisponibilidades especialmente se a infraestrutura é de alta disponibilidade. Por causa disto é preciso ser prático e realista e nunca fingir que as aplicações são perfeitas. A boa gestão não se ilude com o pensamento que a reinicialização da aplicação que falhou é uma solução boa o suficiente para resolver o problema. É preciso pensar e entender o que ocorreu. O runbook é muito bom para automatizar a solução de contorno, mas não deve ser entendido como resposta definitiva. Tipicamente o runbook é muito útil para a organização de TI e Service Desk para assegurar a correta execução do plano de contingência, orientar e coordenar as pessoas nas urgências, pois a automatização faz com que todos conheçam as suas responsabilidades pessoais, os níveis de escalaçoes e os limites em cada nível e para facilitar o entendimento dos processos dinâmicos com tantas variáveis que a documentaçao completa de todas as situações exige um esforço monumental do time. Em geral a completa automatizaçao é uma atividade que dura alguns anos nestes casos.

Os runbooks devem conter somente os conteúdos relevantes para ajudar as pessoas pela evolução da comunicação. Tudo o que foi documentado pode ser traduzido em códigos. Os códigos sem erros do runbooks permitem um comportamento da infraestrutura mais previsível e controlado. É uma clara situação de melhoria do Controle, Transparência e Previsibilidade (CTP) do ambiente.

Nenhum comentário:

Postar um comentário