dezembro 21, 2025
17 min de leitura

Perguntas para Entrevista de Engenheiro de Confiabilidade de Site Júnior: Guia Completo

interview
career-advice
job-search
entry-level
Perguntas para Entrevista de Engenheiro de Confiabilidade de Site Júnior: Guia Completo
MB

Milad Bonakdar

Autor

Domine os fundamentos essenciais de SRE com perguntas abrangentes para entrevistas, cobrindo monitoramento, resposta a incidentes, SLOs, automação, solução de problemas do Linux e práticas de confiabilidade para funções de SRE júnior.


Introdução

A Engenharia de Confiabilidade de Sites (SRE) combina engenharia de software e administração de sistemas para construir e executar sistemas confiáveis em larga escala. Como um SRE júnior, você se concentrará no monitoramento, resposta a incidentes, automação e aprendizado de práticas de confiabilidade que mantêm os serviços funcionando sem problemas.

Este guia abrange as perguntas essenciais de entrevistas para SREs juniores, organizadas por tópico para ajudá-lo a se preparar de forma eficaz. Cada pergunta inclui respostas detalhadas, exemplos práticos e cenários práticos.


Fundamentos de SRE

1. O que é Engenharia de Confiabilidade de Sites e como ela difere de DevOps?

Resposta: SRE é a abordagem do Google para executar sistemas de produção de forma confiável em escala.

Princípios-chave:

  • Tratar operações como um problema de software
  • Máximo de 50% do tempo em trabalho operacional (toil)
  • Orçamentos de erro para equilibrar confiabilidade e velocidade
  • Postmortems sem culpa
  • Lançamentos graduais e rollbacks automatizados

SRE vs DevOps:

AspectoSREDevOps
FocoConfiabilidade e escalabilidadeColaboração e automação
MétricasSLIs, SLOs, orçamentos de erroFrequência de implantação, tempo de entrega
AbordagemPrescritiva (práticas específicas)Filosofia (movimento cultural)
ToilExplicitamente limitado a 50%Não definido especificamente

SRE implementa os princípios de DevOps com práticas e métricas específicas.

Frequência: Muito Comum Dificuldade: Fácil


2. Explique SLIs, SLOs e orçamentos de erro.

Resposta: Esses são conceitos centrais de SRE para medir e gerenciar a confiabilidade:

SLI (Indicador de Nível de Serviço):

  • Medida quantitativa do nível de serviço
  • Exemplos: Latência, disponibilidade, taxa de erro

SLO (Objetivo de Nível de Serviço):

  • Valor alvo para um SLI
  • Exemplo: "99,9% das solicitações são bem-sucedidas"

Orçamento de Erro:

  • Taxa de falha permitida (100% - SLO)
  • Usado para equilibrar confiabilidade vs velocidade de recursos
# Exemplo de cálculo de SLI/SLO
def calculate_error_budget(total_requests, failed_requests, slo_target=0.999):
    """
    Calcular o consumo do orçamento de erro
    
    SLO: taxa de sucesso de 99,9%
    Orçamento de Erro: 0,1% de falhas permitidas
    """
    success_rate = (total_requests - failed_requests) / total_requests
    error_rate = failed_requests / total_requests
    
    # Orçamento de erro: quanto dos 0,1% permitidos usamos
    allowed_errors = total_requests * (1 - slo_target)
    budget_consumed = (failed_requests / allowed_errors) * 100
    
    return {
        'success_rate': success_rate,
        'error_rate': error_rate,
        'slo_target': slo_target,
        'slo_met': success_rate >= slo_target,
        'error_budget_consumed': budget_consumed,
        'remaining_budget': max(0, 100 - budget_consumed)
    }

# Exemplo
result = calculate_error_budget(
    total_requests=1000000,
    failed_requests=500,  # taxa de erro de 0,05%
    slo_target=0.999
)

print(f"Taxa de Sucesso: {result['success_rate']:.4%}")
print(f"SLO Atingido: {result['slo_met']}")
print(f"Orçamento de Erro Consumido: {result['error_budget_consumed']:.1f}%")

Frequência: Muito Comum Dificuldade: Média


3. O que é toil e como você o reduz?

Resposta: Toil é trabalho operacional repetitivo e manual que:

  • É manual (requer ação humana)
  • É repetitivo
  • Pode ser automatizado
  • Não tem valor duradouro
  • Cresce linearmente com o crescimento do serviço

Exemplos de toil:

  • Reiniciar serviços manualmente
  • Copiar arquivos entre servidores
  • Escalar recursos manualmente
  • Respostas repetitivas a tickets

Estratégias de redução de toil:

# Exemplo: Automatizar a reinicialização do serviço
#!/bin/bash
# auto-restart-service.sh

SERVICE_NAME="myapp"
MAX_RETRIES=3
RETRY_DELAY=5

check_service() {
    systemctl is-active --quiet $SERVICE_NAME
    return $?
}

restart_service() {
    echo "$(date): Reiniciando $SERVICE_NAME"
    systemctl restart $SERVICE_NAME
    
    # Aguardar o serviço estabilizar
    sleep $RETRY_DELAY
    
    if check_service; then
        echo "$(date): $SERVICE_NAME reiniciado com sucesso"
        # Enviar notificação
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME reiniciado automaticamente\"}"
        return 0
    else
        return 1
    fi
}

# Lógica principal
if ! check_service; then
    echo "$(date): $SERVICE_NAME está inativo"
    
    for i in $(seq 1 $MAX_RETRIES); do
        echo "Tentativa $i de $MAX_RETRIES"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done
    
    # Todas as tentativas falharam - escalar
    echo "$(date): Falha ao reiniciar $SERVICE_NAME após $MAX_RETRIES tentativas"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

Objetivo de SRE: Manter o toil abaixo de 50% do tempo, automatizar o resto.

Frequência: Muito Comum Dificuldade: Fácil-Média


Monitoramento e Observabilidade

4. Qual é a diferença entre monitoramento e observabilidade?

Resposta: Monitoramento: Coletar métricas e alertas predefinidos

  • Conhecido-desconhecido: Você sabe o que observar
  • Dashboards, alertas, métricas
  • Exemplos: CPU, memória, taxa de requisição

Observabilidade: Entender o estado do sistema a partir das saídas

  • Desconhecido-desconhecido: Depurar problemas que você não previu
  • Logs, métricas, rastreamentos combinados
  • Pode responder a perguntas arbitrárias
Loading diagram...

Três Pilares da Observabilidade:

  1. Métricas: Números agregados (CPU, latência)
  2. Logs: Eventos discretos
  3. Rastreamentos: Fluxo de solicitação através do sistema

Exemplo: Prometheus + Grafana + Loki

# Configuração de scrape do Prometheus
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

Frequência: Comum Dificuldade: Média


5. Como você configura alertas eficazes?

Resposta: Bons alertas são acionáveis, significativos e não causam fadiga.

Melhores Práticas de Alerta:

1. Alerte sobre sintomas, não causas:

# Ruim: Alerta sobre CPU alta
- alert: HighCPU
  expr: cpu_usage > 80
  
# Bom: Alerta sobre o impacto no usuário
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "A latência da API está alta"
    description: "A latência do 95º percentil é {{ $value }}s"

2. Inclua links para runbooks:

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "O pool de conexões do banco de dados está quase esgotado"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. Use níveis de severidade apropriados:

# Que merecem ser paginados (acorda alguém)
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical
    
# Que merecem ser registrados (lidar durante o horário comercial)
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

4. Evite a fadiga de alertas:

  • Use a duração for: para evitar oscilações
  • Agrupe alertas relacionados
  • Defina limites apropriados
  • Revise e ajuste regularmente

Frequência: Muito Comum Dificuldade: Média


Resposta a Incidentes

6. Descreva seu processo de resposta a incidentes.

Resposta: Uma resposta a incidentes estruturada minimiza o impacto e o tempo de recuperação:

Etapas de Resposta a Incidentes:

Loading diagram...

1. Detecção:

  • Alerta é acionado ou usuário relata problema
  • Reconhecer o alerta
  • Criar canal de incidente

2. Triagem:

# Lista de verificação de avaliação rápida
- Qual é o impacto no usuário?
- Quantos usuários afetados?
- Quais serviços são impactados?
- Está piorando?

3. Mitigação:

# Estratégias comuns de mitigação
- Reverter a implantação recente
- Escalar recursos
- Desativar recurso problemático
- Failover para o sistema de backup
- Limitar a taxa de tráfego

4. Resolução:

  • Corrigir a causa raiz
  • Verificar se as métricas retornam ao normal
  • Monitorar a recorrência

5. Postmortem (Sem Culpa):

# Modelo de Postmortem de Incidente

## Resumo
Breve descrição do que aconteceu

## Impacto
- Duração: 2024-11-25 10:00 - 10:45 UTC (45 minutos)
- Usuários afetados: ~10.000 (5% do total)
- Serviços impactados: API, Frontend Web

## Causa Raiz
O pool de conexões do banco de dados esgotou devido a consultas lentas

## Cronograma
- 10:00: Alerta disparado para alta latência da API
- 10:05: Engenheiro de plantão reconheceu
- 10:10: Identificado o banco de dados como gargalo
- 10:15: Aumentado o tamanho do pool de conexões (mitigação)
- 10:30: Identificadas e eliminadas consultas lentas
- 10:45: Serviço totalmente recuperado

## Resolução
- Imediata: Aumentado o pool de conexões de 100 para 200
- Curto prazo: Adicionado tempo limite de consulta (30s)
- Longo prazo: Otimizar consultas lentas, adicionar monitoramento de consulta

## Itens de Ação
- [ ] Adicionar alerta para consultas lentas (Proprietário: Alice, Vencimento: 2024-12-01)
- [ ] Implementar tempo limite de consulta no aplicativo (Proprietário: Bob, Vencimento: 2024-12-05)
- [ ] Revisar e otimizar as 10 consultas mais lentas (Proprietário: Charlie, Vencimento: 2024-12-10)

## Lições Aprendidas
- O monitoramento do pool de conexões era insuficiente
- A degradação do desempenho da consulta passou despercebida

Frequência: Muito Comum Dificuldade: Média


7. Como você soluciona um serviço que está apresentando alta latência?

Resposta: Abordagem sistemática de depuração:

# 1. Verificar o problema
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/health

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# 2. Verificar métricas do aplicativo
# - Taxa de requisição (pico repentino?)
# - Taxa de erro (erros causando retentativas?)
# - Uso de recursos (CPU, memória)

# 3. Verificar dependências
# - Tempo de consulta do banco de dados
# - Chamadas de API externa
# - Taxa de acerto do cache

# 4. Verificar infraestrutura
top  # Uso da CPU
free -h  # Memória
iostat  # E/S do disco
netstat -s  # Estatísticas de rede

# 5. Verificar logs em busca de erros
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. Criar perfil do aplicativo
# Exemplo em Python
import cProfile
cProfile.run('my_function()')

# 7. Verificar banco de dados
# Log de consultas lentas
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# Consultas ativas
SELECT pid, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active';

Causas comuns:

  • Consultas lentas no banco de dados
  • Tempos limite de API externa
  • Pressão de memória (pausas de GC)
  • Problemas de rede
  • Esgotamento de recursos
  • Caminhos de código ineficientes

Frequência: Muito Comum Dificuldade: Média


Automação e Scripting

8. Escreva um script para verificar se um serviço está saudável e reiniciá-lo se necessário.

Resposta: Script de verificação de saúde e auto-remediação:

#!/usr/bin/env python3
"""
Verificador de saúde do serviço com capacidade de reinicialização automática
"""
import requests
import subprocess
import time
import sys
from datetime import datetime

class ServiceMonitor:
    def __init__(self, service_name, health_url, max_retries=3):
        self.service_name = service_name
        self.health_url = health_url
        self.max_retries = max_retries
    
    def check_health(self):
        """Verificar se o serviço está saudável"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: Verificação de saúde falhou: {e}")
            return False
    
    def restart_service(self):
        """Reiniciar o serviço usando systemctl"""
        try:
            print(f"{datetime.now()}: Reiniciando {self.service_name}")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # Aguardar o serviço iniciar
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: Reinicialização falhou: {e.stderr}")
            return False
    
    def send_alert(self, message, severity='warning'):
        """Enviar alerta para o sistema de monitoramento"""
        try:
            requests.post(
                'https://alerts.company.com/webhook',
                json={
                    'service': self.service_name,
                    'message': message,
                    'severity': severity,
                    'timestamp': datetime.now().isoformat()
                },
                timeout=5
            )
        except Exception as e:
            print(f"Falha ao enviar alerta: {e}")
    
    def monitor(self):
        """Loop de monitoramento principal"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} está saudável")
            return 0
        
        print(f"{datetime.now()}: {self.service_name} está não saudável")
        self.send_alert(f"{self.service_name} está inativo", severity='warning')
        
        # Tentar reiniciar
        for attempt in range(1, self.max_retries + 1):
            print(f"Tentativa de reinicialização {attempt}/{self.max_retries}")
            
            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: Serviço recuperado")
                self.send_alert(
                    f"{self.service_name} auto-recuperado após a reinicialização",
                    severity='info'
                )
                return 0
            
            time.sleep(5)
        
        # Todas as tentativas falharam
        print(f"{datetime.now()}: Falha ao recuperar o serviço")
        self.send_alert(
            f"{self.service_name} falhou ao recuperar após {self.max_retries} tentativas",
            severity='critical'
        )
        return 1

if __name__ == '__main__':
    monitor = ServiceMonitor(
        service_name='myapp',
        health_url='http://localhost:8080/health'
    )
    sys.exit(monitor.monitor())

Frequência: Comum Dificuldade: Média


Práticas de Confiabilidade

9. O que é um runbook e por que ele é importante?

Resposta: Um runbook é um procedimento documentado para lidar com tarefas operacionais e incidentes.

Estrutura do Runbook:

# Runbook: Alta Latência da API

## Sintomas
- Latência do 95º percentil da API > 1 segundo
- Reclamações de usuários sobre carregamento lento de páginas
- Alerta: "HighAPILatency" disparando

## Severidade
**Aviso** - Degrada a experiência do usuário, mas o serviço é funcional

## Etapas de Investigação

### 1. Verificar métricas atuais
```bash
# Verificar a distribuição da latência
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# Verificar taxa de requisição
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

2. Identificar gargalo

  • Verificar tempo de consulta do banco de dados
  • Verificar chamadas de API externa
  • Verificar taxa de acerto do cache
  • Revisar implantações recentes

3. Verificar dependências

# Conexões do banco de dados
mysql -e "SHOW PROCESSLIST;"

# Latência do Redis
redis-cli --latency

# APIs externas
curl -w "%{time_total}\n" -o /dev/null -s https://external-api.com/health

Etapas de Mitigação

Correções rápidas (< 5 minutos)

  1. Escalar instâncias do aplicativo
kubectl scale deployment api --replicas=10
  1. Aumentar o TTL do cache temporariamente
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Se o problema persistir

  1. Reverter a implantação recente
kubectl rollout undo deployment/api
  1. Habilitar a limitação de taxa
kubectl apply -f rate-limit-config.yaml

Resolução

  • Corrigir a causa raiz (consulta lenta, código ineficiente)
  • Implantar a correção
  • Monitorar por 30 minutos
  • Reduzir a capacidade para o normal

Escalonamento

Se não for possível resolver dentro de 30 minutos:

  • Escalonar para: @backend-team
  • Canal do Slack: #incidents
  • De plantão: Usar a política de escalonamento do PagerDuty

Relacionado


**Por que os runbooks são importantes:**
- Resposta a incidentes mais rápida
- Procedimentos consistentes
- Compartilhamento de conhecimento
- Estresse reduzido durante incidentes
- Ferramenta de treinamento para novos membros da equipe

**Frequência:** Comum
**Dificuldade:** Fácil

---

### 10. Explique o conceito de degradação graciosa.

**Resposta:**
**Degradação graciosa** significa que um sistema continua a operar com capacidade reduzida quando os componentes falham, em vez de falhar completamente.

**Estratégias:**

**1. Feature Flags:**
```python
# Desativar recursos não críticos durante alta carga
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }
    
    def is_enabled(self, feature):
        # Desativar recursos não críticos se o orçamento de erro estiver baixo
        if self.error_budget_low():
            non_critical = ['analytics', 'search_autocomplete']
            if feature in non_critical:
                return False
        return self.flags.get(feature, False)
    
    def error_budget_low(self):
        # Verificar se o orçamento de erro < 20%
        return get_error_budget() < 0.2

# Uso
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # Degradação graciosa - mostrar conteúdo estático
    show_popular_items()

2. Circuit Breaker:

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # Operação normal
    OPEN = "open"      # Falhando, rejeitar solicitações
    HALF_OPEN = "half_open"  # Testando a recuperação

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.failures = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
            else:
                # Retornar fallback em vez de chamar o serviço com falha
                return self.fallback()
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            return self.fallback()
    
    def on_success(self):
        self.failures = 0
        self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN
    
    def fallback(self):
        # Retornar dados em cache ou resposta padrão
        return {"status": "degraded", "data": []}

# Uso
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

3. Timeouts e Retentativas:

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

def create_resilient_session():
    session = requests.Session()
    
    # Estratégia de retentativa
    retry = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )
    
    adapter = HTTPAdapter(max_retries=retry)
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    
    return session

# Uso com timeout
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # Degradação graciosa - usar dados em cache
    response = get_cached_data()

Frequência: Comum Dificuldade: Média


Noções Básicas de Containerização

11. O que é Docker e como ele difere das máquinas virtuais?

Resposta: Docker é uma plataforma de containerização que empacota aplicativos com suas dependências.

Containers vs Máquinas Virtuais:

Loading diagram...

Principais Diferenças:

RecursoContainersMáquinas Virtuais
Tempo de InicializaçãoSegundosMinutos
TamanhoMBsGBs
Uso de RecursosLevePesado
IsolamentoNível de processoNível de hardware
SOCompartilha o SO hospedeiroSO separado por VM

Noções Básicas de Docker:

# Puxar uma imagem
docker pull nginx:latest

# Executar um container
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# Listar containers em execução
docker ps

# Visualizar logs
docker logs my-nginx

# Executar comando no container
docker exec -it my-nginx bash

# Parar container
docker stop my-nginx

# Remover container
docker rm my-nginx

Exemplo de Dockerfile:

# Imagem base
FROM python:3.9-slim

# Definir diretório de trabalho
WORKDIR /app

# Copiar requisitos
COPY requirements.txt .

# Instalar dependências
RUN pip install --no-cache-dir -r requirements.txt

# Copiar código do aplicativo
COPY . .

# Expor porta
EXPOSE 8000

# Verificação de saúde
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# Executar aplicativo
CMD ["python", "app.py"]

Construir e Executar:

# Construir imagem
docker build -t myapp:1.0 .

# Executar com variáveis de ambiente
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# Visualizar uso de recursos
docker stats myapp

Docker Compose (Multi-container):

version: '3.8'

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://db:5432/mydb
    depends_on:
      - db
      - redis
    restart: unless-stopped
  
  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Executar com Docker Compose:

# Iniciar todos os serviços
docker-compose up -d

# Visualizar logs
docker-compose logs -f web

# Escalar serviço
docker-compose up -d --scale web=3

# Parar todos os serviços
docker-compose down

Melhores Práticas:

  • Usar imagens base oficiais
  • Minimizar a contagem de camadas
  • Não executar como root
  • Usar .dockerignore
  • Taggear imagens corretamente
  • Verificar vulnerabilidades

Frequência: Muito Comum Dificuldade: Fácil-Média


Controle de Versão e Implantação

12. Explique os fluxos de trabalho do Git e como você lida com as implantações.

Resposta: Git é essencial para controle de versão e automação de implantação.

Fluxo de Trabalho Git Comum:

Loading diagram...

Comandos Básicos do Git:

# Clonar repositório
git clone https://github.com/company/repo.git
cd repo

# Criar branch de recurso
git checkout -b feature/adicionar-monitoramento

# Fazer alterações e commitar
git add .
git commit -m "Adicionar monitoramento do Prometheus"

# Enviar para o remoto
git push origin feature/adicionar-monitoramento

# Atualizar do main
git checkout main
git pull origin main
git checkout feature/adicionar-monitoramento
git rebase main

# Fazer merge do recurso (após aprovação do PR)
git checkout main
git merge feature/adicionar-monitoramento
git push origin main

Estratégia de Branching:

1. Gitflow:

  • main: Código pronto para produção
  • develop: Branch de integração
  • feature/*: Novos recursos
  • release/*: Preparação para lançamento
  • hotfix/*: Correções de emergência

2. Desenvolvimento Baseado em Trunk:

# Branches de recurso de curta duração
git checkout -b feature/correção-rápida
# Trabalhar por < 1 dia
git push origin feature/correção-rápida
# Fazer merge para main imediatamente após a revisão

Fluxo de Trabalho de Implantação:

1. Pipeline CI/CD (GitHub Actions):

name: Implantar para Produção

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Executar testes
        run: |
          npm install
          npm test
      
      - name: Executar linting
        run: npm run lint
  
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Construir imagem Docker
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} myapp:latest
      
      - name: Enviar para o registro
        run: |
          echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push myapp:${{ github.sha }}
          docker push myapp:latest
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Implantar para produção
        run: |
          kubectl set image deployment/myapp \
            myapp=myapp:${{ github.sha }}
          kubectl rollout status deployment/myapp

2. Script de Implantação:

Newsletter subscription

Dicas de carreira semanais que realmente funcionam

Receba as últimas ideias diretamente na sua caixa de entrada

Decorative doodle

Pare de Se Candidatar. Comece a Ser Contratado.

Transforme seu currículo em um ímã de entrevistas com otimização impulsionada por IA em que candidatos a emprego em todo o mundo confiam.

Comece grátis

Compartilhar esta publicação

Reduza o Tempo de Escrita do Currículo em 90%

O candidato a emprego médio gasta mais de 3 horas formatando um currículo. Nossa IA faz isso em menos de 15 minutos, levando você à fase de candidatura 12 vezes mais rápido.