GetNet

Если построить график, где по горизонтали — количество запросов в секунду (в тысячах), а по вертикали — latency, картина будет одинаковой почти для любой системы. Пример ниже снят на одной машине с 48 ядрами, но принципиально ничего не меняется, если машин несколько, если есть кластер или даже много кластеров. График тот же, отличаются только цифры.

Пока система не упирается в ядра, всё работает быстро: нагрузка распределяется по ядрам и по нодам кластера. Затем latency — время ответа на запрос пользователя — начинает расти. Сначала потихоньку, потом сильнее, потом ещё сильнее — до момента, когда с точки зрения пользователя система перестаёт работать вообще. Формально она отвечает, но отвечает так долго, что смысла в этом уже нет.

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

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

Воркер — это не абстракция, а HTTP-сервер и код на Go, PHP или Rust. Под ним — операционная система, база данных и десятки компонентов, которые в рамках одного доклада даже перечислить нельзя. И всё это исполняется на конкретных ресурсах: CPU, RAM, диск, сеть.

Внутри каждого ресурса — свой мир. Ядра, hyper-threading, context switching, NUMA-архитектура. В дисковой подсистеме — RAID с батарейкой и без, SSD, NVMe, а где-то до сих пор и шпиндели. Сеть — отдельная дисциплина со своей глубиной.

Все эти зависимости перекликаются между собой и периодически мешают друг другу работать. Задача получается совсем нетривиальной — поэтому и нужен мониторинг.

Мониторинг нужен для того, чтобы понять, в какой момент начинаются проблемы — желательно до того, как они начнутся. Условно он делится на три уровня.

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

Нагрузка не приходит сразу. Продукт проходит через несколько стадий: MVP → начальный рост → масштабирование → сокращение и оптимизация → следующий виток (новый MVP) или вывод сервиса из эксплуатации.

MVP
Быстрый старт, простой прототип, тестовая группа пользователей. Интересна ли на этом этапе стабильность? Разумеется, нет: если MVP упал — ничего страшного.
Но бывают исключения. Известен случай, когда команда сделала MVP, показала бизнесу, получила одобрение — и на две недели пропала обратная связь. MVP выключили. Через пять минут позвонил бизнес: «У нас ничего не работает». Оказалось, прототип поставили в продакшен как есть — сырым, без мониторинга — и пользователи уже вовсю им пользовались. Так делать не стоит.
Существует и отдельный класс MVP для нагруженных проектов, где кластеризация и масштабирование закладываются сразу. Но это уже другая история.

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

Масштабирование
Пользователей всё больше, данные растут, релизы новой функциональности летят пачками — компания растёт. Падение продакшена в этот момент становится очень дорогим, потому что бизнес хочет денег. ИТ существует не само по себе: бизнес платит зарплату и ставит задачи именно ради заработка.
Как понять, что этап масштабирования наступил? Формально — нефункциональные требования начинают превалировать над функциональными. Практический критерий проще: если релиз сломал продакшен, его никто не откатывает — его идут дебажить прямо на проде. Смотрят, что упало, что не упало, докручивают на месте. Если так происходит — нагрузка уже есть.

Нагрузка ли виновата?
Важно отличать проблемы роста от проблем компании как таковой. Есть несколько маркеров:

Сокращение и оптимизация
Задача снижения стоимости и резки косты — актуальная повестка буквально сегодня, и не только в России. Денег мало, работать нужно в ограниченных ресурсах.
По сути это те же самые проблемы роста, только наоборот: нужно запихнуть нагрузку в те рамки, которые можно позволить себе финансово. Финансы — это не только железо, но и софт: его тоже приходится оптимизировать и переделывать.
В благословенные годы с нулевых по 2016–2017 большинство проблем решались деньгами: закупить железо, поставить в продакшен, продакшен вырастал — и оптимизации становились неинтересны. Фреймворк на пять гигабайт ради одной странички? Ничего страшного, интернет быстрый. Сейчас это перестаёт работать: задача — уложить работающий продакшен в заданный объём финансирования. Это хорошая инженерная задача.
Проблема в том, что цена изменений велика:

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

Инженерная культура — вещь эфемерная, но именно она определяет, во что превратится продакшен под нагрузкой. Её признаки:

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

Всё это менеджмент должен видеть и убирать. Хуже, когда проблема в самом менеджменте: «у меня KPI, закрываем глаза, фигачим, а в следующем квартале разберёмся». Или когда за счёт компании решаются личные проблемы — человек получает метлу и двух помощников и начинает показывать, как делаются дела.

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

Даже когда бизнес чётко понимает, чего хочет, он может нанять яркого менеджера — обычно знакомого или человека, который где-то себя проявил. Здесь работает известный эффект: выбирают не тех, у кого всё работает (это скучные люди), а тех, кто героически преодолевает трудности. О таких пишут книги и посты, хотя достаточно было сразу сделать так, чтобы всё работало.

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

Позитивный пример из практики. Небольшая компания спросила: «А может, нам нужен Kubernetes?» Ответ был примерно такой: конечно, нужен. Причём собственный, а не managed — значит, сразу отдельная команда на поддержку, ФОТ ×2. Функционально он не нужен, зато технология хайповая: следующие два года — сплошные KPI и победы, продакшен за это время слегка деградирует, и года через два, возможно, вернётся к исходной точке. Kubernetes изначально делался Google под собственные задачи, и далеко не все компании такие же большие, как Google. Некоторые компании не имеют даже трёх дата-центров. С двумя дата-центрами справится любой — сложность начинается на тридцати. Компания подумала и решила: пока справляемся без Kubernetes. С адекватными людьми приятно работать.

Стабильность продакшена — вообще не техническая задача. Это задача бизнеса, потому что именно бизнес определяет, насколько она ему важна. И иногда стабильность не является приоритетом:

Когда компания растёт, идёт активный найм, и существующие связи рвутся.
Люди, которые несколько лет пилили в надежде на повышение, его не получают: на новый уровень проблематики берут человека, компетентного именно в этом уровне. А каждый следующий этап — это по факту новая компания с новыми проблемами. Отсюда уходы и разочарования.
Ломаются коммуникации. Если на этапе MVP или раннего роста три-четыре человека решали любой вопрос за чашкой кофе, то при десяти командах за чашкой кофе можно только выпить кофе. Нужны другие коммуникации — старые не работают, качество проседает.
Смена парадигмы компании сама по себе становится проблемой. Люди стремились к поставленным целям, достигли их — а потом всё поменялось, и возникает ощущение, что старались зря. Не зря: компания просто прошла очередной уровень, и теперь нужно решать другие задачи. Раньше писали красивые пользовательские сценарии — теперь важнее не упасть. Фокус сместился, ценности изменились, и это рождает разочарование. Результат — текучка. Приходят новые люди, смотрят на код предшественников и говорят, что с этим работать невозможно. А тем, для кого система была родной, она уже не нужна — они ушли.