Enquanto o ITIL promove um conjunto de práticas recomendadas para o Gerenciamento de Serviços de TI mais eficaz, o DevOps se alinha aos princípios Lean, como gerenciamento de Work In Progress (WIP), trabalho em lote e agilidade no tempo de resposta. Do ponto de vista do DevOps, o ITIL nada mais é que um conjunto de obstáculos, atrapalhando o caminho das prioridades associadas a integração/entrega contínua (CI/CD).
Fonte: itsm.tools
Enquanto o DevOps deseja acelerar os ciclos de lançamento de software, o gerenciamento de mudanças (associado ao ITIL) geralmente os torna mais lentos. Essa dicotomia significa que as organizações deveriam escolher um OU outro? Ou talvez, quem sabe, seja possível ajustar as abordagens de forma que sejam compatíveis ou mesmo complementares uma com a outra?
O ITIL é parte do problema ou da solução?
Os céticos do ITIL são muitos, e costumam defender que frameworks como o ITIL acabam criando uma ilusão de controle que, em consequência, resulta na ilusão organizacional de que a TI é eficiente e gerenciável. Aparentemente, a criação de silos organizacionais leva a atitudes menos colaborativas.
Um desses silos vem a ser o Change Advisory Board (CAB), composto por uma equipe que tem como responsabilidade tomar decisões positivas ou negativas em várias atividades diferentes em toda a organização de TI. Naturalmente, ter o CAB analisando cada solicitação de mudança torna o processo bastante lento, especialmente quando envolve dezenas de milhares de implantações por hora em algumas organizações.
Case ING
Uma organização que tem lutado para transformar seu processo ITIL à medida que acontece uma mudança gradual para um modelo DevOps, é a empresa de serviços financeiros ING. Lá, as equipes CABs representavam um ponto de contenção. “Éramos uma seguradora, que sempre acabava rejeitando a primeira reclamação”, conta Mark Heistek, especialista em TI. “Para voltar depois, caso houvesse bons argumentos para tanto”. [abaixo o vídeo da palestra dele, em inglês, detalhando o case]
O ING descobriu que era capaz de modificar o ITIL para funcionar dentro de uma nova abordagem DevOps. “Não faça tudo o que o livro ITIL diz”, aconselha Jan-Joost Bouwman, Identity e Access Management Specialist no ING. De acordo com ele, seguir o ITIL para práticas como gerenciamento de incidentes “é ainda a melhor maneira de fazer isso, porque todos sabem o que fazer, sem perigo de haver confusão com as regras.”
Há controvérsias
A abordagem DevOps é inerentemente flexível e orientada por humanos. Afinal, as pessoas ainda criam software – e o DevOps tem mais a ver com encorajar novas maneiras das pessoas cooperarem para atingir um objetivo comum do que com a transferência de tarefas humanas para processos automatizados.
Como resultado, o DevOps não é tão preto-no-branco quanto os maiores entusiastas do assunto podem fazer acreditar. Por exemplo, o “continuous” em CI/CD não significa “o tempo todo” ou mesmo “o mais rápido possível”. Na prática, continuous significa “tão rápido quanto prático, dados os requisitos de negócios específicos que se aplicam em uma determinada situação.”
É evidente que a Amazon pode fazer muitos deploys por minuto e é capaz de integrar facilmente conformidade e governança em suas tecnologias, mas isso não significa que qualquer empresa pode, ou mesmo que deva fazê-lo, certo? Afinal, as empresas têm um contexto de negócios e tecnologia muito diferentes da escala representada pela Amazon.
É possível simplesmente haver requisitos diferentes – e ainda mais importante, um determinado tipo de software provavelmente terá cadências de deploy diferentes, mesmo dentro da mesma organização.
Esses princípios de flexibilidade e centralização no ser humano se aplicam além da implantação de todos os aspectos da mudança – e, portanto, se aplicam também ao gerenciamento de mudanças e às práticas de lançamento ITIL de forma mais ampla.
Moral da história: às vezes você precisa de um Change Advisory Board, às vezes não; às vezes, verificações de qualidade totalmente automatizadas são suficientes para acender a luz verde na implantação, e às vezes não são – e assim por diante.
E talvez o mais importante, às vezes os humanos devem tomar decisões que envolvem aprovação, e às vezes essas decisões devem ser automatizadas. Quanto mais automatizadas forem essas aprovações, mais rápida será sua implantação. Mas se for possível identificar essas mudanças que requerem aprovação humana e encaminhá-las de acordo, então será possível otimizar como lidamos com as mudanças de uma forma que reúna ao mesmo tempo práticas de DevOps e ITIL.
5 mitos sobre ITIL e DevOps
Existem muitos mitos gerais sobre ITIL e DevOps. Muitas vezes, as empresas falham na execução de projetos, acreditando cegamente nesses mitos. É importante entender o que são esses mitos e por que se provam questionáveis.
ITIL e DevOps são excludentes? ITIL e DevOps geralmente são considerados como alternativas excludentes, o que é um mito – como mostramos neste artigo. Na verdade, eles podem se dar muito bem, pois seus objetivos são totalmente diferentes. As empresas podem realizar o gerenciamento de serviços usando ITIL para otimizar esses processos, enquanto o DevOps impulsiona a entrega de serviços, reunindo equipes e automatizando tarefas de rotina para serem mais ágeis.
DevOps tem tudo a ver com implantação de software. Frequentemente se ouve por aí que o DevOps é “sobre implantação e entrega”. Na verdade, o DevOps é muito mais que isso e cobre aspectos que envolvem colaboração, quebra de silos e transparência. A implantação de software é apenas UM aspecto do DevOps. A abordagem envolve também um treinamento interdisciplinar para que todos tenham uma compreensão básica de cada tarefa.
ITIL é adequado apenas para grandes empresas. É um mito afirmar que o ITIL é complexo e caro para empresas pequenas. As empresas podem implementar ITIL independentemente do tamanho do negócio. O ITIL é flexível em termos de adotar apenas processos adequados específicos. Portanto, comece pequeno e implemente apenas os processos necessários. As PMEs também podem adotar o ITIL de maneira incremental.
DevOps é uma ferramenta de automação. DevOps não é uma ferramenta nem um mecanismo de automação. É uma abordagem que impulsiona a automação, identificando lacunas e promovendo a colaboração entre as funções. Porém, não se trata apenas de automatizar tarefas, mas sim de resolver problemas de TI de forma ampla. O DevOps faz a ponte entre as questões associadas a pessoas e a resolução de inconsistências operacionais.
Implementações ITIL e DevOps requerem muito investimento. Adoção de frameworks como ITIL e metodologia DevOps resultam em otimização de recursos e custos. Quando a ferramenta certa e relevante para o negócio é implementada, a realização do resultado é mais rápida. Além disso, a implementação de ITIL e DevOps não incorre em muitos custos quando os objetivos são entendidos claramente. A adesão do Gerenciamento é importante para obter a alocação do orçamento de TI.
Enquanto o ITIL promove um conjunto de práticas recomendadas para o Gerenciamento de Serviços de TI mais eficaz, o DevOps se alinha aos princípios Lean, como gerenciamento de Work In Progress (WIP), trabalho em lote e agilidade no tempo de resposta. Do ponto de vista do DevOps, o ITIL nada mais é que um conjunto de obstáculos, atrapalhando o caminho das prioridades associadas a integração/entrega contínua (CI/CD).
Fonte: itsm.tools
Enquanto o DevOps deseja acelerar os ciclos de lançamento de software, o gerenciamento de mudanças (associado ao ITIL) geralmente os torna mais lentos. Essa dicotomia significa que as organizações deveriam escolher um OU outro? Ou talvez, quem sabe, seja possível ajustar as abordagens de forma que sejam compatíveis ou mesmo complementares uma com a outra?
O ITIL é parte do problema ou da solução?
Os céticos do ITIL são muitos, e costumam defender que frameworks como o ITIL acabam criando uma ilusão de controle que, em consequência, resulta na ilusão organizacional de que a TI é eficiente e gerenciável. Aparentemente, a criação de silos organizacionais leva a atitudes menos colaborativas.
Um desses silos vem a ser o Change Advisory Board (CAB), composto por uma equipe que tem como responsabilidade tomar decisões positivas ou negativas em várias atividades diferentes em toda a organização de TI. Naturalmente, ter o CAB analisando cada solicitação de mudança torna o processo bastante lento, especialmente quando envolve dezenas de milhares de implantações por hora em algumas organizações.
Case ING
Uma organização que tem lutado para transformar seu processo ITIL à medida que acontece uma mudança gradual para um modelo DevOps, é a empresa de serviços financeiros ING. Lá, as equipes CABs representavam um ponto de contenção. “Éramos uma seguradora, que sempre acabava rejeitando a primeira reclamação”, conta Mark Heistek, especialista em TI. “Para voltar depois, caso houvesse bons argumentos para tanto”. [abaixo o vídeo da palestra dele, em inglês, detalhando o case]
O ING descobriu que era capaz de modificar o ITIL para funcionar dentro de uma nova abordagem DevOps. “Não faça tudo o que o livro ITIL diz”, aconselha Jan-Joost Bouwman, Identity e Access Management Specialist no ING. De acordo com ele, seguir o ITIL para práticas como gerenciamento de incidentes “é ainda a melhor maneira de fazer isso, porque todos sabem o que fazer, sem perigo de haver confusão com as regras.”
Há controvérsias
A abordagem DevOps é inerentemente flexível e orientada por humanos. Afinal, as pessoas ainda criam software – e o DevOps tem mais a ver com encorajar novas maneiras das pessoas cooperarem para atingir um objetivo comum do que com a transferência de tarefas humanas para processos automatizados.
Como resultado, o DevOps não é tão preto-no-branco quanto os maiores entusiastas do assunto podem fazer acreditar. Por exemplo, o “continuous” em CI/CD não significa “o tempo todo” ou mesmo “o mais rápido possível”. Na prática, continuous significa “tão rápido quanto prático, dados os requisitos de negócios específicos que se aplicam em uma determinada situação.”
É evidente que a Amazon pode fazer muitos deploys por minuto e é capaz de integrar facilmente conformidade e governança em suas tecnologias, mas isso não significa que qualquer empresa pode, ou mesmo que deva fazê-lo, certo? Afinal, as empresas têm um contexto de negócios e tecnologia muito diferentes da escala representada pela Amazon.
É possível simplesmente haver requisitos diferentes – e ainda mais importante, um determinado tipo de software provavelmente terá cadências de deploy diferentes, mesmo dentro da mesma organização.
Esses princípios de flexibilidade e centralização no ser humano se aplicam além da implantação de todos os aspectos da mudança – e, portanto, se aplicam também ao gerenciamento de mudanças e às práticas de lançamento ITIL de forma mais ampla.
Moral da história: às vezes você precisa de um Change Advisory Board, às vezes não; às vezes, verificações de qualidade totalmente automatizadas são suficientes para acender a luz verde na implantação, e às vezes não são – e assim por diante.
E talvez o mais importante, às vezes os humanos devem tomar decisões que envolvem aprovação, e às vezes essas decisões devem ser automatizadas. Quanto mais automatizadas forem essas aprovações, mais rápida será sua implantação. Mas se for possível identificar essas mudanças que requerem aprovação humana e encaminhá-las de acordo, então será possível otimizar como lidamos com as mudanças de uma forma que reúna ao mesmo tempo práticas de DevOps e ITIL.
5 mitos sobre ITIL e DevOps
Existem muitos mitos gerais sobre ITIL e DevOps. Muitas vezes, as empresas falham na execução de projetos, acreditando cegamente nesses mitos. É importante entender o que são esses mitos e por que se provam questionáveis.
ITIL e DevOps são excludentes? ITIL e DevOps geralmente são considerados como alternativas excludentes, o que é um mito – como mostramos neste artigo. Na verdade, eles podem se dar muito bem, pois seus objetivos são totalmente diferentes. As empresas podem realizar o gerenciamento de serviços usando ITIL para otimizar esses processos, enquanto o DevOps impulsiona a entrega de serviços, reunindo equipes e automatizando tarefas de rotina para serem mais ágeis.
DevOps tem tudo a ver com implantação de software. Frequentemente se ouve por aí que o DevOps é “sobre implantação e entrega”. Na verdade, o DevOps é muito mais que isso e cobre aspectos que envolvem colaboração, quebra de silos e transparência. A implantação de software é apenas UM aspecto do DevOps. A abordagem envolve também um treinamento interdisciplinar para que todos tenham uma compreensão básica de cada tarefa.
ITIL é adequado apenas para grandes empresas. É um mito afirmar que o ITIL é complexo e caro para empresas pequenas. As empresas podem implementar ITIL independentemente do tamanho do negócio. O ITIL é flexível em termos de adotar apenas processos adequados específicos. Portanto, comece pequeno e implemente apenas os processos necessários. As PMEs também podem adotar o ITIL de maneira incremental.
DevOps é uma ferramenta de automação. DevOps não é uma ferramenta nem um mecanismo de automação. É uma abordagem que impulsiona a automação, identificando lacunas e promovendo a colaboração entre as funções. Porém, não se trata apenas de automatizar tarefas, mas sim de resolver problemas de TI de forma ampla. O DevOps faz a ponte entre as questões associadas a pessoas e a resolução de inconsistências operacionais.
Implementações ITIL e DevOps requerem muito investimento. Adoção de frameworks como ITIL e metodologia DevOps resultam em otimização de recursos e custos. Quando a ferramenta certa e relevante para o negócio é implementada, a realização do resultado é mais rápida. Além disso, a implementação de ITIL e DevOps não incorre em muitos custos quando os objetivos são entendidos claramente. A adesão do Gerenciamento é importante para obter a alocação do orçamento de TI.
