Treinamento escrito de DevOps

Quais problemas sua TI enfrenta sem DevOps?

Em uma TI sem DevOps, as equipes de desenvolvimento e operações geralmente entram em conflito. A garantia de qualidade de ponta a ponta das funcionalidades e dos benefícios exigidos pelo cliente só começa depois que o desenvolvimento já passou para outro projeto. As auditorias de segurança da informação e de prontidão para produção são realizadas na véspera da implantação. Resolver problemas de software nessa etapa crítica, especialmente falhas de projeto e segurança que deveriam ter sido identificadas e corrigidas oito meses antes, põe em risco a continuidade da TI e do negócio. Desenvolvedores cansados, equipes de operações pouco colaborativas, silos de testes e segurança da informação, gerentes de projeto e de produto exigentes e desesperados, executivos irritados e clientes e partes interessadas de TI frustrados pouco agregam.

Transferências demais de atividades e dependências em todas as direções imagináveis e uma quantidade enorme de trabalho manual, descoordenado e pouco transparente são parte do dia a dia do seu departamento de TI.

Apesar dos prazos longos para concluir qualquer tarefa, não há opção melhor, pelo menos por enquanto, e você sabe que ainda precisa desse emprego para ganhar dinheiro.

Finalmente chega o grande dia. Depois de uma implantação caótica e problemática, que provocou um período significativo de indisponibilidade para o negócio, você se pergunta se ela comprometeu alguma funcionalidade que já estava em produção. Você começa a pensar na falta de clareza e evidências concretas sobre o que de fato aconteceu e o que foi afetado nos sistemas de produção.

Mesmo assim, a comemoração da entrada em produção já começa nos corredores da grande sala de TI. É hora de tomar um drinque e se recuperar mentalmente da noite difícil que passou sem dormir. O que você quebrou ontem à noite em produção vai acabar sendo problema de outra pessoa. Nada demais…

A esta altura, você deve estar se perguntando como esses projetos difíceis conseguem terminar de algum modo, mesmo depois de chegarem a uma situação tão ruim e desesperadora. A resposta está no teorema do macaco infinito. Em resumo, o teorema do macaco infinito diz que um macaco apertando teclas ao acaso em uma máquina de escrever por um tempo infinito certamente digitará um texto dado, como as obras completas de William Shakespeare. É sério.

Da mesma forma, por mais difícil que seja prever quando o trabalho vai terminar, se sua equipe de TI adiar o bastante e ganhar tempo suficiente, acabará entregando o projeto.

Conflito crônico entre desenvolvimento e operações

Entre várias responsabilidades importantes, sua organização de TI tem duas missões principais:

1. Sua equipe de desenvolvimento precisa entregar rapidamente para responder às mudanças nas demandas dos clientes e do mercado atendido pela empresa.
2. Sua equipe de operações precisa garantir um serviço estável, previsível, seguro e contínuo para atender aos clientes e ao mercado.

Com essa estrutura, as equipes de desenvolvimento e operações têm missões e motivações conflitantes. O conflito reduz a produtividade, a qualidade do serviço, a satisfação dos clientes e os resultados da TI e, por fim, prejudica o desempenho de todo o negócio.

Agora você tem dívida técnica

Resolver emergências o tempo todo, recorrer a soluções paliativas e realizar atividades não planejadas para salvar o dia apenas acumula mais dívida técnica. Isso prejudica o desempenho do desenvolvimento e das operações e também afeta arquitetura, segurança da informação, testes, gestão de produtos, gestão de liberações e as partes interessadas do negócio.

A dívida técnica se parece com uma dívida financeira. Quanto mais endividado você está, menos opções tem para atingir seus objetivos. Por fim, fica quase impossível tomar a decisão certa para chegar ao resultado desejado, e aumenta a probabilidade de contrair mais dívidas.

Com a dívida técnica, acontece o mesmo. Quanto maior a dívida, menos opções você tem para construir e entregar as soluções certas. Você acaba empilhando soluções paliativas e construindo um castelo de cartas sobre outro. É questão de tempo até tudo desabar. Você já sabe disso.

Seu negócio depende dos sistemas mais frágeis para gerar receita

Um fato previsível, mas preocupante, é que os sistemas mais críticos e que geram receita são os mais sujeitos a erros, falhas e indisponibilidade.

Esses sistemas normalmente estão no centro do negócio e acabam aparecendo de alguma forma em todas as reuniões. São sistemas críticos afetados por quase todos os projetos. Por sua importância, merecem atenção contínua, mudanças urgentes e correções não planejadas. Mesmo assim, continuam produzindo incidentes de prioridade 1.

Quando uma promessa falha, você promete ainda mais

Como a TI quebra promessas e frustra continuamente as partes interessadas, elas passam a exigir mais para compensar o passado. Muitas vezes, você e seus líderes só conseguem responder “por que não?”, a menos que já tenham uma oferta de emprego melhor.

Então as equipes de desenvolvimento e entrega recebem um desafio maior do que de costume. Como os sistemas críticos e a arquitetura de TI estão longe de atender aos requisitos nos prazos “urgentes” definidos, você começa a criar novas soluções paliativas sobre as que já existem.

O trabalho perdeu a graça

No fim, todo mundo fica um pouco mais ocupado. Não sobra uma hora sequer na agenda para fazer sem interrupção o trabalho para o qual você foi contratado. Chovem e-mails na sua caixa de entrada, e você usa o tempo pouco produtivo das reuniões para ler e limpar mensagens geralmente confusas e sem propósito. Você se pergunta por que a organização não oferece treinamento obrigatório sobre como usar e escrever e-mails.

Normalmente, você depende de outras equipes para dar continuidade ao próprio trabalho. Mas o que você pediu há algumas semanas ainda nem entrou no radar da outra equipe. Ela acabou de iniciar o projeto “Horizon 2400” enquanto precisava resolver 9 incidentes de prioridade 1 causados por aplicações frágeis.

Você começa a perder a paciência porque precisa de respostas da sua única pessoa de contato na outra equipe para poder avançar.

Você não se conteve e enviou outro e-mail para lembrar a pessoa da solicitação. Dessa vez, colocou o chefe dela em cópia e pensou que deveria ter feito isso desde o primeiro e-mail.

Em poucos segundos, apareceram duas respostas automáticas de ausência. Sua única pessoa de contato na outra equipe estará nas oficinas do “Horizon 2400” até o fim da semana. E o chefe dela está em casa, doente.

CONCLUSÃO

Neste capítulo, explicamos os desafios que a maioria das empresas e dos profissionais de TI enfrenta. São espirais de deterioração e ciclos viciosos com que quase toda empresa e todo profissional convivem.

A Gartner estima que empresas de todo o mundo desperdicem cerca de 600 bilhões de dólares por ano com trabalho de manutenção de TI fora do orçamento e do planejamento para manter em funcionamento sistemas que geram receita. Em algarismos, para ter uma ideia da dimensão: US$ 600.000.000.000.

Como talvez já tenha ficado claro, é difícil entender esse nível de desperdício em uma área que exige tanto raciocínio quanto a TI.

Vale a pena enfrentar esse desafio. DevOps tem algumas respostas para certas empresas, talvez inclusive para a sua, se ela estiver pronta para experimentar, aprender e se adaptar.