Mais uma vez me deparo com uma daquelas situações em que um texto simplesmente sensacional me deixa tão entusiasmado que me vejo na obrigação de compartilhá-lo com você.
O site australiano
IT News traz uma análise extremamente útil sobre os dilemas atuais que envolvem duas das siglas mais comentadas nos últimos anos: ITSM e DevOps.
Deleite-se com mais este excelente texto, em tradução e adaptação livres deste blogueiro.
Há uma batalha feroz em curso sobre a melhor maneira de abordar os negócios de TI, com duas grandes escolas de pensamento competindo pelo domínio: IT Service Management (ITSM) e DevOps.
ITSM favorece um processo formal, planejado pela organização de TI, enquanto DevOps enfatiza um estilo dinâmico, mais fluido, livre das amarras da burocracia. Eles são, se você perguntar aos defensores mais estridentes de qualquer abordagem, a antítese um do outro.
Então, quem está certo? E o que são estas abordagens, de qualquer maneira?
O que é ITSM?
Essas idéias foram construídas ainda em 1986 no Reino Unido, pela Agência Central de Computação e Telecomunicações (CCTA) – um órgão do governo, dada a difícil tarefa de melhorar a qualidade e eficiência de TI. A CCTA já havia desenvolvido o Structured Systems Analysis and Design Method (
SSADM) para desenvolvimento de software, e o PRojects IN Controlled Environments (PRINCE) para gerenciamento de projetos.
Uma equipe liderada por Peter Skinner e John S. Stewart trabalhou com várias empresas de consultoria, incluindo IBM, para desenvolver o “pesado” Government IT Infrastructure Management Method, ou GITTMM. A IBM forneceu à equipe CCTA um conjunto de checklists para gerenciamento de serviços de TI derivados do seu trabalho sobre a referida ISMA, e a equipe expandiu esses conceitos para definir boas (“melhores”) práticas conhecidas. O princípio orientador foi, de acordo com Stewart, simples:
“A abordagem padronizada pode ser adaptada por organizações individuais como base para os seus processos próprios, repetitivos.”
O GITTMM foi mais tarde renomeado para IT Infrastructure Library (ITIL) por duas razões principais: em primeiro lugar, porque não era um método, e em segundo lugar, com a palavra “governo” o nome teria desanimado a adoção das idéias para além dos departamentos governamentais.
O ITIL define essencialmente que processo uma organização de TI deve seguir para tudo, desde como implantar um novo aplicativo, como definir a política de segurança, de como controlar licenças de software a como lidar com as chamadas de suporte. E três décadas após a necessidade de tal idéia ser reconhecida pela primeira vez, o ITIL é hoje mais ou menos onipresente. Se julgado pela concepção de Stewart do princípio central da biblioteca, o projeto teria de ser considerado um sucesso retumbante.
E ainda assim o problema original que se propôs a resolver – que os projetos de TI não estavam à altura das expectativas de alta qualidade ou de baixo custo – não parece ter sido resolvido.
Depois de quase 30 anos de ITIL na prática, ainda ainda lemos sobre falhas em rotinas de TI e em larga escala.
As páginas de iTnews estão continuamente cheias de argumentos para demonstrar porque.
O consultor Greg Ferro é um crítico ferrenho do ITIL.
“A premissa fundamental ITIL é que atividades de tecnologia podem ser segmentadas como máquinas ou funções de trabalho em uma fábrica onde cada tarefa pode ser atribuída a uma máquina, com recursos humanos fixos aplicados à tarefa e financiamento aplicado à máquina”, diz ele. “Isso simplesmente não funciona quando as máquinas e processos da fábrica sofrem mudança transformacional a cada três a cinco anos.”
“ITIL não é sobre a entrega ou excelência. Na minha experiência, ITIL e PRINCE2 evitam a excelência através de um foco em entregáveis e gestão de custos.”
Ele está convencido de que ITIL teve seu dia e que é hora de seguir em frente.
“Na última década, tenho trabalhado para dezenas de empresas que utilizam modelos ITSM/ITIL e todas elas eram locais de trabalho miseráveis e infelizes”, diz ele. “Quando eu trabalhei em empresas que não usam ITIL, achei que eram ótimos lugares para trabalhar, enquanto o valor real do negócio estava sendo criado e entregue.”
“É sobre a felicidade. ITIL é igual a miséria e infelicidade. Quem quer isso?”
Leia mais enquanto explicamos a escola de pensamento oposta…
O que é DevOps?
Muitos que têm manifestado insatisfação com processos ITIL descobriram que o modelo DevOps – uma extensão da metodologia ágil – resolve muitas questões que ITIL e ITSM não conseguem.
DevOps como conceito ganhou destaque em 2009, principalmente com o lançamento de “
DevOps Days” na Bélgica por Patrick Debois. DevOps é uma palavra que combina Desenvolvimento e Operações, que descreve o que parece ser a síntese da abordagem: desenvolvimento e operações trabalhando em conjunto.
A maior dificuldade com DevOps é que ninguém, nem mesmo seus defensores, parece bastante certo do que DevOps é exatamente. Alguns chamam de método de desenvolvimento de software, alguns uma abordagem para o gerenciamento de TI, enquanto outros o chamam de “movimento global”.
O ponto em comum na descrição DevOps é em grande parte uma reação à abordagem de silos tomada por muitas empresas quando implementam processos do ITIL.
No mundo ITIL, os desenvolvedores são responsáveis por atualizações e alterações, enquanto as operações de TI são responsáveis por manter tudo funcionando. Esta abordagem leva muitas vezes a incentivos incompatíveis, onde a operação é motivada a reduzir a mudança (e manter as coisas estáveis), enquanto o desenvolvimento é totalmente sobre mudar as coisas.
A ascensão da abordagem Agile para desenvolvimento de software no início de 2000 – e sua ênfase em ciclos de liberação rápida – colocou pressão sobre os processos formais de gestão de mudança e de transição de serviços recomendados pelo ITIL. Se um comitê de mudança só se reúne uma vez por semana, liberações em produção não podem acontecer mais rápido. Mas se a empresa segue Agile ao pé da letra, como muitas empresas on-line fazem, você pode liberar mudanças em produção várias vezes por dia. Os dois mundos não se encaixam muito ordenadamente.
Portanto, assim como a abordagem Agile para desenvolvimento de software substitui o método cascata SSADM, o DevOps visa substituir a formalidade lenta dos processos ITIL quando se trata de operações. DevOps requer que os desenvolvedores possuam o ciclo de vida completo de uma aplicação, desde o desenvolvimento, testes, implantação e suporte em produção, todo o caminho até o descomissionamento.
A pedra angular da abordagem DevOps é a automação. Sem ela, as grandes organizações não poderiam conceber tais ciclos de liberação rápida, sem introduzir erros. Ferramentas como o Puppet, Jenkins e Selenium são todas voltadas para automatizar tarefas que eram anteriormente centradas em humanos. Em vez de um comitê de mudança de seres humanos que se reúne uma vez por semana, um teste de software automatizado determina se um lançamento está pronto para implantação em produção.
As ferramentas de automação já existem há décadas, mas a sua utilização sempre foi um pouco limitada. O humilde utilitário UNIX make foi criado em 1976, e as ferramentas subseqüentes, mesmo internas da HP como a ferramenta MEDUSA, podem pedir antiguidade em relação a ferramentas mais recentes como Puppet, Ansible, e Jenkins.
Mas como acontece com tantas tecnologias, sem dúvida, as ferramentas anteriores chegaram muito cedo. Simplesmente não havia necessidade generalizada suficiente para serem utilizadas fora de nichos ou empresas específicas. O estilo DevOps de automação explodiu em popularidade porque o timing estava certo.
Automação tem sido muito demandada desde a virada do milênio, inicialmente para as grandes empresas online como Google, Yahoo, Facebook, entre outros. O sucesso dessas empresas dependia de economias de escala para o sucesso comercial, e ninguém podia se dar ao luxo de contratar um grande número de seres humanos para alcançá-la. As tarefas de curadoria de resultados de pesquisa, execução de leilões do AdWords, e mostrar quais dos seus amigos tornaram-se solteiros são impossíveis para seres humanos, quando se tem milhões de membros. Pagando um desenvolvedor realmente bom o triplo do salário de mercado para escrever software que substitui 15 administradores de sistemas parece um bom negócio.
A automação também cabe na cultura do desenvolvimento online da ‘era digital’. Técnicas e códigos originalmente desenvolvidos por estas grandes empresas online foram liberados para o mundo em geral (considere o Apache Hadoop e a biblioteca de interface de usuário do Yahoo!), geralmente muito tempo depois que permitiu qualquer vantagem competitiva significativa para a empresa original. É mais fácil para uma ferramenta ou prática para se tornar amplamente adotada, se muitas pessoas sabem que a ferramenta existe, e ainda mais fácil, se o custo de aquisição é baixo. Operações “digitais” de hoje dentro de bancos ou empresas de telecomunicações são frequentemente reciclagem de código desenvolvido para redes sociais uma década antes.
Até o final dos anos 2000, uma massa crítica de ferramentas e técnicas que tinham surgido começaria a desafiar seriamente o domínio do ITIL.
Mas será que isso realmente tem que ser uma escolha difícil entre ITIL ou DevOps?
Podem as duas abordagens co-existir?
Leia sobre como os líderes empresariais discutem essa opção…
Lições do passado, presente e futuro
Mudanças culturais à parte, a causa raiz do crescimento do DevOps se dá pelos benefícios acumulados através de um maior uso de automação.
Ela evita muitos dos famosos problemas de comunicação entre silos, principalmente porque, na maioria dos casos, os seres humanos que poderiam se comunicar foram substituídos por computadores. Ao contrário dos humanos, os computadores fazem exatamente o que são ditos pra fazer, então não há essa coisa de falha de comunicação. Os computadores também fazem tarefas repetitivas com grande precisão. Seria uma abordagem ITIL funcional, se a maioria dos seres humanos fossem substituídos por Jenkins, Puppet e scripts shell?
Don Meij, CEO da Domino Pizza, diz que os problemas operacionais que afligem a maioria das organizações de TI têm geralmente mais a ver com a implementação do que com a escolha da abordagem.
“Muitas empresas tornam tudo uma questão de processo”, diz ele. “CEOs se apaixonam por processos. É quase como se justifica o que se faz. É o câncer de uma organização se você não gerenciar adequadamente.”
Peter Nikoletatos, diretor de TI atuando na Universidade de New England, diz que o IT Service Management e ITIL ainda serão relevantes no futuro. Mas as organizações precisam melhorar a forma como aplicam.
“ITIL é um framework que exige adaptação”, diz ele. “A maioria das organizações erram ao buscar muita sofisticação. Isso torna as coisas muito burocráticas.”
“O entusiasmo para execução ao implementar ITIL deve ser moderado. Você precisa ter um cronograma realista. Construir os serviços de forma incremental. Comece com coisas simples: gerenciamento de incidentes e gerenciamento de problemas.”
“Do ponto zero para o ITIL totalmente implantado pode levar de dois a três anos. Isso é um investimento significativo de tempo. Você não tem que fazer tudo isso.”
“Nem todas as organizações se prestam ao Agile“, continuou ele. “ITIL é apenas uma maneira de pensar sobre um problema, mas não a única. ITIL é conveniente porque a maioria das pessoas entende. Com o Agile, ainda estamos aprendendo como usá-lo. Demora alguns anos para construir provas de que isso funciona”.
O que confunde tudo é o ritmo acelerado de mudanças no setor de TI em geral, cortesia da Lei de Moore. O tipo de automação possível hoje era impensável em meados dos anos 80, ao mesmo tempo, a explosão de dados e processamento de dados criou novos problemas que não existiam então. Com a paisagem mudando sob seus pés tanto assim, pode uma abordagem para gerenciar as coisas realmente cobrir todas as bases?
Para o deleite dos consultores em todos os lugares, a resposta sobre adotar ITIL ou DevOps parece perpetuamente ser: “Depende.”
Como a velha piada de gerenciamento de projetos: você normalmente só pode escolher duas das três variáveis - rápido, barato e bom. Tanto ITIL quanto DevOps pretendem buscar os mesmos objetivos – resultados finais de negócio melhores. Poderia ser o caso de que ITIL foi otimizado para qualidade boa e barata, com menos ênfase na velocidade, enquanto DevOps oferece um ponto de otimização diferente – muito mais rápido e, invariavelmente, mais barato. A pergunta que muitos estão esperando para responder é se ele vai entregar a mesma qualidade.
Uma maneira mais construtiva de fazer uma escolha entre os dois é avaliar o custo da mudança para qualquer solução.
O software se beneficia de mudança rápida, porque o custo de mudança é baixo. Quanto mais baixo o custo da mudança, mais mudança você pode se dar ao luxo de contemplar. Mas o hardware raramente é tão fácil mudar. Aqueles que implantam hardware ainda precisam considerar as ramificações de longo prazo de suas ações, ou, pelo menos, o impacto do custo de errar e ter que mudar.
Faz sentido usar a técnica que combina a quantidade e o custo de mudanças ao seu ambiente. Algo que não muda com freqüência, e custa muito quando isso acontece, requer um planejamento cuidadoso e de gestão da mudança. Mas, para as coisas que são relativamente fáceis de mudar e não custam tanto, tentar muitas opções diferentes rapidamente faz muito mais sentido.
Nessa base, a necessidade de reinvenção é um pouco exagerada. Não há nada que diga que processos ITIL não podem ser automatizados. Ele é, afinal, apenas uma estrutura, pronta para ser adaptada às especificidades do seu negócio, enquanto continua a fornecer uma maneira padronizada de pensar sobre problemas de negócios.
Adeptos ITIL podem aprender muito emprestando idéias do DevOps, pois adeptos do DevOps tendem a reciclar seus softwares de gerenciamento de configuração e compartilhar receitas Puppet através da internet.
Compare e contraste
|
ITIL |
DevOps |
| Optimizado para |
Economia de escala |
Velocidade para o mercado |
| Despesas de execução |
Alta |
Baixa |
| Tempo para execução |
2-3 anos |
6 meses+ |
| Níveis de pessoal necessário |
Médio para Alto |
Baixo para Médio |
| Estabilidade |
Bem estabelecida |
Ainda em evolução |
| Habilidades de mercado disponíveis |
Amplamente disponível |
Poucos, mas em rápido crescimento |
| Melhor para |
Processos padronizados, repetitivos |
Inovação |
