CÂU HỎI
Why does the same outage keep recurring?
Dùng nhãn dán cho điều quan trọng nhất. Một ý có bằng chứng có thể vào chỗ dành riêng.
đã đóng · quay lại giai đoạn Biện pháp
Đang xem với tư cách khách. Nhập tên người dùng để vào và tham gia.
Số nhãn dán của bạn
Mỗi ý một nhãn, tổng cộng 5. Tối thiểu là một phiếu.
Có 5 chỗ dành riêng cho các ý bị bỏ sót — đề cử một ý kèm một đường dẫn, và đề cử được tính khi 2 người đồng ý rằng nguồn đó liên quan.
vì sao
Khi giai đoạn kết thúc, một ý được đề cử vào bằng bốc thăm ngẫu nhiên và các ý còn lại theo số lượt đề cử, mỗi thành phần liên quan tối đa một ý. Mô hình chỉ kiểm tra trang có nói về cùng chủ đề hay không — không bao giờ kiểm tra nó có chứng minh được nhận định hay không. Việc đánh giá đó là của cả phòng, và một đề cử không có ai khác ủng hộ thì không được chỗ.
CỤM 1
The on-call rota has the same two people on it most weeks
7 phiếuthảo luận
CỤM 2
Post-mortem actions are written up and then never scheduled
4 phiếuthảo luận
Feature flags are never cleaned up, so nobody knows which paths are live
Meaning the repeat outages, not the one-off hardware failure in March.
7 phiếuthảo luận
CỤM 3
Migrations are run by hand from a laptop
2 phiếuthảo luận
Config lives in five places and drifts between them
I mean the pattern over the last two quarters, not a single incident.
3 phiếuthảo luận
CỤM 4
Reliability has no budget line of its own
To be precise: this is about the process, not the person on call that night.
11 phiếuthảo luận
Every team has its own logging format
3 phiếuthảo luận
CỤM 5
Customers report outages before monitoring does
I mean the pattern over the last two quarters, not a single incident.
10 phiếuthảo luận
Alerts fire so often that on-call mutes them
I mean the pattern over the last two quarters, not a single incident.
6 phiếuthảo luận
CỤM 6
The service map in the wiki is two years old
5 phiếuthảo luận
Runbooks are out of date within a month of being written
To be precise: this is about the process, not the person on call that night.
2 phiếuđang thảo luận (1)
CHƯA GOM CỤM
Tests that fail intermittently are retried until green
10 phiếuthảo luận
Leadership asks for a root cause within the hour, so the first plausible one wins
I mean the pattern over the last two quarters, not a single incident.
1 phiếuthảo luận
Success is measured in features shipped per quarter
1 phiếuthảo luận
Dependencies are upgraded only when something breaks
Meaning the repeat outages, not the one-off hardware failure in March.
0 phiếuthảo luận
Deploys go out on Friday afternoons because that is when the sprint ends
2 phiếuthảo luận
Rollbacks take longer than the outage they are meant to end
To be precise: this is about the process, not the person on call that night.
3 phiếuthảo luận
Post-mortems assign actions to people who were not in the room
Scope: the services this team runs, not the whole platform.
8 phiếuđang thảo luận (1)
Feature work always outranks reliability work in planning
Scope: the services this team runs, not the whole platform.
4 phiếuthảo luận
There is no time set aside after an incident, so the write-up is done at midnight
2 phiếuthảo luận
Incidents are declared late because declaring one feels like blame
1 phiếuthảo luận
Load tests were last run before the customer base doubled
1 phiếuthảo luận
One engineer knows how the payment path actually works
Scope: the services this team runs, not the whole platform.
5 phiếu
↳ được đề cử vào chỗ dành riêng: https://example.org/ops-incident-review.pdf could not read it (HTTPError) 1/2 người ủng hộ
thảo luậnError budgets exist on a slide and nowhere else
8 phiếuthảo luận
The staging environment does not resemble production
7 phiếuthảo luận
The incident channel fills with people asking for status instead of giving it
3 phiếuthảo luận
Nobody owns the shared database schema
To be precise: this is about the process, not the person on call that night.
2 phiếuthảo luận
Retries are unbounded, so a slow dependency becomes a flood
6 phiếuthảo luận
Capacity is added after the outage, never before
0 phiếuthảo luận