README
Esse artigo é uma adaptação de uma palestra, oriunda do conjunto de duas palestras chamada "DevOps Deep Dive". Por esse motivo, o texto pode parecer um pouco subjetivo, mas na verdade ele deixa o espaço para que você reflita e faça suas contribuições no momento em que for apresentá-lo, colocando um pouco das suas experiências e perspectivas em cada tópico.
São duas apresentações que tratam sobre os conceitos e pilares da cultura de DevOps e como ela acontece no dia-a-dia. São as apresentações:
1. O que é a cultura DevOps (este artigo);
2. DevOps na prática.
Apresentação: O que é a cultura DevOps
Definição
O termo DevOps já tem mais de dez anos. Ele foi utilizada pela primeira vez em uma palestra sobre desempenho Web e operações (na Velocity da O'Reilly) ao se demonstrar como era possível entregar valor 10 vezes ao dia para os clientes sem que esse processo fosse instável e burocrático. Há mais de 10 anos, e acredito que até hoje, há um conflito de interesses entre essas duas áreas em algum nível. Por um lado, temos um time muito mais próximo do processo de tomada de decisão, dando forma às necessidades do negócio; enquanto do outro há um time mais voltado para a manutenção e o suporte da plataforma onde o negócio funciona.
Preciso abrir um parenteses para dizer que ambos os times são igualmente importantes para o funcionamento do negócio e que um depende do outro para sobreviver, como veremos mais adiante. Mas pelo fato de que ambos tem papéis e estão em pontos diferentes da esteira de entrega de valor, o time de desenvolvimento tem um papel bem mais influente. Se pararmos para pensar um pouco, veremos que o processo de entrega de valor acontece majoritariamente desta forma: a estratégia da empresa define as prioridades (C-level), o time de produtos verifica as prioridades e o que precisa ser feito, o time de desenvolvimento faz o que precisa ser feito (o valor é gerado aqui), o time de testes valida e o time de operações se encarrega de refletir o valor para o ambiente produtivo e garantir que o valor está sendo entregue. Verifica-se que o time de desenvolvimento diz o que é tecnicamente viável enquanto o time de operações apenas aplica o que foi feito.
Desta forma, fica claro que o maior do desejo do time de desenvolvimento é ver suas funcionalidades refletidas o mais rápido possível no ambiente, enquanto o do time de operações é ver o ambiente estável. Porém, as novas mudanças podem trazer instabilidade e, por isso, o processo de transição pode ser demorado.
Esse tipo de pensamento tradicional torna o relacionamento entre os dois setores um pouco tempestuoso. Se quisermos mudar essa realidade, precisamos fazer com que ambos se entendam. Ou seja, precisamos que a operação pense um pouco mais como desenvolvimento e vice-versa. Assim como no universo do desenvolvimento, todas as metodologias atuais apontam para as mudanças rápidas, a uma boa dinâmica de codificação, testes e lançamento do software; o time de operações também precisa se adequar a essa mentalidade.
Vivemos em um mundo em que a mudança é constante e o alinhamento com as necessidades do mercado, e principalmente dos clientes, é vital para o máximo ganho e o menor prejuízo. Cem porcento de todas as pessoas de um empresa sabem como certos contextos estão no limiar entre uma grande oportunidade e um abismo de prejuízo. Porém, se quisermos continuar relevantes, precisamos estar sempre alinhados com o que os nossos clientes precisam. Só assim as empresas sobrevivem.
Como eu faço para que o time de operações se alinhe com as necessidades do seu cliente "a empresa"? Pegando algumas metodologias ágeis (que fizeram isso muito bem) e olhando para as melhores práticas de operação a partir dessas lentes. Em suma: cultura e ferramentas.
Pilares
O nível estratégico sabe melhor do que todos que para alcançar os objetivo de uma empresa/projeto precisamos que todos os elementos dela apontem em direção ao alvo. Se queremos implantar a cultura DevOps de maneira assertiva, precisamos que os processos, investimentos e decisões se baseiem nos seguintes elementos norteadores:
- Cultura de colaboração e bom relacionamento entre times;
- Automação para eliminar o máximo de trabalho repetitivo e manual (automatizar é a arte de fazer em seis horas algo que levaria seis minutos mas que depois disso não vai mais precisar ser feito em seis e sim em um minuto);
- Medição é a base do processo de melhoria contínua, se não aferirmos o que fazemos, ficamos às cegas durante as tomadas de decisão.
- Compartilhamento e experimentação. Ou seja, incentivo a inovação e ao aprendizado. Errar faz parte do processo de aprender qualquer coisa.
Em termos práticos, esses pilares afetam diretamente o relacionamento entre times de desenvolvimento e operações. Mas se pensarmos na cultura de uma empresa como um todo, podemos ver que esses pilares facilmente se encaixam em quase toda empresa. Com efeito, sabemos que a colaboração e o bom relacionamento são cruciais para termos um ambiente de trabalho sadio e produtivo. Já a automação é a chave para desburocratização e aumenta não só o valor da empresa, que terá processos mais eficientes, mas também o valor do funcionário, que terá desafios mais complexos e menos repetitivos. Além disso, é inegável que a medição e o processo de melhoria contínua são indissociáveis. Pois se não é possível medir, é impossível de se melhorar; e não sabemos melhorar o que não se mede. Por fim, o compartilhamento e a experimentação fazem parte da industria 4.0. Compartilhamos informações, experiências, erros e acertos; damos oportunidade a novos conceitos e métodos e não esquecemos de fazer isso seguindo os passos anteriores: colaboração, automatização, medição, compartilhamento.
Vantagens
Quanto temos uma boa implementação do DevOps, conseguimos ver claramente o nosso progresso pela aferição de alguns objetivos. São eles:
- Melhorar a frequência de implantações: isso significa implantar quanto for necessário por mês, semana ou dia;
- Automatizar processos: ferramentas em prol da redução de trabalhos repetitivos;
- Diminuir a ocorrência de erros em novas versões: integração e testes contínuos;
- Encurtar períodos de tempo para mudanças e melhorias: alinhamento com a cultura ágil (não é para tanto que hoje a cultura DevOps está debaixo do guarda-chuva ágil);
- Recuperação rápida em casos de falhas no ambiente: boas práticas de operações;
- Padronização nos processos de configuração e servidores: alinhamento com governança, automações e agilidade.
Se observarmos com atenção, veremos que todos os níveis da organização gozam dos benefícios de uma implantação da Cultura DevOps. Visto que, para a operação, isso significa entregar exatamente o que o negócio precisa com estabilidade; para o time de desenvolvimento o mais importante é a agilidade na entrega das suas soluções; para o gestor do produto é a garantia da entrega de valor; e para o time estratégico é escalabilidade, eficiência, cliente satisfeito, competitividade e relevância.
Ciclo de Desenvolvimento
O que muda na forma como entregamos valor quando seguimos a esteira DevOps de desenvolvimento? Você pode pensar: "Lá no meu setor nós meio que já fazemos essas coisas" ou "Isso não parece estar tão distante da minha realidade", o que já é excelente. Mas se desejamos usufruir de todas as vantagens no nosso processo de entrega de valor, precisamos que todo os envolvidos estejam alinhados com as melhores práticas da cultura DevOps.
Vale ressaltar de ante-mão que estamos falando de um ciclo contínuo, bem definido, ainda assim flexível, escalável e independente. Ou seja, quando pensamos em todos os elementos na imagem acima, devemos entender que todas essas etapas acontecem de forma independente em diferentes setores. Dando um exemplo prático: enquanto um está codificando uma nova funcionalidade, outro está esperando os testes do código finalizarem; entregáveis estão sendo transicionados de ambientes de teste para produção automaticamente; enquanto isso os dados de desempenho da última entrega já estão sendo gerados, e os problemas críticos já estão sendo triados para que ações rápidas sejam tomadas; ao mesmo tempo outras melhorias estão sendo planejadas, fundamentadas em dados concretos e nas necessidades do negócio.
Há ainda um tópico que eu gostaria de mencionar, que é a abertura para falhas. Entendo que em certos contextos é difícil manter essa proposta, mas acredito que ela é capaz de fazer seu projeto progredir com segurança. Quando não absorvemos esse tipo de cultura para a nossa organização, ou ciclo de desenvolvimento, estamos limitando o aprendizado, aumentando a insatisfação das equipes, aumentando os níveis de estresse por medo de errar, diminuímos a qualidade do software, aumentamos a resistência a mudanças e favorecemos a ocultação de problemas. Porém, não podemos ser desleixados. Existe uma frase do Eric Ries, autor do livro "The Lean Startup", que diz: "você precisa errar fácil, erra rápido e errar barato".
Então, como lidamos com essa cultura no dia-a-dia: colocando cada uma das etapas em cima dos pilares. É difícil falar de uma sem mencionar a outra.
O planejamento é posterior ao monitoramento e anterior à codificação. Isso implica dizer que os processos que tangem ao planejamento terão influência dos nossos resultados anteriores, isto é, feedback. Com efeito, paramos de apenas receber os pedidos de desejo de modificações e novas funcionalidades, e passamos a nos aprimorar por nós mesmos. Esse tipo de prática é a base da melhoria contínua. O que significa ocupar em torno de 20% do esforço para a reduzir débitos técnicos e corrigir bugs. Se ocuparmos 20% do nosso esforço na sprint para essas atividades, dificilmente precisaremos de força-tarefas para aplicação de melhoria ou correções críticas, sem contar que não teríamos a necessidade de reescrever funcionalidades inteiras por ela ter muitos bugs, ou ser ineficiente ou não ter documentação.
Do que é referente ao processo de planejamento, eu não tenho autoridade para falar quais as melhores metodologias ágeis para tal, mas em termos culturais precisamos que as decisões sejam tomadas com, ao menos, o conhecimento de todos os envolvidos, ou seja: desenvolvimento e operações. Em linhas de desenvolvimento, a arquitetura da solução e os elementos necessários para tal precisam ser tecnicamente viáveis, e os prazos e esforços precisam ser alinhados. Em linhas de operações, precisa-se garantir que os recursos necessários estarão disponíveis e são capazes de atender à necessidade da solução, contando ainda com o alinhamento do time de finops e o financeiro. Sabendo de tais coisas, fica assim comprovada a necessidade do envolvimento de ambos os times no processo de planejamento das soluções.
Além disso, no que tange a etapa anterior (de monitoramento), é essencial que possamos medir os diferentes aspectos das soluções que estão sendo planejadas. Desta forma, saberemos se o que foi entregue passou por toda a esteira de maneira eficaz, se as expectativas do cliente foram atendidas, se algo foi executado errado, se o que estava planejado e os gastos esperados condizem com a realidade (para mais ou para menos), entre outros. Neste ponto, cada um dos times vai saber quais as métricas mais importantes para os relatórios de cada um, e é importante que todos saibam quais são: 1) para que as ações necessárias para tais sejam tomadas, seja de desenvolvimento, operações, financeiro, etc; 2) para que seja evitado retrabalho e falta de entendimento das necessidades de cada setor; 3) para que todos tenham suas necessidades atendidas e consigam realizar um bom trabalho.
Na codificação, realizamos aquilo que foi previamente combinado e definido no planejamento. Aqui devemos pensar em ferramentas que nos auxiliem durante o trabalho de codificar, indo desde a máquina de trabalho até inteligências artificias. Quando o time se comunica e troca suas experiências sobre a forma como cada um aborda os problemas diários, conseguimos identificar e definir padrões, mas também sabemos até que ponto fazer isso. Se desejamos remover impedimentos e agilizar o processo de desenvolvimento, precisamos que a máquina, o SO, a IDE, as ferramentas de análise, bibliotecas e o gerenciador de pacotes se adequem ao programador sem que a conformidade e as necessidades do negócio sejam desprioradas. Neste ponto, vemos que os pilares de compartilhamento e experimentação são relevantes.
Ademais, durante a elaboração da solução, devemos usar uma abordagem que favoreça a reutilização e o automação. Como dito anteriormente, o DevOps é totalmente compatível com o ágil e com as melhores práticas de programação. Então não haverá conflitos de interesses aqui no tocante a cultura, pelo contrário, haverá um incentivo para tal. Com a implementação da integração contínua, os testes e as validações serão feitos precocemente na evolução da solução. Desta forma, garantimos que as novas linhas sejam compatíveis com o código atual e não apresentem um comportamento inesperado. Algumas metodologias vão tirar mais vantagem do continuos integration (CI), como é o caso do Desenvolvimento guiado a testes (TDD) e do Desenvolvimento guiado a comportamento (BDD).
Não podemos apenas valorizar as ferramentas e as técnicas nesse etapa. Esse tipo de pensamento é tentador, mas podemos cair na armadilha de estar sempre procurando por coisas mais sofisticadas e automatizadas, e não valorizar aquilo é fundamental: a colaboração e o bom relacionamento. O que significa dizer que apesar de haverem boas ferramentas, por vezes não temos o capital financeiro para as implementar. Nesse contexto, a colaboração e ajuda dos colegas do time é essencial. Cada um divide a sua experiência e faz a sua contribuição, e fazendo isso, cada um aprende e reforça os próprios conhecimentos. Uma equipe que não faz esse exercício de compartilhamento, não teve toda a sua potencialidade explorada ainda.
Agora, eu falarei de dois elementos que não há consenso sobre a ordem de execução deles, eu particularmente não vejo diferença, mas ambos precisam existir e estar ligados. Estou falando dos testes e o build. De toda forma, ambas podem ocorrer de forma simultânea e automática. Vou me deter, a princípio, na etapa de testes:
Os testes são cruciais quando se deseja produzir software com excelência. Nesta etapa, o time de desenvolvimento e o time de qualidade de código trabalham mais próximos para que haja diversos tipos de coberturas de testes. Um QA saberia falar melhor do que eu sobre todos os aspectos desse etapa, mas o que eu gostaria de frisar é a automação. Creio que essa seja uma das maiores necessidades dos testadores. Podemos integrar testes ao processo de CI e fazer os testes mais fundamentais, como também os unitários, funcionais e build. Ainda podemos integrar testes de carga, estresse e caixa branca ao pipeline, sem contar os de segurança.
Existe uma gama muito grande de testes que podem ser integrados ao pipeline de integração. Acerca disso, é necessário que haja um diálogo aberto entre o time de desenvolvimento, testes, operações e financeiro. Visto que quanto maior a bateria de testes, maiores serão os critérios de avaliação, maior será a quantidade de relatórios para avaliar, podem haver maiores custos com ambientes e ferramentas de teste, entre outros. O importante é que os testes atendam a necessidade do negócio, estejam disponíveis sempre que necessários e possam agregar valor.
Outro aspecto relevante dos testes é a presença de múltiplos ambientes. Quando trabalhamos desta forma, conseguimos níveis de capacidade e disponibilidade diferentes por ambiente. Deveríamos ter tantos ambientes quanto o necessário para evitar que o máximo de instabilidade seja transmitido de um para outro. O ambiente de produção deve ser o mais robusto possível, dentro dos requisitos e limitações da organização. Já o ambiente de homologação é considerado essencial para testes com o cliente e testes fim-a-fim, ele deve ser o mais semelhante do ambiente produtivo possível. Há ainda literaturas que tratam de ambiente de QA, desenvolvimento e teste. Os ambientes de desenvolvimento e testes se aproximam mais da abordagem gitflow de versionamento de código, onde o ambiente de desenvolvimento tem o software que será lançado ao fim da sprint; e nos ambientes de testes temos o código das branchs de feature e hotfix, em que a segregação é feita por funcionalidade. Em qualquer abordagem que seja, a automação é vital para o gerenciamento eficiente de múltiplos ambientes, porque o pipeline precisa ser inteligente para entender para qual ambiente o código integrado deve ir e a infra precisa estar automatizada/codificada para atender as necessidades do negócio sob demanda.
O build, ou empacotamento, é a etapa de construção do entregável. Isso pode ser um pacote de aplicação, um módulo, um zip ou uma imagem de contêiner. Só é possível automatizar um processo quando ele está bem definido. Por isso é mister que a construção da entrega passe pelas mãos tanto do time de desenvolvimento como da operação. Porque o desenvolvedor, o criador, deve saber exatamente que parâmetros passar, que passos realizar para a execução da funcionalidade, quais os cenários de falha esperados, quais os elementos críticos do novo fluxo, entre outros. E o time de operações precisa saber onde colocar os parâmetros, quais a melhores práticas de segurança para a plataforma onde roda a automação, quais métricas devem ser coletadas, como implantar e fazer rollback, entre outros. Ratifico que, essa etapa exige que operações e desenvolvimento trabalhem juntos, para que todos os requisitos sejam repassados para a construção e implantação da solução. Digo isso porque é neste momento em que ocorre a maior parte dos desentendimentos. Pela falta de comunicação e bom relacionamento entre as equipes, o processo de atualização é conturbado. Quando o objetivo dos times é o mesmo, todas as necessidades do outro time, são nossas também. Por muitas vezes, a necessidade do time de desenvolvimento é de informações para throubleshooting, ou comunicação sobre os problemas, ou relatórios de erros e desempenho, entre outros. Em contrapartida, o time de operações precisa saber como lidar com erros, quais erros são críticos ou não, como garantir o SLA, entre outros.
Não podemos esquecer de testar o entregável antes de aplicá-lo. Lembra que eu mencionei anteriormente que não há um consenso sobre qual vem primeiro: Build ou Testes? Então, isso não faz diferença na esteira DevOps, mas está diretamente ligado aos critérios de aceite da demanda, empresa ou cliente. Há alguns testes que só são possíveis de se acontecer com o entregável pronto, como os testes fim-a-fim, testes de aceitação, teste de carga, entre outros. O objetivo dos testes é, assim como em outros momentos, garantir que o comportamento da funcionalidade, adicionada ou modificada, esteja dentro do esperado. Dos testes que comumente são realizados nessa etapa, o teste de usuário é um dos mais importantes.
Por vezes, precisamos verificar o comportamento da aplicação em ambiente produtivo e, para tal, utilizamos da implantação automatizada para nos auxiliar.
Quando falamos de implantação, não podemos deixar de mencionar a entrega. A etapa de release, ou entrega contínua, é responsável por gerenciar as entregas das novas funcionalidades, versionar os pacotes de implantação e documentar as alterações feitas. Entregar software pode ser um trabalho complicado quando não temos a metodologia e a cultura certa. Antigamente, os times de desenvolvimento e operações trocavam muitas farpas durante a entrega da aplicação pelo bom relacionamento e compartilhamento de informações serem precários. Mas hoje, com o advento da cultura DevOps e das metodologias ágeis, temos um cenário muito mais colaborativo e construtivo. Se analisarmos os passos anteriores, veremos que ambos os times participaram da concepção, criação, testes e construção da entrega.
Analise comigo essa etapa: 1) gerenciar entregáveis é gerenciar o produto final... isto é: verificar o que entra de novo e o que sai, verificar se os critérios de aceite foram atingidos, saber quais os comportamentos esperados e inesperados; 2) e tudo isso será versionado e disponibilizado para todos aqueles a quem essas informações importam; 3) alem de tudo isso, precisamos garantir o minimo de documentação possível que garanta o entendimento imediato daquilo que interessa a todas as partes (negócio, desenvolvimento, produtos, operações).
Desta forma, os últimos alinhamentos foram feitos e o pacote é entregue para o cliente.
A etapa de implantação é a mais esperada por todos. Alguns sentem alívio, outros sentem ansiedade, e outros ficam em estado de alerta. Nesta etapa, o ambiente alvo passa pelas mudanças necessárias para que a aplicação seja atualizada. Seja qual for o ambiente, a implantação deve acontecer da mesma maneira em todos eles. Além de poupar retrabalho, isso poupa incompatibilidades, ajudando também na manutenibilidade e na redução da complexidade dos ambientes. Outrossim, a maior semelhança entre ambientes melhora a confiabilidade dos testes.
Um pilar importante nas etapas de operações é o de automatização. Apesar de a imensa quantidade de ferramentes disponíveis para tal, os times de operações tendem a se apegar ao bom e velho bash script. Para nós, ele é essencial, mas deve ser buscado como última alternativa na maioria dos casos; casos esses como: provisionamento, subida de infraestrutura, notificação, alterações em massa, atualização de aplicativos, entre outros. Ele tem o seu lugar em tarefas simples, mas não podemos limitar a ele. Pense no bash como um canivete suíço: ele é bom, versátil, pode fazer quase tudo e é confiável; porém, fugindo de alegoria, ele é complexo, tem pouco desempenho, possui uma acoplação perigosa como sistema operacional e é difícil de manter. Na cultura DevOps, especialmente em infraestrutura de nuvem, abordagens de mercado para codificação de infra e provisionadores são muito mais modernas, robustas, performáticas e modulares. E quando elas não dão conta, podemos trabalhar com o Python que dá muito mais suporte e facilidades do que o bash, é mais performático, suporta múltiplas plataformas, é ainda mais versátil, e muito mais. Por isso, é importante que a caixa de ferramentas do operador esteja cheia de opções no tocante a lida com a implantação.
Outro elemento que é mister de se encontrar no arcabouço de um time de operações é a capacidade para múltiplas metodologias de implantação e testes em produção. Parece um pouco exagerado fazer um teste em produção para alguém de operações, mas essa é uma necessidade mais presente do que um SRE gostaria que fosse. Para isso, utilizamos certos métodos já bem documentados e suportados por diversas plataformas de operação: são as implantações canário e blue/green. Essas metodologias não apenas nos asseguram de certos problemas, como também garantem que comportamentos inesperados e instabilidades sejam evitadas de ocorrer para uma boa parcela dos clientes. Também conseguimos dados de métricas, de log e de banco (isto é, transações), para por meio deles tomar decisões sobre os próximos passos, o que pode ser melhorado, o que não se comportou como deveria, etc.
Conforme o ciclo de vida do software evolui no ambiente, alguns eventos específicos ocorrem, e certas atitudes são responsabilidade do time de operações. Por vezes, são ações referentes a escalabilidade, disponibilidade, investigações de comportamentos inesperados e até mesmo scripts de rotina. Na maioria das vezes, são eventos que estão indiretamente ligados ao que foi desenvolvido. Por exemplo, a troca de arquivos entre cliente e plataforma; a geração de relatórios operacionais; o suporte e manutenção à infraestrutura; as alterações de rotas e lógica de redes; as configurações de soluções de terceiros; as tarefas voltadas para finops com foco em infraestrutura; a criação de elementos de monitoramento; entre outros.
Quando trazemos uma veia de desenvolvimento para a operação, esperamos que os softwares auxiliem nas tarefas citadas acima, automatizando-as. Sejam eles de terceiros ou desenvolvidos pela própria equipe, precisamos que as necessidades específicas do negócio sejam atendidas. Muitas soluções de mercado surgiram desta maneira. Espera-se que, com a adoção da cultura DevOps, a quantidade esmagadora dos processos dentro da operação seja automatizada, ocorrendo de forma instantânea ou com o apertar de um simples botão. Uma das linguagens mais populares é o Python, pela sua baixa curva de aprendizado e versatilidade.
A automatização de processos repetitivos é primordial, mas não podemos negligenciar a automatização da infraestrutura. Resiliência e elasticidade são as regras quando falamos de programação WEB. Por isso, a maioria das ferramentas e plataformas dão suporte a ações automáticas que previnam indisponibilidade ou sub-capacidade das aplicações. Esse recurso é importante para que o acordo de nível de serviço seja satisfeito, para que os gastos com infraestrutura sejam minimizados, para que a aplicação seja responsiva à demanda de clientes, para que as recuperações pós-desastres sejam mais eficientes, entre outros.
E não podemos deixar de mencionar a governança quando o assunto é a operação. Muitas vezes precisamos nos adequar a certos padrões da indústria para ganhar uma licitação, enquadrar-nos com as determinações estatais ou ainda para fazer parcerias com outras empresas. Essas padronizações nos ajudam a ter um processo de entrega de software mais adequado à empresa, e ele pode influenciar em diferentes aspectos dela. No nosso caso, precisamos nos atentar a normas que ditem a forma como o software deve ser desenvolvido, como os dados devem ser armazenados, como lidar com a segurança nas esferas de desenvolvimento e operações, como os diferentes processos internos devem ocorrer, etc.
Por fim, a etapa de monitoramento é o elemento que interliga a operação com o planejamento das entregas. Esse tópico eu gostaria de começar com uma pergunta: por que é tão importante medir? Dar-lhe-ei a resposta mais adiante, mas antes uma provocação: você dirigiria um carro sem painel de instrumentos? Isso é pelo menos falta de bom senso. Pensando sob essa perspectiva, a medição da nossa operação é essencial quando desejamos saber quando um elemento crítico do funcionamento da empresa está prejudicado. Ela é importante para verificar o nosso desempenho, respeitar normas e acordos de serviços, verificar se temos os insumos necessários para manter o operação do produto, juntar dados que justifiquem planos de ação, etc. Em suma, geramos feedbacks e monitoramos o estado da aplicação.
Os feedbacks são elementos fundamentais do processo de melhoria contínua. A evolução exige consciência das deficiências e forças do estado atual para que a mudança que venha a ocorrer seja benéfica, porque podemos evoluir positivamente, mas também negativamente. Ou seja, se eu apenas mudo, mas não sei que resultados obtivemos com isso, ficamos sem saber se fizemos de fato uma decisão boa (que vai manter a engrenagem funcionando), ou se tomamos uma péssima decisão (causando prejuízo e até falência). Ou seja, ficamos sujeitos a mediocridade, ou pior: ficamos antiquados. Uma empresa desatualizada vai perdendo aos poucos espaço de mercado para outras que sabem operar de forma adequada, sabendo aproveitar as oportunidades e se esquivando dos perigos.
Já o monitoramento, que não deixa de ser um tipo de feedback, vai garantir que todos os aspectos importantes do negócio estejam visíveis, disponíveis, documentados e cobertos. Seu objetivo é observar os indicadores e dizer se eles estão nos valores esperados. Não estando eles, será verificado se esse cenário é positivo ou negativo para o produto final. Sendo eles positivos, podemos dizer que aproveitamos uma oportunidade adequadamente ou que encontramos uma boa oportunidade para investir. Caso negativos, devemos notificar a quem compete resolver a situação, já o munindo das informações necessárias para tomada de decisão ou início da investigação em caso de problema. Podemos ainda identificar casos desavantajosos que não são urgentes, mas que revelam um mal planejamento ou uma oportunidade a se explorar (que eu acredito que seja o melhor dos casos, porque transforma uma fraqueza em uma vantagem).
Desafios
Apesar de todas as vantagens, pode ser desafiar implantar essa cultura na empresa alvo. Como se trata de algo cultural, fica muito mais difícil fazer com que todos optem por ela. Uma metodologia, ou um protocolo é muito fácil de ser implantado, visto que não implicar em mudança de perspectiva. Por outro lado, uma mudança cultura envolve não só uma mudança de paradigma mas uma mudança de mente. Tais coisas somente são internalizadas quando repetidas e incentivadas.
Outro ponto desafiador, é implementar uma série de ferramentas e práticas para pessoas de diferentes níveis de conhecimento. Porque sempre há pessoas com mais dificuldades de aprendizado e pessoas de áreas distintas. Por isso, o reforço e o aprendizado contínuo são peças fundamentais para a adoção da cultura DevOps.
E existe ainda o risco de que, se a cultura for má implementada, teremos um aumento da complexidade dos processos. Isso é a consequência da automatização, que pode ser feitas de variadas formas e em diferentes cenários. Desta forma, o compartilhamento e a margem para erros devem ser intrínsecos aos envolvidos.
Conclusão
Então, como você pode notar, o ciclo DevOps apresenta coesão. Ele busca aprimorar o ciclo de desenvolvimento de software por meio da maior sinergia entre as áreas, de forma multidisciplinar, colaborativa, programática e contextualizada. Ele contempla desde o planejamento do projeto até o monitoramento do que foi entregue, estruturando as etapas ordenada e logicamente. Ele enfatiza a automação e as ferramentas durante todos os elementos para reduzir falhas, aprimorar entregas, agilizar processos e assegurar padrões. Além disso, a colaboração é outro componente fundamental da cultura, bem como o bom relacionamento entre desenvolvimento e operações. E podemos contar também com o aspecto da medição, que nos dará os insumos para os processos de tomada de decisão, monitoramento e melhoria contínua.
Top comments (0)