Arquivo da categoria: DEVOPS

Modelos de migração IaaS para Azure parte 01

Modelos de migração IaaS para Azure parte 01

27 abr

Publicado por

Olá pessoal

Muita gente tem dúvida ou quer ter ideia de como levar seus, servidores, workloads e apps locais para nuvem.

Pois bem, o maior desafio e um administrador ou gestor é levantar informações para apresentar ao seu superior o investimento em capex que vai utilizar pelo menos nos próximos 5 anos.

Dependendo do levantamento o valor mesmo diluído pode até passar mais de 5 anos pagando seu capex através de financiamentos e o que investiu depreciou.

Isso é um tormento por que passa os 5 anos e novamente seu parque de hardware e software está ultrapassado.

E vai além por que dependendo do tempo você estende para mais tempo perdendo até em conhecimento e atualização de capacidade do time de TI.

A nuvem traz capacidade de investimento baixo inicial, capacidade de crescimento rápido, sazonalidade e elasticidade.

A orientação que estamos passando independe de nuvem e neste post irei mostrar como podemos decidir levar seus insumos para o Azure.

Normalmente o cliente quer levar “AS IS”, ou seja quer levar do jeito que é seu parque.

Mas para otimizar e melhorar o uso e adoção para jornada para nuvem o aconselhamento é analisar o quanto cada servidor ou aplicação está consumindo.

Quando você trabalhava com seu ambiente de hardware puro você avaliava o quanto sua aplicação estava consumindo e comprava um hardware com o dobro da capacidade para manter o ambiente com performance e espaço.

Depois veio a era da virtualização e já melhorou e deu disponibilidade de o ambiente ser migrado para outro ambiente de host com mais flexibilidade e rapidez de transferência de um host para o outro. Não se preocupando muito com o tamanho da máquina e mantendo ainda performance e espaço.

Com o advento da nuvem recebemos o boom da transformação e avaliar realmente o que pode ser feito e avaliar em detalhes o que o seu servidor esta consumido em alguns pilares:

  1. CONSUMO DE PROCESSAMENTO
  2. CONSUMO DE MEMORIA
  3. CONSUMO DE ESPAÇO EM DISCO
  4. CONSUMO DE I/O DE DISCO
  5. CONSUMO DE BANDA

Estes 5 pilares te credenciam preferencialmente em ambiente Iaas (Infraestrutura como serviço) a garantir que você terá um custo baixo com boa performance.

Para isso irei mostrar 2 ferramentas que você pode utilizar para avaliar ir para nuvem com saúde e performance.

Microsoft Azure Virtual Machine Readiness Assessment.

Esta ferramenta lhe traz um relatório e lista de verificação bem detalhado de Workloads e Servidores que estão prontos e gabaritados para nuvem Azure.

Para baixar esta ferramenta clique neste link https://go.microsoft.com/fwlink/?LinkId=391029&clcid=0x416

Instale a ferramenta que é bem simples e siga os passos.

Aguarde a instalação finalizar.

Ferramenta finalizada agora vamos analisar.

A ferramenta permite que eu faça analise de um ambiente Active Directory, SQL Server e Sharepoint.

Ele checa requisitos do ambiente para que você possa coletar de forma correta.

Alguns requisitos de banda são necessários para a analise.

Requisitos de Firewall são necessários para que a ferramenta possa analisar de forma correta.

Requisitos de localidade são importantes para que sejam criados ambiente no Azure.

Muito importante informa se o ambiente é de produção, dev ou teste.

Importante se o que você irá levar para o Azure será dados ou a imagem VHD e se os requisitos cobrem a levar imagem de sua máquina virtual ou física local.

Como mencionei acima é importante se a sua aplicação tem participação no uso de I/O de disco para que seja escolhido de forma correta os modelos de maquinas no Azure.

Se seu ambiente tem DR (Disaster Recover)

Neste caso está sendo coletado dados de um ambiente de Active Directory.

Finalizado irá gerar um relatório.

Salve em um diretório onde possamos ver o relatório de laboratório.

O relatório eu coloquei neste link para ser analisado que é montado um template com informações do Active Directory e através dele é possível informações de objetos de dados de servidores da sua rede.

Baixe aqui https://1drv.ms/w/s!An-dPolj_Ee_g5Qw45EZwP5FkwkErg

Fique ligado no próximo post

Até mais

Publicado em Azure, Cloud, DEVOPS, Virtualização

2 Comentários

Tags: ,

Transferências de dados com AZCOPY para Azure

Transferências de dados com AZCOPY para Azure

22 mar

Publicado por

Olá pessoal

Hoje irei demonstrar a vocês de uma forma fácil e barata a transferência de dados através do AZCOPY.

Se você já tem a familiaridade do XCOPY o AZCOPY é semelhante.

Além de você ter como ferramenta de transferência o Azure File Explorer ou o REDGATE Azure explorer o Azcopy é uma forma barata ou para automação através do Windows com Schedule.

O AzCopy pode ser baixado deste link ( http://aka.ms/downloadazcopy ). Para instalar, basta seguir as instruções de instalação.

A instalação é bem tranquila.

Depois de baixar siga com NEXT

Aceite os termos do contrato e siga com NEXT.

Escolha o diretório onde o software ficará armazenado e siga com NEXT

Continue com o procedimento e clique em INSTALL

Finalize a instalação com FINISH para continuarmos com o procedimento.

O modelo de conexão que iremos realizar é este abaixo.

@echo off

cd C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy

AzCopy /Source:C:\myFolder /Dest:https://myazureaccount.windows.net/myfileshare1 /DestKey:mydestKey /S /Y

Vejamos cada componente do comando AzCopy em detalhes:

  • / Source: – Especifica a origem do arquivo. Essa fonte pode ser armazenamento de arquivos regular ou qualquer uma das opções de armazenamento do Microsoft Azure . Neste caso, estamos especificando uma pasta em nossa unidade C.
  • / Dest: – Especifica o destino do comando. Se o destino for uma das opções de armazenamento do Microsoft Azure, será necessário especificar uma chave de destino para acessar o armazenamento.
  • / DestKey – Especifica a chave da conta de armazenamento para a chave de destino
  • / S – Define o modo para recursivo, o que fará com que o AzCopy copie todos os blob ou arquivos.
  • / Y – Confirma que o comando será feito do AzCopy

Agora você precisa criar um storage acount no Azure.

Acessamos o portal e criamos um storage como General purpose que o foco é transferência de arquivos como OBJETO em geral.

Lembrando que temos 4 tipos de arquivos como BLOCO, ARQUIVOS, TABELAS e FILAS.

Saiba mais aqui sobre ARMAZENAMENTO em https://docs.microsoft.com/pt-br/azure/storage/storage-introduction

Storage criado, vamos criar a pasta que vai receber os dados dentro de FILES. Iremos clicar em FILES e criar a pasta.

Clicamos em File Share e criamos a pasta

Criamos com nome como exemplo acima e configure o tamanho até 5120GB ou 5TB (Cinco terabyte) que é o tamanho máximo de casa pasta.

Pasta criada, e veremos o endereço URL e a chave para que faça sentido o comando AZCOPY para a cópia dos arquivos.

Em Connect teremos um exemplo para conexão e iremos usar como exemplo para utilizar o comando para transferir os dados.

AzCopy /Source:C:\myFolder /Dest:https://myazureaccount.windows.net/myfileshare1 /DestKey:mydestKey /S /Y

Seguindo o exemplo AzCopy /Source:C:\myFolder /Dest:https://myazureaccount.windows.net/myfileshare1 /DestKey:mydestKey /S /Y

A copia dos arquivos que fiz através da minha maquina é da pasta Documentos

C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy>AzCopy /Source:C:\Users\fpere\Documents\ /Dest:https://storagefabiosilva.file.core.windows.net/pastafabio /DestKey:C4br1VX27L8P67BFQ1yrr0U7qYnaZ2hFHIevE8Ph/999jXV0BOnisxAkUOuWDpIjXsXFnhbposten9jUtwpg6g== /S /Y

Veja que quando é dado o comando em amarelo ele mostra em tempo real os arquivos sendo transferidos.

Para conferir que os arquivos estão sendo transferidos através do portal vá na pasta criada e veja os arquivos.

Outra forma também de visualizar os arquivos podemos utilizar através no mapeamento em https://fabiosilva.com.br/2016/11/23/mapeando-storage-no-linux-e-no-windows-no-azure/ ou pelo Azure explorer ou Redgate Azure Explorer mencionado acima.

Arquivos transferidos finalizados com êxito.

Espero que tenham gostado.

Até o próximo post.

Publicado em Azure, Backup, DEVOPS

Deixe um comentário

Tags: , , ,

Automatização de ambiente com Ansible

Automatização de ambiente com Ansible

28 set

Publicado por

ansible

Você que tem ambientes grandes e complexos, ambiente com muitas maquinas hoje é até um pecado não automatizar ambiente.

Com o advento de Nuvem e virtualização cada vez mais teremos mais servidores e serviços separados com elasticidade.

O Ansible veio para automatizar ambiente e facilitar as tarefas chatas de atualização ou instalação de patchs e muito mais.

Eu não vou mostrar como instalar o Ansible pois é uma tarefa relativamente facil

yum install ansible ou apt-get e blá blá blá o google mostra o caminho a você que se interessar.

header2

Introdução

Ansible é um sistema de gerenciamento de configuração fácil que pode ser usada para automatizar e organizar suas tarefas de configuração do sistema para uma grande rede de computadores. Enquanto alguns outros sistemas de gerenciamento de configuração exigem muitos pacotes diferentes para ser instalado nos sistemas de servidor e cliente, com Ansible, você só precisa instalar um componente do servidor e ter acesso SSH para as máquinas clientes.

Neste guia, vamos discutir playbooks ansible, que são forma de criar scripts automatizados para configurar computadores clientes do Ansible.

Vamos supor que você tem um servidor Ansible configurado e alguns clientes.

No nosso guia, o servidor é um Ubuntu 12.04 máquina, e os clientes que vão ser configuração também são Ubuntu 12.04 máquinas, para facilidade de explicação.

Quais são Playbooks ansible?

Playbooks ansible são uma forma de enviar comandos para computadores remotos via script através do SSH. Em vez de usar comandos Ansible individualmente para configurar remotamente os computadores a partir da linha de comando, você pode configurar ambientes complexos inteiros por meio de um script para um ou mais sistemas.

Playbooks ansible estão escritos no formato de serialização de dados YAML. Se você não sabe o que é um formato de dados, pense nisso como uma maneira de traduzir uma estrutura de dados (listas, matrizes, dicionários, etc) em um formato que pode ser facilmente armazenado no disco. O arquivo pode então ser utilizada para criar a estrutura em um momento posterior. JSON é um outro formato  de dados popular, mas YAML é muito mais fácil de ler.

Cada cartilha contém uma ou mais peças, que mapeiam hosts para uma determinada função. Ansible faz isso através de tarefas, que são basicamente as chamadas em módulos.

Explorando um Playbook Básico

Veja o comando.

--- - hosts: droplets tasks: - name: Installs nginx web server apt: pkg=nginx 
state=installed update_cache=true notify: - start nginx handlers: 
- name: start nginx service: name=nginx state=started

Vamos em seções para que possamos entender como esses arquivos são construídos e que cada peça significa.

O arquivo começa com:

 ---

Este é um requisito para YAML para interpretar o arquivo como um documento adequado. YAML permite que vários “documentos” em um arquivo, cada um separado por --- , mas Ansible só quer um por arquivo, de modo que este só deve estar presente na parte superior do arquivo.

YAML é muito sensível ao espaço em branco, e usa isso para agrupar diferentes peças de informação em conjunto. Você deve usar apenas espaços e não tabs e você deve usar espaçamento consistente para o arquivo a ser lido corretamente. Itens no mesmo nível de recuo são considerados elementos irmãos.

Os itens que comecem com um - são considerados itens da lista. Os itens que têm o formato de key: value operar como hashes ou dicionários. Isso é muito bonito tudo o que há para YAML básica.

Documentos YAML, basicamente, definir uma estrutura de árvore hierárquica com os que contêm elementos mais à esquerda.

Na segunda linha, temos o seguinte:

 --- - hosts: droplets

Este é um item de lista no YAML como aprendemos acima, mas uma vez que é no mais à esquerda do nível, é também uma “peça” Ansible. Peças são basicamente grupos de tarefas que são executadas em um determinado conjunto de hosts, que lhes permitam cumprir a função que deseja atribuir a eles. Cada jogo deve especificar um host ou grupo de exércitos, como fazemos aqui.

Em seguida, temos um conjunto de tarefas:

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - start nginx

No nível superior, temos “tarefas:” no mesmo nível “hosts:”. Este contém uma lista (porque começa com um “-“), que contém pares chave-valor.

O primeiro, “nome”, é mais do que uma descrição do que um nome. Você pode chamar isso de qualquer coisa que você gostaria.

A próxima chave é “apto”. Esta é uma referência a um módulo Ansible, assim como quando usamos o comando ansible e digitar algo como:

 ansible -m apt -a 'whatever' all

Este módulo permite especificar um pacote e o estado que ele deve estar em, que é “instalado” no nosso caso. O update-cache=true parte diz a nossa máquina remota para atualizar seu cache de pacotes (apt-get update) antes de instalar o software.

O item “notificar” contém uma lista com um item, o que é chamado de “começar nginx”. Este não é um comando interno Ansible, é uma referência a um manipulador, que pode executar determinadas funções quando é chamado a partir de uma tarefa. Vamos definir o “start nginx” manipulador abaixo.

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - 
start nginx handlers: - name: start nginx service: name=nginx state=started

A seção “manipuladores” existe ao mesmo nível que os “hosts” e “tarefas”. Manipuladores são como tarefas, mas eles só correr quando lhes foi dito por uma tarefa que ocorreram alterações no sistema do cliente.

Por exemplo, temos um manipulador aqui que inicia o serviço Nginx após o pacote é instalado. O manipulador não é chamado a menos que o “Instal servidor web nginx” resultados da tarefa em mudanças no sistema, o que significa que o pacote teve de ser instalado e já não estava lá.

Nós podemos salvar este em um arquivo chamado algo como “nginx.yml”.

Só por algum contexto, se você fosse escrever esse mesmo arquivo em JSON, que poderia ser algo como isto:

 [ { "hosts": "droplets", "tasks": [ { "name": "Installs nginx web server", 
"apt": "pkg=nginx state=installed update_cache=true", "notify": [ "start nginx" ] } ], 
"handlers": [ { "name": "start nginx", "service": "name=nginx state=started" } ] } ]

Como você pode ver, YAML é muito mais compacto e maioria das pessoas diria mais legal.

Executando um Ansible Playbook

Depois de ter um guia estratégico construído, você pode chamá-lo facilmente usando este formato:

 playbook.yml ansible-playbook

Por exemplo, se queríamos para instalar e iniciar o Nginx em todos os nossos servidores, poderíamos emitir este comando:

 ansible-playbook nginx.yml

No entanto, se nós gostaríamos de filtrar a lista , aplicar-se apenas a um desses hospedeiros, podemos adicionar um sinalizador para especificar um subconjunto dos arquivos:

 ansible-playbook -l host_subset playbook.yml

Então, se nós só quesermos instalar e executar o Nginx em um servidor, por exemplo “host3”, que poderia digitar o seguinte:

 ansible-playbook -l host3 nginx.yml

Adicionando recursos ao Playbook

Agora a nossa cartilha tem esta aparência:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

É simples e funciona, em vários hosts ou em um só.

Podemos começar a expandir a funcionalidade através da adição de tarefas.

Adicionar um padrão Index Arquivo

Podemos dizer-lhe para transferir um arquivo do nosso servidor Ansible no host, adicionando algumas linhas como este abaixo:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644

  handlers:
    - name: start nginx
      service: name=nginx state=started

Podemos, então, fazer um diretório chamado static_files em nosso diretório atual e coloque um arquivo index.html dentro.

 mkdir static_files nano static_files/index.html

Dentro desse arquivo, vamos apenas criar uma estrutura básica html:

 <html> <head> <title>This is a sample page</title> </head> <body> 
<h1>Here is a heading!</h1> <p>Here is a regular paragraph. Wow!</p> 
</body> </html>

Salve e feche o arquivo.

Agora, quando executar novamenter o playbook, Ansible irá verificar cada tarefa. Vai ver que Nginx já está instalado no host, por isso vai deixá-lo ser. Ele vai ver a nova seção tarefa e substituir o arquivo index.html padrão com o do nosso servidor.

Resultados

Quando instalar e configurar os serviços manualmente, é quase sempre necessário saber se suas ações foram bem-sucedidas ou não. Podemos cozinhar essa funcionalidade em nossos playbooks usando “registrar”.

Para cada tarefa, que pode, opcionalmente, registrar seu resultado (sucesso ou falha) em uma variável que podemos verificar mais tarde.

Ao utilizar esta funcionalidade, também temos de dizer Ansible para ignorar erros para essa tarefa, já que normalmente ele aborta a execução cartilha para aquela máquina se qualquer problema acontece.

Assim, se quiser verificar se uma tarefa falhou ou não para decidir sobre os passos subsequentes, podemos usar a funcionalidade de registo.

Por exemplo, poderíamos dizer o nosso guia estratégico para carregar um index.php  se ele existir. Se essa tarefa falhar, poderíamos em vez de tentar carregar um index.html. Vamos verificar a condição de falha na outra tarefa, porque nós só queremos fazer o upload do arquivo HTML se o arquivo PHP falhar:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.php for host
      copy: src=static_files/index.php dest=/usr/share/nginx/www/ mode=0644
      register: php
      ignore_errors: True

    - name: Remove index.html for host
      command: rm /usr/share/nginx/www/index.html
      when: php|success

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644
      when: php|failed

  handlers:
    - name: start nginx
      service: name=nginx state=started

 

Esta nova versão tenta carregar um arquivo de índice PHP para o local indicado. Ela regista com sucesso da operação em uma variável chamada “PHP”.

Se esta operação foi bem sucedida, a tarefa ira remover o arquivo index.html é executado em seguida.

Se a operação falhar, o arquivo index.html é carregado em vez disso.

Conclusão

Agora, você deve ter um bom controle sobre como automatizar tarefas complexas usando Ansible.

Este é um exemplo básico de como você pode começar a construir a sua biblioteca de configuração.

Combinando definições de host e do grupo como nós aprendemos sobre este tutorial, e com variáveis disponíveis para preencher as informações, podemos começar a montar sistemas complexos que interagem uns com os outros. Em um artigo futuro, vamos discutir como implementar variáveis em nossos playbooks e criar funções para ajudar a gerenciar tarefas complexas.

Como ainda falamos de nuvem o Ansible em ambiente IaaS publico ou não é ideal.

Teste no Azure e Amazon e não precisa falar que ambiente Onpremisses, todos funcionaram.

Tem um demo sensacional no site oficial:

https://www.ansible.com/

Veja um howto facil.

Se você quer seguir para um caminho de DEVOPS o Ansible é a porta de entrada.

Espero ter ajudado.

Abraços

 

Publicado em DEVOPS, Linux

Deixe um comentário

Tags: ,

DevOps: saiba como ela pode promover a segurança da informação

DevOps: saiba como ela pode promover a segurança da informação

15 abr

Publicado por

devops

A segurança da informação é hoje uma das grandes preocupações das empresas de todos os portes. E não era para menos, as ameaças não param de aumentar. Um levantamento feito pela Symantech no início de fevereiro detectou que as empresas brasileiras receberam mais de 40 mil spams para roubo de dados em apenas oito dias. Isso mostra o quanto os hackers estão interessados em invadir contas de e-mails para, a partir delas, chegar aos servidores e colocar em ameaça informações sensíveis como transações financeiras entre outras.

Além das crescentes tentativas de ataques externos por phishing, as próprias vulnerabilidades das soluções desenvolvidas pelas empresas, que agora lidam com um pool muito grande de ferramentas e equipamentos tecnológicos, podem ameaçar a segurança da informação. E, nós sabemos, é muito comum que as equipes de projetos de segurança sejam também responsáveis pela operação da segurança, quando não são também responsáveis por outras áreas de TI. Este dia a dia corrido sobrecarrega os profissionais que, por sua vez, deixam involuntariamente brechas em algum ponto do processo.

E a segurança da informação, neste processo, também se torna uma preocupação das equipes de desenvolvimento, cada vez mais pressionadas para entregar aplicações com agilidade e eficácia.

A boa notícia é que na mesma proporção também crescem os esforços para manter os dados corporativos seguros. Você sabia que a metodologia DevOps pode ajudar a promover a segurança da informação no processo de desenvolvimento da sua empresa? É sobre isso que vamos conversar neste artigo. Confira!

Antes de tudo, vamos relembrar rapidamente o que é, afinal, a DevOps:

O que é DevOps?

Nascido da necessidade de melhorar a entrega de serviços agilidade, o movimento DevOps enfatiza comunicação, colaboração e integração entre desenvolvedores de software e operações de tecnologia da informação (TI). Ao invés de ver estes dois grupos como silos, ou seja, departamentos separados que não trabalham juntos, DevOps reconhece a interdependência das operações de desenvolvimento de software e de TI e ajuda no desenvolvimento mais ágil, com iterações mais frequentes.

Em outras palavras, trata-se de uma metodologia de desenvolvimento de software que cumpre a difícil missão de integrar desenvolvedores de software e profissionais de infraestrutura de TI. E desta integração nascem benefícios como padronização dos desenvolvimentos de desenvolvimento, facilitação da gestão de lançamentos de novas versões, controle e documentação de relatórios, menor tempo de entrega do software, além de diminuir as chances de erros e problemas com testes de qualidade.

Dito isso, vamos agora à explicação de como é possível conseguir mais segurança da informação com a utilização da metodologia DevOps!

Como DevOps promove a segurança da informação?

As organizações adotam a metodologia DevOps para agilizar o processo de desenvolvimento através da combinação de várias etapas em um único processo, automatizado. Assim, diferentemente do processo tradicional de desenvolvimento (cascata), os profissionais de TI de todas as áreas trabalham em conjunto desde o início para reduzir drasticamente o tempo para lançar um produto. Em vez de continuar a existir como um autônoma, entidade isolada de segurança, a segurança da informação passa a ser integrada no processo desde o início.

Dito de outra forma: o método DevOps integra uma série de áreas funcionais, incluindo a segurança, para o produto final. Assim,  a entrada de todos os envolvidos no desenvolvimento começa mais cedo e, em seguida, o processo é automatizado para garantir tempos de liberação previsíveis, curtos e de qualidade. O resultado? Soluções mais seguras, menos vulneráveis, entregues em menos tempo.

Vamos a um detalhamento maior desta proposição:

DevOps promove análises verificativas desde o início do processo de desenvolvimento

Ao usar a metodologia DevOps, a equipe de desenvolvimento preza por fatores relacionados à confiabilidade, proteção e análise do desempenho desde as primeiras etapas. Além disso, DevOps permite ao gestor o monitoramento mais apurado de tudo o que envolve os esforços de desenvolvimento e testes.

DevOps requer testes em todas as etapas do desenvolvimento

Ao invés de começar a fazer testes somente quando o produto estiver finalizado, com DevOps, as equipes testam a performance da aplicação etapa por etapa. Assim fica mais fácil identificar falhas, desajustes, aplicações incompletas e necessidades ainda não supridas pelas funcionalidades. Podemos dizer que o software é corrigido de forma mais instantânea, permitindo que as outras etapas tenham um grau de confiança maior.

DevOps promove a sincronização das equipes permitindo múltiplos mecanismos de autenticação

O método DevOps pode ser disponibilizado em uma ferramenta multi-inquilino (funcionando em ambientes híbridos). Isso permite diversos mecanismos de autenticação, inclusive no próprio servidor. Isso faz com que as equipes trabalhem mais sincronizadas, fazendo com que os erros involuntários, muitas vezes causados por má interpretação de requisitos, sejam mitigados.

DevOps traz mais poder de intervenção durante o desenvolvimento

A dinâmica do processo de desenvolvimento trazida pela metodologia DevOps facilita a detecção de falhas. Isso faz com que os profissionais envolvidos consigam intervir em tempo para fazer as correções e não comprometer as etapas posteriores.

DevOps é um novo paradigma para profissionais de desenvolvimento e segurança da informação — uma conclusão

Em suma, podemos resumir que a metodologia DevOps traz mais segurança no código (testes ao longo do desenvolvimento), correções ao longo do processo (no processo tradicional, os testes são feitos ao final), traz os profissionais de segurança da informação para o meio do processo de desenvolvimento, o que também melhora a detecção de vulnerabilidades e as correções e promove uma cultura de prevenção.

DevOps é, portanto, não só uma cultura de desenvolvimento mais ágil e de integração das equipes de desenvolvedores com a operação de TI, mas também é um salto em matéria de segurança da informação. Trata-se de um método que faz com que a segurança deixe de ser um ponto isolado, passe a fazer parte de todo o desenvolvimento da aplicação. E isso é também um novo paradigma para os profissionais de TI que estão, cada vez mais, em busca de maior agilidade e assertividade em suas entregas.

Você já utiliza a metodologia DevOps no desenvolvimento? Quer saber mais sobre o assunto? Baixe grátis o e-book: ‘Guia Rápido DevOps — Aprenda de maneira simples o que é e como implantar DevOps’.

 

Publicado em DEVOPS, Segurança da Informação, Uncategorized

Deixe um comentário

Tags: ,

Você sabe o que é DEVOPS?

2 jun

Publicado por

O que é DevOps afinal?//

O que é DevOps afinal?

Mar 16th, 2013 | Comments

1. Papo sobre DevOps

Hoje vim falar sobre a buzzword DevOPs. Algumas pessoas tem me procurado pelo blog para conversar sobre este termo, e normalmente eles querem que eu responda as seguintes perguntas:

  1. O que significa DevOps?
  2. DevOps é um movimento?
  3. DevOps é uma filosofia, é um conceito ou uma cultura?
  4. DevOps é uma metodologia?
  5. DevOps é algum tipo de ambiente ou grupo de ferramentas ?
  6. O especialista DevOps é um devel que entende de infra?
  7. O especialista DevOps é um sysadmin que entende de devel?
  8. DevOps é um cargo? é um setor ou um departamento?
  9. DevOps só funciona em startups ou serve para o ambiente corporativo?
  10. O DevOps é algo novo?

Ao longo do texto eu pretendo responder a todas estas questões, mas para respondê-las vamos precisar entender algumas coisas antes.

2. Como tudo começou?

Para que possamos compreender de forma plena, precisamos ir ao cerne desta história. O movimento DevOPs não começou em um lugar só, existem muitos lugares que dão pistas sobre as origens do termo, mas aparentemente as informações mais concretas sobre as origens deste movimento nos levam ao ano de 2008. Neste ano, começaram a utilizar o termo infraestrutura ágil em algumas listas de discussão com foco em desenvolvimento ágil, e na mesma época durante evento Agile 2008, surgiram conversas que abordavam o tema metodologia ágil para a administração de infraestrutura, inspirada no modelo ágil de desenvolvimento, no entanto, foi a lista de discussão européia com nome agile-sysadmin que começou a abordar o tema com propriedade, com isso ela ajudou a colocar os primeiros tijolos na ponte que faria a ligação entre developers e sysadmins. Um dos participantes desta lista era Patrick Debois (@patrickdebois), além de muito ativo ele era e ainda é um grande entusiasta do assunto.

O termo DevOPS só foi criado de fato em 2009 durante a conferência Velocity da O’Reilly, nesta conferência John Allspaw (Etsy.com) e Paul Hammond (Typekit) apresentaram o trabalho 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, veja abaixo os slides desta palestra.

A palestra acima deixou Patrick Debois muito animado, foi então que ele teve a ideia de criar um encontro chamado DevOpsDay, este encontro ocorreu em Ghent no final de 2009, foi um encontro de dois dias e aparentemente foi lá que tudo começou.

De lá para cá, Patrick Debois, Gildas Le Nadan, Andrew Clay Shafer, Kris Buytaert, JezzHumble, Lindsay Holmwood, John Willis, Chris Read, Julian Simpson, R.I.Piennar (mcollective) e muitos outros levaram o evento para diversas localidades, dentre elas:

  • New York 2012
  • Rome 2012
  • Mountain View 2012
  • India 2012
  • Tokyo 2012
  • Austin 2012
  • Goteborg 2011
  • Bangalore 2011
  • Melbourne 2011
  • Mountain View 2011
  • Boston 2011
  • Göteborg 2011
  • Sao Paulo 2010
  • Hamburg 2010
  • Mountain View 2010 (video intro)
  • Sydney 2010
  • Ghent 2009

É importante falar que ao levar o evento para diversos países, estas pessoas foram responsáveis por disseminar a cultura DevOps pelo globo, com isso, direta ou indiretamente eles se tornaram a força motriz de uma discreta revolução no mundo da TI.

Inicialmente a cultura DevOps se mostrou muito presente no ambiente das startups, porém, algum tempo depois começou a fazer parte do mundo corporativo, aqui neste texto procuro trazer a visão da cultura DevOps no meio corporativo.

Na abertura do evento DevOpsDay há sempre um vídeo de intro, veja dois deles:

Ghent 2009

Mountain View 2010

3. DevOps Manifest

Apesar de terem organizado o DevOpsDays em diversos países, não foi estabelecido um manifesto para o assunto, logo existem muitas interpretações acerca deste termo.

Mas antes de argumentar acerca do possível conteúdo de um manifesto DevOps, primeiro temos que entender a dinâmica na relação entre as áreas de infraestrutura (infra) e desenvolvimento (devel).

4. Analisando Infra e Devel

Para entender melhor o que DevOps significa, precisamos então analisar de forma prática e direta a vida de sysadmins, desenvolvedores e o cotidiano destas áreas, eu espero que isto lhe ajude a compreender melhor o assunto adiante.

Vamos imaginar – hipoteticamente – uma empresa de comunicação que desenvolve aplicações web em sua maioria para portais de notícias, e em alguns casos também faz aplicações web internas (rh, financeiro, administrativo), nessa empresa o devel trabalha com PHP, PYTHON, RUBY e JAVA.

Para um melhor entendimento, considere as duas características abaixo como cotidianas nesta empresa fictícia:

  1. O Devel está começando a trabalhar com metodologias ágeis (pró-ativo, evolutivo e contínuo).
  2. A Infra continua trabalhando no modelo tradicional de administração (manual, caótico e reativo).

4.1 Infra em foco

A infra é composta em parte pelos sysadmins, estes rapazes e moças tem a missão de manter os sistemas funcionando, são eles que fazem os deploys e os rollbacks das aplicações do devel, é responsabilidade deles manter o ambiente de produção intacto.

Os sysadmins tem que rodar as aplicações, monitorar o funcionamento, a performance, avaliar e propor melhorias de forma a manter as aplicações sob seu cuidado a pleno vapor – rodando de forma rápida e estável, além disto, eles devem planejar as mudanças com cautela, tentando minimizar os riscos envolvidos.

Eles se preocupam com segurança, estabilidade e principalmente com o acordo de nível de serviço (SLA) de cada produto sob sua responsabilidade, esta preocupação é fundamental para o negócio.

Entenda que se uma aplicação parar de funcionar isto vai impactar no SLA, podendo significar perdas financeiras significativas relacionadas ao produto, afinal produto fora significa cliente insatisfeito e prejuízo, seja ele financeiro, seja ele institucional, e no caso da sustentação do produto, isto significa que a prestadora do serviço, neste caso a empregadora dos sysadmins, pode ser multada. De toda o jeito, o que ocorre de forma direta é diminuição do valor do negócio.

Em resumo, a infra (sysadmins) se preocupa em proteger o valor do négocio.

4.2 Devel em foco

O devel é composto em parte por desenvolvedores, estas moças e rapazes trabalham com lógica e criatividade, eles passam boa parte de seu tempo codificando soluções, e focam seu trabalho nos requisitos que o analista conseguiu mapear junto ao cliente.

Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos recursos solicitados.

Nova versão significa novo deploy, e caso ocorra algum problema, isto irá demandar um rollback, ambos procedimentos envolvem equipes de infra.

Em resumo, podemos dizer que o devel se preocupa em aumentar o valor do negócio.

4.3 Onde está o conflito?

Os desenvolvedores querem colocar suas aplicações no ar o mais rápido possível, no entanto os sysadmins querem ter certeza que a aplicação está estável o suficiente para entrar em produção sem gerar incidentes.

Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras tão rígidas que só permitiam deploy uma vez por semana – em casos mais rígidos apenas uma vez por mês, tudo isto pensando em proteger o negócio.

Com o devel mudando de metogologia, nem preciso dizer que esse método de deploy – uma vez por semana – não combina com desenvolvimento ágil, com isso a infra teve que evoluir a fórceps, e quem antes fazia deploy uma vez por semana, teve que aprender a fazer várias vezes por dia.

É claro que a infra trabalhando com os métodos que estava acostumada (deploy 1 vez por semana e manual) não dava vazão as demandas, e também é óbvio que o devel não possuía uma infra adequada para fazer o desenvolvimento de forma contínua.

Além de tudo isso, normalmente o devel não conhece e não tem como prever aspectos importantes relativos a infra que fica de cara para o cliente, portanto, quando a aplicação vai para produção, normalmente ocorrem – constantes – pequenos incidentes que geram uma enorme perda de valor no negócio. Traduzindo, são aqueles ajustes na aplicação que precisam ser feitos de última hora pois o ambiente devel é completamente diferente da produção.

O cliente por sua vez reclama – com razão – e depois a gerência de TI ficava tentando encontrar o dono do problema (caça as bruxas), de um lado devel dizendo que infra é engessada, lenta e que não oferece um ambiente adequado para desenvolverem suas aplicações, do outro lado a infra dizendo que o devel faz código ruim e instável e que não é culpa deles se a aplicação não funciona.

Eu sou de infra há muitos anos, mas tenho que dizer que a infra devido a culturas arcaicas de administração, heranças do tempo dos mainframes, tem mais culpa no cartório neste cenário, porém o devel também tem seus problemas, afinal, como estão começando a aplicar métodos ágeis, ainda estão criando a cultura de execução de testes e garantia de qualidade (QA).

4.3.1 Incidentes

Quando ocorre algum incidente, você vai ouvir da infra falando para o devel que o problema não são as máquinas, é o código, e certamente o devel vai falar para infra que o problema não é o código, são as máquinas, e provavelmente ainda vão dizer que o sistema está funcionando no notebook deles, e infelizmente isso será algo cotidiano.

Espero que neste ponto você já esteja enxergando o problema.

É preciso entender que infra e o devel trabalham em nichos, cada um no seu quadrado, cada um em sua realidade e nenhum deles está muito disposto a mudar sua cultura, nenhum deles está disposto a ceder. A infra não conhece o devel e não sabe como mudar para ajudá-los, o devel não conhece a infra e não sabe como pedir o que precisam.

No final das contas, as pessoas não conseguem estabelecer uma forma sadia e eficiente de comunicação, e com isso, não existe trabalho colaborativo entre estas duas áreas.

4.4 O combustível do conflito

Acima eu apresentei o conflito comum entre as áreas, porém existe o combustível que o mantém acesso, e esse combustível é o comportamento do sysadmin, portanto, há de fato uma razão para se ter tanto ódio deles, vamos a elas:

  • Eles falam não
  • Eles falam não pela segunda vez
  • Eles falam não pela terceira vez
  • Eles falam não o tempo todo por diversas razões, para diversos pedidos
  • Eles demoram, atrasam e perdem prazos de atendimento
  • Eles se recusam a quebrar as coisas mesmo que seja para encontrar o problema
  • Eles se preocupam com UPTIME e não com o negócio
  • Eles acham que o devel só quer saber de perfumarias e coisas do gênero
  • Eles não se esforçam para ajudar o devel a encontrar o problema
  • Eles acham que o problema do devel não é problema deles
  • Eles não conseguem enxergar o negócio e não enxergam que infra e devel são parte de um todo

E isso tudo faz parte daquele comportamento arcaico que eu já mencionei, eu quis reforçar isto pois é bom mostrar as raizes de um problema para ajudar na reflexão do que é preciso mudar.

Veja que tal comportamento é inaceitável e incompatível com o mundo de hoje, mesmo assim ainda é muito comum encontrar pessoas que possuem este tipo de atitude e perfil.

4.5 Uma pitada de realidade

Lembra que eu disse que a infra se preocupa em proteger o negócio e o devel se preocupa com as formas de agregar valor ao negócio?

Esqueça o que eu disse, isso funcionava nos anos 70/80/90, mas hoje isso não é suficiente.

A infra deve entender que sua obrigação é oferecer os meios para fazer o negócio fluir, e isso também é papel do devel.

Ambas equipes precisam mudar a forma de pensar e de agir, porém é preciso ter consciência de que mudanças estão associadas a problemas, uma mudança pode quebrar seu produto e afetar o seu negócio.

Então qual é a receita mágica?

Como mudar sem afetar o negócio?

4.6 Mudanças necessárias

A infra previsa evoluir, e precisa fazer isto rapidamente.

O devel predisa ter controle de todas as fases do deploy.

A infra precisa começar a trabalhar de forma automatizada e dinâmica, precisa ser mais veloz para subir novos ambientes ou mesmo reconstruir/duplicar os ambientes existentes para suprir as necessidades do devel, não dá mais para trabalhar de forma manual e usar as mesmas metodologias da época dos mainframes.

O devel precisa conseguir passar para infra suas necessidades de forma clara, e tem que se esforçar para fazer a infra entender isto – e eles não vão entender na primeira vez.

4.6.1 Busca de soluções

E foi a busca de soluções para estas necessidades que motivou importantes discussões no mundo da TI, foi então que começaram a falar de ‘Infraesturura ágil’ no ano de 2008, vamos agora entender o que é isso.

5. Infraestrutura ágil

5.1 Infraestrutua como código

A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências, são elas virtualization e cloud computing. Desde 2003 empresas começaram a conviver com ambientes virtualizados, logo um parque com poucas máquinas físicas poderia se tornar um parque com dezenas máquinas virtuais, e após o recente advento da Cloud, dezenas de máquinas virtuais podem se tornar centenas ou milhares de instâncias a serem administradas na nuvem.

Não havia mais espaço para se trabalhar infraestrutrua da forma tradicional, foi necessário dar um passo a diante e pensar em infraestrutura como código, principalmente quando paramos para analisar o recente boom das startups, empresas pequenas com produtos de enorme alcance, produtos que rodam em centenas de instâncias na nuvem, atendendo milhões de usuários, e tudo isso é administrado por equipes mínimas.

O objetivo é fazer deploy não só de aplicações, mas deploy de infraestrutura de forma rápida e controlada.

Isso significa que se você precisa subir um ambiente JBOSS você vai fazer isto em poucos minutos e não em dias.

5.2 Ferramentas de infraestrutura ágil

Quando se fala em infraestrutura ágil o que vem a mente são ferramentas, e de fato elas são parte disto.

Basicamente temos três tipos de ferramentas, são elas:

  1. Orquestradores
  2. Ferramentas para gerenciamento de configurações
  3. Ferramentas para bootstrapping e provisionamento

Orquestradores são ferramentas que nos permitem executar comandos e controlar nodes/instâncias de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective.

Ferramentas de gerência de configuração normalmente controlam estados de seu sistema, ajudam a centralizar toda as configurações e facilitam a administração e criação de novos ambientes. Algumas delas são Puppet, Chef, Cfegine e Salt.

Ferramentas de bootstrapping são aquelas que nos ajudam a instalar um sistema operacional seja em uma máquina física, seja em um máquina virtual, seja em uma instância na nuvem, dentre elas temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente, existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.

A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura ágil.

Mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.

5.3 Equipe de infraestrutura ágil

Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de organização, normalmente estas equipes estão trabalhando seguindo estes eixos:

  1. Versionamento do código e arquivos de configuração (git)
  2. Organização de atividades de forma visual (KANBAN BOARD)
  3. Trabalho em pares
  4. Divisão das atividades em sprints
  5. Reuniões ágeis diárias (standup meeting de 10 minutos – em pé)
  6. Reuniões ágeis periódicas (retrospectiva e planejamento de sprints).

Parece com SCRUM mas não é, mas é fortemente inspirado nele e no Kanban.

5.4 Então DevOps e Infraestrutura ágil são a mesma coisa?

Não, infraestrutura ágil é parte da cultura DevOps.

DevOps depende de infraestutura ágil, mas ainda tem muito mais.

Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de mudanças principalmente no meio corporativo.

6. Cultura DevOps

Chegou a hora de entrar neste assunto, agora nós vamos aprofundar nossos estudos em relação a cultura DevOps.

6.1 Características da cultura DevOps

Para entender a cultura devops sem fazer um texto muito longo, vou pontuar as suas principais características – em minha opinião.

6.1.1 Em relação as características da cultura

Patrick Debois (foi quem cunhou o termo) diz que DevOPs essencialmente é uma cultura, e a descreve utilizando 4 eixos, são eles:

  • Cultura
    • Colaboração
    • Fim das divisões
    • Relação saudável entre as áreas
    • Mudança de comportamento
  • Automação
    • Deploy
    • Controle
    • Monitoração
    • Gerência de configuração
    • Orquestração
  • Avaliação
    • Métricas
    • Medições
    • Performance
    • Logs e integração
  • Compartilhamento
    • O feedback é tudo
    • Boa comunicação entre a equipe

Eu prentendo detalhar um pouco mais estes eixos, vamos lá.

6.1.2 Em relação as características técnicas

Um ambiente DevOps deve ter/possuir/oferecer/permitir:

  • Infraestrutura como código
  • Orquestração de servidores
  • Gerência de configurações
  • Provisionamento dinâmico de ambientes
  • Controle de versões compartilhado entre infra e devel
  • Ambiente de desenvolvimento, teste e produção (no mínimo)
  • O ambiente de devel deve possibilitar TDD
  • Infra deve participar dos projetos desde o início [1]
  • Infra deve participar das reuniões de devel [2]
  • Devel deve participar das reuniões de infra [3]
  • Ambiente de entrega contínua [4]
  • Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5]
  • Monitoramento eficaz com processamento adequado dos eventos e métricas
  • Capacidade de resposta rápida a incidentes e problemas
  • Backup e restore confiável

[1] O devel precisa envolver a infra nos projetos desde o início – isso significa participar das reuniões técnicas ou SCRUM, afinal sem a infra não há projeto, e além disto, quanto mais problemas foram resolvidos durante o projeto – com ajuda da infra, menos problemas serão expostos aos clientes.

[2] A infra também precisa observar quais são as metas da empresa a longo prazo, principalmente aquelas ligadas ao devel, pois enxergando onde o devel quer chegar, ela pode se programar melhor para ter certeza que a infraestrutura tecnológica estará preparada para atendê-los quando esse momento chegar.

[3] A infra precisa envolver o devel em suas reuniões técnicas para que o devel entenda e tenha ciência da realidade da infra, assim eles vão conseguir enxergar suas qualidades, atribuições, planos de melhorias, atualizações programadas, agendas de manutenção, eles vão conhecer os recursos disponíveis e também descobrir a limitações da equipe, sejam elas técnicas, sejam materiais. Além disto, o devel pode ser um grande aliado da infra na solução de problemas, afinal o conhecimento que o devel traz pode ajudá-los a melhorar a forma com que administram seu ambiente, tornando este processo mais eficiente.

[4] O devel precisa adotar alguma metodologia de entrega ou desenvolvimento contínuo e a infra precisa entender esse processo para que juntos criem os ambientes com as ferramentas certas.

[5] A infra precisa ceder um pouco e evoluir, precisa oferecer ao devel um ambiente adequado onde eles sejam o dono do produto, onde o devel consiga fazer todo o ciclo de desenvolvimento de forma direta, o devel precisa conseguir gerar e controlar o código, precisa fazer o commit com segurança, precisa fazer o build, testar o build, validar a aplicação e entregar a nova versão de forma transparente sem que para isso precise passar por um burocrático e engessado processo de mudança.

6.1.3 Em relação aos valores humanos

Para a adoção da cultura funcionar, a equipe precisa observar e exercitar os seguintes valores:

  • Confiança no trabalho de sua equipe
  • Respeito pessoal e profissional por todos da equipe
  • Sinceridade sobre eventos e incidentes ocorridos
  • Honestidade sobre as causas dos incidentes (não esconda nada da sua equipe)
  • Entendimento de que o problema é responsabilidade de todos
  • Entendimento de a solução é responsabilidade de todos
  • Entendimento de que os resultados são o reflexo do trabalho de toda a equipe
  • Comunicação efetiva e dinâmica
  • Postura construtiva sempre
  • Espírito de colaboração

6.1.4 Em relação a forma de trabalho

É recomendavél que a equipe:

  • Internalize e adapte métodos ágeis como KABAN e SCRUM para seu dia-a-dia
  • Aprofunde estudos em entrega contínua
  • Aprofunde estudos em gerência de configurações e orquestração

Acho que é isso, características técnicas, valores humanos e forma de trabalhar, espero que tenha ficado claro para você.

6.2 Aplicando a cultura

Após observar as principais características deste movimento, normalmente pensamos em como aplicar isto em nosso meio. Para ajudar na reflexão vamos avaliar o meio startup e o meio corporativo.

6.2.1 A realidade no ambiente startup

A cultura DevOPs combina muito com startups, nestes locais normalmente já se trabalha desenvolvimento utilizando metologias ágeis, foi inclusive neste nicho em que começaram a discutir infraestrutura ágil – a precursora do movimento devops, portanto, as pessoas deste meio conseguem absorver os conceitos e a cultura DevOPs sem grandes dificuldades, eles conseguem compreender os preceitos de colaboração e feedback pois já fazem isto em seu dia-a-dia.

Quem está uma startup não tem as amarras e vícios da coporação, este é um grande facilitador e não é necessário nenhum tipo de intervenção para internalizar a cultura, a partir do estímulo de um líder as pessoas começarão a estudar e aplicar DevOPs naturalmente.

Na startup normalmente não existe divisões, departamentos, todos trabalham juntos e isso também é um facilitador, afinal não existem barreiras para se comunicar.

6.2.2 A realidade no ambiente corporativo

A corporação não funciona como a startup, lá existe burocracia e o uso vicioso de métodos ultrapassados, portanto não bastará o estímulo da alta hieraquia para que equipes de infra e devel comecem a vivenciar a cultura DevOPs, neste tipo de ambiente, em minha opinião pessoal e profissional, é necessário intervir cirurgicamente para conseguir internalizar a cultura DevOps.

Em resumo, você precisa trazer alguém – de fora – que conhece DevOP para que esta pessoa passe a contaminar os demais.

Esse processo é lento, mas se o especialista tiver os meios e o apoio do alto escalão, mudanças fantásticas poderão ocorrer.

6.3 O especialista DevOps no meio corporativo

Ele foi trazido para atuar como um agente de mudanças, ele precisa contaminar as áreas e mostrar que a cultura DevOps funciona.

6.3.1 Característica gerais de um especialista DevOps em 2013

  • Está na casa dos 30 anos ou mais
  • É um profissional sênior em infraestrutura
  • Tem um bom background em desenvolvimento
  • Tem um bom background em metodologias ágeis
  • Tem sólidos conhecimentos em soluções opensource e similares
  • Trabalha intensamente com automação e infraestrutura como código

6.3.2 Onde esse especialista atua?

Este especialista em DevOps terá um pé na infra e outro no devel, em alguns casos também terá o pé na área de garantia de qualidade (QA).

Ele é a cola que faltava para unir infra, devel e qualidade.

6.3.3 Como esse especialista atua?

Ele será a ponte entre as áreas de infra e devel, ele conhece a infra a fundo e entede de forma ampla processos de desenvolvimento ágil.

6.3.3.1 Pé no devel

Ele participa dos projetos de desenvolvimento desde o seu nascimento, seu foco é oferecer os recursos para os desenvolvedores trabalhem da forma mais eficiente, além disto, com sua ótica de infra ele toma todas as precauções para que os aspectos de segurança, monitoramento, eficiência e escalabilidade sejam observados desde o início do projeto.

O DevOps vai ainda estudar todo o processo de desenvolvimento e definir – em conjunto com o devel – as ferramentas que irão permitir um processo de desenvolvimento e entrega contínua. Após definir ele vai instalar e manter esse infra.

Alguns DevOps conseguem até avaliar o código do produto e enxergar problemas de performance, esse tipo de visão sistêmica e raciocínio rápido são diferencias importantes para uma entrega com mais qualidade.

6.3.3.1 Pé na infra

Na infra ele é o principal agente de mudanças, é ele que vai puxar a fila para iniciar a implantação de uma infraestrutura ágil, ele domina as ferramentas de orquestração, gerência de configuração e provisionamento e vai usar esse conhecimento para que a equipe passe a trabalhar a infraestrutura como código.

Este profissional também vai ajudá-los a mudar seu comportamento e cultura, ele vai orientá-los nos métodos ágeis de execução de atividades, aqueles inspirados no SCRUM e KANBAN.

6.4 Ele fica na infra ou no devel?

Para internalizar DevOPs, normalmente estas barreiras não existem, infra e devel devem habitar o mesmo espaço, sem paredes, sem divisórias, todos na mesma sala, isso é fundamental para extinguir os nichos e criar uma equipe mais unida e coesa.

Respondendo a pergunta, ele deve ficar junto com as duas equipes se for possível, esse é o melhor dos mundos.

Se não for possível ficarem todos juntos, o especialista deve se esforçar para interagir com as duas equipes diariamente.

Ele vai ser o agente de mudanças até que infra e devel comecem a entender e adotar a cultura de forma natural.

7. Quais os ganhos em adotar a cultura DevOPs?

Vamos avaliar dentro da ótica de cada área o que melhora com a adoção da cultura DevOPs.

7.1 Ganhos para a infra

  • Infraestrutua como código (equipe para de administrar e passa a desenvolver a infra)
  • Infra mais eficiente e rápida usando métodos ágeis
  • Equipe de Infra mais organizada
  • Equipe de Infra se comunicando melhor
  • Infra fazendo mais em menos tempo com menos gente
  • Ambientes de gerência de configuração, orquestração e provisionamento implantados
  • Deploys de infra (novos ambientes) mais rápidos e seguros => entrega rápida
  • Ambiente padronizado e sob-controle
  • Feedback rápido em todas as atividades de infra

7.2 Ganhos para o devel

  • Devel tem ambiente mais adequado para trabalhar (dev/teste/prod)
  • Devel passa a contar com ambiente de desenvolvimento contínuo
  • Devel passa a contar com testes automatizados
  • Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida
  • Feedback rápido em todas as fases de desenvolvimento

7.3 Ganhos mútuos Infra/Devel

  • Acaba a divisão Infra vs Devel (acaba a guerra)
  • Infra participa dos projetos e acompanha de perto tudo o que acontece
  • Infra participando resulta em melhor planejamento do ambiente de produção
  • Infra participando resulta em monitoramento mais eficaz da aplicação
  • Devel começa a compreender melhor a infra e isso resulta em um produto melhor
  • Equipes trabalhando em conjunto para aumentar o valor do negócio

7.4 Ganhos para a empresa

  • Melhor comunicação entre devel e infra (diminuição de conflitos)
  • Soluções rodando com maior estabilidade e desempenho
  • Entregas mais rápidas
  • Menor tempo de paradas
  • Diminuição de incidentes
  • Diminuição de custos
  • Diminuição de riscos
  • Aumento do valor do negócio

8. Amarrando as pontas

Vamos partir para perguntas e respostas no melhor estilo FAQ.

8.1 Indo direto ao ponto (e respondendo as perguntas do início)

Respondendo sobre o termo DevOps:

  1. DevOps está diretamente relacionado a um melhor feedback entre as áreas de TI.
  2. DevOps é um movimento, é um conceito, é uma cultura e uma filosofia, e não existe uma explicação fácil.
  3. DevOps possibilita diminuição dos riscos de mudanças através do uso de um ferramental adequado e adoção de uma cultura específica.
  4. DevOps busca entregar sistemas melhores, com menor custo, fazendo isto de forma mais rápida e com menor risco.
  5. DevOps envolve a área de Infra e Devel primáriamente.
  6. DevOps é pura metodologia ágil tando na Infra quanto no Devel.
  7. DevOps só funciona se as equipes de infra e devel estiverem dispostas a ceder, mudar sua cultura e método de trabalho.
  8. DevOPs não é um cargo, tão pouco um setor ou departamento, é uma cultura.
  9. DevOps não está restrito ao ambiente das startups, é possível utilizar essa cultura no meio corporativo.
  10. DevOps não é algo novo, as boas práticas estão ai desde de sempre, logo esse ‘juntado’ de práticas não é novidade para muita gente, mas para alguns serve como uma boa referência para aplicar mudanças necessárias.

Respondendo sobre o especialista em DevOps:

  1. O especialista em DevOps de hoje é normalmente alguém que conhece muito de infra e tem uma base sólida de devel.
  2. O especialista em DevOps também pode ser alguém que veio do devel e que tem uma base sólida de infra (esse geralmente é mais completo).

8.2 Quero ser um DevOps e não sei por onde começar

Não há um tutorial para isto, minha recomendação é que você estude desenvolvimento ágil e procure entender o processo de desenvolvimento do local onde você trabalha, estude ferramentas para desenvolvimento contínuo, estude ferramentas de gerência de configuração, orquestração e provisionamento, fazendo isto você poderá dar os primeiros passos como entusiasta da cultura DevOps e estará apto a atuar em seu ambiente, você poderá agir como uma ponte entre as áreas de devel e infra, e principalmente, poderá modernizar os processos e o ambiente de infra.

8.3 Eu trabalho com infra ágil, sou um DevOps?

Não existe uma entidade certificadora, uma prova ou alguém que possa lhe conceder este título, não existe um manual de conduta para dizer se você é um DevOps ou não, mas em 2013 é bastante comum encontrar profissionais que estão estudando infraestruta ágil e se denominando DevOps.

Se você está buscando melhorar seu ambiente, entregar mais rápido, entregar algo com mais qualidade, algo que minimize custos, algo que diminua riscos, algo que envolva automatização pesada, se você trabalha infraestrutura como código, se você está atuando como um agente de mudanças em sua equipe, penso que DevOps é um termo adequado para descrever o seu trabalho, mesmo que não esteja diretamente envolvido com uma equipe de Devel.

8.4 Não existe receita mágica ou caminho rápido

Como eu já mencionei não existe uma metodologia clara, DevOps ainda é um movimento em constante construção e definição, eu citei uma série de melhorias que fazem parte da cultura DevOps, cabe a cada empresa ou a cada gestor estudar e descobrir a melhor forma de combinar essas pequenas receitas técnicas e aplicar em seu ambiente.

Espero que este artigo tenha te ajudado a entender melhor a cultura DevOPs.

9. Referências

Sites

Slides

Fonte das imagens

[1] Dev OPs: https://devcentral.f5.com/blogs/us/devops-is-not-all-about-automation
[3] Ops Burn: http://devops.com
[4] Combusível: http://www.huffingtonpost.com
[5] DevOps Diagram: http://www.skybotsoftware.com/skynews/2012/07/24/why-devops-more-trend

Fone principal: http://gutocarvalho.net

Publicado em DEVOPS

Deixe um comentário

Tags: