Criando a cultura DevOps

      Comentários desativados em Criando a cultura DevOps

As organizações de TI passam muito tempo tentando eliminar pontos únicos de falha em seus sistemas. Igualmente problemático é o problema da “ponto unico do fracasso”, que pode ter consequências tão desastrosas.

Quem seria este ponto único de falha ?

Construir sistemas altamente disponíveis é complicado e caro. Apesar dos melhores esforços das organizações de TI, a maioria dos sistemas tem pelo menos alguns pontos de falha. Mas digamos que é possível tornar o software e a infraestrutura de sua empresa perfeitos – portanto, não há pontos de falha únicos, tudo é feito de backup, cada servidor é balanceado, cada banco de dados está em um cluster, etc.

Mesmo neste cenário tecnicamente perfeito, o potencial de desastre existe porque você pode ter se esquecido de uma dependência – vamos chamar essa dependência “Zé”. O Zé é a pessoa de TI que sabe tudo e gerencia tudo, e todos vêm o Zé para conseguir o que eles tem necessidade. Mas um dia Zé vai de férias, algo dá errado e ninguém sabe o que fazer porque o Zé é a única pessoa com conhecimento ou ferramentas para resolver o problema. Pronto, o Zé é a única pessoa do fracasso.

Muitas equipes de TI acabaram com pelo menos um “Zé” que coloca um ou mais sistemas em risco. Não é que “Zé” é uma pessoa ruim – ele poderia ter acabado na única pessoa de posição de falha por uma série de razões:

Como assim ?

  • Falta de orçamento de TI que dificultou a contratação de mais pessoas para ajudar a gerenciar sistemas
  • Um mercado apertado para o talento de tecnologia que dificultou a contratação de pessoas mais qualificadas
  • Um desejo de implementar mais controle e consistência em todos os sistemas (ou mesmo centralizador)

É natural que as organizações de TI derivem na pessoa singular do problema de falha devido a esses fatores. Mas os seres humanos não estão altamente disponíveis – ao contrário da tecnologia, eles têm tempo de atividade limitado, precisam lidar com interrupções regulares e não podem ser replicados. Pelo menos até onde escrevi, não sei de clone em seres humanos com cloudformation. Portanto, as organizações de TI devem se proteger contra a queda da única pessoa no problema de falha e tomar medidas para corrigi-lo quando isso ocorra.

Três sinais de um problema de “único ponto de falha”

Como você reconhece que você tem uma única pessoa de problema de falha? Existem três cenários que podem ajudá-lo a reconhecer o problema.

# 1 – Cenário “Centralizador – Apenas EU faço – Apenas EU sei”

Nesse cenário, existe uma única pessoa que atua como administrador em um servidor de produção ou em alguma parte do sistema. Ele tem o único acesso a esse servidor ou sistema.

Como esse cenário ocorre? O problema pode ter se desenvolvido organicamente com o crescimento da empresa, se ninguém jamais pensou em adicionar mais pessoas à equipe para gerenciar sistemas. Às vezes, as pessoas simplesmente assumem o controle. Eles pensam no bem, tentando impor coerência, mas acabam criando um problema maior.

Este problema pode ser resolvido com o acesso baseado em função, onde uma função é definida para abranger um grupo de pessoas (o grupo deve ter mais de uma pessoa para que isso funcione). Por exemplo, o acesso pode ser concedido a um grupo Administradores de Produção. Outra maneira de abordar o problema é certificar-se de que quem está ligando tenha acesso a tudo o que precisa para resolver qualquer problema que possa surgir.

# 2 – Cenário “O especialista super inteligente”

Este cenário pode ser resumido em uma citação que será familiar para muitos profissionais de TI: “Esta questão levará 15 minutos para consertar e 8 horas para explicar.” A falta de disposição ou tempo para transferir conhecimento para outros no time pode levar a uma única pessoa de problema de falha. Isso significa que há alguma parte do seu sistema que não está documentado, não automatizado e só pode ser corrigido confiando no conhecimento na pessoa singular da cabeça da falha.

Este cenário oferece uma ótima oportunidade para envolver juniores na equipe de TI na solução do problema (“juniores”, o que significa novas contratações que não pegaram o vírus daquela que é-como-sempre-foi). Eles vão fazer perguntas difíceis e não estão envolvidos emocionalmente com a base do código ou o sistema, como os long-timers. Peça a esses membros da equipe para resolver o problema com documentação, teste e / ou automação. E se você precisa justificar o tempo gasto na transferência de conhecimento, pense nisso dessa maneira: se demorar um dia para explicar e documentar um problema, provavelmente provavelmente levará três ou quatro dias para investigar e corrigir o problema, se você não fizer isso, tenha alguma documentação.

# 3 – Cenário “Não é possível aproveitar as férias”

Este cenário ocorre quando as pessoas se voluntariam para conseguir o impossível – se essa pessoa que está sempre disponível, trabalha longas horas e pode resolver qualquer problema. Mas os seres humanos não estão altamente disponíveis e são suscetíveis ao cansaço.

Muitas pessoas assumem que trabalhar longas horas melhora a produtividade, mas não. A pesquisa mostra que a produtividade realmente diminui após um certo número de horas trabalhadas por semana. Quando sua única pessoa de falha neste cenário fica cansada, eles ficam lentos e desleixados, e eles começam a cometer erros. Ou então, eles alcançam seu limite e, finalmente, demoram, deixando outros na equipe se esforçar para preencher para eles. Ou simplesmente não “largam o osso”. E se denominam o “mal necessário”.

As férias obrigatórias vão um longo caminho para evitar esse cenário. Se você acha que as férias obrigatórias são impossíveis, lembre-se de que é uma prática rotineira no setor de serviços financeiros para evitar desfalques. Outra opção é enviar cada um dos membros da sua equipe para treinar ou internar com outra parte da organização por uma semana. Durante a ausência de cada pessoa, os outros membros da equipe documentam quaisquer lacunas de acesso ou conhecimento que surjam.

Não importa como uma situação de “ponto única de falha” tenha evoluído, reconhecer sua existência e implementar mudanças para resolvê-la é um grande passo no caminho para fomentar uma verdadeira cultura DevOps.