Há algum tempo desejo escrever sobre DevOps, pois tenho visto e ouvido muitas definições sobre o termo. Há empresas que começaram a utilizar o DevOps como cargo ou função. Outras criaram unidades, times ou squad de DevOps em sua estrutura. Dá para entender a ideia, mas pode gerar algumas disfunções visto que o termo está atrelado a uma cultura e não a uma estrutura.
Neste Artigo
DevOps é uma declaração de paz (Porque existe)
DevOps é uma cultura que tem o seu principal propósito extinguir a rivalidade entre desenvolvedores e pessoal de operações / infraestrutura. Caso você não seja da área de Tecnologia da Informação (TI), saiba que durante décadas as empresas separaram as unidades de Desenvolvimento de Software da unidade de Operação e Infraestrutura de Sistemas. O Desenvolvimento constrói produtos que são instalados em servidores, computadores e nuvens mantidos pelas unidades de Operação.
Infelizmente, como sempre foram unidades separadas, criou-se uma espécie de rixa entre elas. Desenvolvimento reclama que Operações é lenta, paranoica e impede a evolução de softwares. Operação reclama que Desenvolvimento é irresponsável, não entende o ambiente e é insegura. Durante anos isso foi uma realidade até perceberem o que agora parece óbvio. Uma é totalmente dependente da outra e não podem viver isoladas. Foi nesse contexto que surgiu o conceito DevOps.
DevOps é uma cultura
O objetivo primário é integrar as equipes de desenvolvimento e operação de software, buscando satisfazer as necessidades dos clientes de TI com agilidade e qualidade. Devops envolve a aplicação de conceitos, práticas e ferramentas que aumentam a capacidade de uma empresa de disponibilizar produtos, serviços e serviços de forma eficaz e eficiente. Além disso, ela impacta o relacionamento entre Desenvolvimento e Operações criando uma cultura de colaboração entre os profissionais dessas áreas.
Vantagens de DevOps
Existem muitas vantagens ao aplicarmos a cultura de DevOps. Dentre elas podemos citar:
- Paz entre áreas que precisam colaborar
- Colaboração entre profissionais, times, squads e unidades
- Maior qualidade do produto e serviço oferecido
- Menor tempo desde o surgimento da ideia ou solicitação do cliente e a entrega
- Maior confiabilidade, segurança e escalabilidade tanto do produto entregue quanto do parque computacional que o suporta
- Compartilhamento de Conhecimento e Melhoria contínua de todos os envolvidos
Desvantagens de DevOps
Nem tudo é só vitória. Alguns pontos de atenção que temos que ter com DevOps são:
- Aumento da complexidade, pois é muito mais fácil gerir áreas isoladas do que integradas.
- Lidar com gestores que não terão “total controle” sobre seus geridos.
- Limitação da pessoa uma vez que a TI hoje é um mundo gigantesco. Esperar que as pessoas sejam especialistas em Cobol, Java, Python, Kubernetes, Banco de Dados, Jenkins, Docker, Cloud, Inteligência Artificial é um tanto utópico.
- O custo de automação pode ser um tanto alto, pois além das ferramentas deve entrar na equação o custo de aprendizado dessas ferramentas.
Trazendo a cultura DevOps para a empresa
Cultura não se muda sozinha. Colocar uma plaquinha dizendo que agora somos DevOps não é suficiente. É necessário tomar ações para que de fato a cultura mude. Seguem abaixo 10 ações que creio que são importantes para que o DevOps se torne uma realidade.
Os profissionais têm que colaborar
Não tem outro jeito. Se há separação entre os times de Desenvolvimento e Operações e sua única forma de colaboração é via abertura de tíquetes, e-mail e chamados, não haverá DevOps. As equipes têm que trabalhar juntas fazendo parte e entendendo os projetos, produtos e serviços que elas são responsáveis. Operações sabe qual a necessidade de Desenvolvimento e Desenvolvimento entende o que Operações precisa para manter o ambiente estável. Aqui dois cuidados são necessários.
O primeiro é não criar um ambiente de harmonia artificial em que você coloca alguém de Operações em todas as reuniões diárias de todos os times de desenvolvimento e fala: “Eles já sabem de tudo”. A pessoa vai participar de umas 10 reuniões por dia e durante meses ele será um 2 de Paus (carta de menor valor em alguns jogos de baralho). E um dia algum time de Desenvolvimento vai reclamar: “Ué? mas isso eles já sabiam!”.
Em pequenas empresas Operações atendem poucos times de Desenvolvimento e, portanto, sentam juntos com eles. Em empresas maiores isso é improvável de acontecer, pois Operações atendem dezenas de times de desenvolvimento. Nesse caso, seja criterioso aos momentos em que Operações deve estar presente com um dos times de desenvolvimento.
O segundo cuidado é o contrário do primeiro. É só chamar Operações quando o desenvolvimento estiver completo e tiver que colocar o produto em produção. Esse é o estilo: “Segura que agora o filho é teu”. Também não funciona. Desenvolvimento e Operações têm que ter encontros no início, durante a construção, na entrega e na evolução do software.
Foco no cliente
Se Desenvolvimento não consegue entregar, o cliente sofre. Se Operações não consegue manter o ambiente, o cliente sofre. Se cada profissional olhar apenas para a sua especialidade, o cliente sofre. Uma empresa é um organismo e como qualquer organismo, se uma parte não funcionar bem, todo o corpo sofre. É fundamental trazer métricas como o Customer Lead Time, Downtime (tempo em que os sistemas estão fora do ar), tempo de restauração, taxa de falhas em mudanças, entre outras. Todas elas impactam o cliente e indicam que partes do corpo podem não estar funcionando.
Responsabilidade de ponta a ponta
Isso nos leva a outra ação importante que é a responsabilidade de ponta a ponta. Se coloque do lado do cliente. Se um sistema está inacessível ou uma entrega demora muito, a culpa é da sua empresa e não dos times A, B ou C. Seu cliente, na maioria das vezes, não sabe como você se divide internamente, logo a culpa de um fracasso é responsabilidade de todos.
Uma dica importante para você que é de Desenvolvimento de Software. Normalmente nos lembramos de Operações quando dá algum problema. Várias vezes celebramos com nossos clientes o sucesso de produtos e serviços. Quantas vezes você já chamou Operações para dividir esses momentos também? Sem eles, o sucesso seria impossível. Lembre-se disso no próximo bolo ou almoço de comemoração.
Melhoria Contínua
Já que temos o mesmo foco e somos responsáveis pelos mesmos resultados, temos então que melhorar continuamente juntos. No Kanban temos as reuniões de melhoria de fluxo que servem justamente para esse fim. Se a melhoria for local, os resultados serão locais. A melhoria DevOps resulta em melhoria sistêmica.
Automação
Hoje, eu, Avelino, não vejo uma forma de ter DevOps sem automação do trabalho. Criação de ambientes, controle de versão, testes automatizados, pipelines de integração e entrega contínua (Continuous Integration / Continuous Delivery), sistemas de reversão (rollback) e recuperação (recovery) de ambiente. Você não precisa ter tudo de uma vez, mas é fundamental que comece a construir um ambiente automatizado para poder acelerar entregas garantindo a estabilidade computacional e, caso algo dê errado, a recuperação da mesma.
Agilidade
Em tese não é um pré-requisito, mas também não vejo como não ter uma gestão e execução que não sejam baseadas em Agilidade. Frameworks como o Scrum , Métodos como Kanban são importantíssimos para manter o foco no cliente, adaptação às necessidades de negócio, segurança e escalabilidade, colaboração entre times etc.
Times Multidisciplinares
O Scrum já falava sobre a importância de ter times multifuncionais que tivessem todo o conhecimento necessário para conceber, criar e disponibilizar produtos e serviços. Pode ser uma estratégia interessante para criar a cultura DevOps. Misturar os profissionais em times que sejam verdadeiramente multidisciplinares.
Não estou dizendo que todos os membros devem dominar todos os assuntos necessários para criar, disponibilizar e manter software e ambiente, mas é muito bom que dentro de um time todo esse conhecimento esteja disponível. Tratei esse assunto com mais detalhes no artigo: Por que precisamos de times multidisciplinares?
Cultura Positiva
Essa aqui eu esbarrei a pouco tempo lendo alguns artigos da Unity, mais especificamente, Princípios e Práticas Recomendadas do DevOps. É necessário matar a cultura do “a culpa não é minha”, “isso é com eles”, Nós vs. Eles. Temos que criar uma cultura colaborativa e positiva. Para tal:
“incentive a sinceridade, a transparência e o feedback (positivo e negativo), enfatizando que não existem ideias ruins. Implemente sistemas que permitam a polinização cruzada de trabalho entre as equipes e reconheça publicamente os indivíduos e as equipes por seus sucessos.”
Unity
O que ler sobre o tema
Links para os livros em cada título
Conclusão
Espero ter deixado claro que DevOps não é só um termo bacana ou algo que posso escrever em algum lugar e um dia todos acordam DevOps. É uma cultura e como qualquer cultura leva tempo para se adaptar. Além disso, como o Rodrigo de Toledo costuma a dizer:
Toda mudança de cultura requer palavras e ações.
Rodrigo de Toledo
Então, mãos à obra.
