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

Еще несколько лет назад большинство инцидентов вокруг API выглядело довольно предсказуемо. Если приложение начинало вести себя подозрительно, специалисты искали ошибки авторизации, проблемы контроля доступа, признаки SQL-инъекций или попытки эксплуатации известных уязвимостей. Логика была простой: есть уязвимость => есть эксплуатация => есть последствия.

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

По прогнозу Международного энергетического агентства (МЭА), к 2030 году дата-центры, ИИ и криптовалюты должны суммарно потреблять около 945 ТВт·ч в год — столько же, сколько сейчас потребляет вся Япония. Центр тяжести этого предложения — в слове «должны». Как бы ни прекрасна была мечта об AGI, все низменно и редукционистски упирается в банальную проблему — в доступность электроэнергии. Но если бигтехи в пресс-релизах обещают открывать огромные десятигигаваттники, значит, проблем с питанием нет — правда же? Да?

А давайте проверим.

Привет, Хабр! Меня зовут Максим Темнов, я руковожу департаментом постгарантийной сервисной поддержки (ПГСО) в «РТК-ЦОД». Это девять складов с комплектующими, более ста тысяч «железок» на поддержке и специалисты, готовые привезти и установить ЗИП за считанные часы. Мы выручаем заказчиков с ИТ-оборудованием, когда угасает последняя надежда на его производителей или вендоров. В условиях санкций, штрафов, дефицита на российском рынке и сложных логистических цепочек в хорошем провайдере ПГСО важно… все. Его компетенции и ресурсы — единственная волшебная таблетка для заказчика. В статье расскажу, как обстоят дела с «железом» сейчас и почему паниковать на этот счет не стоит.

Привет, Хабр! Меня зовут Александр Власов, 6 лет назад я создал Лабораторию R&D в «РТК-ЦОД» и с тех пор ей руковожу. О том, как работала наша команда в те далекие времена, я уже рассказывал на Хабре. С тех пор нам — впрочем, как и всем остальным инженерам и разработчикам — пришлось многое пережить. Мы росли и количественно, и качественно. Росло количество, а иногда и качество, российского «железа» и ПО, которое мы испытываем. О том, до чего все доросло, я и хочу рассказать.

Всем доброго времени суток! Мы — Руслан Алиев, главный эксперт, и Михаил Калганов, начальник отдела вычислительных комплексов Лаборатории R&D «РТК-ЦОД». Наш отдел проводит испытания различного вычислительного оборудования и программных решений.

Основная задача испытаний — определение степени соответствия СХД требованиям проектов, в которых предполагается ее использовать.

Привет, Хабр. Меня зовут Илья Самылов, я работаю в NGENIX и отвечаю за сопровождение сервисов информационной безопасности, анализ веб-атак и бот-активности. 

За последние пару лет ИИ в кибербезопасности стал универсальным объяснением всего. Любая сложная атака — «это нейросеть». Любой аккуратный фишинг — «генеративный ИИ». Я же предпочитаю разделять маркетинг и реальность. Но реальность в том, что профиль атак действительно изменился. И это видно не в презентациях, а в логах.

Сегодня расскажу, как ИИ реально чувствует себя в веб-безопасности и как влияет на борьбу атакующих и защитников.

Всем привет! Сегодня поговорим об Open Source Intelligence (далее по тексту — OSINT), разведке на основе открытых источников. Это систематизированный процесс поиска в интернете — не взлом и не покупка слитых баз — общедоступной информации и ее дальнейшая аналитика. К методам OSINT прибегают как в легальных целях, так и с недобрым умыслом. Как все это выглядит на практике?

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

Привет! Меня зовут Денис Мухин. Я руковожу управлением мониторинга в РТК-ЦОД. Расскажу о том, как должен работать грамотный мониторинг и зачем он вообще нужен.

Наш ЦОД «Медведково», о котором мы уже рассказывали, в 2024 году стал кластером, так как рядом был построен еще один дата-центр — «Медведково-2». В этой статье мы покажем, как устроен новый ЦОД.

Здание «Медведково-2» возвели за год, параллельно проводили интеграцию инженерных систем. К 2024 году ЦОД полностью подготовили для проведения аудита и сертификации. Дата-центр успешно прошел испытания Uptime Facility и получил сертификат Tier III.

Выкатили новый проект. База — на PostgreSQL. Все работает. DBA в штате нет, база крутится на виртуалке, обновления никто не трогал, мониторинга нет. И вот ночь, все падает. Начинается экстренный чат, поиск багов, попытки восстановиться из бэкапа… если он вообще был.

Так случается, когда инфраструктура и сопровождение баз данных остаются на совести команды разработки. Чтобы избежать этого, все чаще используются управляемые СУБД в облаке — сервисы, где ключевые задачи закрываются автоматически или силами провайдера.

На связи продуктовая команда РТК-ЦОД, и в этой статье мы расскажем, как устроены облачные базы и зачем они бизнесу.

Недавно мы обновили BareMetal 2.0 в составе нашего «Публичного облака». Теперь в инфраструктуре есть выделенные физические серверы с высокопроизводительными GPU-картами. Они позволяют работать с задачами, где критична скорость вычислений.

Расскажем, что именно изменилось и какие задачи можно теперь решать быстрее.

Привет, Хабр! Я Роман Лысенко, начальник отдела систем резервного копирования в РТК-ЦОД. Четыре года назад я пришел в РТК-ЦОД специалистом 1-й линии ТП. Через два года я стал работать уже в отделе СРК, но с теплом вспоминаю период в техподдержке.

Такое начало карьеры — один из самых естественных и эффективных способов роста в IT. Многие молодые айтишники могут сомневаться в этом, задаваясь вопросом: «Зачем начинать с техподдержки, если можно сразу выбрать более интересные и высокооплачиваемые роли?» Для того чтобы разрушить основные мифы и стереотипы о работе в техподдержке и рассказать подробнее о профессии, я решил написать эту статью.

Привет! Меня зовут Олег Рябов, я главный эксперт Управления исследований и разработок новых решений компании «Ростелеком-ЦОД» и автор программы и методики испытаний (ПМИ) серверов.

В этой статье расскажу, как мы проводим тестирование серверов и какие утилиты и методы используем.

Привет, меня зовут Александр, я руковожу Управлением исследований и разработки новых решений в «Ростелеком-ЦОД», если коротко — лабораторией R&D.

Сейчас лаборатория хорошо прокачана и продуктивна, но так было не всегда. В этой статье я расскажу, как мы ее создавали, к чему пришли и как тестируем оборудование, ПАК и ПО.

Меня зовут Андрей, я работаю в группе резервного копирования в компании «Ростелеком-ЦОД». Мы отвечаем за хранение и целостность резервных копий наших клиентов и поддержку инфраструктуры РК в оптимальном состоянии. В этой статье я хочу рассказать о том, как мы смогли значительно упростить мониторинг статуса заданий в системе резервного копирования Veeam, создав мощный инструмент на основе Grafana. Этот инструмент позволяет нам получать ценные метрики и статистику о производительности и состоянии нашей инфраструктуры резервного копирования.

Мы открыли новый дата-центр «Ростелеком-ЦОД» в Медведково. Строительство началось в июле 2022 года на базе складского комплекса класса А+, первый этап был реализован за 9 месяцев.

Сегодня в эксплуатацию принято 4 машинных зала из шестнадцати. Каждый из них может вместить до 312 стандартных серверных шкафов, т. е. всего 1248 стойко-мест. Общая электрическая мощность четырех машинных залов и поддерживающей инженерной инфраструктуры составляет 9 МВт.

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

Кроме своих наработок, я также использовал материалы из разных англоязычных источников. По некоторым вопросам описания тянули на отдельные статьи, поэтому на них я дал ссылки.

Иногда возникают ситуации, когда требуется работать с базой данных VMware Cloud Director не только с поддержкой инженеров вендора, но и самостоятельно: могут залипнуть объекты, невозможно переконфигурировать ВМ, не получается удалить или создать какие-либо объекты, необходимо перенастроить БД, восстановить работу PostgreSQL HA Cluster и т. д.

Хочу поделиться опытом настройки и работы со встроенной БД на примере версии Cloud Director 10.х.

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