Le operazioni Fliclic attraversano stati e fasi differenti. Sapere che cosa stavi facendo, quando è avvenuto e quale messaggio hai visto è più utile di una descrizione generica come “non funziona”.
Prima di inviare la segnalazione, non ripetere azioni distruttive e non modificare database o file per “sbloccare” uno stato in esecuzione o in errore. Un processo principale può essere terminato mentre un'attività figlia continua, oppure un workflow può avere già modificato alcune risorse.
Non viene dichiarato alcuno SLA finché questi punti non sono approvati e pubblicati.
Indica, se disponibili:
Per un problema di compatibilità applicativa, aggiungi versione PHP, CMS e versione del componente interessato, se note. Non inviare l'intero file di configurazione.
Non inserire nella segnalazione:
Se un dato sensibile è indispensabile, il supporto dovrà indicare un canale e una procedura protetti. Non anticiparlo tramite email o form generico.
Per un backup, specifica modalità HOT o STOP, momento di avvio e stato mostrato. Non eliminare directory o residui manualmente: un'area di lavoro incompleta può essere utile alla diagnosi.
Per un restore, indica il backup selezionato con il suo identificativo non sensibile, la fase o lo step visibile e se l'ambiente risponde ancora. Non avviare un secondo restore e non cambiare lo stato dal database. Un errore prima del preflight ha conseguenze differenti da un errore dopo la ricostruzione.
Se non riesci ad accedere:
Se ritieni di aver individuato un problema di sicurezza, evita test distruttivi, accesso a dati di altri utenti o pubblicazione di dettagli sfruttabili.
Conserva l'identificativo della segnalazione, se il sistema ne fornisce uno. Evita di duplicare la stessa richiesta su più canali finché non sono definite regole di escalation.
Il team potrà chiedere informazioni aggiuntive o verificare stato e log tecnici. Non è garantito che un errore possa essere risolto senza intervento sull'ambiente, soprattutto dopo operazioni distruttive o crash.
