Короткий ответ
#Что это такое
- Карта интеграций
- Запись о внешних интерфейсах, которые система использует и предоставляет: какой компонент с каким внешним сервисом разговаривает, в каком направлении, через какой интерфейс и ради чего, — вместе с тем, что о каждом из них установить не удалось.
- Если проще Всё вне вашей программы, что вашей программе нужно, чтобы работать, и то, как она до каждого из них дотягивается.
#Почему список всегда неполон
Спросите список внешних зависимостей у троих в компании — получите три разных списка, и ни одного полного.
Причина структурная, а не в чьей-то небрежности. Зависимости накапливаются по одной: каждую добавил один человек по одному поводу в момент, когда это было очевидно и не требовало записи. Через четыре года:
- того, кто добавил провайдера SMS, уже нет в компании;
- интеграция с аналитикой вызывается из одного файла, который никто не открывает;
- внутренний API отчётности принадлежит команде, которую с тех пор реорганизовали;
- на бакет объектного хранилища ссылается переменная окружения, в значение которой никто не заглядывал с момента установки.
Ничего из этого не видно снаружи и ничего из этого не всплывает в разговоре, потому что вся категория состоит из того, о чём никто не думает. Видимым это становится ровно в двух случаях: когда что-то из этого ломается и когда кто-то выводит список из системы, а не из памяти.
#Что считается зависимостью
| Вид | Примеры | Как выглядит отказ |
|---|---|---|
| Платный сторонний сервис | Платежи, доставка почты, SMS, карты, поиск адресов | Останавливается деловая функция. Обычно видно сразу. |
| Инфраструктурный сервис | Объектное хранилище, управляемая база, очередь, кэш, поиск | Широкий и тяжёлый. Чаще всего труднее всего заменить. |
| Аутентификация | Единый вход, провайдер OAuth, платформа идентичности | Никто не может войти, включая вас. |
| Внутренний API другой команды | Сервис отчётности, общая карточка клиента | Медленно, политически и невидимо до самого момента. |
| Исходящая интеграция | Ночной файл партнёру, вебхук клиенту | Молча. Первым замечает кто-то другой, недели спустя. |
| Входящий интерфейс | Публичный API, вебхук, который вы принимаете | Ломается чужой продукт, а чинить это вам. |
Последние два чаще всего отсутствуют в собственном списке компании, потому что не ощущаются зависимостями. А они ими являются: что-то снаружи полагается на договорённость, и ни одна сторона её не записала.
#Пять вопросов к каждой записи
На первые три карта отвечает из системы. Остальные два — для человека, и они обычно дорогие.
-
Что это и зачем?
Название сервиса и одна фраза о том, что перестаёт работать без него.
-
Какая часть нашей системы его касается?
Какие компоненты, через какой интерфейс, в каком направлении.
-
Как это себя ведёт?
Как аутентифицируется, есть ли таймаут, есть ли повторы, безопасно ли повторить запрос.
-
Чей это аккаунт?
Из кода не выводится. Если ответ «личный аккаунт нашего разработчика», вы нашли что-то важное.
Проверки зависимости от агентства и готовности к передаче спрашивают об этом прямо.
-
Что будет, если это остановится?
Суждение, а не факт, — но его никто не вынесет, пока у первых трёх вопросов нет ответов.
#Как она выглядит
ИСХОДЯЩАЯ Платёжный провайдер REST · внешний
от Сервиса биллинга
авторизация ключ API из конфигурации
для Приёма платежей по картам
⚠ Поведение при повторах не установлено
ИСХОДЯЩАЯ Транзакционная почта REST · внешний
от Модуля уведомлений
для Чеков, писем о просрочке, сброса пароля
ИСХОДЯЩАЯ Объектное хранилище SDK · внешний
от Генератора счетов
для Хранения созданных PDF-счетов
⚠ Бакет и регион приходят из конфигурации вне
репозитория — не установлены
ИСХОДЯЩАЯ Выгрузка CSV партнёру ФАЙЛ · внешний
от Ночной выгрузки
для Ежедневного файла с платежами
⚠ Получатель не установлен. Никто в анализе не смог
сказать, кто это принимает.
ВХОДЯЩИЙ API платежей REST · публичный
к Сервису биллинга
для Возможности витрине принять платёж
авторизация токен, выданный витриной
ВХОДЯЩИЙ Вебхук провайдера REST · внешний
к Сервису биллинга
для Подтверждения, что платёж прошёл
⚠ Проверка отправителя не установленаЧетыре предупреждения на шесть записей — реалистичное соотношение для первого анализа настоящей системы. Два из них — куда уходит ночной файл и проверяет ли вебхук провайдера отправителя — владельцу стоило бы знать уже сегодня, и ни одно не всплыло бы в разговоре об архитектуре.
#Зависимость — не то же самое, что владение
Карта может установить, что ваша программа обращается к платёжному провайдеру. Она не может установить, чей это аккаунт, — а именно второй вопрос решает, насколько всё плохо.
Что стоит искать: зависимость, нужную вашей системе, но лежащую в аккаунте, которым ваша компания не управляет. Облачный проект в организации агентства. Домен, зарегистрированный на личную почту разработчика. Платёжная интеграция на торговом счёте подрядчика. Всё это невидимо в коде, совершенно обычно по происхождению и оказывается серьёзной проблемой ровно в один момент.
Об этом на сайте есть две вещи: кому должна принадлежать продакшен-инфраструктура и проверка зависимости от агентства, которая проходит по аккаунтам по одному.
#Чего она не найдёт
Чего это не делает
- Того, что существует только в облачной консоли. Если на это не ссылается никакой код, анализ кода этого не увидит. Он может лишь сказать, что значение конфигурации используется, а его смысл не установлен.
- Кто за что платит. Расчётные отношения не являются свойством программы.
- Есть ли договор. Поставщик, от которого зависит ваша система и с которым нет соглашения, выглядит точно так же, как поставщик с пятилетним контрактом.
- Ограничений на частоту, квот и коммерческих условий. Иногда они видны в коде как константы; обычно нет.
- Теневых зависимостей, добавляемых во время работы: подключаемого из конфигурации плагина, адреса из переменной окружения. Они всплывают как неизвестное, а не как записи.