DevOps e Controle de Alterações

Como ter e alcançar o equilibrio em um mundo que exige entrega contínua ?

As organizações lutam para obter e implementar as metodologias de DevOps porque as partes interessadas de segurança, conformidade e auditoria (interna e externa) acreditam que os requisitos de controle de mudanças não podem ser atendidos.

Essas partes interessadas geralmente tendem a interromper a adoção do DevOps antes que uma organização possa explorar seu potencial de implementação.

A intenção de um processo rigoroso de controle de mudanças é reduzir o risco de implementação de mudanças que podem levar ao aumento de falhas operacionais, transação deficiente de processamento e falta de confiabilidade do sistema. A preocupação de auditoria mais comum sobre DevOps é que os desenvolvedores podem implantar seu próprio código sem qualquer processo formal de aprovação de mudanças.

Uma abordagem de auditoria de DevOps descreve a perspectiva do auditor desta maneira: A ausência de controles de aprovação de alteração cria o risco de introdução de código não testado e não autorizado na produção. Simples assim.

As pequenas empresas podem ser bem-sucedidas na implementação de um processo enxuto de aprovação de mudanças que lhes permita fazer implementações frequentes.

Como essas empresas normalmente têm um pequeno espaço ocupado no data center, aplicativos limitados e equipes de pequeno porte, há uma probabilidade maior de que problemas sejam detectados por meio de seu processo de aprovação de mudança. Em uma empresa de médio a grande porte, a probabilidade de detectar um problema é potencialmente reduzida devido ao volume, complexidade e tamanhos de equipe maiores. Empresas que decidem migrar para um modelo de DevOps acham difícil a transição, pois processos manuais tornam-se bloqueadores para taxas de mudança rápidas.

Olhando de perto, descobrimos que, ao contrário da percepção geral, as práticas de DevOps oferecem melhor gerenciamento de riscos e facilitam o processo de controle de mudanças.

Tamanho de processos menores são entregues com mais rapidez e frequência É bem conhecido que o risco é maior para grandes mudanças de quantidade. Sabe-se também que atrasos na entrega de mudanças envolvem riscos mais altos e custos mais altos. Mudanças que têm riscos menores passam por um processo de controle de mudanças mais enxuto.

Um grande e unico conjunto em quantidade de alterações de uma só vez ,geralmente é estressante devido a também muitas incógnitas e dependências. Geralmente envolve muito planejamento, processos gerais de despesas não previstas, e consequentemente, as equipes de TI associam gastos noturnos em relação à “liberação de produção”.

Também envolve um plano detalhado de “reversão” que é igualmente complicado.

É exatamente aí que as práticas de DevOps ganham. As práticas de DevOps permitem que as equipes forneçam conjuntos de mudanças menores à produção com mais freqüência, com menos riscos e menos sobrecargas no processo de controle de alterações.

Se a entrega da mudança for mais frequente, ela terá melhor repetibilidade e tornará todos os envolvidos mais confiantes sobre o processo.

O controle de mudança emergêncial não pode ser uma norma!. 

Um padrão interessante e frequentemente observado em quase todas as organizações de TI. Enquanto o processo de liberação normal tem processo de controle de mudança manual complexo, mudanças de emergência passam mais rápido. Na verdade, os controles para mudanças de emergência são projetados como práticos, e estão em conformidade com os requisitos de auditoria e normas regulamentares.

A ideia aqui não é literalmente fazer de cada mudança uma mudança de emergência, mas provar que uma pequena quantidade de mudanças pode ter um processo enxuto de controle de mudanças e ser compatível ao mesmo tempo.

Controle automatizado de mudanças

O controle de mudanças tradicional requer aprovações e verificações manuais. Muitas destas verificações manuais podem ser alcançadas de forma programática e segura
incorporando lógica de negócios, limites pré-definidos e controles automatizados em todo o pipeline de entrega.

Como exemplos, as aprovações podem exigir: análise e verificação de código estático de prova de conjuntos de mudanças; prova de regressão bem-sucedida, carga e teste de desempenho; prova de verificação de segurança e testes de teste de toda a pilha, etc. Quase todos estes podem ser automatizados em muitos níveis diferentes, dependendo da adoção de DevOps.

A incorporação dessas aprovações de maneira automatizada permite a implantação contínua, que é um benefício fundamental do modelo DevOps. Além do que, risco é bem gerenciado neste modelo como a automação do gerenciamento de mudanças que incorpora todas as verificações de segurança e auditoria que uma aprovação de mudança formal do processo fornece.

Existem vantagens comerciais e operacionais significativas e comprovadas para implementar o DevOps. As organizações devem explorar a transformação e não permitir
preocupações antiquadas de segurança e auditoria para interromper o progresso.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

This site uses Akismet to reduce spam. Learn how your comment data is processed.