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:
  
 
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]
 
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]
 +
 +
Visto che l'incremento della comunicazione è anche in linea con le nostre linee guida di [[sviluppo software]],
 +
 +
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 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 l'incremento della comunicazione è anche in linea con le linee guida di [[sviluppo software]],
 
  
 
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,
 
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
 
; Si decide
 +
 +
:;Punto 1
  
 
Per chi ha l'incarico di seguire una migrazione o dismissione di [[siti]], [[server]] o [[fornitori]],
 
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:
+
si richiede, almeno 10 giorni prima, di prevedere almeno 20 minuti del proprio incarico per:
  
# pubblicazione di un breve annuncio tecnico
+
# pubblicare un breve annuncio tecnico
 
## dove: Wikimedia Phabricator [[phabricator:tag/wmit-infrastructure/]]
 
## dove: Wikimedia Phabricator [[phabricator:tag/wmit-infrastructure/]]
 
## cosa specificare:
 
## cosa specificare:
 
### referente staff
 
### referente staff
 
### referente tecnico
 
### referente tecnico
 +
### data migrazione proposta
 
### durata disservizio prevista
 
### durata disservizio prevista
### data migrazione proposta
+
### test plan<br />Esempio minimo: «controlleremo alcuni contenuti a campione, di cui almeno 5 molto vecchi e 5 molto recenti»)
### 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
 
# pubblicare un breve annuncio non-tecnico
 
## dove: lista soci - o altro strumento già esistente e funzionante che permetta di raggiungere le utenze attive
 
## 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>»
 
## 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).
+
:; Punto 2:
 +
 
 +
In aggiunta, in caso di migrazione di fornitori o server o avanzamento di versione di software:
 +
 
 +
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:
 +
 
 +
In aggiunta, in caso di incidenti durante queste attività pianificate:
 +
 
 +
Le persone coinvolte in un incidente si impegnano a collaborare alla pubblicazione di un report post-incidente e che includa almeno:
 +
 
 +
# cause
 +
# cosa è andato bene
 +
# cosa poter fare per il futuro
 +
 
 +
:; Eccezioni
 +
 
 +
I preavvisi naturalmente non valgono per situazioni non pianificabili, per esempio per incidenti straordinari (e.g. incendi.)
  
Favorevoli / contrari / astenuti
+
;Favorevoli / contrari / astenuti
  
 
...
 
...

Versione delle 16:36, 15 mar 2026

Delibera proposta... prego 😺

Delibera comunicazione prossime migrazioni

Visto che

Vista la possibilità per WMIT di migliorare la stabilità, trasparenza e collaborazione della sua infrastruttura con una delibera a costo zero,

Vista la possibilità di imparare dall'esperienza del trascorso incidente BigBlueButton di giugno 2025, evitabile grazie ad una maggiore comunicazione,[1]

Visto che l'incremento della comunicazione è anche in linea con le nostre linee guida di sviluppo software,

Vista la presenza di diversi saggi sui vantaggi del coltivare uno spirito di trasparenza nei post-incidenti, come segnalato dal socio Valepert, [2][3] 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, [4]

Visto che nelle ultime due assemblee era emersa la richiesta di impegnarsi maggiormente nel consultare le commissioni (maggio 2025 · nov 2025). Tuttavia, visto che ogni commissione consultiva è stata poi sciolta, inclusa la commissione tecnica, come da delibera gruppi di lavoro e che quindi è necessario trovare soluzioni fattibili con l'assetto attuale,

Si decide
Punto 1

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:

  1. pubblicare un breve annuncio tecnico
    1. dove: Wikimedia Phabricator phabricator:tag/wmit-infrastructure/
    2. cosa specificare:
      1. referente staff
      2. referente tecnico
      3. data migrazione proposta
      4. durata disservizio prevista
      5. test plan
        Esempio minimo: «controlleremo alcuni contenuti a campione, di cui almeno 5 molto vecchi e 5 molto recenti»)
  2. pubblicare un breve annuncio non-tecnico
    1. dove: lista soci - o altro strumento già esistente e funzionante che permetta di raggiungere le utenze attive
    2. 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>»
Punto 2

In aggiunta, in caso di migrazione di fornitori o server o avanzamento di versione di software:

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

In aggiunta, in caso di incidenti durante queste attività pianificate:

Le persone coinvolte in un incidente si impegnano a collaborare alla pubblicazione di un report post-incidente e che includa almeno:

  1. cause
  2. cosa è andato bene
  3. cosa poter fare per il futuro
Eccezioni

I preavvisi naturalmente non valgono per situazioni non pianificabili, per esempio per incidenti straordinari (e.g. incendi.)

Favorevoli / contrari / astenuti

...