O Movimento DevOps

Mais do que apenas dar aos desenvolvedores acesso root!

Ou nem isso. A grande ideia por trás do “movimento” não está simplesmente dando aos desenvolvedores mais corda;’Trata-se de garantir melhores linhas de comunicação entre os desenvolvedores e as equipes de operações da empresa. Muito disso não é novo, na verdade’é uma rehash do movimento kaizen do movimento dentro das cadeias de suprimentos industriais tradicionais (esp. automóvel) durante o século anterior. Os painéis Kanban são apenas a mais recente reformulação de painéis de controle (duplicando como gerentes de inventário de fluxo de trabalho) que cobrem o esforço diário coletivo para enviar produtos de qualidade que encantam clientes e parceiros de negócios.

O gerenciamento de restrições é a chave para o processo. Ao identificar primeiro todos e quaisquer gargalos no sistema, você pode reorientar seus esforços na otimização desses recursos para o desempenho máximo. Otimizações além dessas áreas quase sempre não valem a pena — o fluxo de trabalho ainda será restrito por esses recursos.

Desenvolvimento baseado em tronco

Incentivar mudanças incrementais com testes automatizados, promoção e processos de lançamento em uma cadência programada é uma ótima maneira de fazer a bola rolar, mas uma grande parte do controle de qualidade em implantações SaaS/PaaS envolve a adoção de desenvolvimento baseado em tronco e seu ramo por abstração conceitos. (Por favor, visite o link para uma discussão completa sobre as características e desvantagens).

Em essência, o multiverso de longo prazo git Os ramos criam a ficção psicológica de que a fusão combinada de todo esse trabalho de desenvolvimento local (e testes!) levará a um todo que é pelo menos tão grande quanto a soma de suas partes. A experiência é o melhor juiz, o que indica que os conjuntos de novos recursos extensivos devem ser projetados incrementalmente, in-situ, no código-fonte da filial de produção/lançamento existente. Basicamente, você desenvolve suas estratégias de desenvolvimento dentro das limitações da física do mundo biológico, que diz:

        Surgery on a patient must result
        in good outcomes (at all times) for
        that patient, not just for siblings
        or future generations.

Pipelines de CI/CD

O Trunk Based Development é a base para todos os consequentes pipelines automatizados de controle de mudanças que cresceram nas últimas duas décadas.

Código é lei (desenvolvimento + infraestrutura + configuração).

Um pouco de perspectiva histórica em primeiro lugar; a linha de soco segue estes quatro parágrafos. O tópico comum aqui é que Apache quase sempre esteve à frente de seu tempo.

De volta ao pré-CFEngine dias, a Apache Software Foundation manteve todos os seus arquivos de configuração de TI e scripts de suporte no CVS e, posteriormente, no Subversion. Além disso, cada serviço que executamos tinha um “manual” para orientar os administradores com suas tarefas de manutenção práticas.

O fluxo de trabalho era inferior ao ideal: além de criar nossas próprias árvores de portas FreeBSD com patches locais em pacotes implantáveis (binários) do zero, a equipe teve que exercer disciplina difícil de aplicar ao implantar alterações na produção, primeiro se comprometendo com o controle de versão, fazendo login no servidor de destino, atualizando seu checkout e potencialmente reiniciando o serviço — todo esse trabalho repetitivo realizado à mão. Na realidade, na maioria das vezes, os administradores de sistemas hackeados diretamente no servidor de destino e comprometidos com esse servidor’s checkout, arriscando um monte de conflitos de mesclagem ao longo do caminho como a árvore foi re-atualizada (ou então, ou em algum momento no caminho por futuras ações executadas por algum outro membro da equipe). Um fluxo de trabalho bastante menos do que transparente, com segurança duvidosa de gerenciamento de senhas, para uma equipe de operações colaborativa.

Hoje em dia, eles mantêm tudo em uma git-backed puppet source tree, e provisionar/implantar/configurar diretamente para a nuvem usando pacotes Ubuntu upstream genéricos, que é uma abordagem um pouco moderna para o seu trabalho de TI-ops, desde que programado git puxa pelo mestre fantoche irá eventualmente implantar atualizações como os agentes fantoches check-back-in. Mas CI/CD é um trabalho em andamento, até hoje.

Por outro lado, uma iniciativa inicial e inovadora semelhante a CI na ASF (para projetos reais de software TLP da Apache) foi Apache Gump, que foi a ideia de colegas brilhantes como Sam Ruby e companhia. O que gump fez foi periodicamente checkout, construir e testar HEAD (incluindo HEAD de todos os deps) do tronco de cada base de código no repositório do Subversion (mas remonta ao CVS) para cada projeto que pudesse descobrir com sucesso como construir (que era, em geral, limitado a projetos Java originalmente). Os relatórios foram enviados automaticamente para cada comunidade de desenvolvimento e arquivados para posteridade. Esta atividade de automação de tarefas perspicaz ainda continua (com git) até hoje! Qualquer comunidade de desenvolvimento do tamanho de uma empresa que não esteja executando seu próprio servidor Gump está 20y atrás do estado da arte no The ASF (IMO; não’t me get started on open source version-pinned software module dependencies in /trunk|master/ …).

Aqui’s o ponto em poucas palavras: todas as suas fontes (desenvolvimento, infraestrutura e configuração) pertencem ao controle de versão (não necessariamente compartilhando o mesmo repositório) que é revisável por todo o pessoal de devops e faz parte de seu conjunto completo de pipelines de teste-automação entre revisões de patch e implantações de produção. Uma pesquisa sobre o estado da arte, onde as mudanças são testadas/provisionadas/implantadas sob demanda em ambientes IaC/CaC, está no meu amigo e visionário Paul Hammant’site aqui. Por favor, dê uma olhada!

Virtualização vs. Containerização: a Animais de estimação vs. gado Redux

Sistemas de contêiner como o Docker são tecnologias de virtualização personalizáveis e reimplantáveis que geralmente são usadas para oferecer suporte a uma estrutura de cluster de aplicativos MicroService Architecture (MSA), como Kubernetes. Eles continuam de onde os sistemas de virtualização pararam, negociando suporte ilimitado de sistemas operacionais por VM (totalmente) isolados para VM baseada em Linux-kernel’s que têm uma personalização e integração consideravelmente mais programáveis com o host pai Linux no qual são executados. Além disso, eles podem ser reconstruídos e carregados em um serviço de distribuição central (como artifactory) para reutilização em larga escala em várias cadeias de dependência e implantações de servidores executáveis brutos.

Escalonamento Vertical x Horizontal

Contêineres reconfiguráveis, que podem ser baixados de um servidor central, permitem possibilidades difíceis de serem percebidas com a tecnologia básica de virtualização.’t bloqueado em qualquer servidor único’limites de hardware para expandir seus serviços para atender à demanda. Em outras palavras, o dimensionamento horizontal ao implantar o mesmo contêiner em coleções de hosts, sob demanda, é um recurso de primeira classe imediatamente viável de estruturas MSA baseadas no Docker. Assim como a implantação de dezenas a mais de contêineres do que núcleos de CPU no host same.

Medir, frear e controlar os esforços de combate a incêndios, reais e praticados

Uma das outras coisas importantes a serem reconhecidas é distinguir entre trabalho planejado e não planejado em qualquer uma de suas métricas de controle de produtividade e como os recursos são alocados para essas tarefas. O trabalho não planejado equivale a firefighting, e se muito tempo (mais de ~20%) for gasto nessas tarefas, o trabalho planejado, que é a verdadeira necessidade de negócios da empresa, fica atrasado.

Os gargalos no sistema raramente podem lidar com o trabalho não planejado, por isso é importante ter recursos adicionais suficientes para lidar com o aumento da carga e consequente backlog.

Uma das principais lições de retrocesso da COVID-19 no início de 2020, como a capacidade hospitalar em termos de TI, é que existe uma coisa como ser muito magro, pelo menos quando se trata de pessoal de devops (hardware é outra história). Planejamento de contingência para um dia chuvoso, seja com “redundante” funcionários ou iniciativas de treinamento cruzado, combinadas com exercícios preparatórios regulares, não apenas mantém o médico afastado, mas é realmente missão crítica.

Começando com o programa

No nível de gerenciamento, uma perspectiva global de gerenciamento de mudanças entre as mudanças de desenvolvimento e operações é vital. Ambos os grupos precisam estar cientes um do outro’s alterações. Idealmente com detalhes de planejamento disponibilizados ao longo do caminho. Grandes coisas podem acontecer quando as equipes são uma mistura saudável de pessoal de desenvolvimento e operações, em uma cultura de trabalho colaborativo transparente e orientada por dados.

A filosofia de inclusão de múltiplas partes interessadas na criação e evolução de um produto de trabalho tangível tem implicações muito além das equipes dev e ops que compartilham o controle e a responsabilidade por um esforço de engenharia de servidores. Esta lição continua a ser repetida em todo o mundo corporativo moderno, à medida que novos domínios para a expressão humana criativa se formam no setor empresarial, bem como na reinvenção de velhas formas de fazer negócios juntos.