Наверняка вы все работаете с Kubernetes, публикуете сервисы наружу через Ingress-контроллер. Уверен, что большинство из вас использует ingress-nginx. Создаете манифест, деплоите его в k8s, но не всегда получаете именно тот результат, который хотели бы. Или же все работает, но спустя какое-то время что-то идет не так. 

В этой серии статей, созданной по мотивам выступления на DevOpsConf’25, мы подробно разберемся как работает сам ingress-nginx контроллер и почему это не совсем классический nginx. Погрузимся в дебри LUA-кода чтобы понять, как реализована балансировка. А также затронем тему сниппетов, как их включить если они вам очень нужны, и почему этого делать не стоит.

Меня зовут Алексей Колосков, я Lead DevOps из Hilbert Team. Больше 15 лет я в IT: за это время админил, разрабатывал, развивал on-premise инфраструктуру, инфраструктуру в облаках и даже курсы по DevOps, Security и DataTech в Yandex Cloud. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.

Привет, Хабр! Меня зовут Анатолий Кохан, я — DevOps-инженер в К2Тех.

Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.

Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.

Привет! Наверное, у каждого рано или поздно возникает вопрос: как упорядочить хаос с купленными (да, мы же против пиратства?) книгами в форматах PDF, DJVU и других, так чтобы:

- получить к ним доступ как с мобильного устройства, так и с любимого ПК или Mac;

- сохранять прогресс чтения между устройствами;

- не терять книги в куче папок.

Хочу поделиться решением, которое помогло мне организовать библиотеку.

Данных в современных приложениях становится все больше, прямо как снежный ком. И рано или поздно многие системы начинают задыхаться – база данных не справляется. Когда старые добрые методы вроде подкрутки запросов, добавления индексов или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета), на помощь приходит горизонтальное масштабирование.

Привет, Хабр!

В этой статье рассмотрим, почему безобидная строчка await fetch() неожиданно превращается в тормоз, где именно она зарывает драгоценные миллисекунды — и что можно сделать с этим.

Привет, Хабр!

В этой статье разберём важнейший механизм защиты от перегрузок и DoS-атак в NGINX — лимиты.

Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь). 

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

Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста). 

Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам. 

Согласны? Узнали? Тогда поехали!

Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.

Вы думали, что путь от Senior Developer до Tech Lead — это всего лишь прибавка к зарплате и новый пункт в резюме? Увы. Техлид - это не только про разработку, но и про управление командой в штормовые времена, сохранение продукта в моменты кризиса, а еще про самодисциплину и менеджмент.

От вас будет зависеть не только качество кода, но и весь проект.

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

Сегодня затронем такую неожиданную тему как работу с брокером сообщений Nats на PHP. Как оказалось, есть очень мало статей на эту тему, так что попробуем с этим разобраться и реализовать базовую работу с очередью.

По мотивам статьи: Не пиши простой код и старого манифеста

Эта статья о других, о тех кто случайно просто пишет код, или кому случайно пришлось писать код раньше. Или о тех, кто случайно код не пишет, но очень хочет.

Просто пиши код, пока остальные на митинге спорят, в какую борду переместить эту таску. Потому что ни одна Jira не напишет багфикс.

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

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

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

Просто пиши код, потому что вместо инвестиций в инженеров компания вкладывалась в настолки и ворклайф баланс — теперь у нас в офисе есть чемпион по "Evolution", но инженеры не знают как пользоваться профайлером.

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

Простопиши код, потому что когда ты пытался разделить архитектуру на слои и модули, тебе отвечали: «Это всё теоретизация, у нас бизнес и фичи». А теперь этот бизнес держится на толпе джунов и пачке jsonов.

Просто пиши код, потому что Хабр завален «Как я продаю на маркетах когтеточки» и «Как я уволился ради душевного баланса», а вот статью про memory fences или perf counters — хрен найдёшь.

❯ Механизм согласования

В моих предыдущих статьях (1, 2) я подробно рассматривал, как работает React.memo, а также делился более эффективными подходами к оптимизации производительности с помощью компоновки. Однако для глубокого понимания работы React необходимо разобраться в основном механизме, лежащем в основе всех этих оптимизаций – алгоритме согласования (reconciliation).

Согласование – это процесс, в результате которого React приводит DOM в соответствие с деревом компонентов. Именно этот механизм позволяет реализовать декларативный подход к программированию на React: вы формулируете свои намерения, а React самостоятельно определяет, как выполнить эти намерения наилучшим образом и с наименьшими затратами.

Разработка отказоустойчивых систем представляет собой важнейшую компетенцию для инженеров, занятых созданием распределённых и масштабируемых приложений. Под отказоустойчивостью понимается способность системы сохранять работоспособность в условиях сбоев отдельных компонентов или недоступности внешних сервисов. В данной статье рассматриваются практики обеспечения устойчивости на уровне программного кода, в частности в контексте серверных приложений, реализованных на языках Python и Java.

Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.

Simple Storage Service или S3 — сервис (и одновременно протокол) для хранения данных большого объёма. Для работы использует API поверх HTTP, который позволяет загружать или получать объекты из хранилища.

В проектах с приватной инфраструктурой часто возникает потребность в организации on-premise S3-хранилища. Популярное решение в таком случае это MinIO — удобная и довольно простая в использовании реализация сервиса S3.  Когда нам в RUTUBE потребовалось S3, мы не стали долго думать и взяли MinIO, потому что он стильный, модный, молодежный хорошо себя зарекомендовал на рынке, хорошо документирован и прост в первоначальной настройке и эксплуатации. 

В этой статье поделюсь своим опытом использования MinIO, сделав акцент на отказоустойчивости и сохранности данных в случае инцидентов разной степени — от выпадения диска до пожара в цоде.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

В одном из больших кластеров S3 в Точке хранится 110 терабайт полезных данных. Это не много по объёму, но он распределён среди 600+ миллионов файлов. Стоимость работы системы оценивается более чем в миллион рублей в месяц — это с учётом фактора репликации, бэкапов, основной системы хранения и резерва ресурсов. Это пятое место по стоимости среди всех сервисов.

Мы выбрали SeaweedFS, потому что это удобный конструктор, который позволяет загружать файлы любого размера, легко масштабироваться без деградации скорости доступа и надёжно защищать данные от потерь. В статье рассказываю, каким должно быть идеальное S3-хранилище для миллионов файлов, и почему нам не подошли Ceph и Minio.

В сентябре 2024 года вышел релиз Valkey 8.0 — это key-value-хранилище также часто называют BSD-клоном Redis. В отличие от Redis, Valkey изначально создавался как опенсорс-проект. У него нет энтерпрайз-версии, а значит, развитие не сдерживается коммерческими ограничениями.

Весной 2024 года, когда началась активная работа над форком, команда разработчиков смогла принять и стабилизировать ряд патчей, которые заметно улучшили производительность по сравнению с Redis 7.2.

В этой статье Евгений Дюков, разработчик Managed Databases в Yandex Cloud, разбирает некоторые из изменений и делится результатами проведённых бенчмарков, которые позволяют оценить, как именно новые патчи повлияли на производительность — и в позитивном, и, в некоторых случаях, в негативном ключе. Особенно интересно будет тем, кто ждёт релиз Valkey 8.1 этой весной.

Если экземпляр PostgreSQL был некорректно остановлен, то перед восстановлением файлов выполняется синхронизаций всех файлов кластера. Способ синхронизации определяется параметром конфигурации recovery_init_sync_method. В статье рассматривается, как ускорить запуск экземпляра и резервирование, если в директории PGDATA много файлов.

Привет, Хабр! Меня зовут Илья, я работаю в команде физического дизайна в дивизионе полупроводников YADRO. Проектирую цифровые микросхемы, помогаю с образовательными программами и привлекаю студентов в наше дело. В этой статье я расскажу про разработку современных микросхем с фокусом на этап проектирования топологии, объясню, что такое SoC (System-on-Chip, cистема на кристалле) и как мы проектируем их в нашей команде. А напоследок покажу, где об этом всем можно узнать на собственном опыте.