За последний год 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 (и продолжаю делать): с какими проблемами сталкивался, как выбирал стек, как не бросил проект на полпути — и что получилось в итоге.
Выбор VPS для размещения сайта на 1С-Битрикс – задача не менее важная, чем разработка самого сайта. Битрикс известен своей ресурсоёмкостью: без оптимального хостинга даже хорошо написанный сайт может «тормозить» и отпугивать посетителей. Высокая скорость загрузки напрямую влияет на конверсию и удовлетворенность пользователей – никто не станет ждать по 5–10 секунд открытия страницы интернет-магазина (если только вы не продаёте терпение оптом, и знаете кого-то лично в совете директоров Яндекса и Гугла, что можете себе позволить медленный ресурс). Поэтому правильный выбор VPS под Bitrix – залог быстрой работы сайта, особенно под нагрузкой.
Более того, хоть я и не считаю себя гуру, но у меня был неудачный опыт и я понял на практике, что часть проблем можно решить, если у хостера компетентная поддержка, которая разбирается в деталях и знает тонкости системы. Проблемы могут вылезти порой в самых неожиданных местах. И я решил помимо нагрузочных тестов добавить сюда раздел про техподдержку.
termis с государственного сайта, источник
Можно много раз говорить, что резервное копирование — это база и необходимая функция для надежной работы с данными в любой системе. А можно раз показать, как мы в нашей инфраструктуре реализовали механизм бэкапов. С учетом специфики виртуальных машин, OpenStack и современных инструментов, обеспечивающих сжатие, дедупликацию и безопасное хранение данных.
Привет, Хабр! Меня зовут Игорь Шишкин, я руковожу командой R&D в облачном направлении Рег.ру и являюсь архитектором наших сервисов — в этой статье расскажу, как мы создавали бэкапы в облаке. Далее о том, как выбирали инструменты для реализации, строили архитектуру и что мы делаем, когда пользователи устраивают тот еще квест — дружно решают забэкапиться в одно время.
Статья рассказывает о том, как облачное объектное хранилище S3 можно интегрировать с Kubernetes с помощью решений от Deckhouse и файловой системы GeeseFS. Автор объясняет, зачем вообще подключать S3 как том для контейнерных приложений, какие задачи это решает и почему для этого выбран именно GeeseFS. А ещё честно указывает на подводные камни — ограничения по скорости, отсутствие привычных файловых атрибутов, особенности кэширования и диагностику.
C 2019 года мир привыкал к новой реальности и приспосабливался к удаленной работе. На дворе 2025 год и теперь вызов для распределенных команд — не просто организовать совместную работу вне офиса, но и подготовиться к блокировкам сервисов, к которым уже успели привыкнуть. Как организовать работу небольшой команды разработчиков (до 50 человек), если у вас нет отдела DevOps и бесконечного бюджета на on-premise и облака, а каждый новый день доступных сервисов становится всё меньше? В статье постараюсь ответить на этот вопрос.
Я Олег Юрчик — старший python-разработчик, сейчас работаю в Cloud.ru За последние два года я организовывал инфраструктуру для трех небольших команд (до 15 человек), а еще около двух лет держу домашний сервер с семейной инфраструктурой: файлохранилище, менеджер паролей, календарь, книгу контактов и так далее. Хочу поделиться, к каким решениям я пришел за это время, а также пошагово, но не вдаваясь в подробности, рассказать, как развернул собственную цифровую крепость.
