80.000 device MikroTik in 6 paesi: cosa abbiamo imparato a gestire una fleet

OptiWize gestisce oltre 80.000 device MikroTik in produzione, distribuiti su sei paesi europei e africani, per clienti che vanno dall'ISP regionale al carrier nazionale. Non è marketing: è lo stato corrente del nostro core, misurato dalla dashboard interna mentre scriviamo. Sono numeri che ti costringono a imparare la differenza fra un'idea buona e un'idea che regge alla scala. Abbiamo raccolto le lezioni più dure in questo articolo, con la speranza che evitino qualche notte di guardia a chi sta crescendo adesso.

Lezione 1: il provisioning manuale non è un MVP, è un debito tecnico

Nella prima fase di OptiWize, ogni nuovo device veniva configurato a mano dal NOC: SSH, copy-paste della config, tag in Winbox. Funzionava. A 100 device era tollerabile, a 1.000 era stancante, a 5.000 era diventato un blocker. Non perché il NOC non ce la facesse: perché ogni operatore introduceva microvarianti. Una rotta in più, una regola firewall mancante, un parametro QoS leggermente diverso. La rete era "a posto" su ogni singolo router, ma a livello di fleet era ingestibile.

Il cambio di paradigma è arrivato con i template di provisioning. Un template è una configurazione parametrizzata: definisci le variabili (IP WAN, VLAN, banda, tier QoS), il sistema genera la config valida, la applica, verifica l'esito. Oggi OptiWize gira con 55+ template attivi, dal CPE residenziale al gateway enterprise al firewall di filiale. Il NOC non scrive più configurazioni: sceglie un template e compila il form. Tempo medio di provisioning −70% rispetto al setup manuale, e — soprattutto — drift azzerato.

Lezione 2: il drift è un cancro, non un fastidio

Drift è la parola gentile per dire "il router non è più come lo abbiamo lasciato". Qualcuno è entrato in Winbox, ha aggiunto una rotta per fare un troubleshooting al volo, e non l'ha rimossa. Una settimana dopo, quel router si comporta in modo diverso dagli altri. Sei mesi dopo, nessuno si ricorda perché.

OptiWize tratta il drift come un sistema di controllo industriale, non come un piacevole nice-to-have. Ogni device ha una configurazione attesa (lo "stato dichiarato") e una osservata (lo "stato letto"). Il sistema confronta le due in continuo. Se divergono — anche solo per un comment di troppo in una regola — generiamo un'eccezione. L'operatore decide: o promuove il drift a stato dichiarato (perché era voluto), o lo ripristina.

Sembra ovvio scritto così. In pratica, quando devi reggere una fleet di decine di migliaia di device, ogni microvariante è una mina che può esplodere fra sei mesi durante un upgrade. Il drift detection lo abbiamo costruito perché abbiamo perso settimane intere a inseguire bug "strani" che erano semplicemente router non più allineati alla baseline.

Lezione 3: il routing asimmetrico è il bug più frequente, e quello peggio diagnosticato

Quando abbiamo migrato OptiWize a Kubernetes — con i pod ovpn-server che gestiscono la VPN di management dei device — abbiamo incontrato un classico del mestiere: il routing asimmetrico. Il traffico dal cluster K8s arrivava ai MikroTik con l'IP sorgente del nodo (es. 192.168.122.51). Il MikroTik non sapeva come routare la risposta indietro: il return path passava per la default route, non per la VPN. Timeout TCP a raffica, sessioni che cadevano in 30 secondi.

La diagnosi ha richiesto giorni. Il fix è stato banale una volta capito il problema: applicare MASQUERADE sulle interfacce tun OpenVPN nel cluster (`iptables -t nat -A POSTROUTING -o tun10x -j MASQUERADE`). Da quel momento, ogni richiesta verso un MikroTik appare provenire dall'IP della tun del server VPN, che il device sa routare indietro. Asimmetria risolta.

Lezione 4: il load balancing si fa con regole esplicite, non con la fortuna

Sempre in fase K8s, abbiamo dovuto distribuire il traffico OpenVPN su tre istanze dietro un'unica porta (1188 → 1181, 1182, 1183). La prima implementazione usava regole iptables DNAT senza specificare la porta destinazione esplicitamente. Risultato: le regole intercettavano TUTTO il traffico TCP del nodo, inclusi SSH, kubelet, e API. Cluster a pezzi in pochi minuti.

La regola corretta è `iptables -t nat -A PREROUTING -p tcp --dport 1188 -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination :1181`. Il `--dport` è obbligatorio. Senza, qualunque pacchetto TCP entra nel matchset. È il tipo di errore che non si vede in lab e ti spacca la produzione. Lo segnaliamo perché abbiamo visto la stessa svista in tre setup diversi di clienti.

Lezione 5: i rollout massivi non si fanno di notte, si fanno con canary

Per anni la regola informale è stata "i rollout grossi si fanno alle 03:00, quando c'è meno traffico". È una regola della prima generazione di NOC, quando il rollback richiedeva un intervento manuale. Oggi non più. Un rollout massivo su una fleet MikroTik si fa con canary release: applichi il cambio a un sotto-insieme (5%-10%), monitori i KPI (packet loss, latenza, ticket aperti), e procedi solo se i numeri reggono.

OptiWize supporta canary release nel template engine: ogni rollout di policy può essere targetato per group, region o customer tag. Il sistema applica progressivamente, monitora i metric Zabbix in tempo reale, e se rileva degrado oltre la soglia interrompe automaticamente. I rollout massivi sono passati da operazioni notturne a processi diurni supervisionati. La differenza per il NOC: dormire la notte.

Lezione 6: ogni device va trattato come se non potessi più toccarlo

L'errore più comune nella gestione di una fleet è pensare al singolo router come a un asset accessibile. Lo è oggi. Non lo sarà domani. Un CPE in casa cliente, un PE in un POP remoto, un firewall in una filiale al terzo piano di un capannone: ogni device è un costo logistico a tornare a metterci le mani. La regola d'oro che abbiamo imparato è: ogni operazione che fai su un device deve essere idempotente, rollback-friendly e osservabile da remoto. Sempre. Senza eccezioni.

OptiWize implementa questa regola con tre meccanismi: backup channel polling (se il device perde la VPN principale, c'è un canale di backup via cellular o L2TP secondario), watchdog di configurazione (se applichi una config che ti taglia fuori, il device fa rollback automatico dopo 60 secondi se non confermi), e scheduling con safe-mode (operazioni programmate si annullano da sole se non hai una connessione di management attiva).

Le tre cose da fare se siete in mezzo al guado

1. Misurate il drift. Se non sapete quanti dei vostri device sono allineati alla baseline che pensate, partite da lì. Anche un check trimestrale manuale è meglio di niente. Quando il numero sarà brutto — e lo sarà — avrete la base per giustificare l'investimento in template engine.
2. Identificate le tre configurazioni più ripetute. Per ogni cliente con cui parliamo, l'80% del lavoro di provisioning è ripetuto su tre o quattro pattern. Trasformateli in template, anche se gestiti manualmente in uno script Python. Il salto di produttività è immediato.
3. Smettete di fare rollout notturni. Non perché siano sbagliati, ma perché vi tengono in un mondo dove il rollback è manuale. Investite due settimane di lavoro per fare canary release con monitoring automatico. Vi cambia la vita operativa.

Se volete vederlo dal vivo

OptiWize gira oggi su 80.000+ device, 55+ template attivi, drift detection in continuo, canary release abilitato. Se gestite una fleet sopra i 1.000 router e vi riconoscete in qualche punto sopra, il modo più rapido per capire se ci convieniamo è un audit di mezza giornata: prendiamo una vostra rete reale, la confrontiamo con i nostri benchmark, vi diamo un numero concreto su tempo di provisioning, drift e MTTR. Senza obblighi, senza pitch.