DevOps, moda, realidade ou simplesmente a morte do ITIL?

A opinião de meu xará Robert Stroud sobre a incompatibidade das plataformas ágeis com o ITIL

Yeah!

robert stroudHyperlinkei (criei um novo verbo!) de um artigo a outro dele para conhecer melhor o que meu xará escreve sobre a morte do ITIL. Aliás, todo mundo fala disso (ITIL vai acabar), todo mundo defende a biblioteca, mas pouca gente a usa, hahaa.

O primeiro texto que li foi esse, cujo tí­tulo – traduzido – resolvi adotar para o meu também:

DevOps, fad, reality or simply the death of ITIL

O que meu xará (VP de alguma coisa da Computer Associates) busca explicar é que as plataformas ágeis de desenvolvimento como o Scrum podem gerar quatro ou dez alterações de código e executáveis nos programas POR DIA. E que isso é atualizado direto, sem passar por Changes Requests, comitês de autorização blá-blá-blá como o ITIL recomenda fazer.

Um exemplo que apresentou foi um sujeito ao lado dele, no avião (exagero?), que fuçou num código e foi liberando para uso várias vezes durante o voo.

Cohen, peraí­, o que é DevOps?

Ah, opa, o que é DevOps? É uma junção das palavras Desenvolvimento e Operações. Envolve produzir rapidamente software e liberá-lo. Em especial aplicações nas nuvens e envolvendo mobile. Ele cita noutro artigo que a super Amazon utiliza esse método.

Dá uma olhada no gráfico abaixo que copiei de um site da BMC:

dev-ops b

E o ITIL?

afraid looking businessmanPois é…

Quem trabalha em software-house ou em corporações sabe que o conserto de certos bugs em aplicativos precisa ser pra ontem (aliás, há uma mudança sociológica mudando esse hábito de ontem para ontem ontem, haha).

Sob o nome de bacalhau, solução temporária, gambiarra e até o conserto do próprio executável, o negócio exige celeridade. Rapidez. Diz o sujeito do desenvolvimento que se for explicar e documentar tudo, a coisa será mais comprida que discurso de gago, que vai longe.

E a documentação e o comitê de autorização de mudanças que precisa avaliar, homologar e blá-blá-blá (again) ficaram lá atrás, com caras de guri em cemitério (assustado) por que tudo já foi para produção e  nem ficaram sabendo (já vi em muitos cursos situação em que clientes usam a “nova versão” e o suporte nem sabe das novidades nela, mas precisa “suportá-las”).

No artigo indicado, Robert diz que o ITIL ainda assim sobrevive nesse novo modelo, mas os procedimentos precisam ser automatizados. Hahaha, digo eu. Se nem a gestão de mudanças as empresas conseguem fazer, quanto mais automatizar tais processos.

Meu tocaio (mesma coisa que xará) diz que isso não é pra todo mundo. É ótimo para ambientes nas nuvens (já escrevi isso?), WEB 2.0 e mobilidade.

Segundo artigo

Noutro artigo intitulado Adpotion of DevOps Continues to Accelerate ele realiza algumas complementações. A da Amazon, por exemplo. Legal dar “nomes aos bois”, pois não fica algo genérico. Cita que os ajustes são contí­nuos e pequenos, dando chance de refazer caso necessário.

Já imaginaram um comitê de avaliação julgando trocentas coisas por dia? Se você convive com tal situação, convém continuar lendo os textos do Robert (nice name).

Abrazon e me vou hoje a Gramado aproveitar uma oferta do Booking (minha esposa é craque nesse assunto de barbadas hoteleiras).

Smack

EL Co

URGENTE – do curso em São Paulo

Não venham com choradeiras depois de vencido o prazo de inscrição com  “- Quando vai ter novo curso…?”.

Se agilize, bata pé com o financeiro, chore parcelamento com o 4HD, explique ao gestor que sua capacitação trará melhoria de produtividade e, principalmente, MAIS DINHEIRO para a empresa. Eu não sou mágico, mas posso lhe ajudar nisso, sim.

www.4hd.com.br/calendario

10 comentários em “DevOps, moda, realidade ou simplesmente a morte do ITIL?”

  1. Ok, El Cohen, muito boa noite!

    Entendi nesses artigos que o que pode fazer o ITIL morrer é a urgência das empresas em fazer com que os sistemas (e as mudanças) atendam rapidamente ao negócio. Percebi também que um dos principais motivos que levam a essa morte seria não cumprir um dos processo do ITIL (Gestão de Mudanças).

    Também já passei por isso e o que fizemos para contornar essa “morte prematura” do ITIL que teríamos em nossa empresa foi criar conceitos de “pré-aprovações” para determinadas mudanças e atendimentos dentro do Service Desk.

    Isso trouxe agilidade e confiança nas mudanças e um atendimento melhor às áreas de Negócio. Atualmente as pessoas continuam seguindo os Processos do ITIL, pois conseguiram visualizar nessa maneira de trabalhar que eles são importantes para a manter o negócio em funcionamento.

  2. Salve, Jeferson.

    Então: a ideia do autor é que algumas coisas sejam pré-aprovadas mesmo. Ou automatizadas ao máximo, de maneira que uma mudança seja feita e PLOP, surgir na tela do gestor de mudanças para autorização e a coisa ser rapidinha.

    Claro que as plataformas ágeis de desenvolvimento também possui sua organização. Quero destacar isso para não acharem que é gandaia geral, mas…

    O exemplo do autor é bom: um técnico liberou oito vezes um executável durante um voo. Vão surgir extensas áreas cinzas (nem branco, nem preto) nessa situação que proporcionarão muita incomodação pro gestor de mudanças, liberações e todo o time atual que busca se organizar com o ITIL.

    Abrazon

    EL CO

  3. Fabio Luis Griebner

    Apenas para contribuir com o assunto, vale lembrar que o ITIL quando fala em gerência de mudança prevê a existência de mudanças que seguem o fluxo normal, são planejadas e aprovadas, mas também prevê a existência de mudanças emergenciais, com aprovação mais ágil e mudanças padrão, que são pré-aprovadas, por serem de rotina.

    A existência de um processo formal de mudança, mesmo nos casos de uma emergencial (mais adequada ao caso em questão) minimiza a possibilidade de erros (leia-se cagadas) do programador que na pressa de corrigir algo acaba causando outros estragos até maiores. O fato de ter que pedir uma aprovação para colocar a correção em produção, mesmo que rápida, faz o camarada pensar e principalmente testar melhor a correção que está liberando, pois se tiver que pedir autorização no momento seguinte vai ficar mal na foto!!!

  4. Fabio,

    Compreendo a questão de mudanças pré-aprovadas (troca de mouse, blá-blá-blá).

    A questão é uma pendência (eterna, aliás) entre a demanda (acelerada) do negócio e a responsabilidade da infraestrutura de segurar tudo isso funcionando. Quando o código gera bug, o cara corrige e submete novamente. E de novo. E de novo.

    O que o autor quis expressar – na minha opinião – é que nessa gangorra DevOps x Infra, tá pendendo pro lado do DevOps, hehe.

    Abração, bro!

    EL Co

  5. boa tarde Cohen
    Acredito que ha que ter alguns cuidados ao misturar assuntos: Gerenciamento de Mudanças não todo oo que compõe o ITIL, e métodos ágeis também não substituem todas as práticas do ciclo de vida do serviço, alias, as práticas de desenvolvimento estão fora do ITIL: elas não fazem parte dos processos, mas deveriam “encaixar” entre Desenho e Transição para conseguir uma vez feitas as alterações no código, realizar os testes necessários para controlar impactos em produção. Incluir práticas ágeis ao próprio ciclo de vida do serviço, não é algo que esteja fora do ITIL, como bem foi colocado nos comentários. Uma questão que parece mais sintomatica no carinha do voo, o pq fez tantas mudanças em tão pouco tempo?, ha algum sintoma de “tentativa e erros”, ou seja, zero planejamento. Nem SCRUM permite Sprint de tão curto tempo. XP conseguiria fazer isso, só se tiver testes automatizados. Bom, em fim, outra coisa que me chamou a atenção é esse comentário de “todos falam da morte do ITIL”, gostaria de saber mais sob a doença que ele tinha antes de morrer… alguem pode comentar?
    abração
    Heinz

  6. Hahahaha…

    Heinz, eu importei a polêmica do autor.
    Ela não é minha, mas se usei, é por que – no mínimo – meio que corroboro, nem que seja para estender a mesma.

    Back to matter: eu acho que as empresas têm dificuldades em implementar a maioria das metodologias. Eu não estou falando de corporações, mas de empresas normais.

    O cotidiano pressiona, ele muda a toda hora – quarta-feira o mundo caiu em Porto Alegre. Sabe-se lá quantas coisas em termos de planejamento foram pro saco? E please, não seja mansuriano ao dizer que isso “também deveria estar planejado”, por que desse jeito viver-se-á apenas planejando.

    Missão crítica é f… Pra ter uma ideia, seis bombas d’água pararam por falta de energia. Imagina o reflexo do “caos” no resto do mundo.

    Não estou desprezando o planejamento, mas achando que sistemas complexos não podem ser “muito” planejados. Há uma enormidade de variáveis que não conseguimos controlar para adotar um jeito “hermético” desejado pelo ITIL. Esse hermético é um “deboche” meu, coisas de sexta-feira. Claro, cada um adota como quiser, com mais ou menos flexibilidade.

    Eu só quero provocar a tribo para pensarem que “flexibilidade” e “processos muito organizados” vivem, cada um, na ponta da gangorra.

    Abrazon e bebe uma por mim hoje 😉

    EL CO

  7. Boa noite!

    Apenas lembrando, os processos do ITIL devem ser adaptados ao ser implantados. As boas práticas nos dão uma trilha para onde ir. Portanto, a flexibilidade deve existir e poderá ser diferente de empresa para empresa. Correto?
    Jeferson

  8. Jeferson,

    A dificuldade é sempre definir até onde estamos realmente fazendo uma “adaptação”. Tipo, uma hora pode, noutra não.

    Seria isso uma adaptação ou um afrouxamento das recomendações?

    Abrazon

    EL Co

  9. Fala mestre,

    Muito tempo já que li esse artigo. Sou fã das recomendações do ITIL, e também sou fã do movimento DevOps. Entendo as constantes análises que partem do princípio de incompatibilidade entre estas duas idéias.

    Interessante o seu ponto. Foi um dos mais lúcidos que vi sobre o tema. Todo o resto do pessoal que fala por aí, não sabe muito bem o que está falando nem de um nem outro (ITIL/DevOps).

    Porém, quanto mais eu estudo DevOps, mais eu discordo do ponto central que é a inabilidade de convivência dos dois. Quem não conseguirá conviver com o DevOps será o cara da Gestão de Mudança/Implantação/Configuração que trabalha num modelo arcaico e não passa de um burocrata. Não entende do negócio, não é técnico suficiente para avaliar os reais impactos de uma implantação/mudança, e por isso vive do mantra “documentado, testado, protocolado, etc” (praticamente Plunct, Plact, Zum!).

    O DevOps, na verdade, é uma forma de praticar um conceito que já existe no ITIL, o Release Engineering (http://en.wikipedia.org/wiki/Release_engineering) que nada mais é do que a prática da Gestão de Mudança/Configuração/Implantação. É claro, no DevOps o jeito que isso é feito muda. Tem que ser dinâmico, eficiente, e fazer sentido pro negócio. Hoje em dia, certas áreas do ITIL em grandes corporações são usadas pra se proteger da incompetência e da falta de gestão das camadas superiores. Na minha opinião, isso vai morrer.

    Veja o caso do Facebook: http://devops.com/2012/11/08/release-engineering-at-facebook/ . Existe uma gestão de implantação misturada a gestão de configuração extremamente técnica e participativa. Lá, o cara da Gestão de Mudanças não fica num esperando que os outros implorem pra colocar as coisas em produção. Ele faz parte do negócio, e ele faz o negócio acontecer.

    Bom, são meus 2 centavos. Eu poderia discursar sobre as virtudes do ITIL e do DevOps por um dia inteiro, sem me cansar.

    Até mais.

    PS: quando vier no Rio, vamos marcar um almoço! 😀

  10. Você é o cara, hein, big man!!!

    Muito legal o link indicado (facebook) e sua participação.

    Acho que o maior problema é ipsis literris que *ode a vida aqui com ITIL x DevOps, na religião ou qualquer outro lugar. Tornam-se incompatíveis com o mundo moderno, considerando que foram coisas escritas no passado (há 2.000 ou meio ano atrás).

    Topo o rango!

    EL Co

Deixe um comentário

O seu endereço de e-mail não será publicado.