LA DOMANDA
Why does the same outage keep recurring?
Una influisce in modo significativo sull’altra? Decidono i tre quarti dei voti espressi.
chiusa · torna alla fase Azioni
Stai guardando come ospite. Inserisci un nome utente per entrare e partecipare.
Le domande sono distribuite tra i gruppi, quindi ricevi quelle assegnate al tuo gruppo — non tutte e 180.
risolte: 176 / 180 da rispondere: 0 perché
Nessuno potrebbe rispondere a diverse centinaia di coppie. Ogni coppia va a un gruppo; una coppia su cui il gruppo si divide passa poi ad altri gruppi, quindi può comparire più tardi nel tuo elenco anche se è partita altrove. Il numero delle risolte include il lavoro di tutti i gruppi, ed è per questo che sale più in fretta di quanto si accorci il tuo elenco.
Ultimo conteggio: decise: 176 · passate ai panel tra gruppi: 1 · contese: 0 · sotto il quorum: 3 — i panel richiedono almeno max(2, 75% del panel) voti espressi; il tuo panel più piccolo ha 15 membri.
Post-mortem actions are written up and then never scheduled → influisce su? → Customers report outages before monitoring does
Ancora nessun intervento.
Fase conclusa — lo storico delle coppie e dei voti è qui sopra.Verifica la logica ↗
| Reliability has no budget line of its own | → | Feature flags are never cleaned up, so nobody knows which paths are live | aperta | discuti |
| The same three services cause most of the pages | → | … | aperta | discuti |
| The incident channel fills with people asking for status instead of giving it | → | The service map in the wiki is two years old | aperta | discuti |
| The staging environment does not resemble production | → | Rollbacks take longer than the outage they are meant to end | aperta passata oltre | discuti |
| Tests that fail intermittently are retried until green | → | Customers report outages before monitoring does | ✓ sì | discuti |
| Alerts fire so often that on-call mutes them | → | Customers report outages before monitoring does | ✓ sì | discuti |
| Alerts fire so often that on-call mutes them | → | Every team has its own logging format | ✓ sì | discuti |
| Every team has its own logging format | → | Customers report outages before monitoring does | ✓ sì | discuti |
| The on-call rota has the same two people on it most weeks | → | Alerts fire so often that on-call mutes them | ✓ sì | discuti |
| Feature work always outranks reliability work in planning | → | Post-mortem actions are written up and then never scheduled | ✓ sì | discuti |
| One engineer knows how the payment path actually works | → | The on-call rota has the same two people on it most weeks | ✓ sì | discuti |
| The on-call rota has the same two people on it most weeks | → | Post-mortem actions are written up and then never scheduled | ✓ sì | discuti |
| Post-mortems assign actions to people who were not in the room | → | Post-mortem actions are written up and then never scheduled | ✓ sì | discuti |
| The service map in the wiki is two years old | → | The staging environment does not resemble production | ✓ sì | discuti |
| Rollbacks take longer than the outage they are meant to end | → | Reliability has no budget line of its own | ✓ sì | discuti |
| Reliability has no budget line of its own | → | The staging environment does not resemble production | ✓ sì | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | The same three services cause most of the pages | ✓ sì | discuti |
| Reliability has no budget line of its own | → | The incident channel fills with people asking for status instead of giving it | ✓ sì | discuti |
| The same three services cause most of the pages | → | The staging environment does not resemble production | ✓ sì | discuti |
| The service map in the wiki is two years old | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✓ sì | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Rollbacks take longer than the outage they are meant to end | ✓ sì | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The same three services cause most of the pages | ✓ sì | discuti |
| The on-call rota has the same two people on it most weeks | → | Customers report outages before monitoring does | ✓ per deduzione | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | The staging environment does not resemble production | ✓ per deduzione | discuti |
| Post-mortem actions are written up and then never scheduled | → | Every team has its own logging format | ✗ no | discuti |
| Every team has its own logging format | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | Customers report outages before monitoring does | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Customers report outages before monitoring does | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Customers report outages before monitoring does | ✗ no | discuti |
| Customers report outages before monitoring does | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | Every team has its own logging format | ✗ no | discuti |
| The on-call rota has the same two people on it most weeks | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | Every team has its own logging format | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Customers report outages before monitoring does | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | Post-mortem actions are written up and then never scheduled | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Customers report outages before monitoring does | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | Every team has its own logging format | ✗ no | discuti |
| Customers report outages before monitoring does | → | Post-mortem actions are written up and then never scheduled | ✗ no | discuti |
| Customers report outages before monitoring does | → | Every team has its own logging format | ✗ no | discuti |
| Customers report outages before monitoring does | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Customers report outages before monitoring does | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Every team has its own logging format | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| Every team has its own logging format | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Every team has its own logging format | → | Post-mortem actions are written up and then never scheduled | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| The on-call rota has the same two people on it most weeks | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Customers report outages before monitoring does | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Customers report outages before monitoring does | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | Customers report outages before monitoring does | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Post-mortem actions are written up and then never scheduled | ✗ no | discuti |
| The on-call rota has the same two people on it most weeks | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| The on-call rota has the same two people on it most weeks | → | Every team has its own logging format | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Every team has its own logging format | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| The on-call rota has the same two people on it most weeks | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| Every team has its own logging format | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| The on-call rota has the same two people on it most weeks | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | Post-mortem actions are written up and then never scheduled | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Alerts fire so often that on-call mutes them | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Post-mortem actions are written up and then never scheduled | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| Error budgets exist on a slide and nowhere else | → | Every team has its own logging format | ✗ no | discuti |
| Tests that fail intermittently are retried until green | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | Customers report outages before monitoring does | ✗ no | in primo piano ↑ · chiudi ✕ |
| Every team has its own logging format | → | Tests that fail intermittently are retried until green | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Post-mortems assign actions to people who were not in the room | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Every team has its own logging format | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | Error budgets exist on a slide and nowhere else | ✗ no | discuti |
| Post-mortems assign actions to people who were not in the room | → | One engineer knows how the payment path actually works | ✗ no | discuti |
| Alerts fire so often that on-call mutes them | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| One engineer knows how the payment path actually works | → | Every team has its own logging format | ✗ no | discuti |
| Feature work always outranks reliability work in planning | → | The on-call rota has the same two people on it most weeks | ✗ no | discuti |
| Post-mortem actions are written up and then never scheduled | → | Feature work always outranks reliability work in planning | ✗ no | discuti |
| The same three services cause most of the pages | → | The service map in the wiki is two years old | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | The same three services cause most of the pages | ✗ no | discuti |
| Config lives in five places and drifts between them | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| … | → | The staging environment does not resemble production | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | Config lives in five places and drifts between them | ✗ no | discuti |
| Reliability has no budget line of its own | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| The same three services cause most of the pages | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| The service map in the wiki is two years old | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| Config lives in five places and drifts between them | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | The service map in the wiki is two years old | ✗ no | discuti |
| … | → | Reliability has no budget line of its own | ✗ no | discuti |
| The service map in the wiki is two years old | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Reliability has no budget line of its own | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | … | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | Reliability has no budget line of its own | ✗ no | discuti |
| Config lives in five places and drifts between them | → | The staging environment does not resemble production | ✗ no | discuti |
| … | → | Config lives in five places and drifts between them | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | … | ✗ no | discuti |
| Reliability has no budget line of its own | → | Config lives in five places and drifts between them | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| The same three services cause most of the pages | → | Reliability has no budget line of its own | ✗ no | discuti |
| … | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The service map in the wiki is two years old | ✗ no | discuti |
| Config lives in five places and drifts between them | → | Reliability has no budget line of its own | ✗ no | discuti |
| The staging environment does not resemble production | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | Config lives in five places and drifts between them | ✗ no | discuti |
| The service map in the wiki is two years old | → | Reliability has no budget line of its own | ✗ no | discuti |
| The service map in the wiki is two years old | → | Config lives in five places and drifts between them | ✗ no | discuti |
| The staging environment does not resemble production | → | Config lives in five places and drifts between them | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | The service map in the wiki is two years old | ✗ no | discuti |
| The staging environment does not resemble production | → | The service map in the wiki is two years old | ✗ no | discuti |
| The staging environment does not resemble production | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| … | → | The same three services cause most of the pages | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| … | → | The service map in the wiki is two years old | ✗ no | discuti |
| Config lives in five places and drifts between them | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| The staging environment does not resemble production | → | … | ✗ no | discuti |
| Reliability has no budget line of its own | → | … | ✗ no | discuti |
| The same three services cause most of the pages | → | Config lives in five places and drifts between them | ✗ no | discuti |
| … | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The staging environment does not resemble production | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| Config lives in five places and drifts between them | → | … | ✗ no | discuti |
| The staging environment does not resemble production | → | The same three services cause most of the pages | ✗ no | discuti |
| Reliability has no budget line of its own | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| Config lives in five places and drifts between them | → | The same three services cause most of the pages | ✗ no | discuti |
| The staging environment does not resemble production | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | The staging environment does not resemble production | ✗ no | discuti |
| … | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| Config lives in five places and drifts between them | → | The service map in the wiki is two years old | ✗ no | discuti |
| The same three services cause most of the pages | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | Config lives in five places and drifts between them | ✗ no | discuti |
| Reliability has no budget line of its own | → | The service map in the wiki is two years old | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | … | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Config lives in five places and drifts between them | ✗ no | discuti |
| Config lives in five places and drifts between them | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| The service map in the wiki is two years old | → | … | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | The same three services cause most of the pages | ✗ no | discuti |
| Rollbacks take longer than the outage they are meant to end | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| Reliability has no budget line of its own | → | The same three services cause most of the pages | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| The same three services cause most of the pages | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ no | discuti |
| The service map in the wiki is two years old | → | The incident channel fills with people asking for status instead of giving it | ✗ no | discuti |
| The service map in the wiki is two years old | → | The same three services cause most of the pages | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | … | ✗ no | discuti |
| The staging environment does not resemble production | → | Reliability has no budget line of its own | ✗ no | discuti |
| The incident channel fills with people asking for status instead of giving it | → | The staging environment does not resemble production | ✗ no | discuti |
| The same three services cause most of the pages | → | Rollbacks take longer than the outage they are meant to end | ✗ no | discuti |
| … | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ no | discuti |
| Retries are unbounded, so a slow dependency becomes a flood | → | Reliability has no budget line of its own | ✗ no | discuti |