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