Artyom_Harris
New member
Когда у нас было три разработчика и один дежурный, мы думали, что полноценный мониторинг — это для больших компаний. Купили дорогой сервис, настроили сотни метрик, но бюджет сгорел, а о сбоях всё равно узнавали от пользователей. Тогда мы решили пересобрать подход вокруг SLI, SLO, алертинга и инцидент-менеджмента. И оказалось, что главное — не количество инструментов, а дисциплина.
Мы перестали мониторить всё подряд. Выбрали четыре пользовательских сценария: вход, оплата, API для партнёров и загрузка файлов. Для каждого определили SLI — измеримый показатель, например доля успешных запросов или 95-й процентиль задержки. SLO поставили реалистично: 99,5 процента на месяц, а не 99,99. Иначе команда выгорит раньше, чем сервер.
Бюджет ошибок стал главным инструментом. Если за месяц сожгли больше двадцати процентов, замораживаем новые фичи и чиним надёжность. Если меньше — спокойно релизим. Это сняло вечные споры между продуктом и разработкой. Никто больше не требует стопроцентной доступности ценой бессонных ночей.
В алертинге мы отказались от уведомлений на каждый чих. Настроили только на симптомы: пользовательский сценарий недоступен или бюджет ошибок выгорает слишком быстро. Всё остальное — в тихий канал, разбираем утром. Ночные дежурства стали реже, а люди перестали игнорировать уведомления. Это, пожалуй, самый большой выигрыш для маленькой команды.
Инцидент-менеджмент у нас простой. Один человек — командир инцидента, даже если он же разработчик. Он не чинит, а координирует, пишет таймлайн и общается со стейкхолдерами. Второй — операции. После инцидента — разбор без поиска виноватых на тридцать минут. Главное — задачи с владельцами и сроками, иначе всё забудется.
По бюджету мы используем открытые инструменты для метрик, дашбордов, алертов и логов. Хостим на своей инфраструктуре, платим только за диски и пару часов поддержки. Вместо дорогой системы мониторинга приложений — выборочное логирование и трассировка по критичным путям. Экономия в разы, а видимость достаточная. Я не призываю отказываться от платных сервисов, но сначала посчитайте, что именно вы покупаете.
Рекомендации читателям: начните с одного SLO, не пытайтесь покрыть всё. Автоматизируйте сбор SLI из существующих метрик. Договоритесь о политике бюджета ошибок до аварии. Назначьте дежурных и ротацию, даже если вас трое. Проводите учебные инциденты раз в квартал. Инвестируйте в культуру, а не только в инструменты.
Мониторинг не обязан быть дорогим. Он должен отвечать на вопрос: чувствуют ли пользователи проблему. Если да — будите людей. Если нет — записывайте и чините в рабочее время. Маленькая команда может иметь надёжность не хуже корпорации, если не копировать её бюджет. А как у вас организован мониторинг и что помогло не сжечь бюджет?
Мы перестали мониторить всё подряд. Выбрали четыре пользовательских сценария: вход, оплата, API для партнёров и загрузка файлов. Для каждого определили SLI — измеримый показатель, например доля успешных запросов или 95-й процентиль задержки. SLO поставили реалистично: 99,5 процента на месяц, а не 99,99. Иначе команда выгорит раньше, чем сервер.
Бюджет ошибок стал главным инструментом. Если за месяц сожгли больше двадцати процентов, замораживаем новые фичи и чиним надёжность. Если меньше — спокойно релизим. Это сняло вечные споры между продуктом и разработкой. Никто больше не требует стопроцентной доступности ценой бессонных ночей.
В алертинге мы отказались от уведомлений на каждый чих. Настроили только на симптомы: пользовательский сценарий недоступен или бюджет ошибок выгорает слишком быстро. Всё остальное — в тихий канал, разбираем утром. Ночные дежурства стали реже, а люди перестали игнорировать уведомления. Это, пожалуй, самый большой выигрыш для маленькой команды.
Инцидент-менеджмент у нас простой. Один человек — командир инцидента, даже если он же разработчик. Он не чинит, а координирует, пишет таймлайн и общается со стейкхолдерами. Второй — операции. После инцидента — разбор без поиска виноватых на тридцать минут. Главное — задачи с владельцами и сроками, иначе всё забудется.
По бюджету мы используем открытые инструменты для метрик, дашбордов, алертов и логов. Хостим на своей инфраструктуре, платим только за диски и пару часов поддержки. Вместо дорогой системы мониторинга приложений — выборочное логирование и трассировка по критичным путям. Экономия в разы, а видимость достаточная. Я не призываю отказываться от платных сервисов, но сначала посчитайте, что именно вы покупаете.
Рекомендации читателям: начните с одного SLO, не пытайтесь покрыть всё. Автоматизируйте сбор SLI из существующих метрик. Договоритесь о политике бюджета ошибок до аварии. Назначьте дежурных и ротацию, даже если вас трое. Проводите учебные инциденты раз в квартал. Инвестируйте в культуру, а не только в инструменты.
Мониторинг не обязан быть дорогим. Он должен отвечать на вопрос: чувствуют ли пользователи проблему. Если да — будите людей. Если нет — записывайте и чините в рабочее время. Маленькая команда может иметь надёжность не хуже корпорации, если не копировать её бюджет. А как у вас организован мониторинг и что помогло не сжечь бюджет?