Карта внешних зависимостей онлайн-бизнеса: поставщики, риски и обходы
Карта внешних зависимостей показывает, какие поставщики и сервисы участвуют в каждом денежном пути, что произойдёт при их отказе, кто отвечает за связь и какой обход доступен. Для интернет-магазина это не только хостинг: продажи зависят от DNS, CDN, платежей, антифрода, 1С или ERP, склада, доставки, SMS, почты, CRM, аналитики и маркетплейсов.
Цель карты — не купить резерв для всего, а заранее выбрать зависимости, отказ которых останавливает выручку или выполнение обязательств.
Коротко
Для каждой зависимости зафиксируйте:
- бизнес-пути, которые от неё зависят;
- тип передаваемых данных и уровень доступа;
- допустимое время недоступности;
- способ обнаружения проблемы;
- владельца внутри бизнеса;
- контакты и порядок эскалации;
- ручной или технический обход;
- порядок восстановления и сверки;
- дату последней проверки обхода.
Начинайте с пути «покупатель оплатил → заказ выполнен», а не с полного списка SaaS-подписок.
Почему список договоров недостаточен
Реестр закупок обычно знает название поставщика и цену. Он редко отвечает:
- какие функции остановятся;
- через сколько минут бизнес заметит отказ;
- есть ли альтернативный канал;
- кто имеет доступ к кабинету;
- где опубликован статус провайдера;
- как безопасно повторить накопившиеся операции;
- какие данные нужно сверить после восстановления.
Карта связана с процессом и поэтому пригодна во время инцидента.
Постройте карту от бизнес-путей
Пример пути заказа:
Реклама → DNS/CDN → каталог → корзина → доставка → платёж → заказ → ERP → склад → уведомление → перевозчик.
Для заявки B2B:
Посадочная → форма → антиспам → backend → почта/webhook → CRM → уведомление менеджеру.
Один поставщик может участвовать в нескольких путях. Один путь может зависеть от десятка поставщиков, но только некоторые из них не имеют обхода.
Шаблон реестра
| Зависимость | Путь | Влияние | Допустимый перерыв | Обнаружение | Обход | Владелец |
|---|---|---|---|---|---|---|
| DNS | Все веб-пути | Сайт недоступен | Внешняя проверка | Резервный план зоны | ||
| Платёжный провайдер | Оплата | Нет онлайн-оплат | Тест + статусы | Альтернативный способ | ||
| ERP/1С | Исполнение | Заказы не обрабатываются | Возраст последнего обмена | Очередь/ручной экспорт | ||
| Доставка | Checkout/исполнение | Нет расчёта или отгрузки | Тест API | Ограниченные тарифы | ||
| CRM | Заявки | Менеджеры не видят лиды | Контрольная заявка | Резервный ящик | ||
| SMS/email | Уведомления | Клиент не получает сообщения | Доставка теста | Другой канал |
Оцените критичность
Поставьте 0–3 балла по пяти критериям:
| Критерий | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Влияние на выручку | Нет | Косвенное | Заметное | Останавливает |
| Влияние на обязательства | Нет | Низкое | Существенное | Критическое |
| Скорость обнаружения | Сразу | До часа | До дня | Дольше дня |
| Обход | Полный | Удобный | Ограниченный | Нет |
| Концентрация | Много альтернатив | Несколько | Одна сложная замена | Уникальная зависимость |
Высокий балл означает необходимость более частной проверки, документированного обхода и внимания руководителя. Он не означает автоматическую покупку второго поставщика.
Проверьте скрытые общие точки отказа
Два поставщика не всегда дают независимость. Они могут использовать:
- одного облачного провайдера;
- общий DNS;
- один корпоративный email для восстановления доступа;
- одну банковскую инфраструктуру;
- одного агрегатора доставки;
- один канал связи;
- одну учётную запись администратора;
- один webhook-адаптер;
- одного сотрудника с единственными знаниями.
Задавайте вопрос: «Что общего должно сломаться, чтобы обе альтернативы стали недоступны?»
Выберите тип обхода
Технический резерв
Второй маршрут, провайдер или регион. Дороже и требует регулярного тестирования.
Функциональная деградация
Сайт продолжает принимать заказы, но временно ограничивает способы оплаты, доставки, поиск или персонализацию.
Ручной процесс
Заказы собираются в защищённую очередь или согласованный канал и позже переносятся в систему. Подходит для небольшого объёма и короткого периода.
Остановка с понятным сообщением
Иногда безопаснее честно приостановить функцию, чем принять деньги без возможности выполнить заказ.
Карточка критического поставщика
| Поле | Значение |
|---|---|
| Юридическое и торговое название | |
| Услуга | |
| Затронутые пути | |
| Договор/SLA | |
| Кабинет и владельцы доступа | |
| Статус-страница | |
| Поддержка P1 | |
| Наши ID аккаунта/договора | |
| Последний успешный сигнал | |
| Обход | |
| Ограничения обхода | |
| Инструкция восстановления | |
| Последняя проверка |
Секреты не храните в самой карте. Ссылайтесь на утверждённое защищённое хранилище.
Учение на 45 минут
- Выберите одну критическую зависимость.
- Объявите условный отказ в пиковый час.
- Попросите команду определить влияние и владельца.
- Найдите актуальные контакты и статус поставщика.
- Пройдите включение обхода без опасных production-действий.
- Опишите накопившиеся операции и будущую сверку.
- Зафиксируйте пробелы с владельцами и сроками.
Учение проверяет не техническую фантазию, а способность бизнеса принять согласованное решение.
Типичные ошибки
- составлять список сервисов без связи с бизнес-путями;
- считать договор SLA гарантией непрерывности;
- покупать резерв, который никто не тестирует;
- хранить единственный доступ у подрядчика;
- забывать зависимость от email и DNS;
- не учитывать задержку переключения и ручную мощность;
- не планировать сверку накопившихся заказов;
- пытаться резервировать аналитику так же, как оплату.
FAQ
Нужно ли иметь второго платёжного провайдера?
Не всегда. Решение зависит от стоимости простоя, доли онлайн-оплат, сложности интеграции и реальной независимости маршрутов. Иногда достаточно альтернативного способа оплаты и понятного процесса.
Как часто обновлять карту?
После изменения архитектуры или поставщика и по расписанию минимум ежеквартально для критических зависимостей. Контакты и доступы проверяйте чаще.
Кто должен владеть поставщиком — IT или бизнес?
Нужны два взгляда: технический владелец знает интеграцию, бизнес-владелец принимает решение о риске, обходе и допустимом перерыве.
Источники
- NIST Cybersecurity Framework 2.0
- NIST CSF 2.0: Resource and Overview Guide
- ЮKassa: документация API и уведомлений
Проверено: 10 августа 2026 года.
Далее: подготовка магазина к распродаже и единый каталог клиентских сайтов.
Pingvera помогает наблюдать внешние бизнес-пути из независимой точки и отличать локальную проблему сайта от отказа связанной системы.
Узнавайте о проблеме раньше клиента
Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.
Попробовать Pingvera бесплатноЧитайте также: Карта бизнес-путей сайта: практический шаблон · Каталог клиентских сайтов: шаблон для студии · Отчёт об инциденте сайта: шаблон для клиента · Регламент мониторинга сайтов клиентов: шаблон · Бесплатно проверить сайт.