Utente:Valerio Bozzolan/Sandbox delibera post-incidente BBB: differenze tra le versioni

Da Wikimedia Italia.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
(Aggiungo che secondo me aiuta molto lo staff avere una procedura così semplice da seguire. Perché non è che sanno necessariamente queste cose e la delibera le chiarisce e ne sottolinea l'importanza)
Riga 17: Riga 17:
*l'importanza per Wikimedia Italia di garantire la stabilità della sua [[infrastruttura]], con attenzione a processi trasparenti e aperti alla collaborazione;
*l'importanza per Wikimedia Italia di garantire la stabilità della sua [[infrastruttura]], con attenzione a processi trasparenti e aperti alla collaborazione;
*i rischi durante le migrazioni e dismissioni di [[siti]], [[server]] o [[fornitori]], e la necessità di mitigare ed evitare questi rischi, imparando dall'esperienza della migrazione di BigBlueButton di giugno 2025 [https://mailman.wikimedia.it/private/associazione/2025-June/085901.html];
*i rischi durante le migrazioni e dismissioni di [[siti]], [[server]] o [[fornitori]], e la necessità di mitigare ed evitare questi rischi, imparando dall'esperienza della migrazione di BigBlueButton di giugno 2025 [https://mailman.wikimedia.it/private/associazione/2025-June/085901.html];
*l'impegno già manifestato da parte del consiglio direttivo nel comunicare maggiormente le future migrazioni in carico allo staff o fornitori, [https://mailman.wikimedia.it/private/associazione/2025-June/085913.html].
*l'impegno già manifestato da parte del consiglio direttivo nel comunicare maggiormente le future migrazioni in carico allo staff o fornitori, [https://mailman.wikimedia.it/private/associazione/2025-June/085913.html];
*la mancanza all'interno dell'associazione di competenze tecniche distribuite e la necessità di avere processi semplici per anticipare rischi e gestire eventuali incidenti.


;Consultati
;Consultati

Versione delle 16:58, 16 mar 2026

Questa pagina è una bozza.

Delibera proposta... prego 😺

Gente notificata:

Delibera comunicazione prossime migrazioni

Visti
  • il principio di trasparenza enunciato nello statuto di Wikimedia Italia (art. 1.3);
  • il valore dell'infrastruttura tecnologica di Wikimedia Italia, che sostiene il funzionamento dell'associazione, le iniziative dei volontari, la produzione e disseminazione di contenuti liberi ed è parte integrante delle attività di Wikimedia Italia a sostegno della conoscenza libera;
  • le linee guida di sviluppo software, già comunicate in più occasioni ai fornitori, che sottolineano l'importanza delle comunicazioni;
  • le best practices internazionali di trasparenza nei post-incidenti (come segnalato dal socio Valepert, [1][2] e in linea con quanto effettuato da Wikimedia Foundation da diversi annim:wikitech:Incident review ritual).
Considerati
  • l'importanza per Wikimedia Italia di garantire la stabilità della sua infrastruttura, con attenzione a processi trasparenti e aperti alla collaborazione;
  • i rischi durante le migrazioni e dismissioni di siti, server o fornitori, e la necessità di mitigare ed evitare questi rischi, imparando dall'esperienza della migrazione di BigBlueButton di giugno 2025 [3];
  • l'impegno già manifestato da parte del consiglio direttivo nel comunicare maggiormente le future migrazioni in carico allo staff o fornitori, [4];
  • la mancanza all'interno dell'associazione di competenze tecniche distribuite e la necessità di avere processi semplici per anticipare rischi e gestire eventuali incidenti.
Consultati
  • i soci e volontari precedentemente attivi nella commissione tecnica.
Il direttivo delibera di
  • assicurare che per ogni migrazione o dismissione di siti, server o fornitori sia seguita una procedura puntuale che garantisca:
    • la pubblicazione di due annunci almeno almeno 10 giorni prima della migrazione o dismissione. Il breve annuncio tecnico va pubblicato su Wikimedia Phabricator phabricator:tag/wmit-infrastructure/ e deve includere: referente staff, referente tecnico, data migrazione proposta, durata disservizio prevista, test plan (Esempio minimo: «controlleremo alcuni contenuti a campione, di cui almeno 5 molto vecchi e 5 molto recenti»); il breve l'annuncio non-tecnico va pubblicato in lista soci o altro strumento già esistente e funzionante che permetta di raggiungere le utenze attive (esempio minimo: «Gentili soci, in data XXX dalle ore XXX alle ore XXX potranno verificarsi disservizi su XXX per un'attività di manutenzione straordinaria. La discussione tecnica prosegue in: <link phabricator>»)
    • il mantenimento del fornitore precedente / server precedente / backup precedenti per almeno 60 giorni successivi alla migrazione o alla dismissione, al fine di facilitare la disaster recovery (questa attenzione è vitale per fornitori/server in uso da più di due anni).
    • in caso di incidenti che causino perdita di dati o disservizi non previsti, la pubblicazione di un report post-incidente che includa cause, cosa è andato bene, cosa poter fare per il futuro.
    • nel caso di emergenze non pianificabili, la pubblicazione immediata dei due annunci tecnico e non tecnico.
  • incaricare lo staff per le attività necessarie e il direttore esecutivo per la responsabilità del processo.