SRE — это про надёжность, но иногда кажется, что весь мир против нас. Какие вещи чаще всего доводят SRE-инженеров до нервного тика?
1️⃣ — А давайте зарелизим в пятницу вечером?
— Нет. Просто нет.
Релиз перед выходными = гарантированный Pager Hell. Если что-то пойдёт не так (а оно пойдёт), вы проведёте субботу не с друзьями, а в логах и Grafana.
2️⃣ — Давайте алертить на всё подряд!
— Если алерты орут постоянно, их просто перестают слушать.
Настроили алерт на 5% падения запросов? Добавили ещё один на 3%? А потом ещё на миллисекунду задержки? Поздравляю, теперь SRE живёт в Pager Hell и игнорирует критические алерты.
3️⃣ — Мониторинг? Да у нас есть логи!
— Логи ≠ мониторинг!
Логов может быть миллионы строк в секунду, и если искать проблему вручную — можно состариться быстрее, чем найдёшь её. Без нормальных метрик и дашбордов SRE работает в темноте.
4️⃣ — Прод упал, а кто-то поменял конфиг. Но кто?
— Конфигурация должна быть под контролем.
Если кто-то пофиксил что-то прямо на проде без ревью, а потом прод лёг — это худшее, что можно сделать. GitOps, версионирование, ревью — наше всё.
5️⃣ — Просто перезапустите контейнер, и всё заработает!
— Нет.
Перезапуск контейнера не решает проблему. Он просто маскирует её. Настоящий SRE должен разобраться, почему он вообще упал.
6️⃣— А давайте убьём кэш!
— А давайте убьём прод сразу?
Очистка кэша без понимания последствий = лавина запросов в базу, перегрузка и падение сервиса.
7️⃣— Зачем нам тестить отказоустойчивость? Всё и так работает!
— До первого сбоя.
Если система не тестировалась на сбои, то первый реальный инцидент станет катастрофой. Поэтому SRE практикуют Chaos Engineering: намеренно ломают системы, чтобы узнать, что произойдёт.
SRE-работа бесценна, но иногда кажется, что мы воюем не только с продом, но и с людьми.
Какой «набор выживальщика» помогает SRE-инженеру воевать с пожарами, рассказали здесь.
1️⃣ — А давайте зарелизим в пятницу вечером?
— Нет. Просто нет.
Релиз перед выходными = гарантированный Pager Hell. Если что-то пойдёт не так (а оно пойдёт), вы проведёте субботу не с друзьями, а в логах и Grafana.
2️⃣ — Давайте алертить на всё подряд!
— Если алерты орут постоянно, их просто перестают слушать.
Настроили алерт на 5% падения запросов? Добавили ещё один на 3%? А потом ещё на миллисекунду задержки? Поздравляю, теперь SRE живёт в Pager Hell и игнорирует критические алерты.
3️⃣ — Мониторинг? Да у нас есть логи!
— Логи ≠ мониторинг!
Логов может быть миллионы строк в секунду, и если искать проблему вручную — можно состариться быстрее, чем найдёшь её. Без нормальных метрик и дашбордов SRE работает в темноте.
4️⃣ — Прод упал, а кто-то поменял конфиг. Но кто?
— Конфигурация должна быть под контролем.
Если кто-то пофиксил что-то прямо на проде без ревью, а потом прод лёг — это худшее, что можно сделать. GitOps, версионирование, ревью — наше всё.
5️⃣ — Просто перезапустите контейнер, и всё заработает!
— Нет.
Перезапуск контейнера не решает проблему. Он просто маскирует её. Настоящий SRE должен разобраться, почему он вообще упал.
6️⃣— А давайте убьём кэш!
— А давайте убьём прод сразу?
Очистка кэша без понимания последствий = лавина запросов в базу, перегрузка и падение сервиса.
7️⃣— Зачем нам тестить отказоустойчивость? Всё и так работает!
— До первого сбоя.
Если система не тестировалась на сбои, то первый реальный инцидент станет катастрофой. Поэтому SRE практикуют Chaos Engineering: намеренно ломают системы, чтобы узнать, что произойдёт.
SRE-работа бесценна, но иногда кажется, что мы воюем не только с продом, но и с людьми.
Какой «набор выживальщика» помогает SRE-инженеру воевать с пожарами, рассказали здесь.
