# Мартин Мао: «Мониторинг не должен стоить столько же, сколько вся инфраструктура»

Источник: https://www.youtube.com/watch?v=XD1ImT0eCXY
Канал: Greylock
Опубликовано: 03.03.2023

---

В новом выпуске подкаста Grey Matter партнер фонда Greylock Джерри Чен беседует с основателями компании Chronosphere — Мартином Мао (CEO) и Робом Скиллингтоном (CTO). Стартап, выросший из внутренних разработок Uber (проекта M3), ставит своей целью переосмыслить мониторинг в эпоху облачных технологий (Cloud-Native). Участники обсуждают технические вызовы масштабирования, экономическую неэффективность старых инструментов и опыт построения корпоративной культуры в условиях глобальной пандемии.

## ☁️ Эволюция инфраструктуры: от виртуальных машин к Cloud-Native
[[JUMP:02:40]]

Джерри Чен отмечает, что за последние 15 лет индустрия прошла путь от простой миграции виртуальных машин в облако (Cloud Evolution) до создания полноценных облачных стеков (Cloud-Native) [02:53]. Если раньше облако воспринималось просто как «чужой дата-центр», то сегодня разделение хранения и вычислений, а также эластичность ресурсов привели к господству Kubernetes и микросервисов.

По определению Мартина Мао, архитектура Cloud-Native подразумевает использование микросервисов и контейнерной инфраструктуры [04:12]. Этот подход дает бизнесу огромные преимущества в скорости разработки, но требует принципиально иных инструментов мониторинга. Мао утверждает, что старые решения, созданные для эпохи монолитов и статичных виртуальных машин, попросту не справляются с динамикой современных систем [04:38].

Мартин Мао выделяет три критических изменения в требованиях к мониторингу:

*   **Масштабируемость данных:** Контейнеры производят в сотни раз больше метрик, чем старые ВМ, что требует систем, способных обрабатывать гигантские объемы данных в реальном времени [05:46].
*   **Географическая надежность:** Приложения теперь распределены по разным зонам доступности и регионам. Мониторинг должен соответствовать этому уровню отказоустойчивости, а не быть «единой точкой отказа» в одном регионе [06:59].
*   **Гибкость жизненного цикла:** Контейнеры эфемерны — они живут недолго. Система мониторинга должна уметь по-разному обрабатывать кратковременные данные для CI/CD и долгосрочные данные для планирования мощностей [08:16].

## 📈 Пять стадий «горя» и рождение проекта M3 в Uber
[[JUMP:09:31]]

Джерри Чен проводит аналогию: системные администраторы проходят через пять стадий принятия неизбежного (отрицание, гнев, торг, депрессия и принятие), когда осознают, что их старые инструменты мониторинга бесполезны в облачном мире [10:13]. 

Роб Скиллингтон вспоминает опыт Uber, где этот переход занял всего 4-5 лет [10:50]. Компания перешла от «голого железа» к тысячам контейнеров, и старые системы вроде Graphite или Nagios перестали работать. В Uber пытались «торговаться», пробуя адаптировать существующие решения, но в итоге пришли к необходимости создания M3 — распределенной базы данных временных рядов (Time Series Database) [12:08].

По словам Скиллингтона, ключевыми особенностями M3 стали:

*   **Горизонтальное масштабирование:** Система изначально проектировалась для работы на сотнях узлов [15:38].
*   **Потоковая агрегация метрик (Streaming Aggregation):** Это позволяет обрабатывать данные «на лету», не дожидаясь записи в базу, что критично при резком росте количества метрик [14:48].
*   **Декларативное управление:** Возможность задавать политики хранения данных так же просто, как описывать ресурсы в Kubernetes через YAML-файлы [14:09].

## 💸 Экономический тупик классического мониторинга
[[JUMP:20:24]]

Одной из главных проблем текущего рынка Мартин Мао называет несоответствие стоимости мониторинга и стоимости самой инфраструктуры [20:37]. 

Мартин Мао приводит показательный пример:

*   Содержание кластера Kubernetes из 10 узлов может стоить компании несколько десятков тысяч долларов в год.
*   При использовании традиционных инструментов (например, Datadog или Wavefront) мониторинг этого же кластера обойдется в ту же сумму [20:37].

По мнению Мао, это происходит из-за того, что старые вендоры тарифицируют каждую единицу данных одинаково, вне зависимости от её ценности [21:55]. Chronosphere предлагает подход, при котором пользователь сам решает, какие данные хранить долго, а какие агрегировать или удалять через несколько дней. По утверждению основателей, решение Chronosphere обходится клиентам в среднем в 10 раз (на порядок) дешевле аналогов [31:16].

## 🛠 Почему Data Warehouse и Prometheus не являются панацеей
[[JUMP:35:13]]

Роб Скиллингтон объясняет, почему для мониторинга нельзя использовать обычные хранилища данных (Data Warehouses) или Data Lakes [35:26]. Главная причина — задержка (latency). В мониторинге критически важно обнаруживать проблемы за секунды, чтобы успеть провести автоматический откат (rollback) софта [35:53]. Данные в Data Warehouse попадают с задержкой в минуты или часы, а запросы к ним выполняются слишком медленно для оперативного реагирования [38:20].

Что касается популярного инструмента Prometheus, то он, по мнению Роба, отлично подходит для старта, но быстро упирается в потолок при росте сложности системы [26:16]. Одиночные инстансы Prometheus становятся «силосными башнями» данных, которые сложно объединить в общую картину, и требуют содержания целой команды инженеров для поддержки работоспособности [29:07].

Chronosphere позиционируется как облачная надстройка, которая:

1.  Полностью поддерживает открытые стандарты (Prometheus, PromQL, Grafana) [33:01].
2.  Снимает с инженеров нагрузку по обслуживанию инфраструктуры мониторинга [33:29].
3.  Обеспечивает централизованный вид на все окружения без потери детализации [32:49].

## 💼 Кейсы: Tecton и крупные логистические сервисы
[[JUMP:40:41]]

Мартин Мао приводит два примера использования платформы:

1.  **Tecton (ML-платформа):** Компания родилась в облаке и использовала Prometheus. Однако инженеры тратили слишком много времени на «тушение пожаров» в самой системе мониторинга [45:32]. Переход на Chronosphere позволил им сохранить привычные дашборды в Grafana, но избавиться от операционных проблем и увеличить срок хранения данных с нескольких дней до нескольких месяцев [47:06].
2.  **Крупный сервис доставки в США:** Клиент столкнулся с резким ростом счетов от облачного вендора (Datadog/Wavefront) при переходе на микросервисы [48:36]. Использование Chronosphere позволило им получить контроль над расходами через прозрачные политики агрегации данных и избежать проблем «шумных соседей» благодаря изолированным ресурсам [49:43].

## 🏢 Культура, найм и VC-партнерство
[[JUMP:50:24]]

Основание компании в июле 2019 года означало, что активная фаза роста пришлась на пандемию COVID-19 [50:24]. Роб и Мартин подчеркивают, что их команда изначально была распределенной (офисы в Нью-Йорке и Сиэтле), что облегчило переход на удаленку [54:37].

Особое внимание в Chronosphere уделяется разнообразию (Diversity & Inclusion). Роб Скиллингтон отмечает, что это требует сознательных усилий и выделения ресурсов [58:36]. Натали, руководитель отдела технического рекрутинга, активно сотрудничает с организацией Anita B для привлечения женщин-инженеров в сферу инфраструктурного ПО [59:02, 1:00:08].

Говоря об отношениях с инвесторами, Мартин Мао признается, что выбирал партнеров на основе личного доверия, а не просто по размеру чека [1:12:36]. Он ценит, что Джерри Чен из Greylock глубоко погружен в дела компании и помогает решать проблемы, а не просто заслушивает отчеты на советах директоров [1:13:02].

Оба сооснователя сходятся во мнении, что запуск стартапа — это скорее эмоциональное решение, чем расчетливое [1:11:18]. Мао утверждает, что если бы он не попробовал превратить M3 в продукт именно сейчас, когда рынок Cloud-Native созрел, это стало бы главным сожалением в его жизни [1:07:19].

---