Mixórdia significa um emaranhado de coisas, uma mistura confusa de coisas variadas. Com exceção do "confusa", meu objetivo é batermos um papo ao entorno dos assuntos relativos ao Sysadmin e SRE.

No mundo da TI, sempre houve uma atração entre generalista e especialista. O sysadmin é o cara generalista, já o SRE surgiu por uma necessidade do Google, é um cara especialista.

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.
Vamos conversar sobre ferramentas, métodos, métricas, mercado de trabalho, carreira, como iniciar, quais desafios de um iniciante, por onde e como iniciar e qual o rumo um sênior, um expert toma.

Estou reunindo as pautas e consolidando o formato de podcast, convido a todos participar com sugestões, duvidas ou entrar no bate papo. Estou preparando alguns textos para o blog, algumas parcerias e irei divulgar os episódios tanto na plataforma oficial, quando no blog esli-nux.com, youtube e etc...

• E hoje, após 1 mês, saiu o piloto do primeiro episodio:

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

O podcast está disponível em diversas plataformas!

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/

Sugestão? comentário? Participar?
Entre em contato ou poste um comentário na pagina deste episódio em https://esli-nux.com