Что такое инфраструктурный продукт
Что проверяют
Понимаете ли вы разницу между внутренним сервисом и продуктовым подходом к инфраструктуре. Вопрос почти всегда означает платформенную команду: у такого продукта пользователь не клиент компании, а соседняя команда разработки, и это меняет и приоритеты, и способ измерять успех.
Как отвечать
Инфраструктурный продукт это система, которой пользуются другие инженеры: хранилище, очередь, внутренняя платформа запуска, сервис конфигурации, общая библиотека логирования и трассировки, конвейер сборки. От просто внутреннего сервиса его отличает жизненный цикл продукта:
- спрос вместо приказа: команды могут остаться на своём решении, и добровольный переход и есть проверка полезности;
- контракт: публичный интерфейс, лимиты, SLO, политика совместимости и срок депрекации;
- онбординг: документация, примеры, время от желания до первого успешного вызова;
- осознанный отказ от фич: попытка закрыть все случаи сразу обычно топит платформу.
Успех измеряют принятием (доля команд и доля трафика), числом обращений в поддержку на пользователя, соблюдением SLO и стоимостью владения.
Для Go такой продукт почти всегда приезжает к пользователю клиентской библиотекой, и она тоже часть контракта: безопасные значения по умолчанию (таймауты, повторы с разбросом), проброс контекста с отменой, аккуратная обёртка ошибок, встроенные метрики и трассировка. Сам пользователь их не добавит.
Где спотыкаются
Перечисляют технологии и ни слова не говорят о пользователях. Инфраструктурный продукт определяется не стеком, а тем, что у него есть потребитель внутри компании и обязательства перед ним.
Считают, что своим ломать совместимость можно: поменяли семантику флага, выкатили несовместимый клиент. Чужая миграция стоит человеко-месяцев, поэтому депрекация с переходным периодом это часть продукта, а не бюрократия.
Не могут назвать признак успеха. Если соседние команды продолжают держать свои велосипеды, платформы нет, есть ещё один сервис, который кто-то должен сопровождать.