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