Состояние системы — это не только аптайм: признаки хрупкого стека

Почему аптайм может ввести в заблуждение

Аптайм говорит только об одном узком показателе: был ли система достаточно доступна, чтобы отвечать на запросы. Это важно, но не показывает, сколько усилий команда тратит, чтобы удерживать её в таком состоянии.

Сервис может показывать 99,9% аптайма и при этом каждый день доставлять проблемы. Такой показатель допускает около 43 минут простоя в месяц. Многие команды даже не доходят до этого лимита, но всё равно тратят часы на неустойчивые релизы, экстренные перезапуски, долгие поиски ошибок и ночные проверки после каждого выпуска.

Именно здесь начинает иметь значение состояние системы не только по аптайму. Клиенты видят работающий продукт и зелёную страницу статуса. Команда видит другую картину: один человек знает порядок перезапуска, скрипт деплоя, которому никто не доверяет, и очередь обращений в поддержку, которая растёт после небольших изменений.

Аптайм, который видят клиенты, и стресс, который чувствует команда, часто движутся в разные стороны. Сайт можно держать онлайн, просто бросая на проблему всё больше людей. Один инженер следит за логами на каждом релизе. Кто-то вручную исправляет плохие данные. Поддержка снова и снова объясняет одну и ту же проблему. Приложение остаётся «в строю», но стек хрупкий, потому что обычная работа зависит от постоянного ручного спасения.

Зелёная страница статуса тоже скрывает, насколько беспорядочными могут быть процессы. Она не показывает, занимают ли релизы 10 минут или 3 часа. Она не показывает, как часто команда откатывает изменения, вручную исправляет продакшен или откладывает обновления, потому что боится сломать что-то маленькое, но важное.

Представьте стартап с панелью, которая почти не падает. На бумаге он выглядит стабильным. На деле каждый релиз по пятницам собирает двух инженеров, одного человека из эксплуатации и основателя, который остаётся онлайн на всякий случай. Если в продакшен проскакивает ошибка входа, поддержка весь понедельник успокаивает раздражённых пользователей, пока команда вручную чистит данные. Аптайм остаётся высоким, но система так и не стала здоровой.

Здоровый стек делает рутинную работу скучной. Если каждое обычное изменение кажется рискованным, аптайм скрывает правду.

Как выглядит хрупкость в повседневной работе

Если вам важно состояние системы не только по аптайму, смотрите на то, что люди делают в день релиза. Хрупкий стек часто показывает клиентам хорошие цифры, а внутри команда ведёт себя настороженно.

Первый признак — задержки. Люди снова и снова переносят релизы на «завтра», потому что никто не доверяет даже маленькому изменению. Исправление бага ждёт спокойного часа, потом подходящего инженера, потом ещё кофе и план отката. Это и есть боль при релизах, даже если продакшен не падает.

Ещё один признак — скрытая память. Один человек знает точный порядок перезапуска, какой кэш очистить, какую задачу перезапустить и какая строка конфигурации ломает вход, если её сдвинуть. Когда этого человека нет на встрече, он спит или ушёл в отпуск, все остальные замедляются или замирают.

Ручная работа после релиза — ещё один тревожный сигнал. Кто-то обновляет несколько записей в базе, меняет одно значение конфигурации на одном сервере или ещё раз запускает скрипт «только в этот раз». Такие исправления кажутся мелкими, но они не оставляют чистого следа. Следующий релиз снова требует тех же спасательных действий, и никто уже не может уверенно сказать, какие из них всё ещё нужны.

Нагрузка на поддержку рассказывает ту же историю. После обычного релиза в почту поддержки сыпятся знакомые обращения: отчёт отображается неправильно, клиент не может завершить оформление заказа, настройка сбросилась сама. Каждое обращение само по себе несложное. Важен именно повторяющийся шаблон. Если поддержка после каждого изменения снова и снова отвечает на одни и те же вопросы, стек заставляет людей закрывать слабые места процесса вручную.

У небольшой SaaS-команды может быть 99,9% аптайма, и при этом она живёт именно так. Они выпускают обновления дважды в месяц, потому что релизы кажутся рискованными, старший инженер помнит ритуал перезапуска наизусть, а поддержка теряет полдня, убирая последствия после каждого деплоя. Панель показывает «всё хорошо». Рабочий день говорит об обратном.

Как проверить стек за одну неделю

Проверка за одну неделю скажет больше, чем блестящий график аптайма. Если команда выпускает изменения в стрессе, вручную чинит продакшен и полнедели отвечает на повторяющиеся жалобы, система не здорова.

Начните с фактов, а не с мнений. Возьмите последние 10 релизов из журнала выпусков, истории в чате или CI-системы. Отметьте каждый, после которого понадобился откат, срочное исправление или дополнительная уборка. Даже два-три проблемных релиза из 10 могут указывать на устойчивый шаблон.

Удобно делать это как короткий аудит:

• День 1: посмотрите последние 10 релизов и отметьте откаты, неудачные миграции и экстренные исправления.
• День 2: выпишите все ручные шаги в продакшене, которые люди всё ещё делают до, во время или после релиза.
• День 3: попросите поддержку назвать самые частые жалобы за последний месяц.
• День 4: сопоставьте дни релизов со всплесками тикетов и заметками об инцидентах.
• День 5: проследите один болезненный сценарий от релиза до финального исправления.

На ручные шаги стоит смотреть особенно внимательно. Команды часто считают их нормой, потому что один надёжный человек знает весь порядок. В этом и есть проблема. Если кому-то нужно вручную очистить кэш, запустить скрипт с ноутбука, изменить конфигурацию в продакшене или перезапустить процесс в полночь, всё может развалиться в тот момент, когда этого человека нет рядом.

Данные поддержки дают ещё один слой понимания. Просите не самые громкие единичные сбои, а повторяющиеся жалобы. Ищите закономерности: проблемы с входом после релизов, медленные страницы по понедельникам утром, дублирующиеся письма или отчёты, которые не проходят под нагрузкой. Эти проблемы могут не влиять на аптайм, но они всё равно вредят клиентам и выматывают команду.

Потом сопоставьте даты релизов со всплесками обращений и заметками об инцидентах. Простая временная линия часто быстро показывает правду. Возможно, аптайм весь месяц оставался высоким, но каждый релиз по четвергам приносил всплеск тикетов и два часа уборки. Это не стабильная система. Это система, которая выживает за счёт дополнительной работы людей.

Завершите проверку, проследив один болезненный сценарий от начала до конца. Возьмите что-то обычное, например релиз, который ломает поиск и требует трёх человек для исправления. Пройдите путь от слияния кода до релиза, алерта, тикета поддержки, диагностики, патча и ответа клиенту. Обычно на этом пути находится одно слабое место, из-за которого проблема повторяется снова и снова.

Вот и есть состояние системы не только по аптайму. Верхнеуровневый показатель может выглядеть нормально, но неделя вокруг него показывает, как стек ведёт себя на самом деле.

Боль при релизах говорит правду

Стек может оставаться онлайн и всё равно наказывать команду каждый раз, когда она выпускает изменения. Если смотреть только на аптайм, такую боль легко не заметить. Работа с релизами показывает, спокоен ли система или держится на осторожности.

Начните с одного простого числа: сколько времени занимает обычный релиз от «готово к выпуску» до «вышло и проверено». Пропустите редкие большие миграции. Измеряйте обычный релиз. Если маленькое исправление занимает три часа, проходит через две цепочки согласований и ночной звонок, стек хрупкий, даже если пользователи не видели сбоя.

Потом посмотрите, сколько людей участвует в каждом релизе. Один инженер с понятными шагами — это нормально. Четыре человека в чате, которые просто ждут, когда нужно будет реагировать, — уже нет. Когда релизу нужны backend-разработчик, специалист по эксплуатации, QA и руководитель, процесс держится на общей памяти. Люди становятся частью системы деплоя.

Посчитайте события вокруг релизов за месяц:

• откаты после релиза
• срочные исправления в течение следующих 24 часов
• заморозка релизов перед пиковыми периодами
• перенос изменений на специальные окна обслуживания

Одна-две плохие недели возможны. Проблема — это повторяющийся шаблон. Заморозка релизов говорит даже больше, чем инциденты. Если команда избегает выкатывать изменения перед демо, запуском биллинга или понедельником утром, она уже знает, что система может преподнести сюрприз.

Небольшие изменения не должны требовать церемоний. Если правка одного поля формы или изменение одного ответа API должно ждать ночного окна, вы платите скрытый налог за каждую функцию. Работа над продуктом замедляется. Поддержка получает больше обращений. Инженеры перестают что-то улучшать, потому что каждое изменение кажется рискованным.

Хорошие релизы скучны. Разработчик выпускает изменения в рабочее время, проверяет логи и ошибки и идёт дальше. Если обычные правки всё ещё требуют аварийной комнаты, сначала исправьте процесс релиза, а уже потом доверяйте цифре аптайма. Более маленькие релизы, более сильные тесты, понятные шаги отката и лучшая автоматизация деплоя обычно делают для реального состояния системы не только по аптайму больше, чем ещё один месяц красивых цифр на панели.

Ручные исправления добавляют скрытый риск

Система может оставаться онлайн только потому, что люди постоянно её спасают. На панели это всё равно считается аптаймом. Но это не значит, что стек здоров.

Начните с обычной недели. Попросите команду записать все задачи в продакшене, которые они делают вручную, даже самые мелкие, к которым уже перестали присматриваться. Включите очистку кэша, перезапуск сервисов, повторный запуск задач и прямое редактирование базы данных, чтобы исправить плохие записи.

Список очень быстро становится неудобным. Часто оказывается, что один инженер знает правильный порядок шагов, правильный сервер и единственную команду, которая «обычно помогает». Если этого человека нет, он спит, в отпуске или ушёл из компании, исправление уходит вместе с ним.

Что стоит отметить в первую очередь

Некоторая ручная работа безвредна. Некоторая — тревожный знак.

• Один и тот же человек каждую неделю выполняет один и тот же шаг восстановления
• Исправление живёт в старых сообщениях Slack или в скопированных shell-командах
• Кто-то перезапускает сервис после большинства релизов
• Команда правит данные напрямую в продакшене, чтобы исправить проблемы пользователей
• Поддержка знает обходной путь раньше, чем инженерная команда устраняет причину

Скопированные команды заслуживают особого недоверия. Скрипт на одном ноутбуке — это не настоящая автоматизация, если никто другой не может безопасно его запустить. Настоящую автоматизацию легко найти, легко повторить и легко понять, что именно она меняет.

Небольшой стартап может показывать 99,9% аптайма и при этом иметь хрупкий технологический стек. Представьте релиз, который каждый раз требует, чтобы один инженер очистил кэш, перезапустил процессы в правильном порядке и вручную исправил две записи. Пользователи могут никогда не увидеть полный простой, но команда платит за эту стабильность стрессом, задержками и скрытой нагрузкой на поддержку.

Поэтому состояние системы не только по аптайму так важно. Верхнеуровневая цифра остаётся красивой, а ручные исправления накапливаются за ней.

Запишите все повторяющиеся ритуалы в продакшене за неделю. Потом отсортируйте их по частоте и ущербу. В первую очередь уберите те, что происходят часто. Даже два-три ручных исправления меньше способны заметно снизить боль при релизах и сделать весь стек спокойнее.

Нагрузка на поддержку показывает то, чего не видно на панели

Сервис может показывать 99,95% аптайма и при этом доставить клиентам тяжёлую неделю. Страница статуса выглядит спокойно, а вот почта поддержки рассказывает совсем другую историю.

Начните с релизов. После каждого деплоя посчитайте, сколько тикетов приходит в ближайшие несколько часов и на следующий день. Для этого не нужна сложная аналитика. Простого журнала релизов рядом с количеством тикетов часто достаточно, чтобы быстро увидеть закономерность.

Если каждый релиз приносит всплеск обращений, система не так здорова, как подсказывает число аптайма. Пользователи могут по-прежнему заходить на сайт, но сталкиваются со сломанным входом, неудачными платежами, медленными страницами или записями, которые не появляются там, где должны.

Полезно группировать жалобы в несколько простых категорий. Большинство команд могут разделить их так:

• вход и доступ к аккаунту
• проблемы с оплатой и оформлением заказа
• медленные страницы или таймауты
• отсутствующие или задерживающиеся данные

Такие группы показывают, где трение возвращается снова и снова. Один тикет по оплате может быть случайностью. Двадцать тикетов по оплате после трёх релизов говорят о более глубокой проблеме.

Следите и за повторяющимися обходными путями. Команды поддержки обычно знают их наизусть: очистите кэш, выйдите из аккаунта и войдите снова, обновите страницу дважды, повторите попытку через десять минут, попросите нас исправить это вручную. Когда поддержка снова и снова отправляет один и тот же ответ, команда закрывает собой проблему продукта.

Это повторяющееся ручное вмешательство создаёт издержки в местах, которые панели почти не измеряют. Поддержка тратит больше времени на каждый тикет. Инженеров отвлекают на мелкие исправления. Клиенты теряют доверие, даже если официальная цифра аптайма остаётся высокой.

Небольшой пример делает это особенно заметным. Представьте SaaS-продукт с 99,9% аптайма за прошлый месяц. Звучит неплохо. Но если каждый релиз по пятницам приносит 30 тикетов о проблемах со входом и отсутствующих данных по счетам, пользователи три-четыре раза за тот же месяц получали плохой опыт. Они не помнят график аптайма. Они помнят, что не смогли завершить работу.

Если вам важно состояние системы не только по аптайму, сравнивайте объём тикетов с числом аптайма каждый месяц. Когда аптайм остаётся высоким, а нагрузка на поддержку растёт, система может быть доступна на бумаге и хрупка на практике.

Простой пример для стартапа

Возьмём небольшой SaaS с несколькими тысячами платящих пользователей. В отчёте по статусу указано 99,95% аптайма за весь квартал. Основателям нравится эта цифра, и на бумаге стек выглядит здоровым.

Повседневная реальность ощущается иначе.

Команда перестала выкатывать релизы по пятницам после пары неудачных ночей. Ничего не падало на часы, но два релиза создали достаточно проблем, чтобы все изменили привычки. Теперь изменения выпускают в начале недели, внимательно следят за логами и стараются не трогать биллинг перед выходными. Это и есть боль при релизах, даже если аптайм остаётся высоким.

Поддержка видит ещё один шаблон. Каждый раз, когда компания меняет тариф, правило купона или сценарий продления, небольшая группа клиентских аккаунтов застревает. Люди не могут перейти на другой тариф, счета не совпадают с доступом или отменённый тариф остаётся активным. Поддержка вручную сбрасывает эти аккаунты один за другим после каждого изменения в биллинге. Публичная панель по-прежнему горит зелёным.

Есть и скрипт. Один инженер написал его несколько месяцев назад, чтобы исправлять записи, когда данные биллинга и права аккаунта расходятся. Он запускает его вручную, когда появляется несоответствие. Остальные не любят к нему прикасаться, потому что он правит живые данные, почти не документирован и вырос методом проб и ошибок. Если его нет, проблема ждёт.

Этот стартап не падает очень часто. Он хрупок более тихими способами. Релизы заставляют людей нервничать. Поддержка несёт на себе уборку, которая никогда не появляется в отчётах об аптайме. Один человек держит решение, от которого зависит команда, но которым нельзя безопасно делиться.

Вот почему состояние системы не только по аптайму так важно. Сильному стеку не нужны удачный тайминг, ручные сбросы и один инженер с личным спасательным скриптом. Если компании нужны все три вещи, чтобы удерживать число высоким, это число рассказывает только часть истории.

Ошибки, которые команды совершают из-за аптайма

Высокий аптайм может заставить слабую систему выглядеть здоровой. Команды видят 99,9% и думают, что сложные части под контролем, даже если каждый релиз кажется рискованным, а каждый инцидент требует вмешательства человека.

Одна распространённая ошибка — сначала гнаться за более высоким целевым аптаймом, а уже потом чинить боль при релизах. Если релизы занимают часы, требуют особого времени или зависят от одного старшего инженера, стек уже хрупкий. Более чистый процесс релиза обычно полезнее для пользователей, чем переход с 99,9% до 99,95% на бумаге.

Ещё одна ошибка — считать ночные подвиги нормальной работой. Когда кто-то снова и снова спасает ситуацию в час ночи, менеджеры могут назвать это самоотдачей. Обычно это предупреждение. Если команде постоянно нужна спасательная работа, система зависит от памяти, удачи и нескольких уставших людей.

Команды также считают простои, но игнорируют усилия на восстановление. Приложение может оставаться онлайн, пока инженеры перезапускают задачи, чистят зависшие очереди, вручную правят данные или дежурят у релиза до рассвета. Пользователи могут никогда не увидеть полный простой, но бизнес всё равно платит за проблему потерянным сном, более медленной работой и большим количеством ошибок.

Нагрузка на поддержку обесценивается по той же причине. Руководители слышат: «приложение оставалось онлайн», — и идут дальше. А поддержка тем временем разбирает двойные списания, пропавшие письма, неудачные импорты или страницы, которые технически загружаются, но не доводят дело до конца. Пользователям всё равно, что сервер ответил, если им всё ещё нужна помощь, чтобы выполнить базовую задачу.

Простой пример делает это особенно заметным. Стартап выпускает релиз каждую пятницу вечером. Сайт остаётся доступным, поэтому график аптайма выглядит нормально. Но каждый релиз вызывает баги с входом у небольшой группы пользователей, поддержка весь понедельник разгребает тикеты, а один инженер вручную исправляет данные в базе. Это не стабильность. Это скрытая хрупкость.

Более полезная проверка добавляет рядом с аптаймом несколько цифр:

• неудачные релизы или релизы с откатом
• ночные обращения по срочным вопросам
• ручные исправления в неделю
• тикеты поддержки, связанные с релизами
• время, которое инженеры тратят на восстановление после инцидентов

Именно здесь состояние системы не только по аптайму становится действительно полезным. Аптайм показывает, ответило ли приложение. Эти другие сигналы показывают, сколько усилий это потребовало, сколько стресса впитала команда и сможет ли стек расти без постоянной заплаточной работы.

Короткая проверка здоровья

Стек может показывать 99,9% аптайма и при этом выматывать команду. Быстрая проверка лучше очередной панели. Вам нужно понять, ощущается ли обычная работа спокойно или хрупко.

Начните с самого простого теста. Дайте новому инженеру небольшое исправление бага и только письменные шаги. Если он может безопасно выпустить его за один проход, процесс в неплохом состоянии. Если он упирается в недостающую настройку, скрытые скрипты или знания, которые живут только в головах, риск уже есть.

Потом посмотрите на откат. После неудачного релиза команда может вернуться к последней рабочей версии за несколько минут или все бросают дела и начинают гадать? Понятный путь отката обычно означает, что команда готовилась к сбою. Паника обычно означает, что боль при релизах пряталась за красивым числом аптайма.

Проверьте привычки в продакшене за последние семь дней. Если кто-то менял конфигурации, правил данные, перезапускал задачи или вручную редактировал живые системы, запишите это. Одно ручное исправление может казаться безобидным. Серия ручных исправлений означает, что стек зависит от памяти и удачи.

Поддержка говорит очень прямо. После обычных релизов пользователи открывают тикеты из-за того, что должно было оставаться стабильным? Сюда входят проблемы со входом, сломанные формы, медленные страницы, пропавшие письма или странные крайние случаи, которые появляются каждую пятницу после выката. Панели могут быть зелёными, пока нагрузка на поддержку растёт.

Есть ещё один очень важный тест. Посмотрите, что происходит, когда один нестабильный сервис начинает тормозить или падает. Если поиск, биллинг, авторизация или фоновые задачи могут потянуть за собой весь продукт, у системы есть хрупкое ядро. Здоровые системы ограничивают масштаб проблемы.

Помогает быстрый счёт. Отметьте каждую область как да, нет или не уверен.

• Новый инженер может выпустить небольшое исправление по письменным шагам
• Команда может откатить релиз за несколько минут
• На этой неделе никто не правил продакшен вручную
• Обычные релизы не вызвали рост пользовательских тикетов
• Один упавший сервис не может нарушить работу всего продукта

Если два или три ответа выглядят сомнительно, считайте это задачей на этот месяц. Так вы получите гораздо более ясную картину состояния системы не только по аптайму, чем даёт верхнеуровневый показатель.

Что делать дальше

Команды обычно добиваются большего с короткой ежемесячной таблицей показателей, чем с большим планом переписывания всего подряд. Если аптайм выглядит нормально, но работа даётся тяжело, начните измерять нагрузку вокруг системы, а не только количество простоев.

Выберите три показателя кроме аптайма и смотрите на них каждый месяц. Сделайте их простыми, чтобы команда могла отслеживать их без споров:

• время от согласованного изменения до попадания в продакшен
• количество ручных шагов в обычном релизе
• тикеты поддержки, связанные с одним и тем же сценарием или функцией

Эти три числа показывают, становится ли поставка проще или сложнее. На практике это и есть состояние системы не только по аптайму. Сервис может оставаться онлайн и при этом каждую неделю сжигать часы на медленные релизы, повторяющиеся исправления и нагрузку на поддержку.

Не пытайтесь убрать все слабые места сразу. Начните с одной ручной задачи в продакшене, которую люди повторяют часто. Это может быть изменение базы данных, выполненное вручную, обновление конфигурации через копипасту или релизный чеклист, который понимает только один человек. Автоматизируйте эту одну задачу, опишите её и убедитесь, что её сможет запустить кто-то ещё.

Потом выберите один процесс, который создаёт слишком много обращений в поддержку, и исправьте его от начала до конца. Не чините только симптом и не переходите дальше. Если сброс пароля, создание счёта или онбординг клиента снова и снова отправляет людей в поддержку, пройдите весь путь и уберите поломку, из-за которой тикет повторяется.

Такая работа менее эффектна, чем полная перестройка, но она быстро окупается. Один исправленный шаг в релизе может сэкономить 20 минут на каждом деплое. Один починенный клиентский процесс может уменьшить шум в поддержке каждый день.

Если вашей команде нужен взгляд со стороны, Oleg Sotnikov может проверить здоровье стека, боль при поставке и практические исправления, которые сначала снизят риск. Хорошая проверка должна оставить вам короткий список, понятных ответственных и изменения, которые можно сделать уже в этом месяце.

Когда время релиза сокращается, ручной работы становится меньше, а шум в поддержке падает, ваш показатель аптайма наконец начинает значить гораздо больше.