Сеть на вырост: Как проектировать надежную и масштабируемую IT-инфраструктуру

Елена Светлова

Сеть на вырост: Как проектировать надежную и масштабируемую IT-инфраструктуру

Сеть на вырост: Как проектировать надежную и масштабируемую IT-инфраструктуру

Елена Светлова

От бизнес-задачи к техническим требованиям: цели, ограничения, SLA и сценарии роста

В переговорной спорили уже двадцать минут, хотя слово было всего одно — «надежность».

— Нам нужна сеть, которая не падает, — сказал руководитель продукта.

— Сеть не падала ни разу за последний месяц, — возразил ИТ-директор.

— А мы получили триста жалоб, что оплата зависает, — заметила начальница поддержки.

Финансовый директор поднял глаза от ноутбука:

— Только не предлагайте решение, которое стоит как новый склад.

На экране презентации по-прежнему красовалась исходная заявка: «Сделать сеть побыстрее и надежнее к запуску нового сервиса». В этой фразе было много уверенности и почти не было требований. Что именно значит «побыстрее»? Для каких пользователей? Насколько надежнее? Что происходит, если сеть всё-таки недоступна? И сколько компания готова заплатить за снижение риска?

На эти вопросы нельзя ответить выбором маршрутизатора. Пока неизвестно, какой бизнес-сценарий нужно обеспечить, новый маршрутизатор — всего лишь дорогая версия догадки.

Запрос на скорость, который оказался запросом на оплату

Компания «СеверМаркет» готовила запуск сервиса экспресс-заказов. Покупатель должен был выбрать товар, оплатить его в приложении и получить доставку в течение часа. Запуск планировали через шесть месяцев — как раз к сезонному пику продаж. Команда продукта пришла к ИТ с просьбой «ускорить сеть»: тестовые платежи иногда проходили с задержкой, а иногда приложение сообщало об ошибке.

Первый важный вопрос звучал не «Какое оборудование у вас стоит?», а так:

— Что именно не может сделать пользователь — и в какой момент?

Владелец продукта ответил не сразу. Затем описал сцену: человек собрал корзину, нажал «Оплатить», увидел вращающийся индикатор и через несколько секунд решил, что ничего не произошло. Нажал кнопку ещё раз. Иногда платёж проходил, иногда возникала ошибка, а иногда покупатель закрывал приложение и уходил.

Итак, бизнес-проблема была не в абстрактной скорости. Она касалась завершения оплаты без неоправданной задержки и без потери доверия пользователя. Сеть могла быть одной из причин, но требовалось выяснить её вклад наряду с приложением, базой данных, внешним платёжным провайдером и мобильным интернетом покупателя.

Это различие принципиально. Время отклика приложения — не то же самое, что задержка сети. Если платёж занимает три секунды, а сеть между компонентами отвечает за 40 миллисекунд, покупка сетевого оборудования сама по себе не решит проблему. Если же сетевые задержки скачут от 30 до 700 миллисекунд при нагрузке, этот участок уже стоит исследовать. Начинают с пользовательского сценария и измерений, а не с заранее выбранного виновника.

Четыре интервью — четыре значения слова «надежность»

Совещание продолжилось короткими разговорами с теми, кто видел проблему с разных сторон. Это не формальность: бизнес-требование редко лежит готовым документом на одном столе. Его приходится собирать по частям — как маршрут, известный каждому только на своём участке.

Владелец продукта описал пользователя, действие и ожидаемый результат:

— Нам важно, чтобы человек мог завершить оплату. Если ответ задерживается, он повторяет попытку. Мы боимся не только потерянной продажи, но и двойного списания.

Из этой фразы появились первые уточнения: какие устройства и регионы важны; какие этапы образуют путь оплаты; какое время ожидания пользователи считают приемлемым; как приложение обрабатывает повтор запроса; какой компонент сообщает об успешной операции.

Финансовый директор перевёл разговор в язык затрат и последствий:

— Сколько стоит час сбоя? И сколько стоит сделать так, чтобы он случался реже?

На вопрос нельзя честно ответить, умножив все незавершённые заказы на средний чек: часть покупателей вернётся, часть платежей восстановится, а часть заказов потеряется безвозвратно. Но финансовой команде можно предложить модель: оценить потерянную маржу, расходы на поддержку и компенсации, влияние на репутацию, а затем сравнить эти потери с ценой резервирования каналов, оборудования и эксплуатации. Бюджет — не досадная помеха проекту, а одно из его условий. Если на снижение риска выделена определённая сумма, это может исключить некоторые варианты архитектуры. Лучше узнать об этом до проектирования, а не после тендера.

Служба поддержки добавила то, чего не было в графиках продукта:

— Пользователь говорит «не работает», а мы не всегда понимаем, где именно. Проблему замечают по звонкам, а не по мониторингу. Если сбой затрагивает только один регион, мы узнаём об этом слишком поздно.

Значит, надёжность — это не только редкие отказы. Это ещё и способность быстро обнаружить проблему, определить её область и восстановить услугу. Показатель, который нельзя заметить, трудно улучшить; инцидент, который нельзя локализовать, обычно длится дольше, чем должен.

ИТ-команда показала текущую инфраструктуру. Оказалось, что два интернет-канала заведены в здание по одной физической трассе. На схеме они выглядели резервированием, но общий кабельный колодец превращал их в два билета на один и тот же автобус. Кроме того, резервный канал никто не проверял под полной нагрузкой, а переключение после отказа было настроено не для всех сервисов.

Так обнаружилось скрытое ограничение: «два провайдера» ещё не означает «два независимых пути». На надёжность влияют общие точки отказа — помещение, ввод кабеля, питание, пограничное устройство, DNS, облачный узел, команда дежурства. Резервирование на схеме и резервирование в реальной аварии — разные вещи.

Превращаем пожелания в измерения

После интервью команда переписала исходную просьбу. Вместо «сделать сеть быстрее» появилось: «Обеспечить предсказуемый сетевой путь для операций оплаты, измерять его задержку и потери, поддерживать работу сервиса во время сезонного пика и восстанавливать связность в согласованный срок».

Формулировка стала лучше, но проектировать по ней всё ещё рано. Её нужно разложить на проверяемые параметры.

Задержка. Среднее значение удобно для презентации и опасно для пользователя. Если большинство операций укладывается в 40 мс, а каждая двадцатая задерживается до 500 мс, именно эти редкие задержки могут создавать ощущение нестабильности. Поэтому для критичных пользовательских путей смотрят на процентили: например, p95 — значение, ниже которого укладываются 95% измерений, а p99 — 99%. Важно заранее определить точки измерения, время суток, направления трафика и тип нагрузки.

Потери пакетов. Даже небольшая доля потерь способна вызвать повторные передачи и увеличить время ответа. Для платежного сценария недостаточно сказать «потерь быть не должно»: нужно назвать границы, место измерения, длительность окна и способ сбора данных.

Пропускная способность и запас. Канал, который справляется со средней нагрузкой, может захлебнуться в пике. Более того, по мере приближения загрузки к пределу очереди часто растут непропорционально: пакеты ждут своей очереди дольше, задержка становится нестабильной. Поэтому сеть нельзя планировать ровно под текущую среднюю нагрузку. Нужны данные о пиковом трафике, резерв на рост, а также проверка поведения при отказе одного из каналов или узлов.

Доступность. Её надо определить для конкретной услуги, а не для абстрактного набора устройств. «Маршрутизатор отвечает на ping» не доказывает, что пользователь может завершить оплату. Измерение должно отражать доступность критичного пользовательского пути — например, с помощью синтетических проверок из нескольких точек, которые регулярно выполняют тестовый запрос до согласованного сервиса.

Время восстановления и сохранность данных. RTO (Recovery Time Objective) — сколько времени допустимо потратить на восстановление услуги. RPO (Recovery Point Objective) — какой объём данных, измеренный во времени, допустимо потерять при восстановлении. Для сети обычно важнее RTO связности; RPO относится к данным и состоянию приложения. Но в платёжном сценарии они соприкасаются: восстановить сеть недостаточно, если после разрыва непонятно, прошла ли транзакция. Значит, нужно отдельно согласовать, как сервис проверяет статус операции и защищается от повторного списания.

На этом этапе у команды появился ещё один полезный принцип: каждый показатель должен иметь способ проверки. Требование «задержка низкая» не принимается тестом. Требование «p95 сетевой задержки между площадкой приложения и платёжным шлюзом не выше 50 мс в заданном окне нагрузки, измерение по согласованному методу» — уже можно проверить и обсудить.

SLA — обещание, за которым стоит цена

Слова SLA, SLO и внутренний целевой показатель часто используют как синонимы. Это всё равно что называть одним словом прогноз погоды, обещание зонта и собственный план не промокнуть.

•SLA (Service Level Agreement) — соглашение об уровне услуги, обычно с условиями, исключениями и последствиями невыполнения. Оно может быть договорным обязательством перед клиентом или внутренним соглашением между командами.

•SLO (Service Level Objective) — целевой уровень услуги, к которому команда стремится и который регулярно измеряет. Например, доступность критичного пути оплаты не ниже 99,95% за календарный месяц.

•Внутренний целевой показатель — более строгая рабочая цель, оставляющая запас до обещанного уровня. Если внешнее обязательство — 99,95%, команде может быть разумно планировать 99,97%, чтобы отдельные инциденты и неточность измерения не съели весь резерв.

Обещанная доступность должна сопровождаться ответами на четыре вопроса: что именно считаем доступным, откуда измеряем, за какой период считаем и что исключаем из расчёта. Также нужен бюджет, соответствующий обещанию. Резервные каналы, независимые маршруты, мониторинг и круглосуточное реагирование стоят денег и требуют обслуживания. SLA без такого обеспечения — не план, а пожелание, написанное шрифтом покрупнее.

Полезно почувствовать масштаб процентов. Если считать непрерывную работу в течение года, доступность 99,9% соответствует примерно 8 часам 46 минутам простоя, а 99,99% — примерно 53 минутам. В 30-дневном месяце 99,95% — это около 22 минут. Реальные договоры могут считать доступность иначе: например, включать только определённые часы, исключать согласованные работы или учитывать лишь подтверждённые инциденты. Поэтому одной цифры в презентации недостаточно: метод измерения — часть требования.

У «СеверМаркета» согласовали пока не клиентское обещание, а проектный ориентир: измерять доступность полного платёжного пути синтетическими проверками каждую минуту из трёх точек; цель — не ниже 99,95% за месяц после запуска; внутренний SLO для команды — 99,97%. Плановые работы и ошибки внешнего провайдера не исчезли из мира, но стороны решили явно описать, как их учитывать, прежде чем включать обязательство в договор.

Сезонный пик — не сюрприз, если спросить о нём заранее

До этого разговора «рост» означал: «Наверное, пользователей будет больше». Теперь команда попросила продукт и аналитику описать конкретные сценарии.

1. Обычный день: текущий объём заказов, известные суточные пики.

2. Сезонный максимум через шесть месяцев: прогноз по одновременным пользователям и числу операций, включая ожидаемую рекламную кампанию.

3. Быстрый рост: сценарий, при котором новая функция окажется популярнее прогноза.

4. Работа при отказе: поведение сервиса при потере одного канала или площадки.

5. Изменение географии: подключение новых магазинов, регионов или облачных компонентов.

Для каждого сценария нужны исходные данные и допущения: текущая нагрузка, темп роста, запас, срок, к которому сеть должна быть готова. Если прогноз неточен — а он будет неточен, — это не повод отказаться от планирования. Это повод зафиксировать диапазон и предусмотреть этапы пересмотра. Например: спроектировать базовую ёмкость под подтверждённый пик, установить порог, после которого требуется расширение, и провести нагрузочное испытание за несколько недель до кампании.

У команды оказалось полгода, но это не означало, что шесть месяцев можно потратить на закупку. Сначала следовало измерить текущий путь платежа, найти узкие места и проверить предположения; затем — определить целевую нагрузку, собрать архитектуру и испытать её в условиях, похожих на пик. Если проверка покажет, что задержка возникает внутри приложения, сеть не придётся перестраивать ради чужой проблемы. Если же один канал не выдерживает нагрузку после отказа второго, это станет основанием для конкретного изменения.

Таблица, которая не даёт бизнесу и ИТ разойтись

Итог совещания команда оформила в таблицу трассировки: от цели — к сценарию, от сценария — к метрике, от метрики — к ограничению и проверке. Такая таблица помогает увидеть, зачем нужен каждый технический показатель, и не забыть, как доказать, что требование выполнено.

Цель

Сценарий

Метрика

Ограничение

Проверка

Покупатель завершает оплату без неоправданной задержки

Пиковая нагрузка в сезонной кампании

p95 сетевой задержки между согласованными точками — не более 50 мс; доля потерь — не более 0,1% в заданном окне

Измеряется только участок сети; полный отклик приложения учитывается отдельно

Нагрузочный тест и синтетические проверки; фиксированные точки, окно и формат отчёта

Сервис оплаты остаётся доступным

Обычная работа и отказ одного канала

SLO доступности платёжного пути — 99,97% в месяц; проектный минимум — 99,95%

Требуется независимость путей и мониторинг; доступность внешнего платёжного сервиса учитывается отдельно по согласованным правилам

Синтетические проверки из трёх точек; испытание переключения; месячный отчёт

Сбой не превращается в долгую остановку

Потеря основного канала

Восстановление связности — не более 5 минут

Предел зависит от механизма переключения и доступности дежурной команды

Плановая имитация отказа с замером времени и проверкой журналов

Сезонный рост не ухудшает качество

Прогнозный пик через шесть месяцев и сценарий роста выше прогноза

Поддержка утверждённого пикового числа операций с согласованным запасом; значения фиксируются после анализа телеметрии

Лимит бюджета и сроки поставки; прогноз пересматривается перед кампанией

Нагрузочный тест на утверждённом профиле; подтверждение резерва после отказа одного канала

Это пока каркас, а не спецификация оборудования. И это правильно: таблица фиксирует, что должна обеспечивать система и как это проверить, но оставляет проектировщику пространство выбрать подходящую архитектуру.

К ней добавили согласованное задание:

Обеспечить платёжный путь нового сервиса для пользователей «СеверМаркета» в обычном режиме и в период сезонного пика через шесть месяцев. После уточнения прогноза зафиксировать целевой профиль нагрузки и провести испытание с дополнительным резервом, согласованным владельцем продукта и ИТ-командой. Доступность платёжного пути измерять синтетическими проверками из трёх точек и оценивать за календарный месяц; целевой SLO — 99,97%, минимальный проектный уровень — 99,95%. Для согласованных сетевых участков контролировать p95 задержки и потери пакетов, отдельно от полного времени отклика приложения. При отказе основного канала восстановить связность не более чем за пять минут; переключение и работу под нагрузкой проверить до запуска. Ограничения бюджета, зависимости от внешнего платёжного сервиса и правила учёта плановых работ документировать до утверждения клиентского SLA.

Так выглядит переход от «сделать сеть побыстрее» к заданию, которое можно обсуждать, проектировать и принимать. Оно не обещает невозможного и не прячет спорные места в слове «надежность». Вместо этого оно связывает пользовательскую задачу с измерениями, сроками, ценой и проверкой результата.

Короткое упражнение перед стартом проекта

Возьмите ближайшую сетевую инициативу и попробуйте заполнить для неё одну строку таблицы. Начните не с модели оборудования, а с пяти вопросов:

1. Кто пользователь и что он пытается сделать?

2. Какой отказ или задержка мешают этому сценарию?

3. Какой показатель докажет, что стало лучше?

4. Какие ограничения — бюджет, срок, старые системы, договоры — нельзя игнорировать?

5. Как и когда вы проверите результат?

Если на последний вопрос ответить нечем, требование пока нельзя принять. Если на первый — «всем нужна хорошая сеть», проект ещё не начал разговор с бизнесом.

На совещании «СеверМаркета» никто не нашёл устройство с надписью «никогда не падать». Зато команда выяснила, что именно должна защищать сеть: путь оплаты в период максимального спроса, в пределах определённого бюджета и с восстановлением, которое проверено не на словах. Это и есть полезный результат сбора требований — не список покупок, а общий договор о том, что считать успехом.

Сначала выясните, какой сценарий бизнес не может себе позволить потерять. Затем определите, насколько надёжно он должен работать, сколько простоя допустимо и какими данными это будет доказано. И только после этого выбирайте архитектуру и оборудование. Сеть, спроектированная таким образом, начинается не с маршрутизатора. Она начинается с правильного вопроса.

Основы сетевой архитектуры: уровни, компоненты, протоколы и физическая инфраструктура

В 9:17 утра Марина открывает ноутбук, подключается к корпоративному Wi-Fi и набирает адрес внутреннего портала. Значок беспроводной сети бодро сообщает: «Подключено». Сам портал работает — коллега за соседним столом только что открыл его. Но у Марины браузер крутит колесо, а затем выдаёт ошибку.

— Это сеть, — говорит служба поддержки. — Сервер исправен, — отвечает команда приложения. — Wi-Fi подключён, — возражают специалисты беспроводной сети.

Каждый прав, но только в пределах своей проверки. Проблема в том, что слово «сеть» здесь используют как название тёмного леса, в котором якобы всё связано со всем. Инженер поступает иначе: берёт один запрос Марины и прослеживает его путь — от сетевой карты до приложения. Не «работает ли сеть вообще?», а «до какого именно шага доходит этот запрос и что происходит на каждом шаге?».

Сначала — уточнить, что именно не работает

Фраза «не открывается приложение» может означать десятки разных вещей. Ноутбук не получил адрес. Wi-Fi слишком загружен. Имя сервера не разрешается. Маршрут потерян. Межсетевой экран отклоняет соединение. Сервер отвечает, но браузер не доверяет его сертификату. Наконец, сеть может быть исправна, а само приложение — нет.

Архитектура помогает превратить эту россыпь вариантов в последовательность проверяемых гипотез. Для этого полезна слоистая модель: не потому, что реальная сеть аккуратно разложена по этажам, а потому, что каждый слой решает свой класс задач и оставляет свои наблюдаемые следы.

У модели OSI семь уровней. В повседневной работе чаще используют более компактное представление TCP/IP:

Уровень TCP/IP

Что обеспечивает

Примеры

Доступ к сети

Передачу по физической среде и в локальном сегменте

Wi-Fi, Ethernet, VLAN

Межсетевой

Доставку между IP-сетями

IPv4, IPv6, маршрутизация

Транспортный

Связь между процессами на узлах

TCP, UDP

Прикладной

Смысл обмена и сетевые сервисы

DNS, DHCP, HTTPS, NTP

Это не четыре отдельных коробки. Это четыре взгляда на один обмен. Инженер может спросить: «Есть ли радиосвязь?», «Есть ли IP-маршрут?», «Установилось ли TCP-соединение?», «Приняло ли приложение запрос?» — и каждый вопрос проверит другую часть пути.

До приложения: адрес, шлюз и имя

В нашем примере ноутбук Марины уже подключён к Wi-Fi, но одного подключения недостаточно. Устройство должно получить сетевые настройки: собственный IP-адрес, маску или длину префикса, адрес шлюза и адрес DNS-сервера. Обычно этим занимается DHCP.

Предположим, ноутбук получил адрес 10.24.18.57/24, шлюз 10.24.18.1, а DNS-сервер — 10.24.2.53. В типичном сценарии DHCP клиент отправляет широковещательный запрос, сервер отвечает, а устройство завершает обмен и получает аренду адреса. Если DHCP-сервер находится в другой подсети, запрос может передать ему DHCP relay на маршрутизаторе или L3-коммутаторе. Поэтому отсутствие адреса не обязательно означает поломку Wi-Fi: радио может работать, а путь до DHCP-сервера — нет.

Теперь браузеру нужно найти портал, например portal.corp.example. Человек запоминает имя; IP-сеть доставляет данные по адресу. DNS преобразует одно в другое. Но DNS-запрос — уже отдельный сетевой обмен: ноутбук обращается к резолверу, обычно по UDP-порту 53, а при необходимости DNS может использовать TCP. Если резолвер находится не в локальной подсети, ноутбук отправит запрос через шлюз. Для этого ему нужно узнать MAC-адрес шлюза — например, с помощью ARP в IPv4 или Neighbor Discovery в IPv6.

Третий сервис часто остаётся за кадром, пока не начинает влиять на результат: синхронизация времени. NTP обычно работает поверх UDP, порт 123. Часы важны не только для аккуратных журналов. TLS проверяет сроки действия сертификатов; если часы устройства сильно спешат или отстают, исправный сервер может показаться браузеру недоверенным.

Именно это происходит с Мариной. DNS возвращает корректный адрес портала, а соединение с ним устанавливается. Но часы ноутбука отстают на восемнадцать минут: запросы к корпоративному серверу времени из пользовательского сегмента блокирует ошибочное правило межсетевого экрана. Сертификат портала ещё не считается действительным по времени устройства. Для пользователя результат выглядит как «сайт не работает». Для инженера это уже конкретная цепочка: сеть доставки довела соединение до проверки TLS, а зависимый сервис синхронизации времени не выполнил свою роль.

Путь запроса: от радиоканала до серверного порта

Разберём путь точнее. Пусть портал находится по адресу 10.60.8.20, а Марина открывает https://portal.corp.example. Для ясности представим обычное HTTPS-соединение поверх TCP. Некоторые браузеры могут использовать HTTP/3 поверх QUIC и UDP — в реальной диагностике это нужно учитывать, но базовые принципы маршрута остаются.

1. Сетевая карта и радиосреда. Ноутбук передаёт кадры по Wi-Fi к точке доступа. На этом участке важны уровень сигнала, качество радиоканала, помехи и занятость эфира. Wi-Fi — общая среда: устройства делят время передачи, а повторные отправки могут замедлять обмен, даже если значок подключения не гаснет. Поэтому проверка «подключён» ещё не доказывает, что радиосвязь хорошая.

2. Точка доступа и коммутируемая сеть. В нашем примере точка доступа локально передаёт клиентский трафик в проводную сеть и связывает SSID корпоративного Wi-Fi с VLAN 118. В другой архитектуре точка доступа может туннелировать его к контроллеру — важно знать, где именно заканчивается радиосегмент и где трафик выходит в обычную сеть. Далее кадры проходят через порт коммутатора доступа. Коммутатор использует MAC-адреса и таблицу коммутации, чтобы пересылать кадр в нужном направлении; VLAN разделяет локальные широковещательные домены.

3. Шлюз и IP-маршрутизация. Адрес портала находится не в подсети Марины, поэтому ноутбук отправляет кадр не непосредственно серверу, а MAC-адресу шлюза 10.24.18.1. IP-пакет при этом адресован порталу: источник — ноутбук, назначение — сервер. Маршрутизатор принимает кадр, извлекает IP-пакет, выбирает следующий переход по таблице маршрутизации и создаёт новый канальный кадр для следующего участка. На каждом маршрутизируемом переходе меняется L2-обрамление; IP-адреса обычно сохраняются, хотя NAT может их преобразовать. Также маршрутизатор уменьшает TTL в IPv4 или Hop Limit в IPv6.