In questa pagina
Se gestisci la reperibilità in Opsgenie, hai una data fissa sul calendario e una sola decisione da prendere prima di quella data.
Le indicazioni che seguono sono neutrali rispetto ai fornitori e coprono quattro temi:
- cosa sparisce insieme al prodotto
- cosa inventariare
- l’ordine che ti tiene coperto durante il passaggio
- come dimensionare lo sforzo
Perstat compare alla fine, alla voce consolidamento, non come premessa.
Due date fissano il tuo calendario
Atlassian ha terminato le nuove vendite il 4 giugno 2025 e terminerà il supporto il 5 aprile 2027. I clienti esistenti possono aggiungere posti fino al 5 aprile 2027 e rinnovare solo se il contratto scade prima di quella data, secondo la pagina delle licenze.
La precisazione che governa la tua pianificazione è non migrati. La stessa pagina delle licenze dice che i dati dei clienti non trasferiti in Jira Service Management vengono cancellati entro quella data. La documentazione sullo spegnimento di Atlassian aggiunge che Opsgenie si spegne automaticamente 120 giorni dopo una migrazione, se non lo spegni manualmente. Prima di quella data, esporta tutto ciò che vuoi conservare al di fuori dei percorsi di migrazione offerti.
È una decisione di prodotto di Atlassian, dichiarata apertamente. Non dice nulla sugli strumenti che gli stanno intorno e fissa solo il tuo calendario.
Per i team regolamentati, lo storico degli incident conservato può contribuire ai registri interni e alle segnalazioni. DORA si applica dal 17 gennaio 2025. Né uno storico esportato né lo strumento sostitutivo determinano se DORA si applica o stabiliscono la compliance di un’organizzazione.
Fai l’inventario prima di cercare uno strumento
Dedica un’ora alla console di Opsgenie e annota cosa usi. L’inventario può essere più corto di quanto temevi e può far emergere dipendenze dimenticate. Cinque categorie coprono tutto.
Registra turni e rotazioni
Annota chi è reperibile, quando, e su quali team e fusi orari. Segna anche le sostituzioni e le regole per le festività. Sono i dettagli che si rompono in silenzio dopo un passaggio.
Annota le policy di escalation
Descrivi ogni catena: chi viene allertato, dopo quanto tempo, e cosa succede se nessuno prende in carico. Registra i tempi, non solo l’ordine.
Elenca integrazioni e sorgenti di alert
Elenca ogni sistema che apre un alert:
- strumenti di monitoraggio
- allarmi del cloud provider
- error tracker
- webhook
- flussi di email
Le integrazioni possono richiedere molto lavoro. Ogni sorgente va ripuntata e testata nel nuovo sistema.
Documenta routing e team
Annota come gli alert vengono assegnati a team, tag e priorità. Le regole di routing codificano il sapere dell’organizzazione, e un passaggio frettoloso può farlo perdere.
Esporta storico e report
Questa categoria comprende alert passati, timeline degli incident e report di reperibilità. Decidi cosa devi conservare. Esportalo presto, nel formato che Opsgenie mette a disposizione, prima che termini l’accesso a Opsgenie.
Procedi in un ordine che ti tiene coperto
Non spostare tutto in una volta. Fai girare i due sistemi in parallelo e sposta le sorgenti di alert una alla volta.
- Esporta storico e report adesso, prima che cambi qualsiasi altra cosa.
- Completa l’inventario qui sopra. Poi scegli tra sostituzione puntuale e consolidamento, come descrive la prossima sezione.
- Ricostruisci turni e policy di escalation nel nuovo strumento. All’inizio mantienili identici e migliorali in seguito.
- Ripunta le integrazioni una sorgente alla volta. Verifica che ognuna allerti una persona prima di passare alla successiva.
- Fai girare i due sistemi in parallelo per una rotazione completa di reperibilità. Prima del passaggio, prova con test controllati ogni percorso di alert previsto.
- Fai il passaggio, poi dismetti Opsgenie quando hai esportato tutto quello che ti serve.
Scegli tra sostituzione puntuale e consolidamento
Questa è la decisione vera. Dedicale 30 minuti prima di stilare una rosa di candidati.
Opsgenie fa reperibilità e smistamento degli alert. Puoi sostituirlo con un altro strumento dedicato alla reperibilità e lasciare com’è il resto dello stack. È la strada con meno sorprese, e per alcuni team è quella giusta.
Considera uno stack in cui la reperibilità convive con monitoraggio dell’uptime, pagina di stato e processo per gli incident separati, di fornitori diversi. Se quei fornitori non condividono dati, la migrazione è l’occasione per valutare il consolidamento mentre ricostruisci i turni e ripunti le integrazioni.
Nessuna delle due risposte è giusta a priori. Se le tue sorgenti di alert sono radicate in un solo ecosistema, uno strumento di reperibilità equivalente può preservare il flusso di lavoro. Lo stesso vale se ti appoggi a un’integrazione stretta con Jira Service Management e al ticketing.
Se il problema è la proliferazione degli strumenti, la migrazione è un momento pratico per valutare il consolidamento.
Stima l’impegno partendo dal tuo inventario
Non adottare una durata generica. Conta queste voci, poi assegna a ognuna un responsabile e un test:
- turni e policy di escalation
- sorgenti di alert e integrazioni
- report
- team
- percorsi di formazione
Il tempo complessivo include approvazioni e una fase in parallelo. Il lavoro operativo nasce dall’inventario.
Definisci i criteri di uscita prima di fissare una data:
- Ogni sorgente di alert raggiunge la route prevista.
- Ogni turno ha un responsabile.
- La presa in carico ferma l’escalation.
- Un incident controllato rientra.
- Il vecchio percorso resta disponibile finché questi controlli non sono superati.
Questi criteri rendono la stima verificabile senza fingere che un solo calendario valga per ogni organizzazione.
Tieni una checklist breve
- Esporta per prima cosa storico degli alert, registri degli incident e report di reperibilità.
- Inventaria le cinque categorie qui sopra, poi scegli tra sostituzione puntuale e consolidamento.
- Ricostruisci turni ed escalation identici nel nuovo strumento.
- Ripunta le integrazioni una alla volta e testa ognuna.
- Fai girare i due sistemi in parallelo per una rotazione completa.
- Fai il passaggio, verifica gli export, poi dismetti.
Perstat è un’opzione per il consolidamento
Se il consolidamento è nella tua lista, Perstat è un’opzione da valutare. Riunisce monitoraggio dell’uptime, pagine di stato, gestione degli incident e reperibilità in un solo prodotto. Il suo control plane nell’UE è gestito dalla società tedesca Datargo GmbH.
I concetti di Opsgenie hanno equivalenti familiari:
- Turni e rotazioni di reperibilità iniziano con Sentinel.
- Il push nativo arriva tramite le app Apple.
- Gli SMS personali iniziano con Pulse.
- Sentinel aggiunge l’escalation di reperibilità dal push a SMS e telefonata.
- La presa in carico resta esplicita.
Il monitoraggio che ti allerta sta nello stesso prodotto. Undici tipi di check regionali, tra cui HTTP, TCP e DNS, usano fino a sei regioni in base al piano e una regola regionale configurabile con quorum predefinito di 2. I monitor agent e heartbeat non usano né regioni né quorum.
Un componente collegato della pagina di stato può usare lo stesso registro di monitor e incident. La pubblicazione resta un’azione esplicita.
Perstat mantiene un registro di disponibilità curato. Il report SLA di esempio pubblico è un esempio editoriale, non un report cliente generato. Ogni vista del monitor offre un report PDF per 7, 14, 30 o 90 giorni, non firmato e non certificato, e un CSV con manifest è disponibile manualmente su richiesta.
Perstat non sostituisce Jira Service Management, ticketing, APM o log management. Se per te sono elementi portanti, uno strumento dedicato alla reperibilità è la scelta migliore. Anche questo è un buon esito dell’esercizio.
La pagina di confronto con Opsgenie mappa i concetti uno per uno. I prezzi sono nella pagina dei prezzi, al netto dell’IVA, e puoi iniziare gratis.
Inizia a monitorare gratis o fai il tour del prodotto. Puoi fare il tour senza registrarti e vedere i prezzi senza una telefonata commerciale.