API-управление внутри компании: зачем это нужно, когда вас больше трёх команд
Когда компания вырастает до нескольких продуктовых команд, внутренние интеграции начинают создавать проблемы. Почему это происходит и как с этим работать.
Есть определённый размер компании, после которого внутренние интеграции начинают создавать больше проблем, чем решают. Обычно это происходит где-то между второй и четвёртой продуктовой командой. До этого момента всё держится на знании - "Петя знает, как это работает, спросите у него". После - это уже не работает.
Я видел это достаточно часто, чтобы сказать: это не проблема конкретных людей или конкретного стека. Это структурная проблема роста. И она решается не тем, что вы нанимаете больше людей, которые "знают как это работает".
Что начинает ломаться
Первый симптом - каждая новая интеграция между системами становится отдельным переговорным процессом. Команда A хочет данные от команды B, команда B говорит "мы сделаем, но у нас спринт забит, подождите". Через месяц команда A сделала обходное решение, которое обращается напрямую к базе данных команды B, минуя любой API.
Второй симптом - появляются "неофициальные" API. Кто-то в команде B заметил запрос к базе, написал быстрый эндпоинт "для внутреннего использования", ничего не задокументировал. Теперь три команды зависят от этого эндпоинта, и никто не знает, что будет, если его убрать.
Третий симптом - обновление одной системы ломает другую. Не потому что никто не думал, а потому что не было никакого механизма для отслеживания зависимостей.
Что такое API governance внутри компании
Это не бюрократия и не отдел, который согласовывает каждый запрос. Это набор соглашений и инструментов, которые позволяют командам интегрироваться друг с другом предсказуемо.
Минимальный набор, с которого обычно имеет смысл начать:
Реестр API. Где живут все внутренние API, что они делают, кто их владелец. Это может быть простой документ или wiki - главное, что он есть и актуален.
Версионирование. Если API меняется несовместимым образом, потребители должны об этом узнать заранее. Это соглашение, а не техническая магия.
Явный владелец. У каждого внутреннего API есть команда-владелец, которая несёт ответственность за его работоспособность. Не "все знают", а конкретная команда.
Процесс изменений. Как сообщается о планируемых изменениях, какой период уведомления, как потребители выражают зависимость.
Почему это важно для бизнеса, а не только для инженеров
Каждый раз, когда интеграция ломается непредсказуемо, это стоит денег и времени. Каждый раз, когда команда не может быстро понять, от чего зависит система, которую она хочет изменить - задача затягивается.
Внутренняя API-дисциплина - это не про технологию. Это про скорость, с которой компания может менять свои системы, не боясь сломать соседей. Это про способность делать небольшие, уверенные изменения, а не большие, рискованные.
Когда начинать
Обычный совет - начинать тогда, когда боль уже есть, но ещё не катастрофическая. Если вы уже потеряли несколько инцидентов из-за сломанных интеграций или несколько недель на распутывание зависимостей - самое время.
Несколько вопросов, которые помогут оценить зрелость:
- Можете ли вы за пять минут ответить, какие системы зависят от конкретного вашего сервиса?
- Есть ли у вас хотя бы список всех внутренних API с явным владельцем?
- Если команда меняет формат ответа - как об этом узнают потребители?
- Сколько раз за последние полгода обновление одной системы неожиданно сломало другую?
Отсутствие внутреннего API-управления не убивает компанию на раннем этапе. Но оно замедляет её именно тогда, когда скорость начинает иметь значение.