SPØRSMÅLET
Why does the same outage keep recurring?
Påvirker det ene det andre i betydelig grad? Tre firedeler av de avgitte stemmene avgjør.
stengt · tilbake til fasen Tiltak
Du ser på som gjest. Skriv inn et brukernavn for å bli med og delta.
Spørsmålene fordeles mellom gruppene, så du får dem gruppen din ble tildelt — ikke alle 180.
avgjort: 176 / 180 til deg å svare på: 0 hvorfor
Ingen kunne svart på flere hundre par. Hvert par går til én gruppe; et par som deler gruppen, sendes så videre til andre grupper, så det kan dukke opp i listen din senere selv om det startet et annet sted. Antallet avgjorte omfatter alle gruppenes arbeid, og derfor stiger det raskere enn din egen liste krymper.
Siste opptelling: avgjort 176 · sendt videre til paneler på tvers av grupper 1 · omstridt 0 · under kvorum 3 — paneler trenger minst max(2, 75% av panelet) avgitte stemmer; ditt minste panel har 15 medlemmer.
Every team has its own logging format → påvirker? → Feature work always outranks reliability work in planning
Ingenting sagt ennå.
Fullført fase — protokollen over par og stemmer står ovenfor.Sjekk logikken ↗
| Reliability has no budget line of its own | → | Feature flags are never cleaned up, so nobody knows which paths are live | åpent | diskuter |
| The same three services cause most of the pages | → | … | åpent | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | The service map in the wiki is two years old | åpent | diskuter |
| The staging environment does not resemble production | → | Rollbacks take longer than the outage they are meant to end | åpent sendt videre | diskuter |
| Tests that fail intermittently are retried until green | → | Customers report outages before monitoring does | ✓ ja | diskuter |
| Alerts fire so often that on-call mutes them | → | Customers report outages before monitoring does | ✓ ja | diskuter |
| Alerts fire so often that on-call mutes them | → | Every team has its own logging format | ✓ ja | diskuter |
| Every team has its own logging format | → | Customers report outages before monitoring does | ✓ ja | diskuter |
| The on-call rota has the same two people on it most weeks | → | Alerts fire so often that on-call mutes them | ✓ ja | diskuter |
| Feature work always outranks reliability work in planning | → | Post-mortem actions are written up and then never scheduled | ✓ ja | diskuter |
| One engineer knows how the payment path actually works | → | The on-call rota has the same two people on it most weeks | ✓ ja | diskuter |
| The on-call rota has the same two people on it most weeks | → | Post-mortem actions are written up and then never scheduled | ✓ ja | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Post-mortem actions are written up and then never scheduled | ✓ ja | diskuter |
| The service map in the wiki is two years old | → | The staging environment does not resemble production | ✓ ja | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | Reliability has no budget line of its own | ✓ ja | diskuter |
| Reliability has no budget line of its own | → | The staging environment does not resemble production | ✓ ja | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | The same three services cause most of the pages | ✓ ja | diskuter |
| Reliability has no budget line of its own | → | The incident channel fills with people asking for status instead of giving it | ✓ ja | diskuter |
| The same three services cause most of the pages | → | The staging environment does not resemble production | ✓ ja | diskuter |
| The service map in the wiki is two years old | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✓ ja | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Rollbacks take longer than the outage they are meant to end | ✓ ja | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The same three services cause most of the pages | ✓ ja | diskuter |
| The on-call rota has the same two people on it most weeks | → | Customers report outages before monitoring does | ✓ utledet | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | The staging environment does not resemble production | ✓ utledet | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Every team has its own logging format | ✗ nei | diskuter |
| Every team has its own logging format | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | Customers report outages before monitoring does | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Customers report outages before monitoring does | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | Every team has its own logging format | ✗ nei | diskuter |
| The on-call rota has the same two people on it most weeks | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Every team has its own logging format | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | Post-mortem actions are written up and then never scheduled | ✗ nei | diskuter |
| 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 | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | Every team has its own logging format | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Post-mortem actions are written up and then never scheduled | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Every team has its own logging format | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Every team has its own logging format | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| Every team has its own logging format | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Every team has its own logging format | → | Post-mortem actions are written up and then never scheduled | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| The on-call rota has the same two people on it most weeks | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Customers report outages before monitoring does | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Customers report outages before monitoring does | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Customers report outages before monitoring does | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Post-mortem actions are written up and then never scheduled | ✗ nei | diskuter |
| The on-call rota has the same two people on it most weeks | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| The on-call rota has the same two people on it most weeks | → | Every team has its own logging format | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Every team has its own logging format | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| 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 | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| Every team has its own logging format | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| The on-call rota has the same two people on it most weeks | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | Post-mortem actions are written up and then never scheduled | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Alerts fire so often that on-call mutes them | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Post-mortem actions are written up and then never scheduled | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| Error budgets exist on a slide and nowhere else | → | Every team has its own logging format | ✗ nei | diskuter |
| Tests that fail intermittently are retried until green | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Customers report outages before monitoring does | ✗ nei | diskuter |
| Every team has its own logging format | → | Tests that fail intermittently are retried until green | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Post-mortems assign actions to people who were not in the room | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Every team has its own logging format | → | Feature work always outranks reliability work in planning | ✗ nei | i fokus ↑ · lukk ✕ |
| One engineer knows how the payment path actually works | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | Error budgets exist on a slide and nowhere else | ✗ nei | diskuter |
| Post-mortems assign actions to people who were not in the room | → | One engineer knows how the payment path actually works | ✗ nei | diskuter |
| Alerts fire so often that on-call mutes them | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| One engineer knows how the payment path actually works | → | Every team has its own logging format | ✗ nei | diskuter |
| Feature work always outranks reliability work in planning | → | The on-call rota has the same two people on it most weeks | ✗ nei | diskuter |
| Post-mortem actions are written up and then never scheduled | → | Feature work always outranks reliability work in planning | ✗ nei | diskuter |
| The same three services cause most of the pages | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | The same three services cause most of the pages | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| … | → | The staging environment does not resemble production | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| Reliability has no budget line of its own | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| The same three services cause most of the pages | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ nei | diskuter |
| 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 | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| … | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| 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 | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | … | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | The staging environment does not resemble production | ✗ nei | diskuter |
| … | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | … | ✗ nei | diskuter |
| Reliability has no budget line of its own | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| The same three services cause most of the pages | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| … | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ nei | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| The staging environment does not resemble production | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| The staging environment does not resemble production | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| The staging environment does not resemble production | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| The staging environment does not resemble production | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| … | → | The same three services cause most of the pages | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ nei | diskuter |
| … | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| The staging environment does not resemble production | → | … | ✗ nei | diskuter |
| Reliability has no budget line of its own | → | … | ✗ nei | diskuter |
| The same three services cause most of the pages | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| … | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | The staging environment does not resemble production | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | … | ✗ nei | diskuter |
| The staging environment does not resemble production | → | The same three services cause most of the pages | ✗ nei | diskuter |
| Reliability has no budget line of its own | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | The same three services cause most of the pages | ✗ nei | diskuter |
| The staging environment does not resemble production | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | The staging environment does not resemble production | ✗ nei | diskuter |
| … | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| The same three services cause most of the pages | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| Reliability has no budget line of its own | → | The service map in the wiki is two years old | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | … | ✗ nei | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Config lives in five places and drifts between them | ✗ nei | diskuter |
| Config lives in five places and drifts between them | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| Feature flags are never cleaned up, so nobody knows which paths are live | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | … | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | The same three services cause most of the pages | ✗ nei | diskuter |
| Rollbacks take longer than the outage they are meant to end | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| Reliability has no budget line of its own | → | The same three services cause most of the pages | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| The same three services cause most of the pages | → | Feature flags are never cleaned up, so nobody knows which paths are live | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | The incident channel fills with people asking for status instead of giving it | ✗ nei | diskuter |
| The service map in the wiki is two years old | → | The same three services cause most of the pages | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | … | ✗ nei | diskuter |
| The staging environment does not resemble production | → | Reliability has no budget line of its own | ✗ nei | diskuter |
| The incident channel fills with people asking for status instead of giving it | → | The staging environment does not resemble production | ✗ nei | diskuter |
| The same three services cause most of the pages | → | Rollbacks take longer than the outage they are meant to end | ✗ nei | diskuter |
| … | → | Retries are unbounded, so a slow dependency becomes a flood | ✗ nei | diskuter |
| Retries are unbounded, so a slow dependency becomes a flood | → | Reliability has no budget line of its own | ✗ nei | diskuter |