In qualità di proprietario di Simple Analytics, ritengo che sia estremamente importante creare fiducia negli utenti. È quasi impossibile non commettere errori, quindi se un'azienda non condivide mai i propri errori, probabilmente non vi sta dicendo la verità. Ecco quindi i miei.
Ogni volta che costruite una nuova funzionalità, probabilmente volete distribuirla il più velocemente possibile perché siete troppo entusiasti di mostrarla ai vostri clienti. Oppure a volte state aggiungendo un nuovo servizio al vostro server e non sapete che tipo di implicazioni potrebbe avere. Quest'ultimo caso è capitato a me.
Nelle ultime due settimane ho implementato una nuova funzione chiamata Dominio personalizzato. Questa funzione ha permesso agli utenti di Simple Analytics di aggirare gli ad-blocker e i tracking blocker. Ritengo che le persone debbano avere la possibilità di bloccare il tracciamento, quindi Simple Analytics rispetta l'impostazione "Do Not Track" del browser. Sfortunatamente, Simple Analytics è stato aggiunto ad alcuni elenchi di blocco della privacy, cosa che ritengo ingiusta dal momento che prendiamo molto sul serio la privacy (abbiamo spostato i server in un paese molto rispettoso della privacy: Islanda; abbiamo criptato il nostro server di database; rimuoviamo i dati dal database quando un utente cancella qualcosa; permettiamo alle persone di scaricare i loro dati). La nuova funzione è stata quindi accolta con grande favore. Una volta distribuita, alcuni utenti hanno iniziato a usarla.
Oggi ho riscontrato un bug (fortunatamente da solo) durante l'utilizzo della funzione Dominio personalizzato: il JavaScript veniva caricato, ma la chiamata API richiedeva una password. Ho consultato il sito di uno dei miei clienti ([excuseme.wtf](https://excuseme.wtf/?ref={{ site.hostname }}) che so che utilizzava la funzione Dominio personalizzato. Ho controllato le sue statistiche e ho scoperto con orrore che non c'erano visite nell'ultima settimana. Immediatamente ho iniziato a scavare nei miei server, alla ricerca di indizi.
Configurazione attuale
Simple Analytics utilizza 4 server per far funzionare tutto al meglio. Abbiamo il Queue-server, che è il server per la raccolta delle visite dai nostri JavaScript. Si tratta di un server diverso dal server principale perché quest'ultimo è criptato. Se un server è crittografato, deve avviarsi solo dopo aver inserito una password (altrimenti la crittografia è inutile). Nel caso improbabile in cui sia necessario un riavvio, voglio garantire l'assenza di perdita di dati. Tutti i dati saranno inviati al Queue-server che li invierà al Main-server. Se il server principale non accetta la richiesta, il server Queue la "mette in coda" (salva) quando il server principale esegue il backup.
A questi server si aggiungono un Testing-server e un External-server. Il Testing-server esegue test di accettazione per monitorare flussi ed endpoint importanti. Il server esterno è necessario per la funzione Dominio personalizzato. Per motivi di sicurezza, non voglio che i certificati SSL dei clienti si trovino sullo stesso server del server principale.
Cosa è andato storto?
Ho deciso di installare una nuova applicazione di monitoraggio sul Queue-server, in modo da poter controllare da remoto se ci fossero problemi nel server. Inoltre, mi dava informazioni sull'uso della CPU e della memoria. Ho aggiunto un file di configurazione NGINX per questa applicazione, in modo da potervi accedere dall'esterno. Quando aggiungo una nuova applicazione, verifico sempre la configurazione di NGINX e la ricarico quando ha successo sudo nginx -t && sudo nginx -s reload. NGINX non ha dato alcun errore e quindi ho potuto accedere alla mia applicazione di monitoraggio appena installata; sono contento.
Fortunatamente, ho una directory/registri dei log di NGINX, da cui posso recuperare la maggior parte delle richieste perse. All'epoca questi log contenevano meno informazioni e registravano solo l'ora, l'URL e l'agente utente.
Cosa ho fatto per evitare che questo accada di nuovo?
Sebbene questo bug non abbia interessato molti clienti e non abbia comportato una perdita significativa di dati, voglio fare tutto il possibile per evitare che ciò accada in futuro. Il bug è stato creato aggiungendo un'altra applicazione allo stesso server che non aveva alcuna direttiva server definita come server predefinito. NGINX fa quindi del suo meglio per selezionare un server come server predefinito e invia le richieste all'applicazione definita in quel server.
Per prima cosa, ho aggiunto il server predefinito alla direttiva listen per le porte 80 e 443 nell'applicazione principale(nginx docs). L'app principale su quel server era l'app esterna che gestisce i certificati per la funzionalità Dominio personalizzato e risponde con uno script e l'endpoint API non utilizza URL di Simple Analytics, il che rende difficile il blocco.
In secondo luogo, ho aumentato la cronologia dei log a 90 giorni in modo da poter recuperare le visite per problemi futuri. Il Queue-server e il Main-server ora registrano ogni richiesta fallita da parte di chiunque. Ciò significa che ogni richiesta che restituisce un codice HTTP 5xx o 4xx sarà salvata nei registri e potrà essere recuperata. Se necessario, sarà necessario un po' di lavoro per farlo, ma ciò significa che non ci saranno perdite di dati.
Ho aggiunto dei test di accettazione per la funzione Dominio personalizzato che verifica se entrambi gli endpoint funzionano ancora come previsto. Se non sono conformi, ricevo una telefonata e un messaggio Telegram.
Infine, etichetterò le nuove funzionalità come "Versione beta", in modo che i clienti siano consapevoli o si aspettino che ci siano degli errori, poiché non sono state completate per la versione finale. Pertanto, spetta ai clienti cogliere l'occasione e utilizzare la funzione a proprio rischio e pericolo.
Ho contattato i clienti interessati da questo bug e ho offerto loro il rimborso del mese. Non lo hanno ritenuto necessario e hanno detto che non dovevo preoccuparmi. Ho fatto del mio meglio per recuperare la maggior parte dei loro dati e con tutte le azioni di cui sopra sono abbastanza sicuro che questo non accadrà più.
Cambiamo la trasparenza sugli errori e credo che le persone prenderanno più seriamente la vostra azienda. Mostrate cosa avete fatto e quanto siete capaci. Alcuni potrebbero discutere se sia una cosa intelligente, ma io la vedo come un'opportunità per mostrare trasparenza.