Il caso
In Raddoppiare le risorse non è una strategia a lungo termine ho raccontato un'istanza EC2 con decine di container che, un mercoledì qualunque, si blocca.
La risposta d'emergenza: CPU e RAM raddoppiate. Settimane dopo l'istanza era ancora lì, il doppio più grande, la fattura pure, e nessuno che ne cercasse la causa. Non era la CPU e non era la RAM: erano gli IOPS di un disco gp2 con i crediti di burst esauriti. Nessun monitoraggio, nessun allarme.
La domanda, anche qui: "Se quel server fosse stato dentro il perimetro di un sistema di gestione della sicurezza delle informazioni, cosa avrebbe trovato un auditor?"
La richiesta
La ISO/IEC 27001:2022 elenca nell'Annex A il controllo 8.6 (gestione della capacità): l'uso delle risorse va monitorato e adeguato in funzione dei requisiti di capacità attuali e previsti.
Perché sta in uno standard di sicurezza? Perché la sicurezza delle informazioni, per la ISO 27001, protegge tre proprietà: riservatezza, integrità e disponibilità. Un servizio che non risponde perché il disco non regge il carico è un problema di disponibilità.
In pratica: devi sapere quanto stai usando delle tue risorse, quale finirà per prima, e adeguarle prima che succeda.
Adeguato, ma alla cieca
Gestire la capacità significa monitorare le risorse e adeguarle in base a ciò che emerge; il server era stato potenziato, ma senza dati che indicassero dove fosse il limite.
L'intervento era una scommessa, ed era stata persa: si era aggiunta la risorsa sbagliata.
Su un disco gp2 la metrica BurstBalance in calo costante racconta settimane prima che i crediti stanno per finire fornendo il segnale necessario. È esattamente il "previsto" del controllo: non solo quanto usi oggi, ma quanto userai domani.
Se quel server fosse rientrato nel perimetro del sistema di gestione, sarebbe stato difficile dimostrare l'effettiva applicazione del controllo 8.6: le risorse erano state aumentate senza dati che giustificassero la scelta, e nessuno avrebbe saputo dire quale sarebbe stata la prossima risorsa a esaurirsi.
Una nota onesta: alla ISO 27001 la fattura non interessa. Pagare il doppio non è un rilievo, il servizio giù senza alcun preavviso sì.
È lo stesso problema che ritrovo dai clienti: log che riempiono il disco di notte, connection pool esaurito al primo picco, quote API raggiunte il giorno del lancio.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "Il server è dimensionato correttamente" | Le metriche di utilizzo degli ultimi mesi, per CPU, memoria, disco e I/O |
| "Ci accorgiamo se qualcosa si satura" | Gli allarmi configurati, con soglie e destinatari, e l'ultimo che è scattato |
| "Abbiamo risolto il problema di performance" | La causa individuata, la modifica fatta e il confronto delle metriche prima e dopo |
| "Sappiamo quando dovremo crescere" | Una stima scritta della crescita prevista, con la data dell'ultima revisione |
| "Le risorse aggiunte in emergenza sono temporanee" | La data in cui sono state rivalutate, e l'esito |
A sinistra c'è quello che si scrive nelle policy, a destra c'è quello che un auditor ti chiede di mostrargli.
Da dove partirei
- Per ogni sistema critico, la risorsa che finisce per prima. CPU, memoria, disco, IOPS, connessioni? Se nessuno lo sa, abbiamo il primo problema da risolvere.
- Un allarme per ogni risorsa che può finire, con la soglia prima del limite. Su un disco gp2 è
BurstBalance. Per la memoria su EC2 serve il CloudWatch Agent, perché non è una metrica nativa. - Una data di revisione per ogni intervento d'emergenza. Hai aggiunto risorse sotto pressione? Annoti cosa, perché, e quando verificherai se servono ancora.
Per correggere questa lacuna non devi comprare una piattaforma di osservabilità. Parti da poche metriche sulle risorse che possono esaurirsi e da una regola: niente si adegua senza dati che giustifichino la scelta.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
Raddoppiare le risorse non è una strategia a lungo termine→
In sintesi (TL;DR)
- Il controllo A.8.6 della ISO 27001 chiede di monitorare l'uso delle risorse e di adeguarle ai requisiti di capacità attuali e previsti.
- Raddoppiare CPU e RAM dopo un'emergenza è un adeguamento, ma senza monitoraggio è una scommessa: la risorsa esaurita era un'altra.
- La disponibilità è una delle tre proprietà che la sicurezza delle informazioni protegge: un servizio giù per un disco saturo è anche un tema di sicurezza.
- Per partire: sapere quale risorsa finisce per prima, un allarme prima del limite e una data di revisione per ogni intervento d'emergenza.