Melhor roadmap para SRE: as principais habilidades que você precisa conhecer

Autoria: Cloud DevOps with Ana · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Best SRE Roadmap: The Top Skills You Need to Know · Canal: Cloud DevOps with Ana · 16:02 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Engenharia de software com IA, Infraestrutura e hardware de IA, Open source e ecossistemas de software

Resumo

O vídeo apresenta um roadmap prático para se tornar SRE, começando por Linux, redes, programação e ciclo de entrega de software antes de avançar para cloud, containers e Kubernetes. Explica conceitos de confiabilidade como SLI, SLO, SLA e error budget, além de observabilidade, resposta a incidentes, troubleshooting e design de sistemas resilientes. Também propõe três projetos para demonstrar habilidades e recomenda como se preparar para entrevistas. A ideia central é que um bom SRE não evita todas as falhas: constrói sistemas que as detectam rapidamente, falham com segurança e se recuperam com eficiência.

Pontos-chave

SRE aplica engenharia de software à operação de sistemas em escala; não se resume a ferramentas de DevOps ou dashboards.
A base do roadmap inclui Linux, redes, programação, Git e compreensão de como aplicações são construídas e entregues.
Aprenda uma plataforma de cloud e, depois, containers, Kubernetes e infraestrutura como código; pratique a criação e a investigação deliberada de falhas.
Use métricas, logs e traces para investigar sistemas, e crie alertas acionáveis ligados ao impacto para os usuários.
SLIs, SLOs, SLAs e error budgets ajudam a equilibrar confiabilidade, velocidade de entrega e custo.
Uma resposta eficaz a incidentes prioriza restaurar o serviço, comunicar-se com clareza e aprender com postmortems sem culpabilização.
Automatize o toil com cuidado, adote mudanças seguras e use IA como acelerador, verificando suas recomendações e protegendo dados e permissões.
Demonstre suas habilidades com projetos que incluam falhas, recuperação, observabilidade, documentação e decisões técnicas.

Capítulos

Início	Capítulo	Resumo
00:00	O que faz um SRE e como medir confiabilidade	O vídeo apresenta o papel de SRE, diferencia confiabilidade de uma simples coleção de ferramentas e explica SLI, SLO, SLA e error budget.
02:33	Fundamentos de sistemas e entrega de software	A primeira etapa do roadmap cobre Linux, redes, programação, automação e o ciclo de construção e implantação de aplicações.
05:10	Cloud, containers e Kubernetes	O roteiro avança para fundamentos de cloud, containers, troubleshooting de Kubernetes e infraestrutura como código.
07:45	Observabilidade e engenharia de confiabilidade	O vídeo aborda métricas, logs, traces e alertas, além de SLOs, resposta a incidentes, análise de causa raiz, design resiliente e capacidade.
10:20	Troubleshooting, automação segura e projetos práticos	A seção reúne métodos de investigação, redução de toil, mudanças seguras, uso responsável de IA e três projetos para comprovar habilidades de SRE.
13:58	Entrevistas e ordem final de aprendizado	O encerramento explica como abordar entrevistas, recapitula a sequência do roadmap e destaca a importância de aprender com falhas.

Citações

SRE é usar engenharia de software para operar sistemas em escala. — 00:31

Confiabilidade não é uma sensação vaga. É uma decisão de engenharia mensurável. — 02:33

Cada alerta deve permitir uma ação. — 08:47

O melhor SRE constrói sistemas que revelam problemas rapidamente, falham com segurança, se recuperam com eficiência e ficam mais fortes após cada incidente. — 15:31

Conceitos e entidades

site reliability engineering (SRE) (conceito): Disciplina que aplica engenharia de software à operação de sistemas confiáveis em escala.
SLI (conceito): Indicador que mede uma característica do serviço, como a porcentagem de solicitações bem-sucedidas.
SLO (conceito): Objetivo de nível de serviço que define uma meta mensurável de confiabilidade.
SLA (conceito): Acordo de nível de serviço que registra o compromisso assumido com os clientes.
error budget (conceito): Margem de falha permitida que ajuda a equilibrar estabilidade e lançamento de mudanças.
Prometheus (ferramenta): Ferramenta indicada para aprender a trabalhar com métricas de sistemas.
Grafana (ferramenta): Ferramenta mencionada para explorar métricas e criar dashboards.
OpenTelemetry (ferramenta): Tecnologia apresentada para trabalhar com traces em sistemas distribuídos.
Terraform (ferramenta): Ferramenta de infraestrutura como código sugerida para tornar a infraestrutura reproduzível e revisável.
Kubernetes (ferramenta): Plataforma de orquestração de containers cujo aprendizado deve vir após Linux, redes e containers.
Google (empresa): Empresa associada à popularização do papel de SRE.

Tradução completa (pt-BR)

00:00 Se você quer se tornar engenheiro de confiabilidade de sites, ou SRE, provavelmente já viu um roteiro como este: aprender Linux, Python, Docker, Kubernetes, Prometheus, Grafana, Terraform e uma plataforma de nuvem. Mas, depois de aprender todas essas ferramentas, muitas pessoas ainda não conseguem responder à pergunta mais importante: como tornar confiável um sistema em produção? >> [música] >> Isso acontece porque SRE não é simplesmente um conjunto de ferramentas de DevOps e definitivamente não se resume a passar o dia olhando painéis de monitoramento. SRE trata de usar engenharia de software para operar sistemas em escala. Trata de decidir o que

00:31 significa confiabilidade, medi-la, responder quando os sistemas falham e reduzir a chance de a mesma falha acontecer de novo. E, em 2026, com a IA gerando código e infraestrutura mais rápido do que nunca, a confiabilidade importa ainda mais. Mais código significa mais mudanças, e mais mudanças criam mais maneiras de os sistemas falharem. Então, neste vídeo, vou apresentar um roteiro completo e realista para SRE, de Linux e redes a Kubernetes, observabilidade, resposta a incidentes, SLOs, automação e projetos práticos. Também vou mostrar o que

01:01 aprender primeiro, o que pode esperar e como comprovar suas habilidades em uma entrevista. O que um SRE realmente faz? SRE significa engenharia de confiabilidade de sites. A função se popularizou graças ao Google, mas hoje as empresas usam esse título de maneiras diferentes. Em uma empresa, [música] um SRE pode se concentrar em plataformas Kubernetes. Em outra, a função pode envolver observabilidade, resposta a incidentes, infraestrutura de nuvem, desempenho ou ferramentas para desenvolvedores. Mas o objetivo central continua o mesmo: manter os serviços confiáveis o suficiente para os usuários, permitindo que a empresa continue lançando mudanças. As palavras confiáveis

01:32 o suficiente são importantes. Em geral, é impossível alcançar confiabilidade perfeita, e tentar fazê-lo pode ficar extremamente caro. Um SRE ajuda a empresa a definir a meta de confiabilidade adequada e equilibrar estabilidade com velocidade de entrega. Imagine que sua empresa opere um serviço de pagamentos online. A empresa promete aos clientes que o serviço estará disponível 99,9% do tempo. Essa promessa pode estar registrada em um SLA, ou acordo de nível de serviço. Mas como medimos se o serviço está saudável? Escolhemos um SLI, um indicador de nível de serviço. Ele pode ser a

02:03 porcentagem de solicitações de pagamento bem-sucedidas, medida ao longo de 30 dias. Em seguida, definimos o SLO, o objetivo de nível de serviço. Por exemplo, 99,9% das solicitações de pagamento válidas devem ser concluídas em até 500 milissegundos, em um período móvel de 30 dias. A pequena quantidade de falhas permitidas é o orçamento de erros. Se o serviço estiver confortavelmente dentro do orçamento, a equipe pode continuar lançando funcionalidades. Se a equipe estiver consumindo o orçamento rápido demais, talvez precise desacelerar os lançamentos e se concentrar na confiabilidade. Esse é o pensamento de SRE. Confiabilidade não é

02:33 uma sensação vaga. É uma decisão de engenharia mensurável. Portanto, um SRE pode passar o tempo [música] automatizando infraestrutura e tarefas operacionais, melhorando o monitoramento e os alertas, respondendo a incidentes em produção, depurando falhas de aplicações e infraestrutura, melhorando a segurança dos deploys, planejando capacidade, reduzindo latência e custos e trabalhando com desenvolvedores para projetar sistemas mais resilientes. Agora que entendemos o trabalho, vamos montar o roteiro. Fase um: construa os alicerces do seu sistema. A primeira parte do roteiro não é Kubernetes. É aprender como computadores, sistemas operacionais,

03:05 aplicações e redes realmente se comportam. Linux. A maioria das cargas de trabalho em produção ainda roda em Linux, então você precisa se sentir à vontade trabalhando sem uma interface gráfica. Aprenda sobre arquivos, diretórios, permissões, usuários e grupos, processos, serviços, sinais e systemd, gerenciamento de pacotes, CPU, memória, disco e conceitos de sistema de arquivos, variáveis de ambiente, SSH, logs e journalctl, scripts básicos de shell e ferramentas como top, ps, free, df, du, lsof, ss, curl e grep. Não apenas decore comandos. Pratique

03:35 a solução de problemas. O que você verifica quando um servidor fica sem espaço em disco? Por que um processo está usando 100% da CPU? Por que a aplicação não consegue abrir uma porta? Por que um serviço falha depois de ser reiniciado? Um SRE precisa passar do sintoma à causa. Redes. Muitos incidentes em produção que parecem falhas de aplicações são, na verdade, problemas de DNS, roteamento, firewall, certificado ou conectividade. Aprenda os modelos TCP/IP e OSI, endereçamento IP e subnetting, DNS, TCP e certificados HTTPS/TLS, portas e sockets, roteamento, NAT e firewalls,

04:08 proxies e balanceadores de carga, VPNs e solução básica de problemas com ferramentas como dig, nslookup, curl, ping, traceroute e tcpdump. Você deve conseguir acompanhar uma solicitação desde o navegador do usuário, passando por DNS, um balanceador de carga e a aplicação, até um banco de dados, e identificar onde ela pode falhar. Programação e automação. SRE aplica engenharia de software às operações. Isso significa que é necessário saber programar. Python é uma ótima primeira opção porque é amplamente usado para automação. Go também é valioso, especialmente em ambientes cloud-native, porque muitas ferramentas do Kubernetes

04:39 são escritas em Go. Você não precisa se tornar um desenvolvedor full-stack, mas deve entender variáveis, funções, loops e estruturas de dados, leitura e gravação de arquivos, chamadas a APIs, análise de JSON, YAML, tratamento de erros, testes e uso do Git. Use código para automatizar tarefas repetitivas: verificar certificados, validar endpoints, analisar logs ou gerar relatórios sobre recursos saudáveis. Se você executa a mesma tarefa manual repetidamente, pergunte-se se um software poderia fazê-la com mais segurança. O ciclo de vida da entrega de software. Para operar uma aplicação, você precisa entender como ela é criada e entregue. Crie uma

05:10 aplicação web simples. Ela não precisa ser complexa. Uma API pequena conectada a um banco de dados é suficiente. Aprenda como uma solicitação percorre o sistema, como a configuração é carregada, como as dependências são gerenciadas, como os logs são gerados, como a aplicação é testada e como ela é colocada em produção. Depois, aprenda o básico de CI/CD: compilação, testes, verificações de segurança, criação de artefatos, deploy, verificação e reversão. Isso lhe dá algo concreto para operar durante o restante do roteiro. Fase dois: aprenda sobre infraestrutura moderna. Quando seus fundamentos estiverem sólidos, passe para a infraestrutura usada nos sistemas modernos de produção. Nuvem

05:42 : fundamentos. Escolha uma plataforma de nuvem: AWS, Azure ou Google Cloud. Concentre-se nos componentes básicos da arquitetura: computação, redes virtuais, gerenciamento de identidade e acesso, armazenamento, bancos de dados gerenciados, balanceamento de carga, escalabilidade automática, monitoramento, backup e recuperação e gerenciamento de custos. Não tente decorar centenas de serviços. Aprenda como os componentes principais funcionam em conjunto e como solucionar problemas neles. Uma certificação pode oferecer uma estrutura, mas é opcional. Ou pode ajudar você a passar pelos filtros de RH. Mas uma certificação sem prática de solução de problemas não vai deixar você pronto

06:13 para o mercado de trabalho. Containers. Aprenda Docker ou outro runtime de containers. Entenda imagens, camadas, registros, volumes, redes, limites de recursos, verificações de integridade e logs. Coloque em um container a aplicação web que você criou antes. Execute-a localmente, provoque falhas de propósito e diagnostique o problema. Por exemplo, use a porta errada, remova uma variável de ambiente, esgote a memória, interrompa a conexão com o banco de dados ou execute o container como um usuário sem a permissão correta. As habilidades de confiabilidade se desenvolvem mais rápido quando você cria falhas intencionalmente. Kubernetes é comum em funções de SRE, mas aprenda-o depois de Linux,

06:43 redes e containers. Caso contrário, todo problema vai parecer um YAML misterioso. Comece com [música] pods, deployments, services, config maps e secrets, namespaces, solicitações e limites de recursos, sondas de liveness, readiness e startup, armazenamento persistente, APIs de ingress ou gateway, agendamento, escalabilidade automática, RBAC e atualizações contínuas. Depois, concentre-se na solução de problemas. Por que um pod está pendente? Por que está em crash loop backoff? Por que uma imagem não está sendo baixada? Por que um service não consegue alcançar outro? Por que o tráfego não chega à aplicação? Por que o rollout falhou? Uma certificação prática

07:14 como a CKA pode fortalecer suas habilidades com Kubernetes, mas o objetivo não é o certificado. O objetivo é depurar um cluster real sob pressão. Infraestrutura como código e configuração. A infraestrutura de produção deve ser reproduzível e passível de revisão. Aprenda Terraform, OpenTofu, Bicep ou CloudFormation. Entenda estado, módulos, variáveis, saídas, backends remotos, drift e fluxos de trabalho de mudança inseguros. Além disso, aprenda como a configuração e os secrets são gerenciados. Seu projeto deve poder ser implantado a partir de um repositório, e não de uma lista de cliques manuais de que você já nem se lembra. Fase três: domine

07:45 a observabilidade. Observabilidade é uma das habilidades mais importantes para SRE. O monitoramento avisa quando ocorre uma condição conhecida. A observabilidade ajuda você a investigar perguntas que não previu com antecedência. Aprenda as habilidades fundamentais. Métricas mostram o comportamento numérico ao longo do tempo. Logs fornecem eventos detalhados e contexto. Traces mostram como uma solicitação percorre serviços distribuídos, e os perfis ajudam a identificar onde uma aplicação consome CPU ou memória. Para métricas, Prometheus e Grafana são ótimas ferramentas para aprender. Para logs, você pode usar Elastic Stack, Loki ou uma

08:16 plataforma gerenciada. Para traces, aprenda Open Telemetry e um backend [música] como Jaeger, Tempo ou um serviço de nuvem. Mas concentre-se nos conceitos, não no logotipo da ferramenta. Aprenda a instrumentar uma aplicação, estruturar logs, definir labels úteis, criar painéis, correlacionar sinais e controlar os custos de observabilidade. Mais importante ainda, aprenda a configurar bons alertas. Um alerta ruim diz: “A CPU está acima de 80%.” Um alerta melhor diz: “O serviço de checkout está consumindo o orçamento de erros rápido demais e os usuários [música] estão enfrentando solicitações com falha.” Crie alertas para sistemas que afetam

08:47 usuários, não toda métrica interna incomum. Cada página deve permitir uma ação. Se a pessoa que recebe um alerta às 3h da manhã não puder fazer nada útil com ele, o alerta precisa ser reformulado. Fase quatro: aprender engenharia de confiabilidade. As ferramentas tornam os dados visíveis. A engenharia de confiabilidade diz o que fazer com eles. SLIs, SLOs, SLAs e orçamentos de erro. Pratique definir SLIs para disponibilidade, latência, correção, atualidade e durabilidade. Depois, crie SLOs realistas com base nas expectativas dos usuários e no impacto nos negócios. Entenda como as porcentagens de confiabilidade

09:18 se traduzem em tempo de inatividade. A diferença entre 99,9% e 99,99% parece pequena, mas o esforço de engenharia e o custo podem ser enormes. Use orçamentos de erro para equilibrar o trabalho de confiabilidade com a entrega de funcionalidades. Gerenciamento de incidentes. Os sistemas falham. Um SRE precisa saber como responder sem criar ainda mais caos. Aprenda o ciclo de vida de um incidente. Um: detectar o problema. Dois: avaliar a gravidade e o impacto nos usuários. Três: atribuir funções claras para mitigar o impacto. Cinco: comunicar-se com as partes interessadas. Seis: recuperar o serviço.

09:49 Sete: aprender com o incidente. Durante um incidente, restaurar o serviço vem antes de fazer um diagnóstico perfeito. Você pode reverter uma alteração, fazer failover, desativar uma funcionalidade ou reduzir o tráfego antes de conhecer a causa raiz completa. Depois, escreva um post-mortem sem culpabilização, incluindo a linha do tempo, o impacto, os fatores contribuintes, o que funcionou, o que falhou e ações de acompanhamento específicas. Acompanhe métricas como o tempo para detectar e o tempo para restaurar, mas não otimize números sem entender o comportamento por trás deles. Solução de problemas e análise da causa raiz. Você não aprende a solucionar problemas com um único livro nem os memoriza com perguntas de entrevista.

10:20 Você desenvolve essa habilidade com a prática repetida. Use um método estruturado. Defina o sintoma, confirme o escopo, verifique as alterações recentes, reúna evidências, formule hipóteses, teste uma variável de cada vez, mitigue o impacto e documente o que aprendeu. Evite partir direto para a primeira explicação que pareça familiar. Projeto de sistemas para confiabilidade. Aprenda a projetar sistemas que contem com a possibilidade de falhas. Estude redundância e domínios de falha, escalabilidade horizontal, balanceamento de carga, cache, filas e processamento assíncrono, timeouts, novas tentativas e backoff exponencial, disjuntores,

10:51 idempotência, degradação gradual, limitação de taxa, backups e testes de restauração, alta disponibilidade e recuperação de desastres. Saiba a diferença entre RTO e RPO. Entenda que um backup não está comprovado até que você consiga restaurá-lo com sucesso. Desempenho e capacidade. Aprenda sobre testes de carga, testes de estresse, saturação, percentis de latência, throughput e análise de gargalos. A latência média pode ocultar experiências terríveis para os usuários. Aprenda por que as latências P95 e P99 importam. Pratique estimar quanto tráfego um sistema consegue suportar e o que falhará primeiro à medida que a carga

11:23 aumentar. A confiabilidade também inclui o custo. Um sistema que só permanece online desperdiçando recursos em enorme quantidade não foi bem projetado. Fase cinco: adotar a mentalidade de SRE. A camada final é a forma de pensar de um SRE. Reduza o trabalho operacional repetitivo. Esse trabalho é repetitivo, manual e operacional, cresce junto com o serviço e gera pouco valor duradouro. Nem toda tarefa manual é trabalho operacional repetitivo, mas, se uma equipe passa horas toda semana reiniciando o mesmo serviço, copiando os mesmos dados ou respondendo ao mesmo alerta ruidoso, o sistema precisa melhorar. Automatize com cuidado. Uma automação mal

11:54 projetada pode falhar mais rápido e em maior escala do que um processo manual. Projete mudanças seguras. Muitas interrupções são causadas por mudanças, não por falhas de hardware. Aprenda técnicas de entrega progressiva, como implantações graduais, implantações blue/green, lançamentos canário, feature flags, verificação automatizada e reversão rápida. Projete pensando nas pessoas. Crie runbooks claros. Melhore as mensagens de erro. Faça dashboards fáceis de usar. Simplifique procedimentos repetitivos. Reduza a carga cognitiva durante incidentes. A confiabilidade é um resultado técnico produzido tanto pelos sistemas quanto pelas pessoas. Use IA com responsabilidade. A IA pode

12:26 resumir logs, explicar alertas, gerar consultas, redigir runbooks e sugerir causas prováveis. Use-a como acelerador, mas verifique tudo. Um assistente de IA pode recomendar com confiança um comando destrutivo, interpretar mal o contexto de produção ou expor informações confidenciais se o sistema não for bem governado. Mantenha as permissões no mínimo necessário. Proteja os dados de produção. Exija aprovação para ações arriscadas. E mantenha um registro de auditoria. Em SRE, a velocidade importa, mas a velocidade com segurança importa mais. Agora, três projetos que podem comprovar suas habilidades de SRE.

12:56 Não construa apenas implantações perfeitas. Construa sistemas que falham e mostre como você os detecta, recupera e melhora. Projeto um: operar uma aplicação web em estilo de produção. Implante uma aplicação pequena com um banco de dados usando infraestrutura como código. Adicione CI/CD, TLS, gerenciamento de secrets, verificações de integridade, monitoramento, logs, dashboards, backups e uma estratégia de reversão. Defina pelo menos um SLA e um SLO. Projeto dois: laboratório de confiabilidade com Kubernetes. Implante a aplicação no Kubernetes. Configure solicitações e limites de recursos, probes, escalabilidade automática e controles de interrupção, além de

13:27 observabilidade. Depois, provoque falhas: encerre pods, interrompa o DNS, sobrecarregue a aplicação, implante uma versão com defeito ou remova o acesso a uma dependência. Meça a rapidez com que o sistema detecta a falha e se recupera. Projeto três: simulação de incidente e post-mortem. Crie um cenário em que a latência aumente ou as solicitações comecem a falhar. Gere um alerta, investigue métricas, logs e traces, mitigue o incidente e escreva um post-mortem sem culpabilização. Inclua a linha do tempo, o impacto nos usuários, as causas raiz, os fatores contribuintes e as ações de acompanhamento. Esses projetos mostram muito mais do que uma lista de ferramentas. Eles comprovam que você entende a confiabilidade como um sistema completo.

13:58 Documente-os no GitHub e explique-os no LinkedIn ou em um blog. Inclua diagramas, decisões, concessões, falhas e aprendizados, não apenas capturas de tela. Agora, como se preparar para entrevistas de SRE? As entrevistas de SRE costumam avaliar várias áreas: Linux e sistemas operacionais, redes, criação de scripts e programação, solução de problemas, projeto de sistemas, cloud e Kubernetes, conceitos de observabilidade e confiabilidade, além de cenários comportamentais ou de resposta a incidentes. Podem perguntar: “Os usuários dizem que a aplicação está lenta, mas o uso de CPU e memória parece normal. Como você investigaria?” O entrevistador não está

14:29 apenas verificando se você conhece um comando. Ele quer ver como você delimita o escopo, reúne evidências, prioriza o impacto nos usuários e se comunica diante da incerteza. Pense em voz alta. Declare suas suposições. Comece de forma abrangente e depois restrinja a investigação. Explique que evidências confirmariam ou refutariam cada hipótese. Prepare relatos comportamentais sobre um incidente de produção, uma automação que você criou, uma concessão difícil, um erro e uma ocasião em que você melhorou um processo. Se ainda não tem experiência profissional em produção, fale com honestidade sobre os incidentes do seu laboratório. Nunca finja que um projeto pessoal foi uma interrupção real que afetou clientes.

14:59 Roteiro final. Vamos colocar tudo em ordem. Primeiro, aprenda Linux, redes, Git, criação de scripts e como as aplicações são desenvolvidas. Segundo, aprenda uma plataforma de cloud, contêineres, Kubernetes, infraestrutura como código e CI/CD. Terceiro, desenvolva habilidades aprofundadas de observabilidade com métricas, logs, traces, dashboards e alertas que permitam agir. Quarto, aprenda SLOs, orçamentos de erro, gerenciamento de incidentes, solução de problemas, projeto de sistemas, continuidade dos negócios e desempenho. Por fim, construa projetos que demonstrem como você reage quando os sistemas falham. Você não precisa dominar todas as ferramentas antes de

15:31 se candidatar. Comece pelos fundamentos, construa evidências e aprimore suas habilidades com a solução de problemas na prática. O melhor SRE não é a pessoa que evita todas as falhas. Isso é impossível. O melhor SRE constrói sistemas que revelam problemas rapidamente, falham com segurança, se recuperam com eficiência e ficam mais fortes depois de cada incidente. Se você quiser construir passo a passo os projetos que mencionei, estou criando um curso prático de projetos para orientar você. Entre na lista de espera pelo link na descrição. E, se estiver se preparando para entrevistas, você também pode baixar as perguntas mais comuns de entrevista na descrição para ajudar

16:02 na sua preparação. E, se quiser mais roteiros práticos de cloud, DevOps e SRE, inscreva-se no canal. Até o próximo vídeo.

Transcrição original

[00:00] If you want to become a site reliability engineer, or SRE, you have probably seen a road map that looks like this. Learn Linux, learn Python, learn Docker, Kubernetes, Prometheus, Grafana, Terraform, and a cloud platform. But, after learning all those tools, many people still cannot answer the most important question. How do you make a production system >> [music] >> reliable? This is because SRE is not simply a collection of DevOps tools, and it is definitely not just monitoring dashboards all day. SRE is about using software engineering to operate systems at scale. It is about deciding what

[00:31] reliability means, measuring it, responding when systems fail, and reducing the chance of the same failure happening again. And in 2026, with AI generating code and infrastructure faster than ever, reliability matters even more. More code means more changes, and more changes create more ways for systems to fail. So, in this video, I will give you a complete and realistic SRE road map, from Linux and networking to Kubernetes, observability, incident response, SLOs, automation, and hands-on projects. I will also show you what to

[01:01] learn first, what can wait, and how to prove your skills in an interview. What does an SRE actually do? SRE stands for site reliability engineering. The role became popular through Google, but today, companies use the title in different ways. In one company, [music] an SRE may focus on Kubernetes platforms. In another, the role may involve observability, incident response, cloud infrastructure, performance, or developer tooling. But, the central goal stays the same. Keep services reliable enough for users, while allowing the business to continue releasing changes. The words reliable

[01:32] enough are important. Perfect reliability is usually impossible, and trying to achieve it can become extremely expensive. An SRE helps the business define the right reliability target and balance stability with delivery speed. Imagine your company operates an online payment service. The business promises customers that the service will be available 99.9% of the time. That promise may be written into an SLA, or service level agreement. But, how do we measure whether the service is healthy? We choose an SLI, a service level indicator. This could be the

[02:03] percentage of successful payment requests measured over 30 days. Then, we define the SLO, the service level objective. For example, 99.9% of valid payment requests should succeed within 500 milliseconds over a rolling 30-day period. The small amount of permitted failure is the error budget. If the service is comfortably within budget, the team can continue releasing features. If the team is consuming the budget too quickly, it may need to slow down releases and focus on reliability. That is SRE thinking. Reliability is not

[02:33] a vague feeling. It is a measurable engineering decision. An SRE may therefore spend time [music] automating infrastructure and operational work, improving monitoring and alerting, responding to production incidents, debugging application and infrastructure failures, improving deployment safety, planning capacity, reducing latency and cost, and working with developers to design more resilient systems. Now that we understand the job, let us build the road map. Phase one, build your system’s foundation. The first part of the road map is not Kubernetes. It is learning how computers, operation systems,

[03:05] applications, and networks actually behave. Linux. Most production workloads still run on Linux, so you need to become comfortable working without a graphical interface. Learn files, directories, permissions, users, and groups, processes, services, signals, and systemd, package management, CPU, memory, disk, and file system concepts, environment variables, SSH, logs, and journalctl, basic shell scripting, and tools such as top, ps, free, df, du, lsof, ss, curl, and grep. Do not just memorize commands. Practice

[03:35] troubleshooting. What do you check when a server runs out of disk space? Why is a process using 100% CPU? Why can the application not open a port? Why is a service failing after a restart? An SRE must move from symptom to cause. Networking. Many production incidents that appear to be application failures are really DNS, routing, firewall, certificate, or connectivity problems. Learn the TCP IP and OSI models, IP addressing and subnetting, DNS, TCP, and HTTPS TLS certificates, ports and sockets, routing, NAT, and firewalls,

[04:08] proxies and load balancers, VPNs, and basic troubleshooting with tools such as dig, nslookup, curl, ping, traceroute, and tcpdump. You should be able to follow a request from a user’s browser through DNS, a load balancer, application, and a database and identify where it might fail. Programming and automation. SRE applies software engineering to operations. That means some coding is required. Python is a strong first choice because it is widely used for automation. Go is also valuable, especially in cloud-native environments, because many Kubernetes

[04:39] tools are written in Go. You do not need to become a full-stack developer, but you should understand variables, functions, loops, and data structures, reading and writing files, calling APIs, parsing JSON, YAML, error handling, testing, and working with Git. Use code to automate repetitive work, checking certificates, validating endpoints, analyzing logs, or reporting on healthy resources. If you perform the same manual task repeatedly, ask whether software can do it more safely. The software delivery lifecycle. To operate an application, you need to understand how it is built and delivered. Create a

[05:10] simple web application. It does not need to be complex. A small API connected to a database is enough. Learn how a request moves through the system, how configuration is loaded, how dependencies are managed, how logs are generated, how the application is tested, and how it is deployed. Then learn the basics of CI/CD, build, test, security checks, artifact creation, deployment, verification, and rollback. This gives you something concrete to operate throughout the rest of the roadmap. Phase two, learn modern infrastructure. Once your foundation is strong, move into the infrastructure used by modern production systems. Cloud

[05:42] fundamentals. Choose one cloud platform, AWS, Azure, or Google Cloud. Focus on the architectural building blocks, compute, virtual networks, identify and access management, storage, managed databases, load balancing, auto scaling, monitoring, backup and recovery, and cost management. Do not try to memorize hundreds of services. Learn how the main components work together and how to troubleshoot them. A certification can provide a structure, but it is optional. Or it will help you to pass HR filters. But a certification without hands-on troubleshooting will not make you job

[06:13] ready. Containers. Learn Docker or another container runtime. Understand images, layers, registries, volumes, networks, resource limits, health checks, and logs. Containerize the web application you built earlier. Run it locally, break it intentionally, and diagnose the problem. For example, use the wrong port, remove an environment variable, exhaust memory, break the database connection, or run the container as a user without the correct permission. Reliability skills grow faster when you deliberately create failures. Kubernetes is common in SRE roles, but learn it after Linux,

[06:43] networking, and containers. Otherwise, every problem looks like mysterious YAML. Start with [music] pods, deployments, services, config maps, and secrets, namespaces, requests and limits, liveness, readiness, and startup probes, persistent storage, ingress or gateway APIs, scheduling, auto scaling, RBAC, and rolling updates. Then focus on troubleshooting. Why is a pod pending? Why is it in crash loop back off? Why is an image not being pulled? Why can one service not reach another? Why is traffic not reaching the application? Why did the rollout fail? A practical

[07:14] certification such as the CKA can strengthen your Kubernetes skills, but the goal is not the badge. The goal is to debug a real cluster under pressure. Infrastructure as code and configuration. Production infrastructure should be reproducible and reviewable. Learn Terraform, OpenTofu, Bicep, or CloudFormation. Understand state, modules, variables, outputs, remote backends, drift, and unsafe change workflows. Also, learn how configuration and secrets are managed. Your project should be deployable from a repository, not from a list of manual clicks you no longer remember. Phase three, master

[07:45] observability. Observability is one of the most important SRE skills. Monitoring tells you when a known condition has occurred. Observability helps you investigate questions you did not predict in advance. Learn the core skills. Metrics show numerical behavior over time. Logs provide detailed events and context. Traces show how a request moves through distributed services and profiles help identify where an application consumes CPU or memory. For metrics, Prometheus and Grafana are excellent tools to learn. For logs, you can use the Elastic Stack, Loki, or a

[08:16] managed platform. For traces, learn Open Telemetry and a back end [music] such as Jaeger, Tempo, or a cloud service. But, focus on the concepts, not the logo on the tool. Learn how to instrument an application, structure logs, define useful labels, build dashboards, correlate signals, and control observability costs. Most importantly, learn how to alert well. A bad alert says, “CPU is above 80%.” A better alert says, “The checkout service is consuming its error budget too quickly and users [music] are experiencing failed requests.” Alert on systems that affect

[08:47] users, not every unusual internal metric. Every page should be actionable. If the person receiving an alert at 3:00 a.m. cannot do anything useful with it, the alert needs to be redesigned. Phase four, learn reliability engineering. Tools make data visible. Reliability engineering tells you what to do with it. SLIs, SLOs, SLAs, and error budgets. Practice defining SLIs for availability, latency, correctness, freshness, and durability. Then, create realistic SLOs based on user expectations and business impact. Understand how reliability

[09:18] percentages translate into downtime. The difference between 99.9% and 99.99% sounds small, but engineering effort and cost can be [music] enormous. Use error budgets to balance reliability work with feature delivery. Incident [music] management. Systems fail. An SRE must know how to respond without creating more chaos. Learn the incident life cycle. One, detect the problem. Two, assess severity and user impact. Three, assign clear roles for mitigating the impact. Five, communicate with stakeholders. Six, recover the service.

[09:49] Seven, and learn from the incident. During an incident, restoration comes before perfect diagnosis. You may roll back, fail over, disable a feature, or reduce traffic before you know the complete root cause. Afterwards, write a blameless postmortem covering the timeline, impact, contributing factors. What worked, what failed, and specific follow-up actions. Track metrics such as time to detect and time to restore, but do not optimize numbers without understanding the behavior behind them. Troubleshooting and root cause analysis. You cannot learn troubleshooting from one book or memorize it from interview

[10:20] questions. You build it through repeated practice. Use a structured method. Define the symptom, confirm the scope, check recent changes, gather evidence, form hypotheses, test one variable at a time, mitigate the impact, and document what you learned. Avoid jumping to the first explanation that feels familiar. System design for reliability. Learn how to design systems that expect failure. [music] Study redundancy and fault domains, horizontal scaling, load balancing, caching, queues, and asynchronous processing, timeouts, retries, and exponential [music] backoff, circuit

[10:51] breakers, item potency, graceful degradation, rate limiting, backups, and restore testing, high availability and disaster recovery. Know the difference between RTO and RPO. Understand that a backup is not proven until you successfully restore it. Performance and capacity. Learn load testing, stress testing, saturation, latency percentiles, throughput, and bottleneck analysis. Average latency can hide terrible user experiences. Learn why P95 and P99 latency matter. Practice estimating how much traffic a system can support and what will fail first as load

[11:23] increases. Reliability also includes cost. A system that stays online only by wasting enormous resources is not well engineered. Phase five, adopt the SRE mindset. The final layer is how an SRE thinks. Reduce toil. Toil is repetitive, manual, operational work that scales with the service and creates little lasting value. Not every manual task is toil, but if a team spends hours every week restarting the same service, copying the same data, or responding to the same noisy alert, the system needs improvement. Automate carefully. A badly

[11:54] designed automation can fail faster and at a larger scale than a manual process. Design safe changes. Many outages are caused by change, not hardware failure. Learn progressive delivery techniques such as rolling deployments, blue/green deployments, canary releases, feature flags, automated verification, and fast rollback. Build for humans. Create clear runbooks. Improve error messages. Make dashboards usable. Simplify repetitive procedures. Reduce cognitive load during incidents. Reliability is a technical outcome produced by both systems and people. Use AI responsibly. AI can

[12:26] summarize logs, explain alerts, >> [music] >> generate queries, draft runbooks, and suggest likely causes. Use it as an accelerator, but verify everything. An AI assistant may confidently recommend a destructive command, misunderstand the production context, or expose sensitive information if the system is poorly governed. Keep permissions minimal. Protect production data. Require [music] approval for risky actions. And preserve an audit trail. In SRE, speed matters, but safe speed matters more. Now, three projects that can prove your SRE skills.

[12:56] Do not build only perfect deployments. Build systems that fail and show how you detect, recover, and improve them. Project one, operate a production-style web application. Deploy a small application with a database using infrastructure as code. Add CI/CD, TLS, secrets management, health checks, monitoring, logs, dashboards, backups, and a rollback strategy. Define at least one SLA and SLO. Project two, Kubernetes reliability lab. Deploy the application to Kubernetes. Configure resources request and limits, probes, auto scaling, disruption controls, and

[13:27] observability. Then, inject failures, kill pods, break DNS, overload the application, deploy a faulty version, or remove access to a dependency. Measure how quickly the system detects and recovers. Project three, incident simulation and postmortem. Create a scenario in which latency increases or requests begin failing. Generate an alert, investigate metrics, logs, and traces, mitigate the incident, and write a blameless postmortem. Include the timeline, user impact, root causes, contributing factors, and follow-up actions. These projects show far more than a list of tools. They prove that you understand reliability as a complete

[13:58] system. Document them on GitHub and explain them on LinkedIn or in a blog. Include diagrams, decisions, trade-offs, failures, and lessons, not only screenshots. Now, how to prepare for SRE interviews? SRE interviews commonly test several areas. Linux and operating systems, networking, scripting and coding, troubleshooting, system design, cloud and Kubernetes, observability and reliability concepts, [music] and behavioral or incident response scenarios. You may be asked, “Users report that the application is slow, but CPU and memory look normal. How would you investigate?” The interviewer is not

[14:29] only checking whether you know a command. They want to see how you narrow the scope, gather evidence, prioritize user impact, and communicate under uncertainty. Think out loud. State your assumptions. Start broad, then narrow the investigation. Explain what evidence would confirm or reject each hypothesis. Prepare behavioral studies about a production incident, automation you created, a difficult trade-off, a mistake, and a time you improved a process. If you do not yet have professional production experience, use your lab incidents honestly. Never pretend a personal project was a real

[14:59] customer outreach. Final roadmap. Let us put everything in order. First, learn Linux, networking, Git, scripting, and how applications are built. Second, learn one cloud platform, containers, Kubernetes, infrastructure as code, and CCD. Third, [music] develop deep observability skills across metrics, logs, traces, dashboards, and actionable alerts. Fourth, learn SLOs, error budgets, incident management, troubleshooting, system design, business continuity and performance. Finally, build projects that demonstrate how you respond when systems fail. You do not need to master every tool before

[15:31] applying. Start with the foundation, build evidence, and improve through real troubleshooting. The best SRE is not the person who prevents every failure. This is impossible. The best SRE builds systems that reveal problems quickly, fail safely, recover efficiently, and become stronger after every incident. If you want to build the projects I mentioned step-by-step, I’m creating a hands-on project course to guide you through them. Join the waitlist using the link in the description. And if you are preparing interviews, you can also download the most common interview questions from the description to help

[16:02] you prepare. And if you want more practical cloud DevOps and SRE road maps, subscribe to the channel, and I will see you in the next one.