Qual a diferença entre SRE e SysAdmin? São a mesma coisa com outro nome? Queremos a sua opinião!
Vamos ver quais são as diferenças chave entre um Site Reliability Engineer (SRE) e um Administrador de Sistemas (SysAdmin) "tradicional", destacando como a "filosofia" SRE, impulsionada pela automação, monitoramento e uma colaboração próxima com os desenvolvedores, leva a uma maior confiança nos sistemas e um ciclo de entregas mais rápido e eficiente (sim, isso é DevOps).

Mencionamos conceitos vitais de SRE como SLO, error budget, métricas, logs, tracing, e como realmente se podem beneficiar os desenvolvedores. Também, o porquê de não ser a mesma coisa que um SysAdmin com um nome mais "legal" (sim, para mim também é difícil pronunciar em inglês).
O mito do "SysAdmin em esteroides"
É muito comum que se perceba os SREs como administradores de sistemas com um nome fino e elegante. Embora muitos SREs venham de ambientes de administração de sistemas, sua abordagem difere significativamente. Um SRE aproveita suas habilidades de desenvolvimento para automatizar tarefas, construir sistemas de monitoramento e, acima de tudo, fomentar uma cultura de colaboração REAL entre Desenvolvedores e Operações. Não se trata apenas de manter pipelines ou colocar muitos passos para implantar seu código, mas de otimizar todos os sistemas, tanto humanos quanto técnicos, para alcançar confiança, estabilidade, segurança nos sistemas, escalabilidade e verdadeira Entrega Contínua (Continuous Delivery).
O Santo Graal SRE: Métricas, Logs e Traces
Um SRE vive e respira dados. Recolhe e analisa métricas, logs e traces para obter informações sobre o desempenho e o comportamento das aplicações em produção. Ao instrumentar aplicações, os SREs podem estabelecer objetivos de nível de serviço (SLO - Service Level Objectives) e "orçamentos de erro" (error budgets), o que permite aos desenvolvedores inovar e ter mais liberdades criativas dentro de faixas acordadas de riscos e alcances.

Que ferramentas usa um SRE?: OpenTelemetry, Prometheus, Loki e mais
O mundo SRE está repleto de ferramentas poderosas. O OpenTelemetry tornou-se um padrão de facto para a instrumentação de aplicações, enquanto o Prometheus e o Loki são ferramentas consolidadas para armazenamento, coleta e visualização de métricas e logs, respetivamente. Ferramentas como o Jaeger levam o rastreamento distribuído a um novo nível, o que permite aos SREs rastrear requests através de serviços complexos (service mesh), microsserviços e outros.

Por que é importante um SRE?
O SRE é seu amigo! yay!
Um SRE não apenas soluciona problemas, mas os previne. Ao adotar a automação, o monitoramento proativo e uma colaboração próxima com os desenvolvedores, os SREs garantem que os sistemas sejam resilientes, escaláveis e capazes de oferecer uma excelente experiência ao cliente, aos desenvolvedores e ao negócio. Um bom SRE dorme bem à noite, sabendo que seus clusters funcionam como devem (e, se não, ele tem alertas para despertá-lo).
Related content
Grave brecha de Trivy en Github Actions amenaza tus secretos, tokens, credenciales e incluso tus artefactos, qué debes hacer y saber
la ironía de la seguridad: las github actions de trivy secuestradas (otra vez) En un giro del destino que haría que cualquier SRE se sirviera un trago fuerte, Trivy —el escáner de vulnerabilidades estándar de la industria mantenido por Aqua Security— ha sido comprometido por segunda vez en un mes.
Read the full post →
La gran unificación de google cloud: opentelemetry se vuelve obligatorio (y ya era hora)
Si pensabas que podrías seguir ignorando el avance de OpenTelemetry (OTel) mientras te escondías en tus scripts legacy, Google Cloud acaba de enviarte un recordatorio amistoso —o una amenaza elegante, según cómo lo mires—. La plataforma ha lanzado una nueva API de ingestión que soporta de forma nativa los protocolos
