A metáfora da troca de pneus com o carro em movimento, se apresenta interessante para podermos pensar em um dos objetivos do DevOps. Em um cenário de alta disponibilidade, onde precisamos aplicar Mudanças sem interrupções, sem paradas ou evitando indisponibilidade programadas, é necessário se utilizar de técnicas que permitam avançar de maneira transparente aos usuários, com a implantação das mudanças em forma segura.
Uma condição fundamental é que além de toda a automação necessária para reduzir os tempos entre uma versão que está sendo usada e uma outra que a substitui, é que a nova versão seja o suficientemente estável para assumir sua posição em produção.
Sabemos que essa substituição é planejada de tal maneira que os riscos sejam controlados. Se por um lado o tamanho da mudança é grande, ou seja há um conjunto grande de funcionalidades que serão afetadas ou evoluídas, os riscos também são maiores. Neste quesito estamos tentando disponibilizar pedaços pequenos e em forma frequente, que permitam uma transição simples, rápida e quase silenciosa. Mas sabemos que não é sempre que podemos fazer isto.
A condição “suficientemente estável” mencionada anteriormente, significa que a nova versão foi testadas exaustivamente ao ponto de reduzir ao máximo a possibilidade de apresentar erros. Se por acaso, o corredor que assumiu o bastão cair, neste nosso caso, o atleta anterior deve continuar a assumir a corrida, ou seja, devemos ser capazes de voltar ao cenário anterior rapidamente.
Na metáfora do carro em andamento, estamos sempre prontos para reassumir a condição anterior em forma imediata. Aqui ha um momento de instabilidade que em DevOps é gerenciado através da Mudança, seja usando técnicas como implantação Canário ou desdobramento Verde-Azul. Sempre teremos a versão que está sendo substituída (a Verde por exemplo) em evidencia para poder assumir caso algo dê errado. É uma grande rede que sustentará o atleta para não cair no chão.
Mas o que muda da maneira de fazer software ou aplicar um mudança, nos métodos convencionais?
Isto nos leva a pensar o extremo e adequação do uso das práticas ágeis, como por exemplo:
- priorização dos requisitos ou histórias, com o estabelecimento de micro historias, elementos significativos, o mais independentes possíveis que sustentam uma parte do software de forma significativa, que entreguem valor aos usuários, cliente e negócio;
- modelagem e estruturação de soluções, que permitam avançar em versões incrementais, versionadas e integradas ao ponto de permitir evolução constante;
- construção de arquiteturas dinâmicas e flexíveis, de modo a suportar um estrutura limpa, refatorada, testada, em forma ágil;
- desenvolvimento de software, usando técnicas direcionadas a aspectos, orientada a testes com a implementação de práticas de integração continua, usando praticas Lean, evitando retrabalho, estocagem de código, divida técnica e simplicidade,
- técnicas de gerenciamento ágeis disciplinadas, que se responsabilizem por suas entregas com alta qualidade, focadas em resultados;
- testes integrados, com a automação de testes unitários, integrados, de aceitação, de estresse, de volumetria, etc;
- implementação de fluxos ou pipeline de implantação contínuos, focados em práticas de controle de versão, integração continua, entrega continua, orquestração de múltiplas equipes e componentes, sincronia de práticas sensivelmente para sustentar este pipeline sem erros;
- cultura orientada ao aprendizado e melhoria continua, que foque em implementar melhorias a cada descoberta de erros e focar em soluções e causa raiz ao invés de culpados e punições;
- alto grau de integração entre as equipes e especialistas com um sentido claro de propriedade, unificando objetivos e metas, nos resultados de valor ao negocio;
- técnicas de Liberação e Implantação Continua, como por exemplo, implantação Canário e desdobramento Verde-Azul, que focam com a sustentação paralela de versões evolutivas com transições controladas de públicos alvo de usuários;
- técnicas de rollback tanto com a construção de scripts de versionamentos em códigos de softwares como técnicas evolutivas de estruturas de banco de dados dinâmicos, tanto para a ida a uma verão avançada como a uma anterior;
- alto grau de automação para a implementação controlada ao ponto de minimizar riscos e lidar com a complexidade dos diferentes componentes e práticas, processos, papeis e responsabilidades;
- uso de praticas de Continuidade de Serviços, para sustentar o negocio de maneira formal, com os Requisitos de Nível de Serviços adequados.
Desafios DevOps
https://www.linkedin.com/pulse/como-trocar-o-pneu-com-carro-em-andamento-desafios-heinz-dieter
Desafios DevOps Desafios DevOps
Meu nome é Heinz Nevermann, ministro aulas de DevOps Master. O objetivo destes posts é sensibilizar as praticas de TI para a entrega de valor ao negócio, dentro de um contexto de novas tecnologias e práticas que nos mobilizam a um aprendizado continuo para melhorar nosso trabalho profissional. Dentre os propósitos é provocar discussão e conhecimento, que naturalmente acontece nos nossos cursos de preparação para a certificação DevOps Master que regulamente ministramos tanto OnLine como presencialmente. Mais informações: heinz@hnz.com.br.
Deixe sua opinião, seus comentários, seus contatos. Caso tenha gostado, curta e compartilhe. Vamos criar um comunidade para nos aperfeiçoar como profissionais e melhorar nossas atividades.
