Perché non si può usarla per estinguere un incendio
Deformazione professionale: quando il lavoro forma cattive abitudini
Ho già scritto che nel settore IT, con centinaia di commutazioni al giorno, non sono le abitudini domestiche a determinare l’approccio al lavoro, ma al contrario, il lavoro forma in noi l’abitudine a risolvere immediatamente i problemi, spesso senza un adeguato analisi delle conseguenze.
Ho trovato per voi alcuni esempi di come le persone cedono al tentativo di ottenere un risultato immediato, prendendo l’esempio dell’acquisto impulsivo. Poveretti, al momento dell’ordine credevano che l’acquisto in un click fosse l’unico passo per risolvere il problema.
Chi è stato a farlo?Immaginate che i CTO e i PM di grandi aziende agiscano esattamente allo stesso modo. Ordinano alle squadre DevOps “soluzioni pronte all’uso”. Ricevono la tanto attesa “scatola” con le ultime tecnologie (Apache Kafka, storage object S3, DB shardata, ricerca semantica), ma non scoprono la brutta verità: il prodotto non include istruzioni per l’installazione, la configurazione e l’uso. Non ci sono script di deploy, né possibilità di scaling, monitoraggio della performance. E soprattutto — nessuno ha avvertito la squadra DevOps che queste tecnologie sarebbero state effettivamente integrate.
Trascorrono tre mesi dall’ordine, ma invece del sollievo atteso, il responsabile si trova di fronte a un nuovo cerchio di problemi. Il suo disappunto può essere espresso con queste parole: «È arrivata la scatola… ma dopo tre mesi di consegna ho dimenticato perché l’avevo ordinata». La ricerca di vittorie rapide si trasforma in caos operativo, mentre l’assenza di pianificazione strategica trasforma le tecnologie in fonte di infinite difficoltà.## Ci serve Kafka per il prossimo rilascio
Qualcuno dei tech leads ha letto un articolo su Habr sul “flusso di eventi in tempo reale”, ha annuito e ha detto: “Ci serve Kafka”. Senza richiesta di proposte. Senza revisione dell’architettura. Senza coinvolgimento dei DevOps. Familiare?
Sì, Kafka è open source. Sì, si scalabilizza. Ma chiedete a qualsiasi squadra che l’abbia gestita in cluster: la maturità di Kafka non è lineare — è una funzione a gradini.
- 0–6 mesi: “Tutto funziona!” — Bilanciamento nascosto dei topic, carico non uniforme sui broker, latenza non controllata
- 6–12 mesi: “Perché aumentano i ritardi?” — Riassegnazione manuale, estinzione degli incendi, responsabilità frammentata
- 12+ mesi: “Chi se ne occupa? Come possiamo disattivarla?” — “Nascita di zombie” con costi esterni non considerati per la manutenzione
Senza automazione, osservabilità e gestione del ciclo di vita dell’intera ecosistema Kafka, non si ottengono flussi di dati, ma flussi di avvisi in Telegram.## Archivio compatibile con S3? Ottimo. Ora proteggetelo
L’equipe di Ozon ha impiegato mesi per riprogettare Lusca su un archivio compatibile con S3 — non perché S3 sia complesso, ma perché implementare una forte coerenza sopra un sistema basato su eventi, gestire i processi in background del database e ripristinare terabyte di dati sono compiti che richiedono una profonda competenza e tempo.
Peggio ancora: se lo deployerete all’interno di contenitori senza una buona pratica DevSecOps — senza scansione delle immagini, senza un sistema di gestione dei segreti, senza politiche di rete L7 — non creerete un archivio. Creerete un vettore di vulnerabilità e un \u003cdel\u003edebito tecnico\u003c/del\u003e.Incendio.
Shardizzazione del database: punto di non ritorno
Shardiamo solo dopo aver esaurito il vertical scaling, l’ottimizzazione delle query, i livelli di caching e le repliche per la lettura. È l’ultimo rimedio.
Facciamolo male – otterremo “hot shard”, ritardi nella replicazione e errori nelle query tra i shard. Soprattutto se la chiave di shard è scelta in modo errato. Facciamolo senza strumenti DevOps per il backup, il monitoraggio e il ri-distribuzione – scambiamo la scalabilità per la resilienza.
La cosa è che non potremo “de-shardizzare”. Una volta implementato questo sistema, non potremo scendere da esso senza un’enorme sofferenza.
E ora il vero problema: non tecnico, ma organizzativo
Nessun benchmark dirà che il punto più stretto nell’attuale DevOps non sono le risorse mentali, la memoria o la velocità di esecuzione delle operazioni. Perché questo è – la latenza nella presa di decisioni causata dai problemi con la roadmap.In alcune aziende non esiste un roadmap DevOps. In altre, semplicemente non esiste affatto. Perché la strategia viene affidata alle vendite demo delle soluzioni a “collo di bottiglia”.
A cosa porta la cultura dell’esecuzione reattiva?
- Dopo che il CTO firma l’ordine di sviluppo, gli ingegneri non ricevono specifiche, ma un “Automatizzate questo su 100 server” - senza documentazione, senza architettura chiara, senza copertura di test.
- E dopo tre mesi: “Perché è così lento? E perché abbiamo costruito questo affatto?”
Questo non è leadership. È fuga dalla responsabilità.
Le squadre DevOps nelle organizzazioni reattive bruciano la buona volontà, inseguendo fantasmi nei log e nei grafici, correggendo ciò che non hanno mai progettato e difendendo ciò che non hanno mai posseduto.Quando qualcosa si rompe? La colpa ricade sulle persone, non sui processi. Non è DevOps, è una squadra di “visionari” chiamata YasnoOps. Una matura cultura DevOps non chiede chi ha sbagliato. Chiede cosa ha causato il guasto e corregge il sistema, non cerca il colpevole. Nel vostro caso, il sistema è l’assenza di una roadmap e l’assenza di coinvolgimento del DevOps nel momento della decisione.
Contesto russo: velocità contro stabilità
Nel 2023-2024, il mercato SaaS in Russia è cresciuto fino a diversi trilioni di rubli, ma non si tratta di un mercato stabile e prevedibile, bensì di una “cottura rapida”. La corsa per apparire moderni distrugge le fondamenta necessarie per essere veramente moderni.Dovremmo muoverci nella direzione indicata da GOSTeh: logistica uniforme, API certificati, monitoraggio, conformità ai requisiti della FSIT e integrità della supply chain. Ma come integrare gli standard nell’architettura costruita con urgenza e decisioni impulsivi? Come garantire la sicurezza se le squadre DevOps non sono state coinvolte nel progetto?
Questa azienda continua a considerare l’infrastruttura come un problema secondario. Non è un fallimento dell’ingegneria. È un fallimento nella gestione delle aspettative.
Come cambiare la situazione?
La soluzione sta nel cambiare prospettiva:
- Da “Costruiamo questo ora per la vendita” → “Siamo pronti a possedere questo nel breve periodo?”
- Da velocità nell’implementazione delle funzionalità → alla resilienza della piattaforma
- Da DevOps come squadra di emergenza → a DevOps come co‑architettoLe grandi aziende hanno già percorso questo percorso. Pubblicano le loro roadmap, rimandano i rilasci per garantire stabilità, misurano la readiness operativa, e non solo le date di rilascio.
Capiscono una semplice verità: la velocità senza controllo non è flessibilità, ma deriva. E questa deriva è particolarmente inaccettabile nel software aziendale, dove sono in gioco segreti di stato.
Per uscire dalla crisi serve una transizione
- Dall’amministrazione reattiva al pianificazione proattiva – sviluppare una roadmap DevOps, coinvolgere tutte le parti interessate fin dalle fasi iniziali.
- Dai semplici esecutori ai partner strategici – riconoscere DevOps come parte integrante dello sviluppo dei prodotti.
- Dagli inserimenti caotici a una trasformazione pianificata – implementare le tecnologie in modo graduale, con pilotaggi e iterazioni per identificare le lacune.
- E allora il pulsante “Acquista” non sarà più premuto automaticamente
Poiché, nelle attuali realtà, soprattutto in condizioni di Gostech, ignorare la maturità operativa non è solo un rischio, ma un’errore strategico.