Всё началось с вопроса, который не имел никакого отношения к серверам: может ли молоко в большом чане с одного края уже скиснуть, а с другого всё ещё оставаться свежим?
Как бытовая задача этот вопрос довольно быстро теряет смысл. Молоко перемешивается, температура выравнивается, бактерии распространяются, поэтому чёткой границы между «свежим» и «скисшим» почти наверняка не будет.
Но меня зацепило другое: в какой момент система становится уже другой системой?
Снаружи молоко какое-то время выглядит прежним. Внутри меняется кислотность, идут химические и биологические процессы, перестраивается структура. Потом наступает момент, после которого свойства продукта меняются качественно.
Так разговор о молоке привёл меня к фазовым переходам. А от них — к IT-инфраструктуре и идее PhaseShift.
Зелёная панель ещё не доказывает устойчивость
Работая со сложными системами, я привык смотреть на текущее состояние.
Процессор не перегружен. Памяти хватает. Ошибок мало. Задержки укладываются в норматив. Очереди не переполнены, база отвечает, на панели всё зелёное.
Это важная информация. Но она не отвечает на вопрос, насколько хорошо система выдержит следующее небольшое возмущение.
Представим два одинаковых контура. У них одна нагрузка, близкие показатели CPU и примерно одинаковое время ответа. Затем входящий поток ненадолго возрастает.
Первый контур возвращается к обычному режиму за пять секунд, второй — за сорок. Через месяц первый по-прежнему восстанавливается быстро, а второму уже требуется полторы минуты. При этом привычные метрики всё ещё могут оставаться в допустимых пределах.
На обычном dashboard системы выглядят одинаково. По характеру реакции это уже две разные системы.
Меня интересует именно этот разрыв: метрики ещё говорят «норма», но способность справляться с изменениями уже ухудшается.
Смотреть не только на состояние, но и на реакцию
Классический мониторинг отвечает на вопрос: «Что происходит сейчас?»
PhaseShift должен добавить к нему другой: «Как система реагирует на происходящее и как эта реакция меняется со временем?»
В живой инфраструктуре постоянно возникают небольшие возмущения. Растёт поток запросов, замедляется сервис, увеличивается задержка базы, появляется короткая очередь, перезапускается процесс или на несколько секунд ухудшается сеть. Само по себе такое событие ещё не авария.
Для анализа важна вся последовательность:
возмущение → отклик → распространение → восстановление
Насколько сильно система отклонилась от обычного режима? Сколько компонентов затронуло изменение? Усилилась проблема по дороге или затухла? Появились ли повторные запросы? Когда исчезла очередь? Сколько времени заняло восстановление?
И главное: как ответы на эти вопросы меняются от недели к неделе.
| Традиционный мониторинг | Анализ устойчивости |
|---|---|
| Показывает текущее значение метрики | Измеряет реакцию на изменение |
| Сравнивает значение с порогом | Сравнивает похожие эпизоды между собой |
| Фиксирует уже возникшее отклонение | Ищет изменение характера восстановления |
| Отвечает «что сейчас не так» | Помогает понять, уменьшается ли запас устойчивости |
Я не хочу заменить мониторинг ещё одной панелью. Задача в том, чтобы добавить новый слой наблюдения поверх уже существующих инструментов.
Почему меня заинтересовало время восстановления
В теории динамических систем есть явление, которое называют critical slowing down, или критическим замедлением. При приближении к критическому состоянию некоторые системы медленнее возвращаются к равновесию после небольших воздействий.
Серверный кластер, конечно, не чан молока и не термодинамическая система. Нельзя просто взять физическую формулу и объявить, что теперь она предсказывает аварии в Kubernetes. Это было бы эффектно, но бездоказательно.
Полезна сама постановка вопроса.
У инфраструктуры есть обычный режим работы. Есть естественные возмущения, отклик и скорость возвращения к исходному состоянию. Есть чувствительность к размеру воздействия и распространение реакции между зависимыми компонентами.
Если после похожих событий восстановление занимало семь секунд, затем девять, двенадцать и двадцать, это стоит исследовать. Возможно, это ранний признак снижения устойчивости, а возможно, обычный шум. Разницу нужно доказывать экспериментально.
Мне нравится, что эта гипотеза проверяема. Можно построить стенд и последовательно уменьшать пул соединений, увеличивать задержку зависимого сервиса, ограничивать ресурсы или усиливать конкуренцию за блокировки. Затем смотреть, какие характеристики меняются до явного отказа и повторяется ли этот эффект на разных системах.
Единицей анализа становится эпизод
Если просто собрать ещё больше метрик, получится ещё одна система мониторинга. Таких систем уже достаточно.
Поэтому базовой единицей анализа я считаю законченный эпизод поведения.
Например, входящий поток вырос на 15 процентов. Через секунду увеличилось время ответа одного сервиса. Ещё через две секунды стало больше соединений с базой, затем начала расти очередь и появились повторные запросы. Поток уже вернулся к норме, а очередь исчезла только через сорок секунд.
Такой эпизод можно сравнить с десятками похожих случаев в прошлом. Тогда виден не только пик конкретной метрики, но и то, стала ли система реагировать сильнее, распространяется ли возмущение дальше и требуется ли ей больше времени на восстановление.
Здесь появляются три полезных направления измерения.
Время восстановления
Сколько времени проходит между окончанием возмущения и возвращением системы к обычному режиму. Важно не отдельное значение, а его тренд для сопоставимых событий.
Чувствительность
Одинаковое воздействие может со временем вызывать всё более сильную реакцию. Если рост нагрузки на 10 процентов раньше увеличивал latency на 5 процентов, а теперь на 20, система стала чувствительнее, даже если оба значения пока не пересекли аварийный порог.
Распространение
Небольшое замедление базы в устойчивом контуре быстро затухает. В менее устойчивом оно приводит к накоплению соединений, retries, дополнительной нагрузке и новым очередям в соседних сервисах. Локальное событие превращается в цепную реакцию.
Наблюдать без переписывания приложений
Я хочу начать с пассивного наблюдения. Инфраструктура и без искусственных экспериментов каждый день переживает множество небольших изменений. Сначала нужно научиться находить их и корректно измерять ответ.
Базовая схема PhaseShift предполагает небольшие агенты на серверах и центральный аналитический контур внутри инфраструктуры заказчика. Агенты наблюдают за операционной системой, процессами, ресурсами и сетевыми соединениями. Для этого не требуется переписывать приложения и обязательно встраивать библиотеку в каждый сервис.
По наблюдаемым взаимодействиям можно постепенно восстановить фактическую карту зависимостей. Не ту схему, которую однажды нарисовали в документации, а живую структуру: кто с кем общается, где меняется время ответа, как возникают очереди и по какой цепочке распространяется возмущение.
Интеграции с базами данных, оркестраторами, брокерами сообщений и существующим мониторингом могут обогатить картину. Но базовая ценность должна появляться раньше, уже из системной, процессной и сетевой телеметрии.
Для такого продукта on-prem развёртывание выглядит естественно. Внутренние адреса, топология, процессы и служебная телеметрия остаются в контуре компании. Анализ выполняется там же, без обязательной отправки данных наружу.
Индекс без объяснения бесполезен
Рано или поздно появится соблазн свести всё к одному числу: например, показать индекс устойчивости 82 из 100.
Красивое число нарисовать легко. Гораздо труднее объяснить, откуда оно взялось.
Если PhaseShift сообщает о снижении устойчивости, инженер должен иметь возможность пройти от общей оценки к фактору, компоненту, событию и исходным наблюдениям. Например, увидеть, что время восстановления выросло, одинаковое возмущение стало затрагивать больше сервисов, а характер реакции изменился после конкретного выпуска.
Без такой трассировки индекс останется гаданием. С ней он может стать рабочим инженерным ориентиром.
Чего я пока не знаю
Сейчас PhaseShift — продуктовая и исследовательская гипотеза. Я ещё не могу честно сказать, что существует универсальная формула, которая заранее обнаружит значительную часть будущих аварий.
Возможно, первая модель окажется неверной. Вторая тоже. Может выясниться, что единого индекса не существует и для разных классов систем нужны разные модели. Или что часть красивых ранних признаков исчезает при проверке на реальной инфраструктуре.
Так и должна выглядеть исследовательская работа. Мне предстоит построить экспериментальный контур, создавать контролируемые ухудшения, собирать данные и отбрасывать признаки, которые убедительно выглядят только на отдельных примерах.
Активные пробы тоже возможны: короткий импульс нагрузки, небольшая задержка или временное ограничение ресурса. Но начинать с них рано. Сначала пассивная модель должна доказать, что умеет находить полезный сигнал в естественном поведении системы.
И всё-таки при чём здесь молоко
Чан с молоком остался хорошей метафорой не потому, что IT-инфраструктура подчиняется тем же физическим законам.
Внутри системы уже могут идти процессы, которые меняют её поведение, пока снаружи она выглядит прежней. Поэтому вопрос остаётся тем же: можно ли заметить приближение качественного изменения раньше, чем оно станет очевидной аварией?
Я собираю PhaseShift, чтобы проверить эту гипотезу на практике. Следить за развитием проекта можно на phaseshift.tirobots.ru.
Если вы отвечаете за сложную инфраструктуру и хотите проверить подход на реальных сценариях отказа и восстановления, напишите мне. Мне особенно интересны системы, в которых обычный мониторинг показывает норму, а инженеры уже чувствуют, что контур стал восстанавливаться хуже.
