Сергей Ковалёв

Меня зовут Сергей, в Selectel я работаю в департаменте IaaS-продуктов и отвечаю за выделенные серверы, которые мы сдаем в аренду. Число клиентов растет каждый год — вместе с ними растет потребность в новых серверах и комплектующих. Чем больше становится оборудования, тем сложнее контролировать его наличие на складе и вовремя планировать новые поставки. Но это часть моей работы. Чтобы облегчить эту задачу, я, не программист, написал скрипт, который стал дополнительным инструментом управления постоянно меняющимися цифрами наличия комплектующих. Для начала поясню, как я дошел до написания скриптов. До Selectel я более 6 лет работал в международной торговой компании. В числе моих задач была аналитика показателей филиала и рынка региона в целом. Инструментом анализа данных о складе и продажах были OLAP-кубы и Excel. В какой-то момент возможностей этой системы уже не хватало, и я познакомился с библиотекой Pandas, открыв для себя возможности Python для анализа данных. Думаю, дата-аналитики подтвердят, что на сегодняшний день это универсальный и эффективный инструмент. Полученные знания я решил применить и в Selectel. Немного контекста Мы в Selectel сами собираем серверы. То есть не получаем собранные вендорами машины в коробочке, а закупаем так называемую «рассыпуху» — комплектующие серверов от процессоров до карт памяти, дисков и так далее. Это более выгодное и гибкое решение: мы не ограничены в возможных конфигурациях и можем предоставлять как фиксированные, так и кастомные сборки. Чтобы поддерживать рост компании, необходимо регулярно закупать новое железо для выделенных серверов, но и не забывать о том, что уже куплено, но не сдано клиентам. Для анализа таких данных мы используем несколько BI- и ERP-систем. С их помощью получаем информацию о расходе комплектующих, остатках на складе, свободных серверах фиксированных конфигураций и арендованных серверах. Однако возможностей систем аналитики не всегда достаточно. В таких случаях приходится лезть в БД и обрабатывать «сырые» данные. В случае, если такие данные необходимы регулярно, аналитика автоматизируется. Почему понадобился скрипт 2021 год был ознаменован кризисом полупроводников, и это отразилось на регулярности поставок оборудования. Чаще стали возникать ситуации, когда отдельные детали задерживаются и собрать конкретную конфигурацию сервера невозможно. При этом остальное железо лежит на складе и снижает показатели оборачиваемости. Подвидов комплектующих и вариаций их использования очень много. По очень грубым подсчетам в конфигураторе серверов можно собрать несколько тысяч серверов в разных вариациях (при наличии всех комплектующих на складе). На сегодняшний день в арсенале выделенных серверов более пяти линеек актуальных процессоров: Intel® Xeon® Scalable 3rd, AMD EPYC™ 7003, Intel® Xeon® W, Intel® Xeon® E, десктопный сегмент. Менее «свежее» железо также доступно к заказу — начиная от предыдущих поколений масштабируемых процессоров Intel® Xeon® Scalable и AMD EPYC™ и заканчивая Intel® Xeon® E3. Под разные модели процессоров применяются совместимые материнские платы, может отличаться тип оперативной памяти. Также, например, на запасы на складе влияет возможность использования масштабируемых процессоров в материнских платах с разным количеством сокетов и их распределения относительно друг друга. Все это усложняет управление заказами и остатками комплектующих на складе. При очередном планировании возник вопрос, какое максимальное число готовых серверов мы можем собрать прямо сейчас из имеющихся на складе комплектующих всех поколений? Какое железо остается и что является блокером для его использования? Вариант 1: ручной сбор отчета Готового отчета с ответами не было, но ручную выгрузку никто не отменял. С помощью Excel и данных по остаткам на складах я определил соответствие процессоров и материнских плат, просуммировав по семействам, и рассчитал, сколько серверов и с каким объемом памяти мы можем собрать. На расчеты потратил несколько часов и решил, что подход интересный — стоит пользоваться им чаще. Вариант 2: подключение аналитиков Для автоматизации отчетов с данными в Selectel можно обратиться к сотрудникам департамента аналитики. Они могут делать сложносочиненные дашборды, которые подтягивают данные десятков источников. Для этого нужно сформулировать задачу, цель дашборда, обсудить нюансы с коллегами и запустить в работу. Вариант 3: самописный скрипт На этапе формулирования задачи BI-специалистам мне стало понятно, что требования к отчету не очевидны и мне нужно протестировать детали на уровне заказчика. Python для этого подходит лучше, чем Excel, так как позволяет загрузить входящие данные и обработать их скриптом, быстро внести необходимые правки и изменения. Я решил создать прототип отчета с помощью библиотеки Pandas и проверить, как и с какими данными он будет работать. И уже после этого поставить задачу департаменту аналитики. Верхнеуровнево в создаваемом отчете было достаточно расчетов по количеству процессоров, совместимых материнских плат и оперативной памяти. Я решил начать с этих компонентов, но впоследствии прибавил к ним корпусы и дополнительные сетевые карты. Создание скрипта Дисклеймер: Все данные, продемонстрированные далее, получены с помощью функции random на входе и не отражают реальные запасы компании, так как такие данные относятся к коммерческой тайне. Также напомню, что я не программист, а категорийный менеджер. Скрипт я написал, чтобы проверить гипотезу о том, насколько полезен был бы такой отчет. Это MVP, главная задача которого — просто работать. А значит, код может быть неидеальным. Входящие данные На входе в отчет используется файл Excel со следующими данными: Наименование (name_seido) и количество комплектующих (qty) выгружаются из учетной системы, столбец type прописывается вручную и содержит в себе тип, семейство комплектующей и количество сокетов для материнских плат. Также доступна выгрузка в Google Sheets, откуда впоследствии можно загрузить датасет в Jupyter Notebook. После загрузки данных файла в датасет на основе столбца type создаются соответствующие столбцы: Функции для расчета Проще всего рассчитать количество доступных для сборки серверов для односокетных материнских плат и совместимых процессоров. Алгоритм функции прост: необходимо определить, чего из двух типов комплектующих меньше, и по этому числу вывести количество серверов. Так же рассчитывается тип и количество «лишних» комплектующих. Для ряда комплектующих масштабируемые процессоры могут устанавливаться как в односокетные материнские платы, так и в двухсокетные. В таком случае задается пропорция. В примере ниже на 60% двухсокетных материнских плат рассчитывается 40% односокетных. Функция усложняется: на первом шаге рассчитываются показатели для односокетных материнских плат, а на следующем — для двухсокетных за вычетом процессоров, использованных на первом шаге. Но и это еще не все. В рамках одного поколения могут существовать масштабируемые процессоры, процессоры, работающие только в одном сокете, и соответствующие материнские платы. Функция для расчета в таком случае предполагает сначала распределение single-процессоров в односокетные системы, затем распределение масштабируемых процессоров в одно- и двухсокетные материнские платы и платформы: Ничего не понятно, но жутко интересно. Как это работает на практике Intel® Xeon® E-23xx Первый пример — для нового поколения процессоров Intel® Xeon® E-23xx. Минимальная номенклатура комплектующих, только односокетные материнские платы и платформы. Результат выполнения кода на экране, пора закупать процессоры: Intel® Xeon® Scalable 3-го поколения Усложним задачу и рассмотрим новейшее поколение Intel® Xeon® Scalable. Это масштабируемые процессоры, которые можно установить как в односокетные, так и в двухсокетные материнские платы или платформы. Что видим после выполнения кода: Ситуация с процессорами повторяется: их снова недостаточно. При этом один процессор — лишний, так как число процессоров четное, а односокетных материнских плат — нечетное. В целом видно, что их значительно меньше, чем двухсокетных. Возможно, также стоит докупить односокетные платформы или материнские платы. Напомню, что в тестовом датасете число CPU рандомное, но в реальной жизни процессоры могут задерживаться или частично не приехать вообще. Тогда и возникает оверсток по материнским платам. Об этом, как правило, известно и так, однако скрипт позволяет посчитать показатели быстрее. AMD EPYC™ 7003 И наконец, вишенка на торте — AMD EPYC™ 7003. То самое поколение, в котором есть single-процессоры, масштабируемые процессоры и материнские платы с разным количеством сокетов: Какие делаем выводы: не хватает односокетных материнских плат и масштабируемых процессоров. Общий итог Общий итог по всем серверам рассчитывается просто: Получаем желаемый результат в виде общего числа потенциальных серверов и разбивку по поколениям. Расчеты для оперативной памяти, корпусов и сетевых карт. На примере регистровой памяти DDR4: В коде определяется размер памяти по наименованию и рассчитывается общий объем памяти этого типа на складе. Далее происходит пересчет на один сервер исходя из общего количества серверов с данным типом памяти: Аналитика поверхностная и не учитывает соотношение планок по размерам, зато она отлично работает как красный флаг для закупки. В нашем примере DDR4 ECC REG на складе недостаточно. Для потенциальной сборки всех серверов не хватит. Четыре строки кода о корпусах и сетевых картах: Если после исключения платформ (а они здесь исключены) материнских плат меньше, чем корпусов, необходимо действовать — докупать разницу. В более подробной аналитике, безусловно, также необходимо проверить совместимость и расход разных типов комплектующих. По сетевым картам решение очевидно — пора оформлять заказ. Что в итоге Во-первых, на написание скрипта я потратил несколько часов. И он работает, без привлечения существенных ресурсов компании. Теперь для формирования отчета по остаткам на складе мне не нужно столько же времени «залипать» в Excel. Во-вторых, при проверке на реальных данных я подсчитал количество доступных к сборке серверов по семействам и поколениям. С удивлением обнаружил дисбаланс комплектующих — например, материнских плат в одном случае и планок памяти в другом. Что примечательно, в обоих случаях для устаревших платформ, например, один из типов DDR3 на складе в избытке. Будем искать ему применение. К работе подключится отдел сборки, так как один из вариантов борьбы с таким оверстоком — создание новой фиксированной конфигурации. Также ничего не мешает нам добавить к актуальным остаткам информацию о количестве комплектующих, которые находятся в пути и гарантированно приедут в ближайшее время. Результат расчетов меняется, иногда кардинально. Если выявляется недостаток актуального железа, которое мы закупаем, логично отправить заявку в отдел закупок на поставку недостающих комплектующих. Минус скрипта — в том, что он не интегрирован в общую систему отчетов. Для его запуска необходимо вручную, пусть и в два клика, добавить актуальные остатки и запустить Jupyter Notebook. Возможно, в дальнейшем мы все-таки сформулируем требование и интегрируем его в BI-систему Selectel. Но сейчас стоимость разработки скрипта в соотношении к выдаваемому результату оптимальна, а тестирование, учет остальных блокеров и поиск новых показателей продолжается.

Сергей Ковалёв

Материалы автора