Привет! Меня зовут Егор, я DevOps/SRE-инженер с небольшим (2+ года) стажем. Ещё пару лет назад мои ночи были полны ужаса: телефон разрывался от PagerDuty, любое уведомление в чате заставляло подскакивать среди ночи, а кофе на 3 часа утра стал обычным делом. В прошлой статье – «Как я перестал тушить пожары и начал говорить с бизнесом на языке SLO» – я рассказывал, как мы внедрили SRE-подход: ввели SLO/SLI, настроили мониторинг по «золотым сигналам» и умные алерты, сделали постмортемы без поиска виноватых. MTTR тогда сократился с часов до минут, а шум от алертов заметно утих. Команда наконец вздохнула спокойно, но у меня оставалась личная проблема: дежурства. Я их ненавидел всей душой.
Сегодня ситуация иная. Дежурства превратились из ночного кошмара в рутинный процесс, который под контролем. Как же так вышло? Ниже — моя история о том, как я перестал бояться звука телефона и научился (почти) любить боевые дежурства. Будет немного юмора, парочка фейлов и много практических советов.
Меньше алертов — крепче сон: настраиваем мониторинг правильно
Когда я только начинал, система мониторинга превращала жизнь в ад. Сыпались сотни оповещений, важные и не очень, по любому чиху сервера. Мы мониторили «всё на свете» и тонули в данных. В результате инженеры боялись каждого звука телефона — уведомления превратились в белый шум, который мешал замечать реальные проблемы.
Первый шаг к исправлению ситуации — причесать мониторинг по SRE-принципам. Я вспомнил про четыре золотых сигнала из книги Google SRE: задержки, трафик, ошибки и нагрузка. Вместо того чтобы метриками измерять абсолютно всё, мы сконцентрировались на этих ключевых показателях. Настроили дашборды в Grafana по каждому из сигналов: время отклика (latency), количество запросов (RPS, трафик), процент ошибок (5xx и т.п.) и использование ресурсов (CPU, память). Дополнительно настроили сбор логов в ELK, чтобы при инциденте сразу видеть подробности. Постепенно мы убрали лишние метрики, которые никто не смотрит, и сосредоточились на действительно важных.
Затем мы взялись за правила алертинга. Каждый алерт должен быть сигналом, а не шумом – эта мантра из SRE-принципов стала нашим девизом. Мы пересмотрели все оповещения: что-то удалили, что-то переделали. Например, вместо десятка нервных триггеров по CPU (которые постоянно флапали при пиковой нагрузке) сделали один комбинированный: “CPU > 85% и высокая нагрузка держится 5 минут”. Вместо мгновенной тревоги на единичную ошибку HTTP 500 – оповещение только если 3 ошибки подряд (чтобы фильтровать редкие сбои). Фокус на симптомах, влияющих на пользователей: скажем, если сервис отвечает HTTP 500 — это реальная проблема, а вот куча 404 от каких-нибудь ботов – нет (такие мы просто логируем).
Результат не заставил себя ждать. Количество ложных тревог сократилось на порядок, и по ночам мне стало звонить заметно реже. Я наконец-то перестал просыпаться в холодном поту от каждого виброзвонка. Если раньше за ночь могло прилететь десятки PagerDuty-вызовов, то теперь — один-два, и те по делу. В промышленной терминологии мы повысили соотношение сигнал/шум (signal-to-noise ratio), а в бытовом смысле – банально стали больше спать. 🙂
Runbook – лучший друг дежурного инженера
Представьте: три часа ночи, приходит аларм с текстом «Queue XBG-45 length 150». Что за очередь XBG-45? В каком сервисе она живёт – RabbitMQ, Redis, может, и вовсе Kafka? Пойди разберись, когда сонный… В моём прошлом это была типичная ситуация. Я в панике искал, кого разбудить: звонил разработчикам, админам – иногда доходило до того, что дежурному приходилось будить трёх-четырёх человек по цепочке. В финале могло выясниться, что это вообще был старый тестовый контур, про который забыли отключить оповещения. То есть реальной проблемы не было, а ночной переполох случился знатный.
После пары таких фейлов мы создали себе нового лучшего друга – Runbook. Если по-простому, это короткая инструкция: что делать, когда сработал конкретный алерт. В больших компаниях runbook-и бывают громоздкими, но мы решили сделать по-своему: минимум букв, максимум пользы. На каждый критичный аларм написали отдельный документик по шаблону: что за проблема, где искать причину и какие шаги предпринять. Не абстрактное “В очереди 100 сообщений” (спасибо, кеп, это и так видно из текста оповещения), а пояснение человеческим языком: например, “Очередь XBG-45 – это RabbitMQ, используется сервисом OrderService для сборки заказов. Если длина >100, возможно, потребитель лег. Шаг 1: проверить лог OrderService в Kibana на ошибки. Шаг 2: перезапустить поды OrderService (см. инструкции ниже). Если не помогло – эскалировать дежурному бэкенд-разработчику.
Главное правило runbook-а: открыв его в 3 часа ночи, должно сразу стать понятно, что делать. Никакой «простыни» текста – только конкретные шаги. Мы включили в шаблон такие поля, как: Описание алерта, Симптомы (что наблюдается), Вероятные причины, Инструкция по исправлению (шаг 1, 2, 3 ...), и Эскалация (кого звать, если ничего не помогло). Каждый runbook хранится в общей базе знаний. Мы распечатали самые критичные и повесили прямо возле мониторов – на случай, если в критический момент руки дрожат и сложно искать файл 🙂.
После внедрения runbookов жизнь заметно упростилась. Больше не приходится лихорадочно гуглить ошибку или названивать коллегам в отпуске, пытаясь выяснить, что означает тот или иной аларм. Bus factor (фактор автобуса) тоже снизился – теперь любая проблема задокументирована, и даже новый дежурный сможет разобраться, не разбудив полкоманды. Плюс, сами runbook-и стали своего рода checklist-ами, которые дисциплинируют: сперва выполни шаги 1-2-3, и только потом паникуй.
Конечно, составление runbook-ов потребовало времени: мы привлекали разработчиков, чтобы они поделились знаниями по своим сервисам (иначе какие из нас «дежурные первой линии»?). Но эта инвестиция окупилась сторицей. Сейчас мой стол дежурного – это монитор с Grafana, второй с Kibana, и рядом открытый runbook. Получаю сигнал — действую по инструкции. Если всё решилось – отлично, пишу короткий отчёт и ложусь спать дальше. Если нет – в runbook-е уже указано, кому звонить. Никакой токсичности: если мне нужно звать помощь, никто не обвинит, что я чего-то “не знаю” – наоборот, совместно решаем, а потом дополняем документ, чтобы в следующий раз и этот кейс покрыть.
Наблюдаемость в помощь: находим и чиним быстрее (TTD vs MTTR)
Monitoring vs Observability – модная тема, но в контексте дежурств это не пустой звук. TTD (Time To Detect, время обнаружения) и MTTR (Mean Time To Recovery, среднее время восстановления) – два ключевых показателя здоровья on-call процесса. В начале моего пути они были удручающе велики: бывало, инцидент оставался незамеченным часами, пока клиент не пожалуется (TTD = вечность), а уж починить за 5 минут вообще казалось из области фантастики.
Теперь всё иначе. Благодаря умным алертам и хорошей наблюдаемости, мы обычно узнаём о проблеме раньше, чем пользователи. Например, мы поставили правило: «если >0,1% HTTP-запросов возвращают 5xx в течение 5 минут – шлём алерт». Такая чувствительность позволила ловить сбои практически сразу при возникновении. Время обнаружения упало почти вдвое – система сама сигналит о неполадке, не дожидаясь утреннего скандала от заказчика.
Но просто узнать мало – надо ещё быстро разобраться и исправить. Здесь помогают наши инструменты: метрики и логи. Раньше ночной дежурный был как слепой котёнок, тыкал куда попало: «Может, база? Нет, может, сеть… А может, сервер перегрелся?». Сейчас же картина прозрачна. Получив сигнал, я сразу иду в Grafana – вижу, например, что перед инцидентом резко выросла загрузка CPU на одном из подов, а вместе с ней и время ответа. Пара кликов – и вот он, виновник: в логах Kibana светится OutOfMemory на сервисе OrderService. Всё ясно – память кончилась, контейнер умер. MTTR в таком случае смешной: я просто перезапускаю проблемный деплой или увеличиваю лимит памяти, и сервис снова в строю в течение минут. При худшем раскладе – переключаю трафик на резервный экземпляр (blue-green deployment спасает).
Ещё пример: пришёл алерт «Latency 95-й перцентиль > 1с». Раньше я бы не знал, с чего начать, а теперь открываю соответствующий дашборд – вижу, что выросла латентность конкретного запроса к базе. Значит, проблема в базе или запросах к ней. Быстро проверяю Grafana: о, у базы скачок по Disk I/O. Сразу понятно – наверное, какой-то тяжёлый отчёт пошёл в ночи. И точно: смотрю журнал – маркетологи запустили экспорт данных. Лечим: лимитируем отчёт, либо даём базе больше ресурсов, либо (если критично) выключаем задачу до утра. Инцидент закрыт, все спят спокойно. 😌
Можно сказать, наблюдаемость (observability) — это суперсила дежурного инженера. Она превращает хаотичный поиск иголки в стоге сена в относительно детективный, но последовательный процесс. Где раньше царил стресс и беготня, теперь — методичный поиск по метрикам, логам, трейсам. Мы сократили MTTR на треть или даже больше, просто потому что перестали «тыкать пальцем в небо». Конечно, тут важна тренировка: мы регулярно упражнялись читать графики, делать dry-run инцидентов (устраивали учения – «что будешь делать, если…?»). Но результат того стоит: любой дежурный знает, что и где посмотреть, чтобы быстро поставить диагноз.
Кстати, отдельный лайфхак: мы научились соотносить метрики друг с другом. Например, алерт пришёл по просадке трафика (RPS резко упал) — сразу смотрим, не прыгнула ли одновременно ошибка 5xx или время ответа. Если да, это уже две подсказки, которые сужают круг причин. А если плюс к этому в логах появились сообщения о таймауте к Redis — картина совсем складывается. Эти связи мы фиксируем в runbook-ах: «Если алерт X, проверь метрику Y и лог Z». Постепенно накопилась целая матрица причинно-следственных связей, которая экономит драгоценные ночные минуты.
В итоге сейчас, когда случается инцидент, я даже чувствую небольшой азарт: смогу ли разгадать загадку быстрее, чем она начнёт влиять на пользователей? Это уже не паническая гонка, а скорее игра в расследование. А благодаря слаженному мониторингу, обычно загадки не слишком хитрые.
График дежурств: предсказуемость вместо хаоса
Отдельная большая тема – организация самих дежурств. Раньше у нас с этим была беда: дежурили “по умолчанию” всегда одни и те же (чаще всего я, как самый ответственный 😅). Никакого расписания, никаких ограничений – будь на связи 24/7, и точка. Естественно, долго так никто не протянет: через несколько месяцев я почувствовал все признаки выгорания.
Мы решили подойти к дежурствам так же системно, как и к техническим процессам. Составили расписание на месяц вперёд, где каждый инженер дежурит не более недели подряд. Неделя – максимальный срок, после которого человек начинает заметно уставать, поэтому ротация еженедельная. Некоторые команды делают смены короче (например, по 2-3 дня), но нам показалось неудобным часто переключаться. Баланс – ключевое слово: нагрузки распределяются равномерно между всеми. Если ты был на дежурстве на прошлой неделе, следующую, считай, свободен как птица. Это важно психологически: люди могут планировать личное время, зная, когда они on-call, а когда нет. Кто-то в отпуске или заболел? Мы заранее находим замену, чтобы никто не тянул лямку в одиночку.
Вместе с графиком появились и правила handoff – передачи дежурства. По окончании своей смены инженер делает короткий отчёт следующему: были ли за неделю инциденты, что по ним сделано, остались ли какие-то риски. Например: "В среду ночью падал сервис авторизации, применили хотфикс, но на следующей неделе планируется полноценный фикс – имей в виду". Такой knowledge transfer не даёт потеряться контексту, и новый дежурный не окажется в вакууме. Также убедились, что каждый дежурный имеет доступ ко всем нужным системам заранее (VPN, продовые логи, консолям облака и т.д.) – странно, но раньше про это могли забыть, и в разгар аварии выяснялось, что у инженера нет прав перезапустить сервис. Теперь у нас есть onboarding чек-лист: вступаешь на дежурство – проверь, что всё логинишься, ключи работают, доступы на месте.
Мы также настроили цепочки эскалаций. Если дежурный не откликнулся за N минут (вдруг проспал или телефон разрядился) – сигнал автоматически уходит его напарнику или тимлиду. У нас, к счастью, такого почти не бывало, но сам факт наличия второго рубежа придаёт уверенности: система не зависит от одного человека. Для критичных инцидентов прописали и план коммуникаций: кого уведомлять из менеджеров, кому писать в общий чат, когда созывать созвон. В пылу момента можно про это забыть, поэтому лучше иметь готовый шаблон действий (в runbook или отдельном регламенте).
Отдельно хочу сказать про режим 24/7. Если команда распределена по разным часовым поясам – идеально покрывать сутки без ночных дежурств (модель follow-the-sun). У нас команда в одном городе, поэтому полностью избежать ночных смен не получится. Но мы сделали хитро: ночью дежурит только один человек, остальные спят. Зато днём, если тревога случилась в рабочие часы, подключаются все, кому интересно/есть время. Таким образом, ночное бремя сведено к минимуму, а днём инциденты разбираются сообща, заодно обучая менее опытных коллег.
Важный момент – компенсации и благодарности. Ночные дежурства – штука тяжёлая, поэтому у нас завелось правило: после тяжёлой ночи (если пришлось просидеть пару часов с аварией) инженер может прийти на работу попозже или вообще взять отгул. Компания это вполне понимает: лучше дать человеку восстановиться, чем требовать от него сразу 8 часов продуктивности с красными глазами. Ну и мелочь, а приятно: если серьёзный инцидент успешно разрулен, тимлид или менеджер потом скажет «спасибо» лично или в чате. Казалось бы, пустяк, но такая поддержка очень помогает не выгореть. Чувствуешь, что твои старания ценят, а не считают «дежурство вне рабочего времени — само собой разумеется».
Командная культура: учимся на инцидентах, а не ищем виноватых
Самое главное открытие для меня – дежурства перестают быть страшными, когда в команде сформирована правильная культура вокруг инцидентов. В первые месяцы моей работы каждый сбой превращался в мини-драму: утро начиналось с того, что искали «кто вчера всё уронил?». Кто-то мог кинуть колкость типа «опять прод похерили, ну вы даёте…». От такой атмосферы, честно говоря, хотелось сбежать. Никто не любит, когда его делают козлом отпущения, тем более если ты всю ночь не спал, пытаясь спасти сервис.
Мы сознательно перестроили этот подход. Я уже писал о blameless postmortem в прошлой статье: мы отменили поиск виноватых и стали разбирать инциденты конструктивно. Каждое ЧП теперь – это не повод ткнуть пальцем, а возможность улучшить систему. Если ночью упало – на утреннем разборе спрашиваем «что поможет, чтобы впредь такого не было?» вместо «кто накосячил?». Такая атмосфера сильно снизила градус страха. Инженеры больше не боятся, что их ночью застукают на ошибке и устроят разнос. Наоборот, зная, что команда поддержит, дежурный чувствует себя увереннее.
Более того, мы сделали так, что инциденты стали учить команду. После каждого серьёзного случая мы обновляем документацию и runbook-и, проводим небольшой knowledge sharing. Например: «Вася починил сложный баг прошлой ночью – давайте он за чашкой чая расскажет, как вычислил причину». Это неформально, без презентаций – просто обмен опытом. Зато в следующий раз Петя или Маша при похожем алерте скажут: «А, я помню, Вася рассказывал про такой баг, надо логи базы посмотреть». Постепенно уровень общей осведомлённости растёт, а пресловутый bus factor падает ещё больше. Новым сотрудникам мы сразу говорим: «Не бойся терминов SLO, SLA, Error Budget – мы всему научим. Дежурства у нас есть, но мы тебя подготовим прежде чем бросать на амбразуру». Никакого дедовщины, одним словом.
Также мы интегрировали надежность в процессы разработки (SRE называет это production excellence). Это означает, что качество и стабильность – зона ответственности не только дежурного, но всей команды. Например, если регулярные ночные вызовы происходят из-за багов в коде или кривых релизов, мы приоритезируем задачи на исправление этого. Включаем их в спринт, ставим как полноценные юзерстори (с оценкой, дедлайном и ответственным). Таким образом, разработчики чувствуют ответственность: они знают, что если дежурного ночью разбудило их некачественное обновление, то завтра им самим надо это пофиксить. Никакой токсичности, просто прозрачные правила: сломал – почини, иначе кто же кроме нас? Зато и наоборот: дежурный, поймав ночной баг, оформляет его в задачу, и команда его не игнорирует, а берёт в работу. Это ломает порочный круг, когда on-call инженер страдает в одиночку ночью, а днём все делают вид, что ничего не случилось. Теперь все в одной лодке, и это ощутимо снизило напряжение.
И последнее: поддержка друг друга. У нас негласно принято, что если инцидент крупный, дежурный может дернуть любого из команды, даже среди ночи – и тому не прилетит негатив. Бывает, сам руководитель присоединяется на звонок в 4 утра, просто чтобы морально поддержать и помочь с коммуникацией. Такие моменты здорово сплачивают. Ты уже не один на один с аварией, а вместе с товарищем воюешь против падения сервиса. Зная это, лично мне гораздо спокойнее вступать в ночное дежурство: страха нет, потому что за спиной – вся команда и культура, где инциденты — это общая боль, а не моя личная проблема.
Epilogue: ночь, телефон, и ничего страшного
Прошло больше двух лет с тех пор, как я впервые заступил на дежурство с дрожью в коленках. Теперь, если честно, я воспринимаю ночные вызовы как обычную часть работы – ну, случается. Бояться тут нечего, если у тебя налажен процесс. Да, я по-прежнему не фанат вставать среди ночи – вряд ли это можно прям «полюбить». Но разница в том, что раньше каждый звонок PagerDuty был как удар молнии: адреналин зашкаливает, голова панически соображает «что делать?!». Теперь же в телефоне я вижу не ужас, а задачу: упало то-то – ок, у меня есть план. Я, как пожарный, знаю где мой огнетушитель и где выход. Более того, мы так снизили частоту инцидентов, что дежурства стали предсказуемыми. Иногда проходит несколько недель без единого ночного вызова — разве не мечта? В такие периоды я даже… скучаю 🙃.
Подводя итог, хочу выделить несколько главных мыслей, которые помогли мне перестать бояться алертов:
Превентивные меры и мониторинг. Лучше вложить силы днём, чтобы не ловить авралы ночью. Правильные метрики (золотые сигналы), адекватные пороги и никаких лишних оповещений – и вы спите значительно спокойнее.
Документация и runbook-и. Подготовь шпаргалки на все основные случаи. Ночью некогда сочинять план спасения – он должен ждать тебя заранее написанным. Runbook в три часа утра – как друг, который подскажет решение или хотя бы направит, куда копать.
Инструменты наблюдаемости. Инвестируй в графики, логи, трейсы. Чем лучше видна система, тем быстрее найдёшь причину сбоя. А быстро найти = быстро починить. Сокращение MTTR напрямую уменьшает стресс: когда знаешь, что в большинстве случаев всё решается за 15-30 минут, уже не так страшно проснуться по тревоге.
Чёткий процесс on-call. Введи расписание, ротации, правила реакций. Дежурство не должно быть стихийным бедствием, оно должно быть процессом. Все знают, кто сегодня на связи, что делать при инциденте, кто подхватит эскалацию. Предсказуемость убивает хаос, а вместе с ним и панику.
Командная культура. Это, пожалуй, самое важное. Убери токсичность и страх наказания. Сделай так, чтобы люди учились на ошибках, а не прятали их. Поддерживайте друг друга. Когда дежурный чувствует за спиной сплочённую команду, ни один звонок в ночи его не сломает.
Напоследок: на одной из встреч мой коллега пошутил, мол, “дежурства – это когда тебе платят за то, чтобы спать с телефоном под подушкой”. Доля правды в этом есть: сейчас, наладив все процессы, я действительно сплю ночью – пусть и с телефоном рядом – и чаще всего меня никто не будит. А если и раздастся сигнал – это уже не тот пугающий рёв сирены, а скорее будильник, напоминающий: «Вставай, дружище, время применять всё, чему ты научился». И я, протирая глаза, иду спасать мир (ну, или хотя бы наш сервис) с чувством, что ничего не выходит из-под контроля. Именно этого я и добивался, проходя путь от хаоса к порядку. Спокойных вам дежурств и поменьше аварий!
