AndrewKuznetsov
New member
Когда нас осталось трое — два бэкендера и один человек, который «немного умеет в инфраструктуру», — я искренне считал, что полноценный мониторинг нам не по карману и не по силам. Мол, это удел команд, где есть отдельный SRE и бюджет на пачку SaaS-сервисов. Спустя полтора года я могу сказать честно: мы ошибались, но не в ту сторону, в которую вы подумали. Нам не нужен был большой стек. Нам нужен был порядок в голове и дисциплина в трёх базовых вещах — логах, метриках и алертах.
Начинали мы, как почти все, с полного хаоса. Логи лежали на серверах и читались через SSH, метрики жили в голове самого опытного из нас, а алерты приходили в один общий чат, куда сваливались ещё и уведомления из трекера, сборки и заявки от клиентов. Один раз мы узнали о падении оплат от клиента, который написал в поддержку с вопросом «а почему кнопка не работает?». В тот момент я понял: мы не команда без мониторинга, мы команда без обратной связи от собственной системы. Это очень разное состояние, и второе гораздо опаснее.
С логов мы начали, потому что это было дешевле всего. Собрали всё в одно место, заставили приложение писать структурно, то есть не человеческими фразами в свободной форме, а аккуратными парами ключ и значение с обязательным идентификатором запроса. Звучит скучно, но именно это спасло нас сотни часов. Раньше поиск причины ошибки занимал вечер, теперь — две минуты, потому что по идентификатору видно весь путь запроса от фронта до базы. И ещё одно правило, которое я теперь отстаиваю с фанатизмом: в логе не должно быть ничего, что мы не готовы показать в общем чате. Ни паролей, ни токенов, ни персональных данных. Мы на этом уже обжигались, и повторять не хочется.
Метрики оказались самой недооценённой частью. Мы долго спорили, что вообще измерять, и в итоге остановились на четырёх простых вещах: сколько запросов приходит, сколько из них падает, как быстро они обслуживаются и насколько загружены наши ресурсы. Никаких сотен графиков «на будущее». У нас есть один экран, который открывается при любом инциденте, и там всё, что нужно для первого диагноза. Скажу честно: соблазн нарисовать красивый дашборд на сорок панелей был огромный, но мы вовремя поняли, что дашборд, на который никто не смотрит, — это не мониторинг, это декорация.
С алертами мы прошли через классическую стадию выгорания. Первая версия настроек будила нас ночью из-за кратковременного роста времени ответа, который сам проходил через минуту. Через две недели мы начали игнорировать уведомления, а это самый опасный симптом из всех возможных. Пришлось переписать правила по простому принципу: алерт должен означать, что страдают пользователи, а не что где-то дёрнулась цифра. Мы добавили задержку, чтобы отсекать короткие всплески, объединили похожие события в одно уведомление и, что важнее всего, к каждому алерту приписали короткую инструкцию — что посмотреть и что сделать первым делом. Теперь ночью звонит телефон редко, но когда звонит, никто не бегает в панике с вопросом «а это вообще нормально?».
Отдельно скажу про то, чего мы сознательно не делали. Мы не строили сложную систему целей по надёжности, не заводили регламенты на сорок страниц и не пытались автоматизировать всё сразу. Для команды из трёх человек главный враг — не отсутствие инструментов, а их избыток. Каждый новый сервис в стеке — это ещё одна штука, которая может сломаться, и ещё один человек, который должен помнить, как её чинить. Мы добавляли что-то новое только тогда, когда текущего перестало хватать, и ни минутой раньше. Может быть, поэтому наш стек до сих пор выглядит скромно и при этом реально работает.
Главный вывод, к которому я пришёл за это время: мониторинг в маленькой команде — это не про технологии, а про честность. Если вы не настроили алерты, потому что «пока и так сойдёт», вы просто откладываете разговор с самим собой. Если дашборд никто не открывал месяц, его стоит удалить. Если инцидент разбирается только по памяти, значит, вы уже потеряли знание, которое завтра понадобится. Мы стали спокойнее спать, у нас упало время реакции с часов до минут, и, что приятнее всего, новые люди в команде входят в контекст за пару дней, а не за пару месяцев.
Если вы тоже работаете маленькой командой, начните с одного: сделайте так, чтобы система сама сказала вам о проблеме раньше клиента. Это не требует денег, это требует вечера времени. А теперь вопрос к вам, коллеги: какая одна вещь в вашем мониторинге дала самый большой эффект при минимальных усилиях — поделитесь, я с удовольствием украду ваш приём для своей тройки!
Начинали мы, как почти все, с полного хаоса. Логи лежали на серверах и читались через SSH, метрики жили в голове самого опытного из нас, а алерты приходили в один общий чат, куда сваливались ещё и уведомления из трекера, сборки и заявки от клиентов. Один раз мы узнали о падении оплат от клиента, который написал в поддержку с вопросом «а почему кнопка не работает?». В тот момент я понял: мы не команда без мониторинга, мы команда без обратной связи от собственной системы. Это очень разное состояние, и второе гораздо опаснее.
С логов мы начали, потому что это было дешевле всего. Собрали всё в одно место, заставили приложение писать структурно, то есть не человеческими фразами в свободной форме, а аккуратными парами ключ и значение с обязательным идентификатором запроса. Звучит скучно, но именно это спасло нас сотни часов. Раньше поиск причины ошибки занимал вечер, теперь — две минуты, потому что по идентификатору видно весь путь запроса от фронта до базы. И ещё одно правило, которое я теперь отстаиваю с фанатизмом: в логе не должно быть ничего, что мы не готовы показать в общем чате. Ни паролей, ни токенов, ни персональных данных. Мы на этом уже обжигались, и повторять не хочется.
Метрики оказались самой недооценённой частью. Мы долго спорили, что вообще измерять, и в итоге остановились на четырёх простых вещах: сколько запросов приходит, сколько из них падает, как быстро они обслуживаются и насколько загружены наши ресурсы. Никаких сотен графиков «на будущее». У нас есть один экран, который открывается при любом инциденте, и там всё, что нужно для первого диагноза. Скажу честно: соблазн нарисовать красивый дашборд на сорок панелей был огромный, но мы вовремя поняли, что дашборд, на который никто не смотрит, — это не мониторинг, это декорация.
С алертами мы прошли через классическую стадию выгорания. Первая версия настроек будила нас ночью из-за кратковременного роста времени ответа, который сам проходил через минуту. Через две недели мы начали игнорировать уведомления, а это самый опасный симптом из всех возможных. Пришлось переписать правила по простому принципу: алерт должен означать, что страдают пользователи, а не что где-то дёрнулась цифра. Мы добавили задержку, чтобы отсекать короткие всплески, объединили похожие события в одно уведомление и, что важнее всего, к каждому алерту приписали короткую инструкцию — что посмотреть и что сделать первым делом. Теперь ночью звонит телефон редко, но когда звонит, никто не бегает в панике с вопросом «а это вообще нормально?».
Отдельно скажу про то, чего мы сознательно не делали. Мы не строили сложную систему целей по надёжности, не заводили регламенты на сорок страниц и не пытались автоматизировать всё сразу. Для команды из трёх человек главный враг — не отсутствие инструментов, а их избыток. Каждый новый сервис в стеке — это ещё одна штука, которая может сломаться, и ещё один человек, который должен помнить, как её чинить. Мы добавляли что-то новое только тогда, когда текущего перестало хватать, и ни минутой раньше. Может быть, поэтому наш стек до сих пор выглядит скромно и при этом реально работает.
Главный вывод, к которому я пришёл за это время: мониторинг в маленькой команде — это не про технологии, а про честность. Если вы не настроили алерты, потому что «пока и так сойдёт», вы просто откладываете разговор с самим собой. Если дашборд никто не открывал месяц, его стоит удалить. Если инцидент разбирается только по памяти, значит, вы уже потеряли знание, которое завтра понадобится. Мы стали спокойнее спать, у нас упало время реакции с часов до минут, и, что приятнее всего, новые люди в команде входят в контекст за пару дней, а не за пару месяцев.
Если вы тоже работаете маленькой командой, начните с одного: сделайте так, чтобы система сама сказала вам о проблеме раньше клиента. Это не требует денег, это требует вечера времени. А теперь вопрос к вам, коллеги: какая одна вещь в вашем мониторинге дала самый большой эффект при минимальных усилиях — поделитесь, я с удовольствием украду ваш приём для своей тройки!