Categoria: DevOps

DevOps

Aprenda sobre o papel que os Bots têm no DevOps

Você sabe dizer onde os Bots se encaixam no pipeline DevOps?
Algumas das principais tendências de DevOps são:

DevOps assembly lines automation
Alertas inteligentes e acionáveis de ferramentas de monitoramento
Monitor e infra-estrutura de orquestração

Colaboração aprimorada:
Com o aumento da adoção do DevOps, as organizações enfrentam hoje muitos desafios no ciclo de vida de entrega de serviços de ponta a ponta.

Para aplicativos com configurações de ambiente complexas, a criação, a configuração e a implementação de um novo ambiente é dispendiosa, demorada e propensa a erros.

Devido a intervenções manuais, mover/promover o código entre os ambientes envolve riscos e pode causar interrupções.
As equipes de desenvolvimento buscam maximizar a mudança escrevendo novos códigos ou aprimorando o código existente, enquanto as equipes de operações procuram minimizar as alterações para acompanhar os principais indicadores de desempenho (KPIs) e os contratos de nível de serviço (SLAs). Essas metas são opostas por natureza e criam uma cultura de culpa entre as equipes de desenvolvimento e operações.
As organizações são incapazes de manter o desenvolvimento, o teste e a produção em sincronia devido a falhas no processo e na ferramenta. Um processo manual, não pode colmatar esta lacuna na consistência: assim interrupções na produção são comuns.

Vários mecanismos de colaboração permitem que as equipes trabalhem e aprendam juntas para produzir melhores resultados. A figura abaixo descreve o ciclo de vida de ponta a ponta do DevOps. A colaboração entre as fases é essencial para o sucesso da transformação de DevOps da sua empresa.

O que são ChatOps e Bots?
ChatOps é um termo cunhado pelo GitHub para descrever “colocar ferramentas no meio de uma conversa”. Em um pipeline típico de CI/CD, há várias ferramentas com as quais você interage e que têm funcionalidades variadas, como gerenciamento de código-fonte (SCM), gerenciamento de defeitos, integração contínua, implantação continua e outros. Essas são todas as ferramentas discretas, mas não há nada que as una juntas. É aqui que o ChatOps entra em jogo.

Um bot é a ponte entre a ferramenta de colaboração e as ferramentas DevOps. O bot recebe uma solicitação do usuário na forma de um comando de chat por meio de uma ferramenta de colaboração, analisa a solicitação e executa um conjunto de comandos na ferramenta DevOps de destino.
Os principais componentes do ChatOps e bots são:
Ferramenta de colaboração/aplicativo de bate-papo: esse é o sistema de bate-papo inicial que conecta as várias partes interessadas e permite que elas interajam entre si e os sistemas ao seu redor.

O bot: este é o núcleo do ChatOps. Um bot é a cola entre sua ferramenta de colaboração e seus sistemas. Facilita um canal de comunicação bidirecional onde você pode buscar informações relevantes dos sistemas e agir sobre as suas informações recebidas. Um bot se encaixa entre sua ferramenta de colaboração e as ferramentas de DevOps, por exemplo, Hubot, Lita, ErrBot ou AWS Lex.
Onde os bots se encaixam no pipeline de DevOps:
Os bots podem provar ser um acelerador em vários estágios do pipeline de CI/CD. Abaixo estão os detalhes da integração com várias ferramentas de DevOps em cada fase do ciclo de vida:

Planejamento proativo – JIRA
Gerenciamento de Requisitos – JIRA
Integração Contínua – Jenkins
Implantação contínua – Ansible, Chef
Monitoramento contínuo – Nagios, Grafana, Splunk
Feedback contínuo – JIRA

Um chatbot desempenha um papel importante em reunir as diferentes equipes em uma única sala de bate-papo persistente para fazer a triagem e resolver o problema em questão. Além de solucionar problemas e triagem, os bots podem ser usados para vários outros trabalhos comuns, como:

Limpar servidores.Iniciando trabalhos de criação e implantação.
Rotating logs do servidor.
Aplicativo de integração nas ferramentas de monitoramento.
Coletando métricas de ferramentas como o Nagios ou o AppDynamics.

Modelo Técnico de Bot:
Para atingir as metas mencionadas, precisamos ter uma plataforma de bot de suporte em funcionamento. A proximidade das ferramentas com o bot garante a qualidade da implementação e abre novas oportunidades de automação.

Como o diagrama mostra, o chatbot está hospedado em uma ferramenta de chat como o Slack. Isso pode estar na plataforma de nuvem ou em um aplicativo de bate-papo/comunicador existente. O bot é integrado a um banco de dados de referência de pares de valores-chave, que é alimentado com as respostas. A chave pode ser o nome do aplicativo para recuperar dados ou qualquer ID exclusivo que reduza o número de leituras. Uma consulta da chave definida correspondente à chave secundária é executada no banco de dados de resposta e uma resposta é enviada de volta ao chatbot. Dependendo do número de saídas, as consultas podem ser definidas e armazenadas no banco de dados de resposta.
DevOps Bots: Casos de Uso:
Abaixo estão alguns exemplos de casos de uso para bots. Isso inclui o ciclo de vida completo do DevOps.
Planejamento proativo:
Crie novas histórias de usuários em ferramentas de planejamento de sprint e atribua sprints a equipes. Atualize sprints e backlogs de produtos.
Construção e Integração Contínua:
Execute tarefas de construção e relate as estatísticas do trabalho de construção. Realize compilações diárias / noturnas e relate o status da compilação para as equipes relevantes.
Implantação contínua:
Execute trabalhos de implantação e execute implantações em vários ambientes. Reverter implantações em caso de falhas, verificações de status, executar ações pós-implantação, como reinicializações da JVM.
Provisionamento de Infraestrutura e Gerenciamento de Configuração:
Inicie os trabalhos do Chef para provisionar infraestrutura ou provisionar ambientes de aplicativos. Ative o monitoramento e a reinicialização de serviços e servidores.
Monitoramento Contínuo:
Forneça estatísticas de aplicativos ou execute pesquisas de dados diárias e métricas de captura.
Feedback Contínuo:
Monitorar a integridade do aplicativo e executar análises.
Principais métricas de medição:
Para obter otimização e melhorar o desempenho do processo de entrega contínua, a medição métrica é a chave. Esses indicadores ajudarão a tomar certas ações corretivas e preventivas com base nos resultados. Abaixo estão alguns dos principais indicadores de métricas que podem ser medidos.
Redução de Esforço:
Indica a redução de esforços humanos/manuais para tarefas como o acionamento de uma construção ou implementação ou coleta de métricas a partir de ferramentas de monitoramento.
Taxa de Redução de Erro Humano Redução:
do esforço necessário devido a retrabalho causado por erros humanos.
Reduzir:
o tempo de triagem do problema indica o tempo necessário para resolver problemas em que várias partes estão envolvidas e a triagem de problemas é necessária.
Conclusão:
Os bots de DevOps podem melhorar significativamente a eficiência da equipe, bem como a capacidade de uma equipe de responder a emergências. Eles economizam tempo e dinheiro, são divertidos de construir e usar e podem ter um impacto positivo no moral da equipe, além de aumentar a produtividade geral das equipes. Isso se aplica às equipes de engenharia e operações. As empresas que adotam a digitalização buscam parceiros com uma mentalidade de engenharia que saiba como reunir equipes ágeis colaborativas com o mais recente conhecimento de plataformas de código aberto e de ferramentas DevOps.

Fonte: devops.com

LER MAIS ARTIGOS

Siga os canais da Kumulus nas redes sociais:

Facebook

Instagram

Youtube

Envelope

Cloud DevOps

Como o Airbnb simplificou o fluxo de trabalho do Kubernetes para mais de 1.000 engenheiros

Como o Airbnb simplificou o fluxo de trabalho do Kubernetes para mais de 1.000 engenheiros
Melanie Cebula, engenheiro de infra-estrutura na Airbnb, deu uma palestra na Qcon Londres sobre a ferramental e estratégias adotadas pela Airbnb para apoiar mais de 1.000 engenheiros simultaneamente a configurar e a implementar mais de 250 serviços críticos para Kubernetes (com uma frequência de cerca de 500 deploys por dia em média). Também foi fundamental a automação de fluxos de trabalho comuns para engenheiros e o uso das mesmas ferramentas em todos os ambientes.

O kube-gen é a ferramenta interna do Airbnb que pode obter os parâmetros de  serviços (definidos em um único arquivo YAML) e gerar a configuração completa do serviço do Kubernetes, adicionando toda a configuração padrão necessária. No passado, o Airbnb utilizou mecanismos de herança de arquivos para configuração (como em livros de receitas do Chef) levava efeitos de falha de infraestrutura em cascata. Portanto, um dos objetivos era reduzir o raio de explosão (blast radius) de possíveis erros usando modelos YAML para configuração de serviço.

O outro grande objetivo do kube-gen era abstrair as complexidades de configuração e ferramentas do Kubernetes para permitir que as equipes de engenharia mantivessem a propriedade de seus serviços, com os níveis de isolamento necessários (parcialmente garantidos pelos namespaces gerados automaticamente baseados em nomes de ambiente padronizados), mas sem longa curva de aprendizado (long learning curve). Embora o kube-gen não esteja disponível publicamente, pois aborda o contexto especifico do Airbnb, o Cebula apontou algumas alternativas de código aberto: helm (gerenciamento de pacotes), kustomize (configuração via file inheritance) e kapitan (configuração via templating).

Imagem: arquivos de configuração de serviço no YAML personalizado são traduzidos nos arquivos de configuração necessários no Kubernetes (um conjunto por ambiente definido no YAML personalizado) e aplicados ao cluster do Kubernetes (crédito: Melanie Cebula, Airbnb).

Outras estratégias para promover configurações de serviços homogêneas e fáceis de evoluir incluem a criação de um novo repositório de service skeleton em um comando, validação no tempo de construção e implantação de arquivos de configuração (não apenas sintaxe, mas também problemas conhecidos em valores fornecidos como nome ou proprietário inválido no projeto) e versionando a configuração de serviço (gerada).

O repositório git de um serviço recém-criado inclui arquivos padrões de aplicativos e de infraestrutura (inclusive CI/CD), preenchimento automático com padrões e boas práticas (como a escalabilidade automática por padrão ou geração de documentação). As configurações do serviço de controle de versão (com um campo especifico no arquivo YAML) permitem marcar versões com problemas (para que elas nunca sejam reimplantadas) – podem ser problemas no próprio Kube-gen ou serviço específico – além de distribuir diferentes versões em diferentes canais (por exemplo, estável vs beta).

Figura: exemplos de arquivos YAML de configuração de serviço do Airbnb, incluindo um campo de versão (crédito: Melanie Cebula, Airbnb)

 

K é outra ferramenta interna do Airbnb. K é principalmente um wrapper opinativo para o kubectl que também filtra a saída detalhada de alguns kubectl. K também suporta algumas funcionalidades extras, como agrupar a ferramenta kube-gen mencionada anteriormente e building/pushing as imagens do Docker.

O objetivo dessa ferramenta era automatizar fluxos de trabalho comuns, simplificando e padronizando o trabalho de engenharia, abstraindo parte da complexidade das ferramentas do Kubernetes. Mas também levou os desenvolvedores e engenheiros de infraestrutura a falar uma linguagem comum e usar as mesmas ferramentas, o que fortaleceu a colaboração, de acordo com o Cebula.

Um fluxo de trabalho típico seria começar com k generate para gerar arquivos do Kubernetes, depois k build para construir imagens do Docker e enviar para o registro e, finalmente, implementar para criar espaços de nomes do Kubernetes e aplicar os arquivos do Kubernetes, aguardando um status de implantação final. Os serviços são criados e implantados da mesma maneira, independentemente do ambiente (ou seja, uma máquina local, IC, preparação ou produção). Também é possível executar o k diagnose, que conta com alguns plugins criados pelo Airbnb: kubectl diagnose e kubectl podevents. O objetivo era automatizar etapas manuais comuns ao depurar um problema de implementação: coletar informações sobre contêineres não-prontos, localizar eventos de conjuntos relacionados e obter os registros desses contêineres.

Finalmente, o Cebula, mencionou alguns desafios remanescentes para a adoção da jornada Kubernetes do Airbnb, em particular relacionadas à migração de milhares de serviços existentes que exigem melhor suporte e escalonamento multicluster (alguns serviços usam centenas de réplicas), manipulando mais serviços com alto nível de memória e movimentando toda a configuração para um modelo de fluxo de trabalho GitOps com controladores personalizados (custom controllers).

Fonte: InfoQ

Application Development Cloud DevOps

Aprenda sobre os 05 pilares da qualidade de software: qualidade, disponibilidade…

Aprenda sobre os 05 pilares da qualidade de software
Um aplicativo em nuvem que funciona de forma satisfatória se concentrará nesses cinco pilares da qualidade do software: qualidade, disponibilidade, resiliência, gerenciamento e segurança. São eles:

Escalabilidade: A capacidade de um sistema para lidar com aumento de carga.
Disponibilidade: A proporção de tempo que um sistema está funcional e funcionando.
Resiliência: A capacidade de um sistema para recuperar-se de falhas e continuar a funcionar.
Gestão: Processos de operações que mantém um sistema em execução na produção.
Segurança: Protegendo aplicativos e dados contra ameaças.
Escalabilidade
Escalabilidade é a capacidade de um sistema para lidar com aumento de carga. Existem duas maneiras principais que um aplicativo pode escalar. Escala vertical (aumento de escala) significa aumentar a capacidade de um recurso, por exemplo, usando um tamanho de VM maior. Escala horizontal (escalando fora) é a adição de novas instâncias de um recurso, como VMs ou réplicas de banco de dados.

A escala de nuvem real. Os aplicativos podem ser projetados para serem executados em centenas ou até milhares de nodes, alcançando escalas que não são possíveis em um único node.
Escala horizontal é elástica. Você pode adicionar mais instâncias se a carga aumentar ou removê-las durante períodos mais silenciosos.
O dimensionamento pode ser disparado automaticamente, seja em uma programação ou em resposta a alterações na carga.
A expansão pode ser mais barata do que a ampliação. Executar várias VMs pequenas pode custar menos que uma única grande VM.
O dimensionamento horizontal também pode melhorar a resiliência, adicionando redundância.

Se uma instância ficar inativa, o aplicativo continuará em execução.

Uma vantagem do dimensionamento vertical é que você pode fazer isso sem fazer alterações no aplicativo. Mas em algum momento você atingirá um limite, onde você não poderá mais escalar. Nesse ponto, qualquer escala adicional deve ser horizontal.

A escala horizontal deve ser projetada no sistema. Por exemplo, você pode dimensionar VMs colocando-as atrás de um load balancer. Mas cada VM no pool deve ser capaz de manipular qualquer solicitação do cliente, portanto, o aplicativo deve estar sem estado ou armazenar o estado externamente (digamos, em um cache distribuído). Os serviços de PaaS gerenciados geralmente têm dimensionamento horizontal e escalonamento automático integrados. A facilidade de escalonar esses serviços é uma grande vantagem do uso de serviços de PaaS.

Apenas adicionar mais instâncias não significa que um aplicativo será dimensionado, no entanto. Pode simplesmente empurrar o gargalo em algum outro lugar. Por exemplo, se você dimensionar um front-end da Web para lidar com mais solicitações de clientes, isso poderá acionar as contenções de bloqueio no banco de dados.

Sempre realize testes de desempenho e carga para encontrar esses possíveis gargalos. As partes com estado de um sistema, como banco de dados, são a causa mais comum de gargalos e exigem um projeto cuidadoso para dimensionar horizontalmente. Resolver um gargalo pode revelar outros gargalos em outros lugares.

Use a lista de verificação Escalabilidade para revisar seu design do ponto de vista da escalabilidade.
Disponibilidade
A disponibilidade é a proporção de tempo em que um sistema está funcional e funcionando. Geralmente é medido como uma porcentagem do tempo de atividade. Erros de aplicação, problemas de infraestrutura e carga do sistema podem reduzir a disponibilidade.

Um aplicativo de nuvem deve ter um Objetivo de Nível de Serviço (SLO) que defina claramente a disponibilidade esperada e como a disponibilidade é medida. Ao definir a disponibilidade, observe o caminho crítico. O front-end da Web pode ser capaz de atender a solicitações de clientes, mas se toda transação falhar porque não pode se conectar ao banco de dados, o aplicativo não estará disponível para os usuários.

A disponibilidade é geralmente descrita em termos de “9s” – por exemplo, “quatro 9s” significa 99,99% de tempo de atividade. A tabela a seguir mostra o possível tempo de inatividade cumulativo em diferentes níveis de disponibilidade.

% Tempo de atividade
Tempo de inatividade por semana
Tempo de inatividade por mês
Tempo de inatividade por ano

99%
1,68 horas
7,2 horas
3,65 dias

99,9%
10 minutos
43,2 minutos
8,76 horas

99,95%
5 minutos
21,6 minutos
4,38 horas

99,99%
1 minuto
4,32 minutos
52,56 minutos

99,999%
6 segundos
26 segundos
5,26 minutos

Observe que 99% de tempo de atividade pode resultar em uma interrupção de serviço de quase duas horas por semana. Para muitas aplicações, especialmente aplicações voltadas ao consumidor, isso não é um SLO aceitável.

Para muitas aplicações, especialmente aplicações voltadas ao consumidor, isso não é um SLO aceitável. Por outro lado, cinco 9s (99,999%) significam não mais do que 5 minutos de inatividade em um ano. É desafiador o suficiente apenas detectar uma interrupção tão rápida, quando mais resolver o problema. Para obter uma disponibilidade muito alta (99,99% ou mais), você não pode confiar na intervenção manual para se recuperar de falhas. A aplicação deve ser self-diagnosing e self-healing, que é onde a resiliência se torna crucial.

No Azure, o Acordo de Nível de Serviço (SLA) descreve os compromissos da Microsoft quanto a tempo de atividade e conectividade. Se o SLA de um determinado serviço for 99,5% isso significa que você deve esperar que o serviço esteja disponível 99,95% do tempo.

Os aplicativos geralmente dependem de vários serviços. Em geral, a probabilidade de um dos serviços ter tempo de inatividade é independente. Por exemplo, suponha que seu aplicativo dependa de dois serviços, cada um com um SLA de 99,9%. O SLA composto para ambos os serviços é de 99,9% x 99,9% ≈ 99,8% ou um pouco menos do que cada serviço por si só.

Use a lista de verificação de disponibilidade para revisar seu design de um ponto de vista de disponibilidade.
Resiliência
Resiliência é a capacidade do sistema de se recuperar de falhas e continuar a funcionar. O objetivo da resiliência é retornar o aplicativo a um estado totalmente funcional após uma falha ocorrer. A resiliência está intimamente relacionada à disponibilidade.

No desenvolvimento tradicional de aplicativos, houve um foco na redução do tempo médio entre falhas (MTBF). Esforço foi gasto tentando evitar que o sistema falhasse. Na computação em nuvem, é necessária uma mentalidade diferente, devido a vários fatores:

Os sistemas distribuídos são complexos, e uma falha em um ponto pode potencialmente se espalhar pelo sistema.
Custos para ambientes de nuvem são mantidos baixos através do uso de hardware commodity, portanto, falhas ocasionais de hardware devem ser esperadas.
Os aplicativos geralmente dependem de serviços externos, que podem ficar temporariamente indisponíveis ou limitar os usuários de alto volume.
Os usuários de hoje esperam que um aplicativo esteja disponível 24 horas por dia, 7 dias por semana, sem nunca ficar off-line.

Todos esses fatores significam em nuvem devem ser projetados para esperarem falhas ocasionais e se recuperarem deles. O Azure tem muitos recursos de resiliência já incorporados à plataforma. Por exemplo:

O armazenamento do Azure, o banco de dados SQL e o banco de dados do Cosmos fornecem replicação de dados incorporada, tanto em uma região quanto entre regiões.
Os discos gerenciados do Azure são colocados automaticamente em diferentes unidades de escala de armazenamento para limitar os efeitos de falhas e hardware.
VMs em um conjunto de disponibilidade estão espalhadas por vários domínios de falha. Um domínio de falha é um grupo de VMs que compartilham uma fonte de energia e um comutador de rede comuns. A disseminação de VMs em domínios de falha limita o impacto de falhas físicas de hardware, interrupções de rede ou interrupções de energia.

Dito isso, você ainda precisa criar resiliência em seu aplicativo. As estratégias de resiliência podem ser aplicadas a todos os níveis da arquitetura. Algumas atenuações são mais táticas por natureza – por exemplo, tentar novamente uma chamada remota após uma falha de rede transitória. Outras atenuações são mais estratégias, como o failover de todo o aplicativo para uma região secundária.

Mitigações táticas podem fazer uma grande diferença. Embora seja raro que uma região inteira sofra uma interrupção, problemas transitórios, como congestionamento da rede, são mais comuns – portanto, direcione-os primeiro. Ter o monitoramento e o diagnóstico corretos também é importante, tanto para detectar falhas quando elas ocorrem quanto para encontrar as causas-raiz.

Ao projetar um aplicativo para ser resiliente, você deve entender seus requisitos de disponibilidade. Quanto tempo de inatividade é aceitável? Isso é parcialmente uma função do custo. Quanto o tempo de inatividade potencial custará à sua empresa? Quanto você deve investir para tornar o aplicativo altamente disponível?

Use a lista de verificação Resiliency para revisar seu design do ponto de vista de resiliência.
Gestão do DevOps
Este pilar cobre os processos de operações que mantêm um aplicativo em execução na produção.

As implantações devem ser confiáveis e previsíveis. Eles devem ser automatizados para reduzir a chance de erro humano. Eles devem ser um processo rápido e rotineiro, para que não atrasem o lançamento de novos recursos ou correções de bugs. Igualmente importante, você deve poder retroceder ou avançar rapidamente se uma atualização tiver problemas.

Monitoramento e diagnóstico são cruciais. Os aplicativos em nuvem são executados em um datacenter remoto, no qual você não tem controle total da infraestrutura ou, em algum casos, do sistema operacional. Em um aplicativo grande, não é prático fazer login em VMs para solucionar um problema ou filtrar arquivos de log. Com os serviços de PaaS, talvez nem haja uma VM dedicada para fazer o login. O monitoramento do diagnóstico fornecem informações sobre o sistema, para que você saiba quando e onde as falhas ocorrem. Todos os sistemas devem ser observáveis. Use um esquema de log comum e consistente que permita correlacionar eventos entre sistemas.

O processo de monitoramento e diagnóstico tem várias fases distintas:

Instrumentação. Gerando os dados brutos, de logs do aplicativo, logs do servidor da web, diagnósticos incorporados na plataforma do Azure e outras fontes.
Coleta e armazenamento. Consolidando os dados em um só lugar.
Análise e diagnóstico. Para solucionar problemas e ver a integridade geral.
Visualização de alertas. Usando dados de telemetria para detectar tendências ou alertar a equipe de operações.

Use a lista de verificação do DevOps para revisar seu design de um ponto de vista de gerenciamento e DevOps.
Segurança
Você deve pensar em segurança durante todo o ciclo de vida de um aplicativo, desde o design e a implementação até a implantação e as operações. A plataforma do Azure fornece proteções contra uma variedade de ameaças, como invasão de rede e ataques DDoS. Mas você ainda precisa criar segurança em seu aplicativo e em seus processos de DevOps.
Segurança de aplicativos
Em geral, as práticas recomendadas de segurança para desenvolvimento de aplicativos ainda se aplicam à nuvem. Isso inclui coisas como o uso de SSL em todos os lugares, proteção contra ataques de CSRF e XSS, prevenção de ataques de injeção de SQL e assim por diante.

Fonte: Microsoft