Pular para o conteúdo principal

Podcast Sysadmin #01: SRE, DevOps e o Sysadmin Raiz






O conceito de Site Reliability Engineering (SRE) foi criado no Google em 2003
DevOps surgiu em 2008, Não se pode chamar a adoção deles como inovação ou diferencial...

Qual a diferença entre eles? Sysadmin DevOps ou Sysadmin "SRE".

DevOps - Desenvolvimento e Operações


DevOps significa simplesmente a integração entre departamentos entre Desenvolvimento, o departamento que cria o código e Operações, o departamento que usa esse código. Claro, é um pouco mais complicado que isso. Há várias partes interessadas ao longo do caminho.

O DevOps é um pensamento enxuto, misturado à filosofia ágil. O aspecto revolucionário do DevOps é que ele cruza uma linha tradicional ao mesclar desenvolvimento de software com o ambiente em que é desenvolvido. 

Isso é mais do que apenas uma tentativa de eficiência, é uma mudança cultural. Essa mudança cultural é possibilitada por uma série de ferramentas que automatizam processos como desenvolvimento e revisão de código por meio de integração contínua, permitindo o controle de versão. De fato, é a automação que possibilita o ciclo de desenvolvimento ágil, mesclando diferentes funções, desde testes de software até a implantação.

Na verdade, o nascimento do DevOps não é tão surpreendente. A TI tem um histórico de se tornar cada vez mais relevante para mais e mais pessoas o tempo todo. O que antes era cercado em seu próprio departamento dentro de corporações e universidades, agora se espalhou por todo o mundo e no bolso de todos.


DevOps é um novo termo que surge da colisão de duas principais tendências relacionadas. O primeiro também foi chamado de "infraestrutura ágil" ou "operações ágeis"; surgiu da aplicação de abordagens ágeis e enxutas ao trabalho de operações. A segunda é uma compreensão muito mais expandida do valor da colaboração entre desenvolvimento e equipe de operações em todas as fases do ciclo de vida de desenvolvimento ao criar e operar um serviço, eles participam juntos de todo o ciclo de vida do serviço, desde o design até o processo de desenvolvimento e o suporte à produção.

“DevOps” não diferencia entre diferentes sub-disciplinas do sysadmin - “Ops” é um termo geral para engenheiros de sistemas, administradores de sistemas, equipe de operações, engenheiros de lançamento, DBAs, engenheiros de rede, profissionais de segurança e várias outras subdisciplinas e cargos. "Dev" é usado como atalho para desenvolvedores em particular, mas, na prática, é ainda mais amplo e significa "todas as pessoas envolvidas no desenvolvimento do produto", que podem incluir Produto, controle de qualidade e outros tipos de disciplinas.


O DevOps tem fortes afinidades com as abordagens Agile e Lean. A visão antiga das operações tendia ao lado “Dev”, sendo os “criadores” e o lado “Ops”, às “pessoas que lidam com a criação após o seu nascimento” - a realização do dano que foi causado na indústria de esses dois sendo tratados como preocupações em silos é o principal fator por trás do DevOps. Dessa forma, o DevOps pode ser interpretado como uma conseqüência do desenvolvimento ágil de software - Agile prescreve uma estreita colaboração de clientes, gerenciamento de produtos, desenvolvedores e (às vezes) controle de qualidade para preencher as lacunas e iterar rapidamente em direção a um produto melhor - o DevOps diz que sim , mas a entrega de serviços e a forma como o aplicativo e os sistemas interagem também são uma parte fundamental da proposta de valor para o cliente e, portanto, a equipe do produto precisa incluir essas preocupações como um item de nível superior.


O DevOps também é caracterizado pela equipe de operações que utiliza muitas das mesmas técnicas que os desenvolvedores para o funcionamento de seus sistemas.

As pessoas falam sobre o DevOps ser "colaboração de desenvolvedor e operações" ou "tratar seu código como infraestrutura" ou "usar automação" ou "usar kanban" ou "uma abordagem de cadeia de ferramentas" ou "cultura" ou uma variedade de itens aparentemente vagamente relacionados. A melhor maneira de defini-lo em profundidade é usar um método paralelo para a definição de um termo igualmente complexo, desenvolvimento ágil. O desenvolvimento ágil, de acordo com a Wikipedia e o manifesto ágil , consiste em "níveis" diferentes de preocupação. Valores, Princípios, Métodos e Praticas.



A Engenharia de confiabilidade de site, ou SRE (Site Reliability enginnering)


A confiabilidade é a característica mais fundamental de qualquer produto, um sistema não será útil de ninguém puder usa-lo.
O SRE tem foco em descobrir maneiras de melhorar o design e a operação dos sistemas para deixa-los mais escaláveis, confiáveis e eficientes.


“SRE é o que acontece quando você solicita a um engenheiro de software que projete uma equipe de operações”, Benjamin Treynor Sloss, Google. Isso significa que uma função SRE é executada por especialistas operacionais de TI que codificam. Esses engenheiros especializados implementam uma abordagem de software em primeiro lugar para automatizar as operações de TI e prevenir falhas. Eles aplicam práticas de software de ponta aos Dev e Ops integrados em uma única plataforma e executam códigos de teste no ambiente contínuo. 

Ao contrário do caminho para se tornar um administrador de sistemas, os SREs são tão prováveis ​​de ter um background de desenvolvimento quanto um background de sysadmin. 

 como integração contínua e entrega contínua  (CI/CD), muitas vezes haverá uma lacuna de habilidades em como executar esses aplicativos imutáveis ​​em vários ambientes, enquanto eles são dimensionados para atender às necessidades da empresa. 
Este é o mundo de uma SRE. Sim, um administrador de sistemas pode aprender as ferramentas adicionais, mas em escala, isso facilmente se torna uma posição de período integral para acompanhar. 
Um especialista faz sentido.

Os SREs usam conceitos como infraestrutura como código para produzir modelos, chamados para implantar o ambiente em que um aplicativo será executado, com o objetivo de cada aplicativo e seu ambiente ser completamente reproduzível com o pressionar de um botão. 

Portanto, o aplicativo um no servidor, um no teste do sistema, terá exatamente os mesmos binários que serão usados ​​no servidor quinze em produção, com exceção de variáveis ​​específicas do ambiente, como senhas e cadeias de conexão de banco de dados.

Um SRE também destruirá completamente um ambiente e o reconstruirá com base em uma alteração na configuração. 
Não há apego emocional a nenhum sistema. 
Cada sistema é apenas um número e é marcado e reciclado de acordo, mesmo ao ponto em que a correção de rotina do servidor é feita reimplantando toda a pilha de aplicativos.

Conclusão
Em certas situações, especialmente ao operar em grandes ambientes baseados em DevOps, as habilidades especializadas que um SRE fornece sobre como lidar com qualquer nível de escala definitivamente oferecem uma vantagem. 


O DevOps e o SRE são práticas complementares para impulsionar a qualidade no processo de desenvolvimento de software e manter a estabilidade do aplicativo.



As diferenças fundamentais


Enquanto o pessoal DevOps está lidando com o desenvolvimento antes da falha (ou da situação ocorrer), suas métricas estão baseadas no CI/CD, nas sprints e entregas, nos ciclos de lançamento, eles se preocupam principalmente com o desenvolvimento eficiente e a entrega eficaz de produtos de software pois sabem que quanto mais tarde no ciclo de vida do produto um problema é descoberto, mais cara será a correção. Eles estão em busca de identificar pontos cegos na infraestrutura e na aplicação.

Já com o SRE, estamos lidando com a situação pós-falha, o principal objetivo é garantir o tempo de atividade ao máximo e eliminar falhas para confiabilidade a longo prazo, O SRE está gerenciando as operações de TI com eficiência depois que a aplicação é implantada.
As métricas são baseadas nos acordos de níveis de serviço (SLA, OLA, UC).

Ao invés de ciclos de lançamento, o SRE faz pequenas alterações em intervalos frequentes. Isso oferece um espaço maior para medir essas alterações e adotar medidas corretivas em caso de uma possível falha. O resultado são testes e correções eficientes para reduzir o custo da falha


Ringue:
Insistir que SLOs sejam atendidos 100% do tempo não é desejável nem realista, fazer isto pode reduzir a taxa de inovação e de implantação, exigir soluções caras e conservadoras. O SRE estará mais preocupado em manter o paciente vivo do que buscar formas de tira-lo da UTI.
Com o DevOps, os times irão começar a ter atritos, o Ops vai querer a todo custo impedir mudanças na aplicação e sempre culpará os Devs por qualquer falha. Por outro lado, o Dev entenderá que Ops está lá apenas para chancelar e acatar quaisquer de suas decisões


Sysadmin vs SRE: Qual a diferença?

Os administradores de sistemas e os engenheiros de confiabilidade são partes valiosas de qualquer organização. 


No mundo da TI, sempre houve uma atração entre generalista e especialista. 
O administrador de sistemas estereotipado cai na categoria generalista 99 vezes em 100. 
A função de engenheiro de confiabilidade do site (SRE) é especializada, no entanto, e surgiu das necessidades de uma das primeiras empresas a conhecer a escala real: o Google. 

Por fim, essas duas funções têm o mesmo objetivo para os aplicativos cuja infraestrutura eles operam: fornecer uma boa experiência para os consumidores dos aplicativos. 

No entanto, esses papéis têm pontos de partida drasticamente diferentes.

Sysadmins: 
Os administradores de sistemas geralmente crescem em sua posição iniciando como suporte básico de rede e de desktop e, com o tempo, adquirindo o amplo conjunto de habilidades que a maioria dos administradores de sistemas tem em comum. 
Nesse ponto, esses administradores de sistema conhecem todos os sistemas e aplicativos pelos quais são responsáveis. 
Eles sabem que o aplicativo no servidor que precisa ser reiniciado a cada terça-feira ou o serviço no servidor nove falhará na quarta-feira sem erros. Eles ajustaram seu monitoramento para que ele ignore o que não importa, mesmo o erro que ocorre no terceiro domingo do mês, apesar do fato de ser marcado como fatal.

Em resumo, os administradores de sistemas sabem como alimentar e cuidar dos servidores que executam o núcleo dos seus negócios. 
Esses administradores de sistemas cresceram para usar a automação para lidar com tarefas de rotina em todos os servidores que gerenciam. 
Eles adoram modelos, imagens douradas e padrões, mas são flexíveis o suficiente para fazer uma alteração de parâmetro apenas no servidor com erro e, em seguida, anotar o motivo pelo qual esse servidor agora está configurado exclusivamente.

Os administradores de sistemas são ótimos, mas têm algumas peculiaridades. 
A primeira é que você simplesmente não obtém acesso root sem intervenção divina, e que quaisquer alterações que eles fizerem que não eram da sua ideia devem ser documentadas conforme exigido pelo aplicativo com o qual estão trabalhando com o fornecedor do fornecedor e, em seguida, ainda serão verificadas duas vezes.

Os servidores são seu domínio e ninguém mexe com suas coisas.


SREs:
Não necessariamente serão sysadmins evoluídos, podem chegar ao cargo por exemplo, desenvolvedores e pessoas que não passaram por cargos em suporte ou redes.
Enquanto a programação não era uma skill ativa e necessária para o sysadmin, para o SRE programação é imperativa! Todo seu trabalho estará pautado na Infra as a Code, automação e ferramentas que precisam ser codadas.
Por outro lado, ele não estará mais cuidando de infraestrutura física e em ambientes mutáveis.




Créditos:
Trilha sonora no podcast: https://www.jennyjahleemusic.com/





Postagens mais visitadas deste blog

TuxMath - Tux, do Comando da Matemática. Ensino e diversão a crianças.

Tux Of Math Command, (Tux, do Comando da Matemática, em sátira ao desenho animado, Buzz Lightyear, do Comando Estelar) ou simplesmente TuxMath é um game open source, no estilo arcade, originalmente desenvolvido para linux, mas atualmente é multiplataforma, disponível em Windows, Mac, BeOS, web, dispositivos móveis...

Tipos de VPNs: PPTP x OpenVPN x L2TP/IPsec x SSTP x IKEv2 x Chameleon x WireGuard

Olá, Baseando-me no formato do artigo sobre Certificados e a sopa de letras: HTTPS, TLS, SSL, HSTS, CA, PGP, GPG e OpenPGP , com o artigo sobre o WireGuard  e a atual crise mundial que forçou muitos em quarentena a trabalhar remotamente, resolvi fazer um semelhante abordando os diferentes tipos de VPN. O principal problema é que ao ler a documentação e artigos atuais, além de longos eles se prolongam muito no detalhe técnico entre elas, então tentei criar um TL;DR (que ficou um pouco grande, mas bem resumido). Uma VPN, ou rede virtual privada, permite criar uma conexão segura entre duas redes ou entre seu dispositivo/host com alguma rede, usando a internet como meio, como túnel para chegar ao destino. As VPNs podem ser usadas para acessar sites restritos por região (países proíbem torrents, outros proíbem redes sociais, sites de noticias...), proteger sua navegação (em redes não confiáveis como hotéis, wifi de lojas, etc...), acessar um sistema corporativo que está instalado e disponív

Melhor desempenho da memória RAM e SWAP no Linux

Melhor desempenho da RAM/SWAP Objetivo: Determinar através do kernel (sysctl) quando o sistema deverá utilizar a memória swap. Com isto, o linux vai usar mais a memória RAM e dar prioridade a ela, ao invés de levar isto para o HD (swap) e deixar alguns processos mais demorados. Por padrão, o valor de swappiness no debian é 60. Ou seja, usará o swap quando a RAM estiver em torno de 40% a 50% em uso. Verificar valor padrão: # cat /proc/sys/vm/swappiness Reduzindo o valor de swappiness para 10 ou 15 (neste exemplo, reduzi para 5), o arquivo de swap será usado apenas quando o uso da RAM chegar em torno de 80 a 90 por cento. Edite: # vim /etc/sysctl.conf Altere (adicione se não existir a linha) no arquivo: # vm.swappiness = 5 (Há quem coloque 0 ou 1, mas prefiro assim) Para evitar a necessidade de reiniciar o sistema, execute: # sysctl vm.swappiness=5 depois, apenas como verificação, execute: # swapoff -a # swapon -a # sysctl -p /etc/sysctl.conf

DHCP - Guia Completo

atualizado em 18/03/2015 Olá a todos, disponibilizo mais um guia ;-) Apesar de um assunto bem fácil, sem segredos ou mistérios, o tema deste guia é DHCP Servers. Nele, abordo o que é o dhcp, como funciona e como configurar. A novidade neste guia é que mostro como realizar a configuração de um servidor DHCP usando roteadores "home / small office", como os famosos d-link, encore, tenda, pacific, tp-link, etc... Como criar um servidor dhcp usando equipamentos Cisco, como habilitar o DHCP Server usando a plataforma Windows (Windows Server 2003), e finalmente usando o GNU/Linux. Claro que meu foco é favorecer o uso do Linux para prover este serviço, para isto, mostro desde a configuração mais simples, até algumas avançadas, tanto em modo texto quanto as mais variadas interfaces gráficas existentes no S.O. para configurar e monitorar este simples serviço de rede. No GNU/Linux, abordo o DHCP Server mais utilizado no mundo (da ISC), as configurações mais utilizadas, o c

SSD no linux

Mitos e verdades do SSD no Linux - Instalando, configurando e otimizando SSD no Linux SSD são suportados no Linux desde o kernel 2.6.29. Schedulers e File Systems também suportam os 'discos sólidos' ou 'não-rotacionais' (SSDs) há um bom tempo. A maioria dos artigos que existem na internet são bem antigos e não refletem os ambientes atuais dos sistemas Linux. Este artigo trás alguns macetes para otimizar o SSD num ambiente onde o sistema operacional estará instalado nele. Tiro alguns mitos de que seria necessário mudanças bruscas no sistema para que o SSD seja bem aproveitado (hoje, basicamente no uso do dia-a-dia, nada é preciso após instala-lo) apenas alguns pontos a serem observados.

Teste de Performance de Rede com Iperf

Troubleshooting,  Throughput,  testes de  conectividade e transmissão de pacotes em rede com Software Livre/Open Source Sumário Base de Conhecimento Rede Local e o tráfego de informações O que é Possíveis situações de uso O Básico - Executando como Server No Windows No GNU/Linux O Básico – o Cliente No Windows No Linux Utilizando UDP Argumentando... Mais Opções Opções gerais -f, --format -i, --interval n -l, --len N -m, --print_mss -o, --output <arquivo> -p, --port n -u, --udp -x, --reportexclude -y, --reportstyle C -w, --window n -B, --bind <host> -M, --mss n -N, --nodelay -V, --IPv6Version Opções para o cliente -P , --parallel -T, --ttl -n, --num -t, --time -d, --dualtest -r, --tradeoff -L, --listenport -b, --bandwidth -F, --fileinput <name> -I, --stdin Opções para o Servidor -s, --server -U, --single_udp -D, --daemon Interface Gráfica em JAVA Conclusão Minha rede está lenta, e agora?? Download e Links Base de Conhecimento O TCP é o protocolo

Colorindo o terminal do Linux

Abaixo, 3 dicas simples para colorir o Linux: Deixar o terminal (bash) colorido; Deixar o vim e o nano colorido; Deixar as manpages coloridas; No bash facilita a identificação de tipos de arquivos, diretórios e permissões (pois cada um terá uma cor diferente). Nos editores de texto, (neste caso o Nano e VIm), as cores facilitam ao criar scripts e programas nas mais variadas linguagens, os esquemas de cores, identificam a sintax da linguagem e colorem de acordo com os comandos, por exemplo, uma cor diferente para scripts entre aspas, comentários, cores diferentes para variáveis, etc... E a melhor de todas as dicas: colorir as manpages! Parece que não, mas facilita muito a vida quando você olha as manpags e enxerga facilmente as flags e opções de cada comando, exemplos e distingui a descrição da opção do comando. Colorindo o Bash Coloque no final do arquivo .bashrc (ele é um arquivo oculto que está dentro do seu /home), é o arquivo de configuração do bash de cada usuário.  

Protocolo RIP - Lab com passo-a-passo em roteadores Cisco

O RIP ou Routing Information Protocol é um protocolo aberto, definido na RFC 1058, e classificado como vetor de distância. As diferenças básicas entre o RIP versão 1 e versão 2 é que o primeiro é classfull, ou seja, suporta apenas classes cheias (A, B ou C) ou subrede com a mesma máscara e troca atualizações de roteamento via broadcast. Já a versão 2 suporta CIDR (classless) e VLSM (divisão de subredes com várias máscaras de subrede), além disso, troca informações através de multicast no endereço 224.0.0.9. Ambas as versões trocam informações utilizando UDP na porta 520. Para IPv6 (versão 6 do protocolo IP) o RIP passa a chamar RIPng (Next Generation) e funciona basicamente da mesma maneira que o RIP versão 2 para IPv4, porém enviando updates no endereço IPv6 de multicast FF02::9. Para configurar o RIP versão 1 basta ativar o protocolo com o comando “router rip”, depois em modo de configuração do roteador definir as redes que serão anunciadas com o comando “network”. No comando

Aula #14 - Os sistemas de arquivos ext2/ext3/ext4

  A família de sistemas de arquivos ext tem sido nativa para o Linux desde os seus primeiros dias, e tem sido a mais utilizada. Até recentemente, o ext4 foi a escolha padrão mais comum das distribuições Linux, devido à sua excelente combinação de desempenho, integridade e estabilidade.

Aula #5 - A estrutura da árvore do Sistema de Arquivos Linux

Existem vários tipos de arquivos presentes em um sistema Linux.  Eles diferem em propósito, tamanho, dono, nível de compartilhamento e volatilidade.  O resultado é uma organização coerente de toda a árvore do sistema de arquivos que é padrão(na medida do possível) entre as distribuições Linux.