Любая большая инфраструктура выживает за счёт унификации всего и вся. По-другому просто не получится, и все эти Ansible, Puppet, Terraform и прочие Pet vs Cattle - как раз про это. Как управлять большим флотом с минимумом усилий.

Про инфраструктуру железную всё тоже самое. Унификация оборудования, стоек, решений и дизайнов - всё это просто неизбежно при масштабировании. Отчётливо помню первый мой опыт столкновения с реальностью: когда я переехал в СПб, работал в провайдере связи, сначала настройщиком оборудования. На тот момент было правило: аплинк всегда в первом порту. Не важно, 100Мбит он или гиг, аплинк всегда в первом медном или оптическом порту (емнип, резервный порт настраивался на последнем). На первый взгляд это же неэффективно! Ведь есть специальные аплинк порты! Но это только на первый. Зато монтажнику не нужно ничего долго объяснять по телефону, и перепутать что-то крайне сложно. А т.к. основным клиентом провайдера были юр. лица и трафик был небольшой, то даже 100мбит хватало с запасом.

Для любителей можжевельника: первый порт считался как "самый левый нижний/верхний".

Я, разумеется, сразу попытался объяснить, что если использовать аплинк-порты, то когда-нибудь потом мы сэкономим кучу усилий на переключениях... Но на тот момент решение было абсолютно оправдано, потому что экономило десятки часов в месяц на скорости подключений. А чем больше подключений за день - тем больше денег у провайдера.

Собственно это вообще суть современного IT: масштабирование дешёвых и не самых эффективных решений.

Для сервис-провайдера (не важно, интернет, облако или что-то ещё) унификация и автоматизация это вообще залог выживания. Всё, начиная от бизнес-процессов и заканчивая настройкой клиентского сервера должно быть максимально автоматизировано, потому что работа человеков стоит дорого (даже у нас в РФ), и масштабировать персонал теми же темпами, что и флот серверов нереально. Вторым фактором для выживания является цена - потому что на объёмах даже в пару десятков стоек сто баксов экономии с каждой - это уже $2000 в месяц, которые можно потратить на расширение аплинка, например.

Теперь вернёмся к эффективности и стойкам. С точки зрения web-scale проекта, эффективный дизайн - это 35-40 серверов на стойку + 3 ToR свича (2xdata + oob). Могут быть опции - роутеры, консольные серверы, storage-свичи и т.д. Потребляет это счастье те самые 9-10кВт в пике, что требует размещение в трёхфазной стойке (√3x16Ax380V). Почему одна на 11, а не две по 7 (1x32Ax230V)? потому что проще с коммутацией, проще искать в мониторинге и планировать работы и экономится одна пара PDU (причём обычно switched, а не просто metered) и не нужно покупать/арендовать ещё одну стойку. И если для компании такой дизайн стал стандартом, она будет продавливать его везде, пока это будет оправдано с точки зрения TCO, а не просто месячного платежа оператору.

Если у провайдера нет своего дата-центра (а даже если и есть), то адаптироваться он будет к самым дешёвым и доступным решениям на рынке, которые решают его задачу - просто потому что иначе не сможет конкурировать по цене. Поэтому местами это будет б/у оборудование (почему нет?), metered PDU (а иногда и просто блоки розеток - если архитектура позволяет), а стойки - 5кВт. Потому что решение массовое, стоимость понятная и проще мириться с перерасходом стоек/пду, чем искусственно ограничивать себя в возможностях роста.

Да, в отдельных случаях и под конкретный проект можно и PDU поставить подороже, и стойки помощнее и вообще сделать лакшери. Только заплатит за это в конечном счёте клиент - за доп. позиции ЗИП на складе, за более высокую стоимость в пересчёте на кВт или (что хуже) за сложности с дальнейшим расширением.

Вот и получается, что либо делать полностью своё, как условный Яндекс (и при этом самостоятельно считать финмодель под свои задачи), либо адаптироваться к тому, что даёт рынок - и тут без компромиссов никак.

#snakeslair_sr @snakeslair