Na minha carreira, fui desenvolvedor de software e praticante de ITIL em uma função de operações. Portanto, o DevOps foi uma progressão natural para mim.
No entanto, sempre lutei com a linguagem altamente especializada que o ITIL apresenta e tornando esse "amigável ao desenvolvedor" o suficiente para não ser uma opção completa para os desenvolvedores.
O ITIL é uma estrutura de Gerenciamento de Serviços de TI reconhecida internacionalmente que foi desenvolvida há mais de 30 anos como um conjunto de práticas que têm um benefício comprovado para a estabilidade e maturidade operacional de uma organização.
O DevOps é verdadeiramente compatível com o ITIL ou, em essência, precisamos levar o espírito do ITIL e "traduzi-lo" para uma linguagem que seja melhor entendida pelas equipes de desenvolvimento:
- Gerenciamento de incidentes e problemas → Defeitos, bugs ou problemas de produção
- Gerenciamento de alterações e liberações → Entrega contínua
- Gerenciamento de Eventos → Registro, Telemetria, Instrumentação e Alerta
fonte
Respostas:
Na minha opinião, a cultura DevOps acompanha uma mudança de metodologia em direção ao gerenciamento de processos Agile .
O ITIL é fortemente voltado para um formalismo claro do processo e dos resultados e, portanto, mais adaptado ao modelo Waterfall .
Isso não significa que o ITIL seja incompatível com o Devops, mas geralmente serão dois processos separados com cronogramas diferentes. Quero dizer que a inclusão de um novo produto no referencial da ITIL geralmente será adiada até que o produto / aplicativo seja lançado na produção por um tempo, onde as armadilhas e alguma documentação necessária para integrar a ITIL foram feitas e adaptadas após o produto " viver".
Uma das coisas no ITIL é o Design de Serviço, que é assumido como definido antes de qualquer tarefa de desenvolvimento, um processo ágil revisará o design em cada iteração, quebrando o formalismo necessário em um processo ITIL.
O principal objetivo do ITIL é, como você disse, fornecer uma estrutura para garantir que nada seja omitido entre a fase de design / concepção e manutenção (Build / Run). Em uma cultura de devops, toda a equipe é responsável por todas as fases a longo prazo, e por isso o formalismo é reduzido.
Isso não significa que precisamos esquecer o ITIL, os princípios básicos são absolutamente bons e, na minha opinião, devem ser usados como uma lista de verificação para criar o backlog inicial de um produto. Acontece que seguir o princípio da ITIL com todo o seu formalismo vai contra a meta de redução de tempo para o mercado de um rápido desenvolvimento iterativo de software e às vezes nem é aplicável, pois há menos transmissão de informações necessárias entre as equipes, pois as tarefas são realizadas pela mesma equipe. .
fonte
Tenho a certificação ITIL (embora já faz um tempo.) Concordo com o Tensibai: ITIL e DevOps não são incompatíveis , mas isso não os torna necessariamente grandes amigos.
Pode-se argumentar que os processos no ITIL devem ocorrer de alguma forma, especialmente para organizações maiores. A integração bem-sucedida das práticas de DevOps, onde o ITIL já é praticado, requer planejamento, comunicação e execução cuidadosos. Então, novamente, isso é verdade para qualquer transformação do DevOps.
Para uma transformação "greenfield" em que nem o ITIL ou o DevOps estão em vigor, eu criaria uma combinação de ambos usando a terminologia "mapeada", como você descreveu. Desde que todos na organização estejam na mesma página, usando o mesmo idioma, o ITIL e o DevOps podem agregar valor quando combinados.
fonte
Gostei das respostas fornecidas pelo IT Skeptic em um episódio do DevOpsCafe.org. Se bem me lembro, a linha de raciocínio dele é que, se você realmente entende o ITIL, há muito pouco conflito. Que a maioria das diretrizes da ITIL é muito geral e que os conflitos estão em grande parte entre algumas implementações da ITIL, não por trás da especificação real.
fonte