Облачные сервисы *

Облако — большой и сложный продукт, поэтому и процесс тестирования может растянуться… Всем привет! На связи Галина Чупрова, главный инженер по тестированию Облака Рег.ру. В какой-то момент мы с командой поняли, что чем раньше начать тестирование — тем меньше багов получим на выходе. В статье расскажу про этапы, которые помогут устранить «узкие горлышки» в процессе проверки качества продукта и подключить команду с первых шагов проекта. Будет полезно тем, кто начинает путь в тестировании или хочет по-новому взглянуть на процессы в своих командах. Поехали проходить этот квест!

Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud.

Мы создаём облако, в котором удобно запускать и управлять проектами: от простых ВДС до масштабных решений с Kubernetes и десятками интеграций. Мы много думаем о том, как сделать инфраструктуру не только стабильной, но и понятной.

Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой?

Что подключено к балансировщику? В какой сети находятся серверы? Почему не пингуется база? Ответы есть, но они спрятаны в разных разделах интерфейса или требуют обращения в поддержку.

Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать.

Мы сделали визуальную карту, на которой можно не просто увидеть ресурсы, но и настроить их расположение как в реальной жизни: сгруппировать, пояснить, добавить связи и комментарии. Это не просто картинка — это инструмент, который помогает понимать, как всё устроено, и быстрее находить проблемы.

Это как перейти от чтения логов к полноценной карте: наглядно, понятно, живо. Визуализация стала тем самым недостающим элементом, который помогает по-настоящему понять, как устроена инфраструктура.

В июне облаку Рег.ру исполняется два года — время оглянуться назад и провести ретро по крупным продуктовым релизам. А их за это время было порядка 350! Кажется, еще недавно мы рассказывали о запуске обновленной облачной платформы, а уже сейчас — уверенно работаем с полным спектром облачных решений.

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

За последний год AI встраивается буквально во всё. Ещё недавно его приходилось отдельно запускать. Теперь он встроен везде. Даже те, кто не ставил себе отдельные плагины, уже взаимодействуют с AI каждый день. Он вшит в SaaS-продукты и работает в фоне. Иногда так, что пользователь об этом вообще не знает.

Вот здесь и появляется первый важный вопрос: Что происходит с твоими данными?

Оптический бюджет в ВОЛС: Невидимая грань между работоспособностью и отказом. Как не оступиться в эпоху 100G+ и плотных ЦОД?

Представьте: вы спроектировали идеальную магистраль, выбрали "качественные" компоненты, смонтировали... И линк не поднимается. Или работает, но с ошибками. Или стабилен сегодня, но "падает" при нагреве летом. Часто корень зла кроется в нарушении оптического бюджета мощности (Optical Power Budget - OPB). Это не абстрактная цифра из даташита – это фундаментальный закон сохранения энергии в мире оптики. Игнорируете его – гарантируете себе головную боль. Сегодня, с ростом скоростей (100G, 400G, 800G) и плотности в ЦОД, понимание и точный расчет OPB критичны как никогда. Давайте разберемся, что это, из чего складывается, где поджидают ловушки и как избежать фатальных ошибок.

1. Суть Оптического Бюджета: Проще, Чем Кажется (На Словах)

По сути, OPB – это разница между мощностью, которую передатчик (Tx) излучает в волокно, и минимальной мощностью, необходимой приемнику (Rx) для корректной работы (чувствительностью) с учетом требуемого запаса (System Margin).

Упрощенная формула:
OPB = P_Tx_min - P_Rx_min - System_Margin

Где:

В этом руководстве рассматривается современный подход к безопасности — Zero Trust Network Access (ZTNA) — и показано, как его реализовать с помощью SPIFFE/SPIRE и OpenID Connect (OIDC). Материала много, по этому я предоставлю его в сухой форме.

В основе ZTNA лежит принцип «никогда не доверяй, всегда проверяй»: каждый запрос на доступ считается потенциально небезопасным и проходит обязательную аутентификацию и авторизацию. По сравнению с классическими VPN-сетями решения ZTNA на базе SPIFFE/SPIRE и OIDC: Ускоряют процедуру аутентификации в 20–80 раз, Повышают производительность на 46–64 %, В облаках AWS и Google Cloud позволяют снизить задержки до 50–100 мс вместо привычных 2–4 с.

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

В этой статье рассмотрим основные сценарии и преимущества использования зарубежных облачных сервисов для бизнеса.

Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков.

Привет, друзья!

В этой серии статей я делюсь с вами своим опытом решения различных задач из области веб-разработки и не только.

В этой статье мы научимся разворачивать Angular+Java веб-приложение на виртуальном сервере Ubuntu Linux с помощью Ansible.

Интересно? Тогда прошу под кат.

Привет! Меня зовут Алексей Федулаев, я руковожу направлением Cloud Native Security в MWS Cloud Platform. Вместе с Андреем Моисеевым мы в этой статье подробно разбираем, как устроены атаки на CI/CD, и почему автоматизация без должной защиты может обернуться серьёзными инцидентами.

Мы покажем, как злоумышленник может получить секреты из пайплайна, обойти security-джобы через конфигурации, скомпрометировать Docker Registry и внедрить вредоносный образ в продакшн. Также разберём, почему даже подпись артефактов не всегда спасает, если есть доступ к раннерам и окружению сборки.

Предупреждён — значит вооружён.

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

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

Yandex Cloud использует квоты для мягкого контроля ресурсов. Квоты можно легко увеличить через специальную форму или техническую поддержку. Однако, очень часто бывает, что о необходимости увеличить квоты мы узнаем поздно, например, когда падает джоба с terraform. Это раздражает, а в некоторых случаях даже может сломать стейт и принести ненужные проблемы. Решить проблему поможет маленькая утилита.

Привет! Я Михаил Абраш — старший Go-разработчик, работаю в команде Evolution AI Factory в Cloud.ru. Недавно мы начали активно внедрять новые сервисы, переходя с Python на Go, и заметили, что нагрузка между репликами распределяется неравномерно. У нас в команде не было единого подхода к тому, как правильно делать балансировку, поэтому решили провести небольшое R&D-исследование. Что из этого вышло, к чему мы в итоге пришли и как работает балансировка gRPC в целом, рассказал в статье. 

Привет, меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud — это крупный облачный провайдер с большой командой и множеством внутренних и внешних продуктов.

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

Так родился statuser.cloud — простой сервис для мониторинга доступности сайтов и серверов. Я хотел сделать его:

— с минималистичным и понятным интерфейсом,

— ориентированным в первую очередь на разработчиков, девопсов, админов,

— с набором действительно нужных фич, ничего лишнего.

В этой статье я расскажу, как вечерами и на выходных делал Statuser (и продолжаю делать): с какими проблемами сталкивался, как выбирал стек, как не бросил проект на полпути — и что получилось в итоге.

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

Привет, Хабр! Меня зовут Игорь Шишкин, я руковожу командой R&D в облачном направлении Рег.ру и являюсь архитектором наших сервисов — в этой статье расскажу, как мы создавали бэкапы в облаке. Далее о том, как выбирали инструменты для реализации, строили архитектуру и что мы делаем, когда пользователи устраивают тот еще квест — дружно решают забэкапиться в одно время.

Статья рассказывает о том, как облачное объектное хранилище S3 можно интегрировать с Kubernetes с помощью решений от Deckhouse и файловой системы GeeseFS. Автор объясняет, зачем вообще подключать S3 как том для контейнерных приложений, какие задачи это решает и почему для этого выбран именно GeeseFS. А ещё честно указывает на подводные камни — ограничения по скорости, отсутствие привычных файловых атрибутов, особенности кэширования и диагностику.