dicembre 21, 2025
17 min di lettura

Domande per il Colloquio di Junior Site Reliability Engineer: Guida Completa

interview
career-advice
job-search
entry-level
Domande per il Colloquio di Junior Site Reliability Engineer: Guida Completa
MB

Milad Bonakdar

Autore

Padroneggia i fondamentali di SRE con domande complete per il colloquio che coprono il monitoraggio, la risposta agli incidenti, gli SLO, l'automazione, la risoluzione dei problemi di Linux e le pratiche di affidabilità per i ruoli SRE junior.


Introduzione

L'Ingegneria dell'Affidabilità del Sito (SRE) combina l'ingegneria del software e l'amministrazione dei sistemi per costruire ed eseguire sistemi affidabili su larga scala. Come SRE junior, ti concentrerai sul monitoraggio, sulla risposta agli incidenti, sull'automazione e sull'apprendimento delle pratiche di affidabilità che mantengono i servizi in esecuzione senza intoppi.

Questa guida tratta le domande essenziali per il colloquio per SRE junior, organizzate per argomento per aiutarti a prepararti efficacemente. Ogni domanda include risposte dettagliate, esempi pratici e scenari pratici.


Fondamenti SRE

1. Cos'è l'Ingegneria dell'Affidabilità del Sito e come differisce da DevOps?

Risposta: SRE è l'approccio di Google per l'esecuzione affidabile di sistemi di produzione su larga scala.

Principi chiave:

  • Trattare le operazioni come un problema di software
  • Massimo 50% del tempo dedicato al lavoro operativo (toil)
  • Budget di errore per bilanciare affidabilità e velocità
  • Postmortem senza colpe
  • Implementazioni graduali e rollback automatizzati

SRE vs DevOps:

AspettoSREDevOps
FocusAffidabilità e scalabilitàCollaborazione e automazione
MetricheSLI, SLO, budget di erroreFrequenza di implementazione, lead time
ApproccioPrescrittivo (pratiche specifiche)Filosofia (movimento culturale)
ToilEsplicitamente limitato al 50%Non specificamente definito

SRE implementa i principi DevOps con pratiche e metriche specifiche.

Rarità: Molto Comune Difficoltà: Facile


2. Spiega SLI, SLO e budget di errore.

Risposta: Questi sono concetti fondamentali di SRE per misurare e gestire l'affidabilità:

SLI (Service Level Indicator):

  • Misura quantitativa del livello di servizio
  • Esempi: Latenza, disponibilità, tasso di errore

SLO (Service Level Objective):

  • Valore target per un SLI
  • Esempio: "Il 99,9% delle richieste ha successo"

Budget di errore:

  • Tasso di errore consentito (100% - SLO)
  • Utilizzato per bilanciare affidabilità e velocità delle funzionalità
# Esempio di calcolo SLI/SLO
def calculate_error_budget(total_requests, failed_requests, slo_target=0.999):
    """
    Calcola il consumo del budget di errore
    
    SLO: tasso di successo del 99,9%
    Budget di errore: 0,1% di errori consentiti
    """
    success_rate = (total_requests - failed_requests) / total_requests
    error_rate = failed_requests / total_requests
    
    # Budget di errore: quanto dell'0,1% consentito abbiamo utilizzato
    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)
    }

# Esempio
result = calculate_error_budget(
    total_requests=1000000,
    failed_requests=500,  # 0,05% tasso di errore
    slo_target=0.999
)

print(f"Tasso di successo: {result['success_rate']:.4%}")
print(f"SLO raggiunto: {result['slo_met']}")
print(f"Budget di errore consumato: {result['error_budget_consumed']:.1f}%")

Rarità: Molto Comune Difficoltà: Media


3. Cos'è il toil e come lo si riduce?

Risposta: Il toil è un lavoro operativo ripetitivo e manuale che:

  • È manuale (richiede l'azione umana)
  • È ripetitivo
  • Può essere automatizzato
  • Non ha valore duraturo
  • Cresce linearmente con la crescita del servizio

Esempi di toil:

  • Riavvio manuale dei servizi
  • Copia di file tra server
  • Scalabilità manuale delle risorse
  • Risposte ripetitive ai ticket

Strategie di riduzione del toil:

# Esempio: automatizza il riavvio del servizio
#!/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): Riavvio di $SERVICE_NAME"
    systemctl restart $SERVICE_NAME
    
    # Attendi che il servizio si stabilizzi
    sleep $RETRY_DELAY
    
    if check_service; then
        echo "$(date): $SERVICE_NAME riavviato con successo"
        # Invia notifica
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME auto-riavviato\"}"
        return 0
    else
        return 1
    fi
}

# Logica principale
if ! check_service; then
    echo "$(date): $SERVICE_NAME è inattivo"
    
    for i in $(seq 1 $MAX_RETRIES); do
        echo "Tentativo $i di $MAX_RETRIES"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done
    
    # Tutti i tentativi falliti - escalation
    echo "$(date): Impossibile riavviare $SERVICE_NAME dopo $MAX_RETRIES tentativi"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

Obiettivo SRE: mantenere il toil al di sotto del 50% del tempo, automatizzare il resto.

Rarità: Molto Comune Difficoltà: Facile-Media


Monitoraggio e Osservabilità

4. Qual è la differenza tra monitoraggio e osservabilità?

Risposta: Monitoraggio: Raccolta di metriche e avvisi predefiniti

  • Noti-noti: sai cosa cercare
  • Dashboard, avvisi, metriche
  • Esempi: CPU, memoria, frequenza delle richieste

Osservabilità: Comprensione dello stato del sistema dagli output

  • Ignoti-ignoti: debug di problemi che non avevi previsto
  • Log, metriche, tracce combinate
  • Può rispondere a domande arbitrarie
Loading diagram...

Tre pilastri dell'osservabilità:

  1. Metriche: Numeri aggregati (CPU, latenza)
  2. Log: Eventi discreti
  3. Tracce: Flusso di richieste attraverso il sistema

Esempio: Prometheus + Grafana + Loki

# Configurazione di scraping di Prometheus
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

Rarità: Comune Difficoltà: Media


5. Come si impostano avvisi efficaci?

Risposta: I buoni avvisi sono azionabili, significativi e non causano affaticamento.

Migliori pratiche per gli avvisi:

1. Avvisa sui sintomi, non sulle cause:

# Errato: avvisa sull'utilizzo elevato della CPU
- alert: HighCPU
  expr: cpu_usage > 80
  
# Corretto: avvisa sull'impatto sull'utente
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "La latenza dell'API è alta"
    description: "Il 95° percentile della latenza è {{ $value }}s"

2. Includi collegamenti al runbook:

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Il pool di connessioni al database è quasi esaurito"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. Utilizza livelli di gravità appropriati:

# Degno di una chiamata (sveglia qualcuno)
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical
    
# Degno di un ticket (gestisci durante l'orario di lavoro)
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

4. Evita l'affaticamento da avvisi:

  • Utilizza for: duration per evitare sbalzi
  • Raggruppa gli avvisi correlati
  • Imposta soglie appropriate
  • Rivedi e sintonizza regolarmente

Rarità: Molto Comune Difficoltà: Media


Risposta agli Incidente

6. Descrivi il tuo processo di risposta agli incidenti.

Risposta: Una risposta strutturata agli incidenti riduce al minimo l'impatto e il tempo di ripristino:

Fasi della risposta agli incidenti:

Loading diagram...

1. Rilevamento:

  • Si attiva un avviso o l'utente segnala un problema
  • Riconosci l'avviso
  • Crea un canale per l'incidente

2. Triage:

# Checklist di valutazione rapida
- Qual è l'impatto sull'utente?
- Quanti utenti sono interessati?
- Quali servizi sono interessati?
- Sta peggiorando?

3. Mitigazione:

# Strategie comuni di mitigazione
- Rollback dell'implementazione recente
- Scalabilità delle risorse
- Disabilita la funzionalità problematica
- Failover al sistema di backup
- Limita la frequenza del traffico

4. Risoluzione:

  • Correggi la causa principale
  • Verifica che le metriche tornino alla normalità
  • Monitora per la ricorrenza

5. Postmortem (senza colpe):

# Modello di Postmortem dell'Incidente

## Riepilogo
Breve descrizione di cosa è successo

## Impatto
- Durata: 2024-11-25 10:00 - 10:45 UTC (45 minuti)
- Utenti interessati: ~10.000 (5% del totale)
- Servizi interessati: API, Web Frontend

## Causa Principale
Il pool di connessioni al database è esaurito a causa di query lente

## Cronologia
- 10:00: Si attiva un avviso per l'alta latenza dell'API
- 10:05: L'ingegnere di turno riconosce
- 10:10: Identificato il database come collo di bottiglia
- 10:15: Aumentata la dimensione del pool di connessioni (mitigazione)
- 10:30: Identificate e interrotte le query lente
- 10:45: Servizio completamente ripristinato

## Risoluzione
- Immediata: Aumentato il pool di connessioni da 100 a 200
- A breve termine: Aggiunto timeout della query (30 secondi)
- A lungo termine: Ottimizza le query lente, aggiungi il monitoraggio delle query

## Elementi di Azione
- [ ] Aggiungi avviso per le query lente (Proprietario: Alice, Scadenza: 2024-12-01)
- [ ] Implementa il timeout della query nell'applicazione (Proprietario: Bob, Scadenza: 2024-12-05)
- [ ] Rivedi e ottimizza le 10 query più lente (Proprietario: Charlie, Scadenza: 2024-12-10)

## Lezioni Apprese
- Il monitoraggio del pool di connessioni era insufficiente
- Il degrado delle prestazioni delle query è passato inosservato

Rarità: Molto Comune Difficoltà: Media


7. Come risolvi un servizio che sta riscontrando un'alta latenza?

Risposta: Approccio sistematico al debug:

# 1. Verifica il 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. Controlla le metriche dell'applicazione
# - Frequenza delle richieste (picco improvviso?)
# - Tasso di errore (errori che causano tentativi?)
# - Utilizzo delle risorse (CPU, memoria)

# 3. Controlla le dipendenze
# - Tempo di query del database
# - Chiamate API esterne
# - Tasso di hit della cache

# 4. Controlla l'infrastruttura
top  # Utilizzo della CPU
free -h  # Memoria
iostat  # I/O del disco
netstat -s  # Statistiche di rete

# 5. Controlla i log per gli errori
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. Profila l'applicazione
# Esempio Python
import cProfile
cProfile.run('my_function()')

# 7. Controlla il database
# Log delle query lente
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# Query attive
SELECT pid, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active';

Cause comuni:

  • Query lente del database
  • Timeout delle API esterne
  • Pressione sulla memoria (pause GC)
  • Problemi di rete
  • Esaurimento delle risorse
  • Percorsi di codice inefficienti

Rarità: Molto Comune Difficoltà: Media


Automazione e Scripting

8. Scrivi uno script per verificare se un servizio è integro e riavviarlo se necessario.

Risposta: Script di controllo dello stato e auto-riparazione:

#!/usr/bin/env python3
"""
Controllo dello stato del servizio con capacità di riavvio automatico
"""
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):
        """Verifica se il servizio è integro"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: Controllo dello stato fallito: {e}")
            return False
    
    def restart_service(self):
        """Riavvia il servizio usando systemctl"""
        try:
            print(f"{datetime.now()}: Riavvio di {self.service_name}")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # Attendi che il servizio si avvii
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: Riavvio fallito: {e.stderr}")
            return False
    
    def send_alert(self, message, severity='warning'):
        """Invia un avviso al sistema di monitoraggio"""
        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"Impossibile inviare l'avviso: {e}")
    
    def monitor(self):
        """Ciclo di monitoraggio principale"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} è integro")
            return 0
        
        print(f"{datetime.now()}: {self.service_name} non è integro")
        self.send_alert(f"{self.service_name} è inattivo", severity='warning')
        
        # Tentativo di riavvio
        for attempt in range(1, self.max_retries + 1):
            print(f"Tentativo di riavvio {attempt}/{self.max_retries}")
            
            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: Servizio ripristinato")
                self.send_alert(
                    f"{self.service_name} auto-ripristinato dopo il riavvio",
                    severity='info'
                )
                return 0
            
            time.sleep(5)
        
        # Tutti i tentativi falliti
        print(f"{datetime.now()}: Impossibile ripristinare il servizio")
        self.send_alert(
            f"{self.service_name} non è stato ripristinato dopo {self.max_retries} tentativi",
            severity='critical'
        )
        return 1

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

Rarità: Comune Difficoltà: Media


Pratiche di Affidabilità

9. Cos'è un runbook e perché è importante?

Risposta: Un runbook è una procedura documentata per la gestione di attività operative e incidenti.

Struttura del runbook:

# Runbook: Alta latenza dell'API

## Sintomi
- Latenza del 95° percentile dell'API > 1 secondo
- Reclami degli utenti per caricamenti lenti delle pagine
- Avviso: "HighAPILatency" in corso

## Gravità
**Avviso** - Degrada l'esperienza utente ma il servizio è funzionale

## Fasi di Investigazione

### 1. Controlla le metriche correnti
```bash
# Controlla la distribuzione della latenza
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# Controlla la frequenza delle richieste
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

2. Identifica il collo di bottiglia

  • Controlla il tempo di query del database
  • Controlla le chiamate API esterne
  • Controlla il tasso di hit della cache
  • Rivedi le implementazioni recenti

3. Controlla le dipendenze

# Connessioni al database
mysql -e "SHOW PROCESSLIST;"

# Latenza di Redis
redis-cli --latency

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

Fasi di Mitigazione

Correzioni rapide (< 5 minuti)

  1. Scala le istanze dell'applicazione
kubectl scale deployment api --replicas=10
  1. Aumenta temporaneamente il TTL della cache
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Se il problema persiste

  1. Rollback dell'implementazione recente
kubectl rollout undo deployment/api
  1. Abilita il rate limiting
kubectl apply -f rate-limit-config.yaml

Risoluzione

  • Correggi la causa principale (query lenta, codice inefficiente)
  • Implementa la correzione
  • Monitora per 30 minuti
  • Riduci la capacità alla normalità

Escalation

Se non si riesce a risolvere entro 30 minuti:

  • Esegui l'escalation a: @backend-team
  • Canale Slack: #incidents
  • Di turno: Usa la politica di escalation di PagerDuty

Correlato


**Perché i runbook sono importanti:**
- Risposta agli incidenti più rapida
- Procedure coerenti
- Condivisione della conoscenza
- Riduzione dello stress durante gli incidenti
- Strumento di formazione per i nuovi membri del team

**Rarità:** Comune
**Difficoltà:** Facile

---

### 10. Spiega il concetto di degradazione controllata.

**Risposta:**
La **degradazione controllata** significa che un sistema continua a funzionare a capacità ridotta quando i componenti falliscono, invece di fallire completamente.

**Strategie:**

**1. Feature Flag:**
```python
# Disabilita le funzionalità non critiche durante il carico elevato
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }
    
    def is_enabled(self, feature):
        # Disabilita le funzionalità non critiche se il budget di errore è basso
        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):
        # Controlla se il budget di errore è < 20%
        return get_error_budget() < 0.2

# Utilizzo
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # Degrada in modo controllato - mostra contenuti statici
    show_popular_items()

2. Circuit Breaker:

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # Funzionamento normale
    OPEN = "open"      # Fallisce, rifiuta le richieste
    HALF_OPEN = "half_open"  # Verifica il ripristino

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:
                # Restituisci il fallback invece di chiamare il servizio in errore
                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):
        # Restituisci dati memorizzati nella cache o risposta predefinita
        return {"status": "degraded", "data": []}

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

3. Timeout e Tentativi:

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

def create_resilient_session():
    session = requests.Session()
    
    # Strategia di tentativo
    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

# Utilizzo con timeout
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # Degrada in modo controllato - usa i dati memorizzati nella cache
    response = get_cached_data()

Rarità: Comune Difficoltà: Media


Nozioni di Base sulla Containerizzazione

11. Cos'è Docker e come differisce dalle macchine virtuali?

Risposta: Docker è una piattaforma di containerizzazione che impacchetta le applicazioni con le loro dipendenze.

Container vs Macchine Virtuali:

Loading diagram...

Differenze chiave:

CaratteristicaContainerMacchine Virtuali
Tempo di AvvioSecondiMinuti
DimensioneMBGB
Utilizzo delle RisorseLeggeroPesante
IsolamentoA livello di processoA livello di hardware
SOCondivide il SO hostSO separato per VM

Nozioni di base su Docker:

# Pull di un'immagine
docker pull nginx:latest

# Esegui un container
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# Elenca i container in esecuzione
docker ps

# Visualizza i log
docker logs my-nginx

# Esegui un comando nel container
docker exec -it my-nginx bash

# Arresta il container
docker stop my-nginx

# Rimuovi il container
docker rm my-nginx

Esempio di Dockerfile:

# Immagine di base
FROM python:3.9-slim

# Imposta la directory di lavoro
WORKDIR /app

# Copia i requisiti
COPY requirements.txt .

# Installa le dipendenze
RUN pip install --no-cache-dir -r requirements.txt

# Copia il codice dell'applicazione
COPY . .

# Espone la porta
EXPOSE 8000

# Controllo dello stato
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# Esegui l'applicazione
CMD ["python", "app.py"]

Costruisci ed Esegui:

# Costruisci l'immagine
docker build -t myapp:1.0 .

# Esegui con variabili d'ambiente
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# Visualizza l'utilizzo delle risorse
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:

Esegui con Docker Compose:

# Avvia tutti i servizi
docker-compose up -d

# Visualizza i log
docker-compose logs -f web

# Scala il servizio
docker-compose up -d --scale web=3

# Arresta tutti i servizi
docker-compose down

Migliori pratiche:

  • Usa immagini di base ufficiali
  • Riduci al minimo il numero di layer
  • Non eseguire come root
  • Usa .dockerignore
  • Tagga correttamente le immagini
  • Scansiona le vulnerabilità

Rarità: Molto Comune Difficoltà: Facile-Media


Controllo della Versione e Implementazione

12. Spiega i flussi di lavoro di Git e come gestisci le implementazioni.

Risposta: Git è essenziale per il controllo della versione e l'automazione dell'implementazione.

Flusso di lavoro Git comune:

Loading diagram...

Comandi Git di base:

# Clona il repository
git clone https://github.com/company/repo.git
cd repo

# Crea un branch di feature
git checkout -b feature/add-monitoring

# Apporta modifiche ed esegui il commit
git add .
git commit -m "Aggiungi il monitoraggio di Prometheus"

# Esegui il push sul remote
git push origin feature/add-monitoring

# Aggiorna da main
git checkout main
git pull origin main
git checkout feature/add-monitoring
git rebase main

# Unisci la feature (dopo l'approvazione del PR)
git checkout main
git merge feature/add-monitoring
git push origin main

Strategia di Branching:

1. Gitflow:

  • main: Codice pronto per la produzione
  • develop: Branch di integrazione
  • feature/*: Nuove funzionalità
  • release/*: Preparazione del rilascio
  • hotfix/*: Correzioni di emergenza

2. Sviluppo Basato sul Trunk:

# Branch di feature di breve durata
git checkout -b feature/quick-fix
# Lavora per < 1 giorno
git push origin feature/quick-fix
# Unisci a main immediatamente dopo la revisione

Flusso di lavoro di implementazione:

1. Pipeline CI/CD (GitHub Actions):

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run tests
        run: |
          npm install
          npm test
      
      - name: Run linting
        run: npm run lint
  
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses:
Newsletter subscription

Consigli di carriera settimanali che funzionano davvero

Ricevi le ultime idee direttamente nella tua casella di posta

Decorative doodle

Il Tuo Prossimo Colloquio Dista Solo un Curriculum

Crea un curriculum professionale e ottimizzato in pochi minuti. Non servono competenze di design—solo risultati comprovati.

Crea il mio curriculum

Condividi questo post

Riduci il Tempo di Scrittura del Curriculum del 90%

La persona in cerca di lavoro media impiega più di 3 ore per formattare un curriculum. La nostra IA lo fa in meno di 15 minuti, portandoti alla fase di candidatura 12 volte più velocemente.