Cloud

Introdução à Cultura DevOps

Hoje, todas as organizações dependem de software. Ramos como varejo, logística, governo, pesquisa científica, tecnologia, educação, serviços financeiros, etc, todos os setores precisam de algum tipo de software para atender às necessidades dos clientes e usuários. As expectativas que as pessoas têm de software mudaram drasticamente ao longo da última década. Eles esperam serviços confiáveis ​​e convenientes que sejam regularmente aprimorados.

A complexidade da nossa infraestrutura computacional aumenta continuamente, assim como a pressão para fornecer mais softwares, mais freqüentemente e com padrões de qualidade mais elevados.

A maneira normal de entregar software nas organizações está falhando, porque os incentivos da equipe simplesmente não foram alinhados. De um lado, os desenvolvedores são incentivados exclusivamente para oferecer novos recursos. A sua responsabilidade acaba assim que o software é entregue às equipes de operações para implantar. E do outro lado, as equipes de Operações foram incentivadas a manter a infraestrutura tão estável quanto possível. Sua responsabilidade pela entrega de software começa apenas uma vez que foram entregues o software para implantar. (E, claro, operações normalmente têm muitas responsabilidades, além de implementar software, incluindo gerenciamento de custos, contas de usuários e capacidade geral, além de garantir a segurança e compliance).

Os incentivos desses dois grupos são fundamentalmente opostos. E o problema não pode ser corrigido pelas práticas tradicionais de gerenciamento, ele deve ser feito por técnicas práticas e apoio de gestão.

Existem duas idéias principais que levam as equipes operacionais a usar as práticas do DevOps:

1. Idéias de Tratar Infraestrutura como Software
Ao tratar a infraestrutura como software, poderíamos tirar proveito de tudo o que aprendemos no campo da engenharia de software nas últimas décadas – por exemplo, o valor do controle de versão, estratégias de ramificação e revisão de código. A crescente prevalência de APIs mais simples e fáceis de usar (como a adoção generalizada de APIs RESTful) tornou mais fácil para os não desenvolvedores usá-las, o que resultou em um grupo mais amplo de pessoas dentro do campo de operações capaz de fazer o desenvolvimento como opor-se ao script. Isso empurrou mais as pessoas de operações para aprender práticas básicas de engenharia de software.

2. Infraestrutura ágil
As comunidades do DevOps mais avançadas começaram a gerar mais conteúdos reutilizáveis ​​que poderiam compartilhar, o que, naturalmente, começou a expor mais e mais sysadmins ao pensamento atual em torno das práticas de desenvolvimento de software. A crescente popularidade das metodologias ágeis resultou em mais lançamentos, colocando ainda mais, pressão sobre as equipes de operações e tornando mais urgente melhorar a forma como geriram a infraestrutura.

Preciso adquirir habilidades do Programador de Software para me tornar um Engenheiro DevOps?

Há um mal entendido comum que vemos regularmente. Se você trabalha em operações, “fazer DevOps” e fazer uso dessas técnicas não significa que você precisa ter todas as habilidades de programação de um desenvolvedor de software sênior.

Nós sempre fizemos o desenvolvimento nas operações, seja fragmentos de script de shell, alias de shell úteis ou arquivos em lote. Não era esperado que absorvêssemos os princípios de engenharia e entrega de software, e não pensamos nisso como desenvolvimento.

Você não precisa se tornar um desenvolvedor profissional de software em tempo integral para “fazer DevOps” como uma pessoa de operações, você só precisa entender práticas básicas de software, como controle de versão, revisão por pares, lançamentos e testes, e ter alguma facilidade com linguagens de programação de alto nível e estruturas para fazer o trabalho.

Se sua equipe estiver seguindo três práticas, você já está fazendo DevOps:

1. Automação
Automação (Automação de Serviço / Automação de Rede / Automação de Configuração) e infra-estrutura de autoatendimento permitem minimizar o tempo de ciclo, pois os indivíduos não podem apenas confiar em resultados automatizados previsíveis, mas também, com a adição de autoatendimento, esses indivíduos e suas equipes podem correr em sua própria cadência e evitam estrangulamentos externos. Isso permite uma experimentação mais rápida e mais agilidade para lidar com mudanças de direção, além de maior confiabilidade e qualidade.

2. Medição
Como diz o ditado, você não pode melhorar o que você não mede, e isso, mesmo que seja, é ainda mais verdadeiro quando você está falando sobre o uso do DevOps para melhorar o ciclo de vida completo da entrega de software.

3. Compartilhamento
Compartilhar entre equipes é um princípio chave do DevOps. As ferramentas moldam o pensamento das pessoas e, portanto, quando as pessoas usam ferramentas muito diferentes, muitas vezes pensam de forma muito diferente. Um conjunto de ferramentas compartilhada pode percorrer um longo caminho para ajudar as pessoas a se entenderem mais rapidamente, e essa empatia ajuda em todas as interações que têm entre si dentro de uma empresa. Oitenta por cento do que um sysadmin faz todos os dias é o mesmo ou similar ao que outros administradores de sistemas fazem por 80% do seu dia, então por que não compartilhar o código que o automatiza? Especialmente quando os dados específicos para cada local de trabalho foram abstraídos do código de operações.

Deixe uma resposta

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.