Differenze tra le versioni di "Utente:Valerio Bozzolan/Sandbox delibera post-incidente BBB"

Da Wikimedia Italia.
Jump to navigation Jump to search
 
(21 versioni intermedie di 2 utenti non mostrate)
Riga 1: Riga 1:
Delibera proposta... prego 😺
+
{{Bozza}}
  
== Delibera comunicazione prossime migrazioni ==
+
Delibera proposta 😺
  
;Visto che
+
Gente notificata:
 +
* 2026-03-15 mailing list tech https://mailman.wikimedia.it/private/tech/2026-March/001629.html
 +
* 2026-03-18 Mattia Nappi in privato - (lasciare tempo per leggere / commentare)
 +
* TODO: 2026-03-25? girare a direttivo
  
Vista la possibilità per WMIT di migliorare la stabilità, trasparenza e collaborazione della sua [[infrastruttura]] con una delibera a costo zero,
+
== Delibera comunicazione prossime migrazioni ==
 
+
;Visti
Visto soprattutto l'interesse di scongiurare ulteriori perdite di dati anche grazie all'esperienza del trascorso incidente BigBlueButton di giugno 2025, causato dallo scioglimento del fornitore Ergonet senza sufficiente preavviso alle utenze,[https://mailman.wikimedia.it/private/associazione/2025-June/085901.html]
+
*i contenuti e la struttura di Wikimedia Italia ispirati al principio di trasparenza ([[Statuto#Articolo 1 - Costituzione e sede|statuto 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;
Visto l'interesse del consiglio direttivo di comunicare maggiormente le future migrazioni in carico allo staff o fornitori, [https://mailman.wikimedia.it/private/associazione/2025-June/085913.html]
+
*le linee guida di [[sviluppo software]], già comunicate in più occasioni ai fornitori, che sottolineano l'importanza delle comunicazioni;
 
+
* le buone pratiche internazionali di trasparenza nei post-incidenti (come segnalato dal socio Valepert, [https://postmortems.pagerduty.com/culture/introduce/][https://www.etsy.com/codeascraft/blameless-postmortems] e in linea con quanto effettuato da Wikimedia Foundation da diversi anni [[m:wikitech:Incident review ritual]]).
Visto che la comunicazione è anche in linea con le linee guida di [[sviluppo software]] (in particolare la sezione "Comunicazione"),
 
 
 
Visto che nelle ultime due assemblee era emersa la richiesta di impegnarsi maggiormente nel consultare le commissioni ([[Associazione:Assemblea_WMI_maggio_2025/Verbale|maggio 2025]] · [[Associazione:Assemblea_WMI_novembre_2025/Verbale|nov 2025]]). Tuttavia, visto che ogni commissione consultiva è stata poi sciolta, inclusa la [[commissione tecnica]], come da [[Associazione:Delibere/2025/Istituzione dei gruppi di lavoro|delibera gruppi di lavoro]] e che quindi è necessario trovare soluzioni fattibili con l'assetto attuale,
 
 
 
; Si decide
 
 
 
Per chi ha l'incarico di seguire una migrazione o dismissione di [[siti]], [[server]] o [[fornitori]],
 
  
si richiede, almeno 10 giorni prima, di investire almeno 20 minuti in:
+
;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 [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];
 +
*la mancanza attuale di una [[commissione tecnica]] (chiusa dopo la [[Associazione:Delibere/2025/Istituzione dei gruppi di lavoro|delibera gruppi di lavoro]] di novembre 2025), che in precedenza poteva intervenire in caso di migrazioni e dismissioni (se contattata 7 giorni prima come da [[Commissioni#Che tipo di impegno comporta|regolamento commissioni]]) e in caso di incidenti (se notificati); questo ruolo attualmente non è garantito da nessun altro gruppo o individuo all'interno di Wikimedia Italia;
 +
*la mancanza all'interno dell'associazione di competenze tecniche distribuite e la necessità di avere processi semplici e condivisi, per anticipare rischi e gestire eventuali incidenti.
  
# pubblicazione di un breve annuncio tecnico
+
;Consultati
## dove: Wikimedia Phabricator [[phabricator:tag/wmit-infrastructure/]]
+
*i soci e volontari precedentemente attivi nella commissione tecnica.
## cosa specificare:
 
### referente staff
 
### referente tecnico
 
### durata disservizio prevista
 
### data migrazione proposta
 
### test plan proposto<br />Esempio minimo: «controlleremo alcuni contenuti a campione, di cui almeno 5 molto vecchi e 5 molto recenti»)
 
# pubblicare un breve annuncio non-tecnico
 
## dove: lista soci - o altro strumento già esistente e funzionante che permetta di raggiungere le utenze attive
 
## esempio minimo:<br />«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>»
 
# in particolare, per migrazioni: si richiede di mantenere il fornitore precedente per almeno 60 giorni successivi alla migrazione, al fine di facilitare ''disaster recovery''
 
  
Salvo ovviamente incidenti straordinari non pianificabili (e.g. come scorso incendio OVH).
+
;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 brevi annunci (uno tecnico e uno non-tecnico) 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 ''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;
  
Favorevoli / contrari / astenuti
+
*incaricare lo staff per le attività necessarie e il direttore esecutivo per la responsabilità del processo.
  
...
 
  
  
  
 
----------------
 
----------------

Versione attuale delle 11:03, 18 mar 2026

Questa pagina è una bozza.

Delibera proposta 😺

Gente notificata:

Delibera comunicazione prossime migrazioni

Visti
  • i contenuti e la struttura di Wikimedia Italia ispirati al principio di trasparenza (statuto 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 buone pratiche internazionali di trasparenza nei post-incidenti (come segnalato dal socio Valepert, [1][2] e in linea con quanto effettuato da Wikimedia Foundation da diversi anni m: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 attuale di una commissione tecnica (chiusa dopo la delibera gruppi di lavoro di novembre 2025), che in precedenza poteva intervenire in caso di migrazioni e dismissioni (se contattata 7 giorni prima come da regolamento commissioni) e in caso di incidenti (se notificati); questo ruolo attualmente non è garantito da nessun altro gruppo o individuo all'interno di Wikimedia Italia;
  • la mancanza all'interno dell'associazione di competenze tecniche distribuite e la necessità di avere processi semplici e condivisi, 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 brevi annunci (uno tecnico e uno non-tecnico) 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 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.