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

Da Wikimedia Italia.
Jump to navigation Jump to search
Riga 8: Riga 8:
  
 
== Delibera comunicazione prossime migrazioni ==
 
== Delibera comunicazione prossime migrazioni ==
 +
;Visti
 +
*il principio di trasparenza enunciato nello [[Statuto#Articolo 1 - Costituzione e sede|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, [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
+
;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].
  
Vista la possibilità per WMIT di migliorare la stabilità, trasparenza e collaborazione della sua [[infrastruttura]] con una delibera a costo zero,
+
;Consultati
 +
*i soci e volontari precedentemente attivi nella commissione tecnica.
  
Vista la possibilità di imparare dall'esperienza del trascorso incidente BigBlueButton di giugno 2025, evitabile grazie ad una maggiore comunicazione,[https://mailman.wikimedia.it/private/associazione/2025-June/085901.html]
+
;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.
  
Visto che l'incremento della comunicazione è anche in linea con le nostre linee guida di [[sviluppo software]],
+
*incaricare lo staff per le attività necessarie e il direttore esecutivo per la responsabilità del processo.
  
Vista la presenza di diversi saggi sui vantaggi del coltivare uno spirito 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 il già annunciato 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]
 
 
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
 
 
;Punto 1 - pubblicare breve comunicazione
 
 
Per chi ha l'incarico di seguire una migrazione o dismissione di [[siti]], [[server]] o [[fornitori]],
 
 
si richiede, almeno 10 giorni prima, di prevedere almeno 20 minuti del proprio incarico per:
 
 
# pubblicare un breve annuncio tecnico
 
## dove: Wikimedia Phabricator [[phabricator:tag/wmit-infrastructure/]]
 
## cosa specificare:
 
### referente staff
 
### referente tecnico
 
### data migrazione proposta
 
### durata disservizio prevista
 
### test plan<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>»
 
 
; Punto 2 - post-migrazione
 
 
In caso sia applicabile:
 
 
Si richiede di mantenere il fornitore precedente / server precedente / backup precedenti per almeno '''60 giorni successivi alla migrazione''', al fine di facilitare ''disaster recovery''. Soprattutto per fornitori/server in uso da più di due anni.
 
 
; Punto 3 - post-incidenti
 
 
In caso di incidenti che causino perdita di dati o disservizi non previsti:
 
 
Segue l'impegno nella pubblicazione di un report post-incidente, con almeno:
 
 
# cause
 
# cosa è andato bene
 
# cosa poter fare per il futuro
 
 
; Eccezioni
 
 
In caso di emergenze non-pianificabili, quindi nell'impossibilità di fornire preavvisi tot. giorni prima: si procede pubblicando semplicemente le comunicazioni immediatamente.
 
 
;Favorevoli / contrari / astenuti
 
 
...
 
  
  
  
 
----------------
 
----------------

Versione delle 17:55, 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].
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.