Qualche giorno fa leggendo l’intervista del vice-CTO di Facebook a proposito dei problemi tecnici che si trova ad affrontare un sito internet con una crescita esplosiva, soprattutto quando il suo lavoro principale è quello di mettere in relazione per ogni singolo utente dati da decine/centinaia di “feed” diversi – cosa che comporta delle sfide peculiari rispetto ai problemi di scalabilità di un sito che fornisce contenuto ‘statico’ – riflettevo su come, nella realtà dei fatti, anche problemi più semplici non siano sempre studiati a sufficienza.
In generale quando la base di dati su cui lavora un sito internet è (a differenza del caso FB) controllata e “stabile”, l’unico problema nello “scalare” il sistema su un grande numero di utilizzatori è quello della capacità: in sostanza la soluzione al problema è “limitarsi” a predisporre un numero di “tubi” e di “macchine” sufficienti per garantire a tutti l’accesso alle informazioni: anche una cosa così semplice pero’ non si riesce sempre a mettere in pratica.
Si pensi al caso del sito dell’azienda trasporti milanese che – in occasione dello sciopero di oggi – è stato preso d’assalto dai visitatori tra stasera e stamattina, cedendo prevedibilmente sotto la mole delle visite per diverse ore (fonte: CorSera).
Quello dell’ATM è un sito di concezione moderna che offre un servizio utile nella misura in cui garantisce un accesso facile a tutte le linee di trasporto con possibilità di controllare i tempi di attesa di ogni linea, fermata per fermata, ed è fatto abbastanza bene rispetto ai patetici standard italiani. Permette inoltre di ricevere alert in tempo quasi reale via email su ogni linea interessata da interruzioni e deviazioni di percorso. L’unico vero grande difetto che ci vedo al momento è la mancanza di una versione adeguata per il telefonino, attraverso la quale sia possibile conoscere percorsi delle linee e tempi d’attesa alle fermate
Eppure anche un sito apparentemente ben congegnato è risultato vittima di un semplice errore di mancata pianificazione come questo, facendo venire a mancare le sue informazioni di pubblica utilità proprio quando agli abbonati sarebbero state più utili: durante uno sciopero.
E’ facile “giustificare” questa mancanza: sopratutto in una situazione di vita reale, con risorse economiche limitate, non è possibile dimensionare una infrastruttura per un picco di capacità che si verificherà in media solo una volta l’anno [alcuni la pensano diversamente a proposito del passante di Mestre].
Pur conscio di questo penso che, come una diga ha degli “sfoghi” che puo’ aprire prima di tracimare, così un sito importante e di pubblica utilità dovrebbe avere un piano B sempre pronto, in caso di raggiungimento della massima capacità.
Una maniera abbastanza semplice ed economica di risolvere questo genere di problemi è ad esempio il predisporre un sito ridotto all’osso, di solo testo, con le informazioni che interessano di più l’utenza in quel momento. Una semplice pagina di testo da 3kb avrebbe occupato molto meno del solo logo dell’azienda in testa al sito “tradizionale” e avrebbe decuplicato la capacità delle macchine disponibili nel reggere l’onda d’urto.
Sarebbe bastata – per ipotesi – una pagina con gli ultimi due comunicati stampa e, più in basso, una tabella dei tempi medi di attesa alle fermate di ogni linea urbana, rilevati nell’ultima mezz’ora: qualcosa realizzabile facilmente, fruibile immediatamente sia dai computer che dai telefoni e utile allo scopo.
Questo post lo metto ovviamente nella categoria dei consigli non richiesti sperando che qualcuno la prossima volta ci possa pensare.
Hunch è un “decision engine”, un motore di ricerca che aiuta le persone a prendere decisioni: una startup valutata più di 50 milioni di dollari. Leggevo che ha appena ricevuto altri 12 milioni di funding dal fondo di venture capital Khosla, per un totale di 19.2M$ di capitale di terzi che credono nell’idea.