3.13 Сети и связность

Обзор и мотивация

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

Для большой организации связность это место, где архитектура одновременно встречает физику и политику. Глобальная корпорация сшивает центры обработки данных, облачные регионы, партнёрские API и унаследованные системы, и каждый переход добавляет задержку, режимы отказа и границу безопасности, которой кто-то должен владеть. Государства накладывают строгие правила о том, как трафик входит в их сети и покидает их и куда могут передаваться данные граждан. Разница между командой, понимающей сеть, и командой, её игнорирующей, проявляется в числах доступности, времени загрузки страниц, отчётах о взломах и находках аудита. Этот материал связан с распределёнными системами (глава 3.3), масштабируемостью и устойчивостью (глава 3.5), безопасностью инфраструктуры и облака (глава 4.3) и криптографией и управлением ключами (глава 4.8).

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

Ключевые принципы

Сеть это зависимость, а не данность. Воспринимайте каждый удалённый вызов как способный быть медленным, потеряться или солгать о том, завершился ли он.
Задержка определяется расстоянием и числом круговых обходов. Нельзя обогнать скорость света, поэтому сокращайте круговые обходы и переносите данные ближе к пользователям.
Имена отказывают чаще, чем машины. Разрешение имён и сертификаты вызывают поразительную долю отказов, поэтому воспринимайте их как первоклассные эксплуатационные заботы.
Защищайте и завершайте шифрование намеренно. Знайте точно, где трафик шифруется, где расшифровывается и у кого ключи.
Каждой границе сети нужны тайм-аут и запасной вариант. Неограниченные ожидания и слепые повторы превращают одну медленную зависимость в глобальный отказ.
По умолчанию запрещайте на краях. Сегментируйте сети, контролируйте, что может выходить, и предполагайте, что периметр уже пористый.
Наблюдайте соединение, а не только код. Ошибки соединений, повторные передачи, время рукопожатий и задержка DNS сигналы, которые ваши журналы обычно упускают.

Рекомендации

Понимайте уровни, которые действительно влияют на ваши решения

Вам не нужно помнить наизусть полную семиуровневую модель, но нужна ментальная карта. На транспортном уровне протокол управления передачей (TCP) даёт упорядоченный надёжный поток байтов ценой рукопожатия и блокировки головы очереди, тогда как протокол пользовательских датаграмм (UDP) даёт дешёвые неупорядоченные датаграммы без гарантии доставки. Надёжный трафик «запрос-ответ» идёт по TCP; медиа реального времени, игры и часть телеметрии идут по UDP, потому что запоздавший пакет хуже потерянного.

Эволюция протокола передачи гипертекста (HTTP) меняет ваш потолок производительности. HTTP/1.1 обрабатывает один запрос на соединение за раз, поэтому браузеры открывают много соединений, а вы платите за повторные рукопожатия. HTTP/2 мультиплексирует много потоков по одному соединению TCP, что устраняет блокировку головы очереди на уровне приложения, но не на уровне TCP: один потерянный пакет задерживает каждый поток этого соединения. HTTP/3 работает поверх QUIC, транспорта на основе UDP, дающего каждому потоку независимую доставку, более быструю установку соединения и миграцию соединения при смене сети. Вы редко реализуете их сами, но выбираете их в своих балансировщиках нагрузки, сети доставки содержимого и клиентах, и этот выбор проявляется в хвостовой задержке.

Воспринимайте DNS и сертификаты как производственные системы

Система доменных имён (DNS) переводит человеческие имена в адреса и стоит перед почти каждым запросом. Поразительное число крупных отказов восходит к DNS: неудачное изменение записи, истёкшая зона, неверно настроенный преобразователь, слой кэширования, отдающий устаревшие ответы, или медленный авторитетный сервер, добавляющий сотни миллисекунд к первому байту. Относитесь к изменениям DNS с той же строгостью, что и к развёртываниям кода. Используйте разумные значения времени жизни (TTL), чтобы быстро перенаправлять трафик во время инцидента, не приглашая устаревшее кэширование в обычной эксплуатации, и мониторьте задержку разрешения и доли отказов как реальные метрики.

Сертификаты заслуживают той же серьёзности. Когда сертификаты безопасности транспортного уровня (TLS) истекают незамеченными, целые сервисы гаснут сразу, а отказ ничем не похож на ошибку кода. Автоматизируйте выпуск и продление, отслеживайте даты истечения централизованно и оповещайте задолго до срока. Решайте намеренно, где завершается TLS: на пограничном балансировщике нагрузки, на прокси или вплоть до сервиса. Завершение на границе упрощает внутренний трафик, но оставляет внутренний переход нешифрованным, если не шифровать заново. Центры сертификации, ротация ключей и выбор шифров рассматриваются в главе 4.8; здесь эксплуатационный вывод в том, что DNS и сертификаты отказывают тихо и увлекают за собой всё, поэтому инструментируйте и автоматизируйте оба.

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

Балансировка нагрузки распределяет трафик по многим бэкендам, и место, где вы это делаете, важно. Балансировщик уровня 4 (L4) маршрутизирует по IP-адресу и порту, не читая содержимое, поэтому он быстр, независим от протокола и дёшев. Балансировщик уровня 7 (L7) понимает HTTP, поэтому может маршрутизировать по пути или заголовку, завершать TLS, повторять идемпотентные запросы и принуждать к ограничениям частоты ценой большей работы на запрос. Большинству трафика приложений нужен обратный прокси L7 или API-шлюз на границе, дающий одно место для TLS, аутентификации, маршрутизации и наблюдаемости. Оставляйте L4 для сырой пропускной способности или не-HTTP протоколов.

Проверки здоровья делают балансировку безопасной. Настраивайте их так, чтобы они отражали реальную готовность, а не просто «процесс запущен», чтобы бэкенд, не способный достучаться до своей базы данных, выводился из ротации до выдачи ошибок, и сливайте соединения при развёртываниях, чтобы запросы в полёте завершались. API-шлюз централизует сквозные заботы (аутентификацию, ограничение частоты, формирование запросов, версионирование), но становится критичной зависимостью и потенциальным узким местом, поэтому дайте ему тот же бюджет доступности и наблюдаемости, что и любому основному сервису.

Приближайте данные к пользователям с помощью CDN и края

Задержка определяется временем кругового обхода, а время кругового обхода определяется расстоянием. Сеть доставки содержимого (CDN) кэширует содержимое в точках присутствия рядом с пользователями, так что статические ресурсы, а всё чаще и динамические и персонализированные ответы, отдаются с расстояния нескольких миллисекунд вместо пересечения океана. Для любого пользовательского продукта с географически разбросанной аудиторией CDN одно из самых окупаемых вложений в производительность, и оно же служит щитом, поглощающим всплески трафика и объёмные атаки.

Переносите работу на край там, где это помогает. Завершение TLS на краю сокращает задержку рукопожатия, потому что дорогие круговые обходы происходят рядом с пользователем, а кэширование ответов API в пограничных точках укорачивает путь для частых запросов. Цена в инвалидации кэша: чем ближе и больше кэшировано ваши данные, тем труднее гарантировать свежесть, поэтому будьте явны в том, что может быть устаревшим и как долго. Это связано с обсуждением кэширования и производительности в главе 3.5.

Делайте границу сети устойчивой по умолчанию

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

Распределяйте свои тайм-ауты вниз по цепочке вызовов. Если у пользовательского запроса двухсекундный бюджет и он пересекает четыре перехода, каждый переход должен знать, как мало времени осталось, и быстро отказывать, а не повторять в пустоту. Повторно используйте соединения через пулы и keep-alive, чтобы не платить за свежие рукопожатия TCP и TLS на каждый запрос, и следите за хвостовой задержкой, а не только за средними, потому что медленный один процент это то, что помнят пользователи и что каскадирует под нагрузкой.

Проектируйте и управляйте топологией своей сети

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

Принимайте модель безопасности нулевого доверия: перестаньте воспринимать «внутри сети» как доверенное и аутентифицируйте и авторизуйте каждый запрос на основе идентичности, а не расположения в сети. На практике это означает взаимный TLS между сервисами, краткоживущие учётные данные и политику, не предполагающую безопасности запроса только потому, что он пришёл из соседней подсети. Сервисная сетка может обеспечить многое из этого единообразно. Запуская прокси-«коляску» (sidecar) рядом с каждым сервисом, сетка даёт взаимный TLS, согласованные повторы и тайм-ауты и телеметрию по переходам без изменения кода приложения. Она добавляет эксплуатационную сложность и некоторую задержку, поэтому принимайте её, когда число сервисов делает единообразное бескодовое принуждение достойным накладных расходов. Нулевое доверие и сегментация развиваются далее в главах 4.3 и 8.3.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы / цена
Балансировщик L7 / API-шлюз	Умная маршрутизация, завершение TLS, аутентификация, ограничение частоты, наблюдаемость	Больше задержки на запрос, критичная общая зависимость
Балансировщик L4	Быстрый, независим от протокола, дешёвый	Не видит и не действует на HTTP, нет маршрутизации по содержимому
Завершение TLS на краю	Более быстрые рукопожатия, более простые бэкенды	Внутренний переход нешифрован, если не шифровать заново
CDN и кэширование на краю	Большой выигрыш в задержке, поглощает всплески и атаки	Инвалидация кэша и устаревание, дополнительные стоимость и настройка
Сервисная сетка	Единообразный mTLS, повторы, телеметрия без изменения приложений	Эксплуатационная сложность, задержка и ресурсная цена sidecar
HTTP/3 поверх QUIC	Нет блокировки головы очереди на транспорте, быстрая установка, миграция соединения	Более новые инструменты, UDP иногда ограничивают, труднее отлаживать

Центральное напряжение между контролем и простотой. Каждый мощный компонент, добавляемый на границе сети (шлюз L7, сетка, CDN, исходящий прокси), покупает вам интеллект маршрутизации, принуждение безопасности и видимость, и каждый же добавляет переход, режим отказа и то, что нужно эксплуатировать. Разрешайте это переносом общих забот в общую инфраструктуру только тогда, когда достаточно команд в этом нуждаются, чтобы оправдать эксплуатационный вес, и держанием быстрого пути коротким. Команда из двух человек, завершающая TLS на управляемом балансировщике и на этом остановившаяся, делает лучший выбор, чем та же команда, вручную собирающая сервисную сетку. Корпорация из тысячи сервисов без единообразного взаимного TLS и контроля исходящего трафика делает худший.

Вопросы для обсуждения с командой

Где завершается TLS на каждом из ваших путей запроса и могут ли все нарисовать это одинаково? Это звучит как мелочь, пока не случится инцидент. Если половина команды считает трафик зашифрованным от конца до конца, а другая знает, что он расшифровывается на границе и отправляется открытым текстом на бэкенд, у вас и дыра в безопасности, и ловушка для отладки. Для большой организации этот вопрос напрямую отображается на соответствие: регуляторы и аудиторы спросят, где данные граждан или клиентов путешествуют в открытом виде, и «мы не уверены» это находка. Принесите настоящую диаграмму одного реального пути от клиента до базы данных, отметив каждую точку, где шифрование начинается и заканчивается, и кто держит каждый сертификат и ключ. Ответ должен сказать вам, нужно ли внутреннее повторное шифрование, где место взаимному TLS и какие сертификаты вывели бы сервис из строя при истечении. Если никто не может нарисовать это уверенно, этот разрыв ваша первая задача.
Что происходит с вашей системой, когда DNS медленный или неверный, и вы действительно это тестировали? DNS стоит выше по течению почти каждого запроса, однако большинство команд никогда не наблюдали свою систему при деградации DNS. Медленный преобразователь добавляет задержку к каждому новому соединению, устаревший кэш может направить трафик на выведенный из эксплуатации хост, а неудачное изменение записи может отправить целый сервис в чёрную дыру за секунды. В большой корпорации радиус поражения шире, потому что внутреннее обнаружение сервисов, партнёрские интеграции и облачные конечные точки опираются на разрешение имён. Принесите ваши настройки TTL DNS, метрики задержки разрешения, если они есть, и ранбук на случай неудачного изменения записи, а затем спросите, как быстро вы действительно смогли бы перенаправить трафик во время инцидента. Ответ должен определить, мониторите ли вы разрешение как первоклассную метрику, настраиваете ли TTL и для гибкости, и для эффективности кэша и репетируете ли переключение DNS при отказе. Если вы никогда не вызывали отказ DNS в контролируемом тесте, этот эксперимент место в календаре.
Какие шаблоны устойчивости на границе сети являются платформенными умолчаниями, а какие каждая команда изобретает заново? Тайм-ауты, ограниченные повторы с джиттером, предохранители, пулы соединений и трассировка по переходам дешевле и надёжнее всего, когда построены один раз и унаследованы всеми. Оставленные отдельным командам, они расходятся: у некоторых вызовов нет тайм-аута, некоторые повторяют неидемпотентные операции, некоторые не испускают телеметрию на уровне соединений, а пробелы проявляются только под нагрузкой. Для большой команды это организационный выбор о том, где живёт устойчивость, в общей библиотеке или платформенном слое против разбросанности по сервисам. Принесите аудит выборки сервисов, считающий, сколько из них задают явный тайм-аут на каждый удалённый вызов и передают идентификатор корреляции от конца до конца. Если это число низко, исправление это платформенное вложение, а стандартизация также делает устойчивость тестируемой и проверяемой, что всё важнее в регулируемых секторах. Ответ должен сказать вам, финансировать ли платформенную сетевую возможность или продолжать платить за непоследовательность в инцидентах.
До чего может дотянуться каждая из ваших нагрузок в публичном интернете прямо сейчас и кто санкционировал каждое из этих исходящих назначений? Входящий трафик получает внимание, потому что туда стучатся атакующие, но исходящий это то, как данные на самом деле уходят при взломе и как скомпрометированная нагрузка «звонит домой» серверу управления и контроля. Большинство команд могут перечислить, что обращается к ним, гораздо легче, чем к чему обращаются они, и эта асимметрия именно тот разрыв, который эксплуатирует атакующий. Противоположное соображение трение: список разрешённых назначений замедляет разработчиков, которые хотят вызвать новый сторонний API сегодня, поэтому честный спор о том, сколько удобства вы меняете на сжатый радиус поражения. Принесите текущие исходящие правила для репрезентативного сервиса, снимок того, куда он на самом деле подключался за прошлую неделю, и процесс (если есть) утверждения нового назначения. Для корпоративных и государственных систем это не необязательная гигиена, а пункт аудита: защита границ и описи исходящего трафика ровно то, что регуляторы и правила защиты границ сети требуют предъявлять, а «любая нагрузка может достучаться куда угодно» это находка, которую вам скажут исправить.
Складываются ли ваши тайм-ауты и повторы в один согласованный бюджет вниз по каждой цепочке вызовов или каждый переход гадает в изоляции? Пользовательский запрос, пересекающий четыре сервиса, имеет единственный срок, который пользователь действительно ощущает, однако каждый переход обычно задаёт свой тайм-аут локально, повторяет в сервис, уже отказавшийся, и разрушает сквозной бюджет, делая лишнюю работу. Для большой команды опасность эмерджентна: по отдельности разумные тайм-ауты сервисов складываются в каскадные остановки и синхронизированные штормы повторов, которые никакая команда не видит со своей панели. Напряжение между локальной автономией, где каждая команда настраивает свои пределы, и передаваемым сроком, который каждый переход читает и сокращает по мере траты времени. Принесите настоящий путь запроса с политикой тайм-аутов и повторов на каждом переходе, сквозным бюджетом, обещанным продуктом, и вашими числами хвостовой задержки (p99, а не среднее) под нагрузкой. В регулируемых контекстах и контекстах высокой доступности свяжите это с вашими целями восстановления: цепочка, не способная быстро отказать в рамках своего бюджета, превращает одну медленную зависимость в нарушенную цель уровня обслуживания, и это нарушение то число, которое руководство и аудиторы попросят вас объяснить.
При каком числе сервисов и профиле трафика единообразное принуждение (сервисная сетка, шлюз L7, кэширование на краю) окупает свой эксплуатационный вес и где вы находитесь на этой кривой сегодня? Каждый мощный компонент, добавляемый на границе сети, покупает интеллект маршрутизации, безопасность и видимость, и каждый же добавляет переход, режим отказа и то, что нужно эксплуатировать круглосуточно. Примите сетку слишком рано, и вы утопите горстку сервисов в сложности sidecar; примите слишком поздно, и у вас тысяча сервисов без единообразного взаимного TLS или согласованных повторов. Конкурирующие соображения это ценность бескодового согласованного принуждения по многим командам против реальной цены эксплуатации плоскости управления, добавленной задержки и дефицитных людей, умеющих её отлаживать. Принесите текущее число сервисов и кривую роста, долю сервисов, уже использующих общие клиенты, дающие те же гарантии, и запас задержки, который можно потратить. Для большой корпорации или ведомства решение также вопрос управления: сетка или центральный шлюз позволяет платформенной команде развернуть политику повсюду разом, что мощно для соответствия и опасно, если эта единая точка сужения недоукомплектована, поэтому бюджетируйте её как основную инфраструктуру с собственной целью доступности, а не побочный проект.

Взгляд по секторам

Стартап. Опирайтесь на управляемую инфраструктуру и тратьте дефицитное инженерное внимание на продукт, а не на пакеты. Управляемый балансировщик L7, завершающий TLS с автоматически продлеваемыми сертификатами, плюс CDN перед приложением покупают вам шифрованный, сбалансированный по нагрузке, глобально быстрый трафик без эксплуатационной команды. Оборачивайте каждый внешний вызов в небольшой общий клиент с тайм-аутом и ограниченным повтором и сопротивляйтесь сервисной сетке, пока сервисов не станет намного больше, чем людей, способных её эксплуатировать.

Малый бизнес. У вас нет сетевого специалиста и ограниченный бюджет, поэтому воспринимайте связность как то, что вы покупаете настроенным, а не строите. Выбирайте облачного провайдера или платформу, чьи умолчания уже дают автоматизированные сертификаты, управление DNS и разумный межсетевой экран, и включайте то, что они предлагают, а не собирайте сами. Где приходится решать, предпочитайте управляемый вариант: оплата поставщику за продление сертификатов и мониторинг DNS гораздо дешевле отказа от забытого истечения.

Крупная организация. Ваша проблема согласованность по многим командам и регионам: единообразный взаимный TLS, стандартизированные тайм-ауты и повторы, контролируемый исходящий трафик и мониторинг сертификатов и DNS, от которого ни одна команда не может отказаться. Переносите это в общую платформенную инфраструктуру (сервисная сетка, внутренний шлюз, общая клиентская библиотека), чтобы устойчивость наследовалась, а не изобреталась заново, и управляйте границей сети с тем же бюджетом доступности и наблюдаемостью, что и любой основной сервис. Сегментируйте VPC, управляйте исходящим трафиком централизованно и воспринимайте топологию как программу, которую вы проверяете.

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

Примеры

Стартап. Компания «программное обеспечение как услуга» из десяти человек запускает всё за единственным управляемым балансировщиком L7, завершающим TLS с автоматически продлеваемыми сертификатами, и ставит CDN перед веб-приложением и API. Эта комбинация даёт быструю глобальную загрузку страниц, поглощает случайный всплеск трафика от запуска продукта и защищает исходный сервер без выделенной эксплуатационной команды. Они задают явный тайм-аут и ограниченный повтор на каждом вызове платёжного провайдера и почтового сервиса, обёрнутые в небольшой общий клиент, так что медленная третья сторона никогда не подвешивает пользовательский запрос. Они сопротивляются добавлению сервисной сетки: с дюжиной сервисов эксплуатационная цена превзошла бы выгоду, а управляемая инфраструктура уже даёт им шифрованный сбалансированный трафик.

Крупная организация. Международный ритейлер работает в трёх облачных регионах и унаследованном локальном центре обработки данных, соединённых частными линиями, а не публичным интернетом, чтобы трафик склада и платежей никогда не пересекал открытые сети. Каждый регион находится в сегментированном VPC с раздельными публичными подсетями, подсетями приложений и данных, а весь исходящий трафик идёт через шлюзы, разрешающие списком утверждённые назначения, так что скомпрометированная нагрузка не может тихо вывести данные. Сотни сервисов общаются через сервисную сетку, везде принуждающую взаимный TLS и применяющую единообразные повторы, тайм-ауты и трассировку, позволяя центральной платформенной команде развернуть новую политику повторов, не трогая код приложений. Централизованный мониторинг сертификатов отмечает истечения за дни, а автоматизация ротирует их до того, как заметит любой клиент.

Государственный сектор. Национальное ведомство работает по правилам защиты границ сети, направляющим весь трафик в интернет через небольшой набор укреплённых мониторимых шлюзов в соответствии с моделью доверенных интернет-соединений. Межведомственный трафик идёт по частным соединениям, а каждая внешняя конечная точка внесена в опись, так что команды безопасности знают точно, что может входить и выходить. Ведомство поддерживает архитектуру нулевого доверия, в которой сервисы аутентифицируются друг перед другом по идентичности с краткоживущими учётными данными, и ни один запрос не считается доверенным лишь потому, что он возник внутри периметра. Управление DNS и сертификатами воспринимается как критичная инфраструктура с выделенным мониторингом, потому что один истёкший сертификат или неудачное изменение зоны могли бы вывести из строя портал пособий для граждан и вызвать и общественное, и законодательное внимание.

Бизнес-обоснование: мотивы, ROI и TCO

Сетевая дисциплина покупается дёшево, а её отсутствие оплачивается в худший возможный момент. Вложения в основном разовые и платформенной формы: общие клиенты с тайм-аутами и повторами, автоматизированное управление сертификатами, мониторинг DNS, разумно сегментированный VPC и кэширование на краю. Каждое приносит пользу каждой команде, которая его наследует, поэтому предельная цена на команду низка, а отдача накапливается. CDN в частности нередко окупается дважды, сокращая затраты на исходящую пропускную способность исходного сервера и улучшая числа конверсии и вовлечённости, следующие из более быстрой загрузки страниц.

Цена пропуска этой работы измеряется отказами и взломами. Истёкший сертификат или неудачное изменение DNS могут вывести из строя весь продукт за минуты, а исправление задерживается, пока инженеры гоняются не за тем уровнем. Отсутствующий тайм-аут может каскадировать одну медленную зависимость в полную остановку платформы. Неконтролируемый исходящий трафик превращает единственную скомпрометированную нагрузку в инцидент вывода данных. Формулируйте обоснование для руководства в терминах, которые оно уже отслеживает: доступность, среднее время восстановления, время загрузки страниц и риск взлома. Автоматизированное управление сертификатами и DNS предотвращает категорию самонанесённых отказов, вложения в край и CDN двигают продуктовую метрику производительности, а сегментация и контроль исходящего трафика сжимают радиус поражения взлома. Аргумент совокупной стоимости владения тот, что повторяется по всему этому руководству: встроить возможность стоит долю цены её дооснащения после инцидента, который вынудит этим заняться.

Антипаттерны и ловушки

Допущение, что сеть надёжна и быстра. Кодирование так, будто удалённые вызовы локальны, без тайм-аутов, повторов и обработки случая «истёк тайм-аут, но, возможно, завершилось».
Ручное управление сертификатами. Отслеживание истечения в таблице или чьей-то памяти, гарантирующее будущий отказ, когда срок истечёт незамеченным.
Игнорирование DNS как эксплуатационной системы. Нет мониторинга разрешения, небрежные TTL и изменения записей без строгости развёртывания.
Повторы без идемпотентности или задержки. Дублированные побочные эффекты и синхронизированные штормы повторов, раздувающие небольшой сбой до отказа.
Доверие внутренней сети. Воспринимание всего внутри периметра как безопасного, с нешифрованным внутренним трафиком и без авторизации на основе идентичности.
Неконтролируемый исходящий трафик. Разрешение нагрузкам достигать любого исходящего назначения, что вручает атакующим путь вывода данных и канал к серверам управления.
Болтливые пути запросов. Глубокие синхронные цепочки вызовов, где каждый переход добавляет круговой обход, так что хвостовая задержка раздувается под нагрузкой.
Слишком ранний переход на сервисную сетку. Принятие сложности и задержки sidecar для горстки сервисов, которым лучше послужил бы общий клиент.

Модель зрелости

Уровень 1, Начальный: Удалённые вызовы воспринимаются как локальные. Тайм-ауты и повторы отсутствуют или наивны, а «истёк тайм-аут, но, возможно, завершилось» не обрабатывается. Сертификаты и DNS управляются вручную и вызывают неожиданные отказы. Нет сегментации, а внутренний трафик по умолчанию доверенный. Работа со связностью реактивна и происходит лишь после того, как инцидент вынуждает.
Уровень 2, Развитие: Некоторые команды приняли базовые практики, но они непоследовательны между сервисами. Тайм-ауты и простые повторы есть кое-где, TLS завершается на балансировщике нагрузки, а сертификаты в основном автоматизированы. CDN стоит перед статическим содержимым и существует базовая сетевая сегментация, хотя исходящий трафик в основном открыт, а каждая команда изобретает свой клиент. То, что одна команда делает хорошо, другая ещё не начала.
Уровень 3, Стандартизация: Устойчивая сеть документирована и соблюдается по организации. Тайм-ауты, задержка с джиттером и предохранители стандартны через общие библиотеки или шлюз, который наследует каждая команда. DNS и сертификаты мониторятся и автоматизированы как производственные системы, VPC сегментированы с контролируемым входящим и исходящим трафиком, телеметрия на уровне соединений собирается повсюду, а принципы нулевого доверия принимаются как политика, а не эксперимент одной команды.
Уровень 4, Управление: Граница сети измеряется и контролируется относительно базовых значений, а не только стандартизирована. Задержка разрешения, время рукопожатия TLS, доли повторных передач и ошибок соединений, хвостовая задержка (p99, а не среднее), запас времени до истечения сертификатов и нарушения политики исходящего трафика отслеживаются на панелях с порогами оповещений и бюджетами ошибок. Решения «пускать или нет» и о мощности основаны на этих данных, вызываемые учения по отказу DNS и зависимостей проводятся по расписанию, а их результаты измеряются, и регрессия любого сигнала замечается и получает владельца, а не обнаруживается в следующем отказе.
Уровень 5, Оркестрация: Устойчивая сеть это непрерывно улучшаемое платформенное умолчание, интегрированное по организации и адаптивное к изменениям. Взаимный TLS и авторизация на основе идентичности единообразны, часто через сервисную сетку; стратегия края и CDN настраивается по живым данным о задержке; исходящий трафик полностью управляем; а выбор топологии, провайдера и маршрутизации перебалансируется по мере сдвигов стоимости, риска и трафика. Сетевые решения вплетены в планирование мощности, безопасности и бизнеса, а организация явно рассуждает о круговых обходах, хвостовой задержке и режимах отказа границ как о само собой разумеющемся.

Идеи для обсуждения

Если бы ваш основной провайдер DNS или преобразователь деградировал на час, какая часть вашей системы всё ещё работала бы и как бы вы об этом узнали?
Какие из ваших сервисов всё ещё отправляют трафик нешифрованным, оказавшись «внутри» сети, и что потребовалось бы, чтобы закрыть этот разрыв?
Где в вашей архитектуре самые глубокие синхронные цепочки вызовов и сколько сетевых круговых обходов на самом деле несёт типичный пользовательский запрос?
Складываются ли ваши тайм-ауты вниз по цепочке вызовов в согласованный бюджет или каждый уровень задаёт свой и надеется?
До чего могут дотянуться ваши нагрузки в публичном интернете прямо сейчас и кто утвердил каждое из этих исходящих назначений?
При каком числе сервисов единообразное принуждение сервисной сетки перевесило бы её эксплуатационную цену для вашей организации и насколько вы близки?

Главные выводы

Сеть это зависимость со своими режимами отказа; проектируйте каждый удалённый вызов под медлительность, потерю и неоднозначное завершение, а не только успех или чистый отказ.
Задержка определяется круговыми обходами и расстоянием, поэтому сокращайте переходы, повторно используйте соединения и приближайте данные к пользователям с помощью CDN и края.
DNS и сертификаты TLS отказывают тихо и выводят из строя целые сервисы; автоматизируйте и мониторьте оба как производственные системы.
Балансируйте нагрузку на уровне, подходящем трафику, и ставьте общие заботы за шлюз L7 только тогда, когда цена доступности и наблюдаемости оправдана.
Делайте границу сети устойчивой по умолчанию с тайм-аутами, ограниченными повторами с джиттером и предохранителями, в идеале как унаследованные платформенные умолчания.
Сегментируйте свой VPC, управляйте исходящим трафиком, планируйте IPv6 и принимайте нулевое доверие, чтобы нахождение «внутри» сети не давало автоматического доверия.

Источники и дополнительное чтение

W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols
Ilya Grigorik, High Performance Browser Networking
Cricket Liu and Paul Albitz, DNS and BIND
Andrew S. Tanenbaum and David J. Wetherall, Computer Networks
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Lee Calcote and Zack Butcher, Istio: Up and Running (service mesh concepts)
Internet Engineering Task Force, RFC 9110 (HTTP Semantics) and RFC 9000 (QUIC)
Peter Deutsch and James Gosling, “The Eight Fallacies of Distributed Computing”
National Institute of Standards and Technology, Special Publication 800-207: Zero Trust Architecture