Когда я только начинал работать, 100% аптайма казались мне священным граалем. Казалось: если сервис никогда не падает — пользователи счастливы, бизнес доволен, инженеры спят спокойно. Но реальность быстро показала: каждая дополнительная «девятка» стоит всё дороже, а выгоды становятся всё менее заметными. В статье делюсь опытом: почему гонка за идеальной надёжностью — тупик, как помогает концепция Error Budget и почему лучше найти баланс между стабильностью и развитием.

Когда я только начинал дежурить, телефон ночью был моим главным врагом: PagerDuty вырывал из сна десятки раз, а инциденты превращались в хаос. Со временем я понял, что on-call можно превратить в предсказуемый процесс — с правильными алертами, runbook-ами и командной культурой. В этой статье расскажу, как я перестал бояться алертов и научился относиться к дежурствам спокойно. Будет личный опыт, фейлы и практические советы

Когда я только начинал работать с инфраструктурой, всё выглядело как бесконечный пожар: сотни алертов, ночные звонки, хаотичные релизы и нервы на пределе. Мы гасили инциденты вручную, но проблема возвращалась снова и снова.

Ситуация изменилась, когда я познакомился с практиками SRE: SLO, SLI и error budget. Они помогли превратить хаос в систему и объяснить бизнесу надёжность на понятном языке. Теперь вместо бессмысленного «сервис упал!» мы обсуждаем конкретные цифры: сколько бюджета ошибок потрачено и когда можно катить релиз.

В этой статье расскажу, как мы внедрили наблюдаемость на основе golden signals, научились писать постмортемы без поиска виноватых и встроили задачи по надёжности прямо в бэклог. Всё — из реальной практики инженера, который за год прошёл путь от «тушения пожаров» к спокойной работе с прогнозируемой стабильностью.