💹 Видишь сбой? И я не вижу. А он есть

Иногда в системах возникают коварные ситуации: проверки состояния показывают, что всё хорошо, но по факту ничего не работает. Это называется «серый отказ».

На связи Александр Душеин, технический лидер команды архитекторов Yandex Cloud. Давайте разбираться, как возникают серые отказы и как Zonal Shift помогает с ними справиться.

❇️ Что-то может пойти не так на уровне сети

Один из вариантов серого отказа — сбой в сетевой связности, когда в одних направлениях она работает, а в других нет. Например, могут сбоить каналы интернет‑провайдеров.

Целевые ресурсы бэкенда в повреждённой зоне доступности могут по‑прежнему отвечать на все проверки Health Check и показывать зелёный статус. При этом они перестают обрабатывать весь трафик или начинают генерировать ошибки.

Эта ситуация может нарушить работу системы, ведь сетевой балансировщик всё ещё будет рассчитывать на бэкенд со сбоями и статусом «Всё ок!».

❇️ Иногда что-то ломается на уровне приложения

На уровне L7 ситуация с серыми отказами становится серьёзнее. Частичная деградация связности может привести к дополнительному ухудшению запросов между зонами: трафик из больной зоны начинает переливаться в здоровую. И наоборот.

🧬 Для управления такими ситуациями мы создали Zonal Shift

Это инструмент для управляемого закрытия конкретной зоны доступности на конкретном балансировщике. Он пригодится не только в ситуации частичных отказов, но и при необходимости закрыть балансировку в зоне доступности, чтобы провести учения или регламентные работы.

Zonal Shift поддерживает два режима:

🟢 Полное закрытие всех балансировщиков в зоне доступности

🟢 Закрытие тех, на которые клиент сам повесил признак «Можно потушить»

Для сетевого балансировщика этот признак позволит сразу перераспределить трафик в другие зоны. Функциональность Zonal Shift поддерживается и на уровне L7, так что в более сложной схеме также можно избежать каскадного сбоя из‑за амплификации. Мы можем явно выключать балансировку на бэкенды в зоне доступности, а семантически это работает аналогично сетевой балансировке (NLB).

При этом важно помнить, что Zonal Shift закрывает не зону, а балансировку трафика в неё. Например, если у клиента есть Kubernetes в нескольких зонах доступности, то микросервисы также будут размещены в них и будут общаться между собой горизонтально.

❇️ Что важно учесть

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

🟢 Делать проверки готовности целевых ресурсов с интервалом не более 3 секунд

🟢 Указывать корректный порог работоспособности и неработоспособности. Значения должны быть строго больше одной проверки

🟢 Следить за тем, чтобы реализация проверок не требовала много ресурсов для генерации ответа. Тогда не будет повышенной нагрузки

🔶 А ещё мы подготовили чек‑лист для работы с ALB-сервисами. Ищите его в статье на Хабре. В ней же мы рассказываем, какие именно настройки балансировщиков критически важны для защиты от серых отказов, и делимся подробными инструкциями по отказоустойчивости.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

⚙️ Фестиваль технологий и инженерного воображения

24 сентября мы провели Yandex Neuro Scale — главную конференцию Yandex Cloud. Традиционно многие интерактивы и активности создавали сами разработчики для разработчиков.

Что происходило на площадке:

🟢 Говорящие грибы. Мы подключили мицелий к нейросетям через нейроинтерфейс. Грибы генерировали сигналы, которые YandexGPT превращала в текст, а SpeechKit — в голос

🟢 Серваки и сосиски. На стенде Infrastructure гости собирали серверы, а мы наглядно тестировали безопасность стоек с помощью пальцев-сосисок

🟢 Хаос в Контейнерленде. Мы создали отдельную вселенную, где сервисы не отвечают, поды падают, а хранилища недоступны. Участники могли попробовать себя в роли мастера K8s и исправить типичные ошибки в коде, чтобы всё спасти

🟢 Мечты о будущем можно было визуализировать на платформе SourceCraft, попрограммировав немного с ИИ-ассистентом и подправив YAML-конфиг. Все результаты стали частью частью общего «вихря образов»

Ребята прочитали более 50 докладов, провели 14 воркшопов и организовали 9 зон экспо. Кстати, на офлайн-часть конфы пришли три тысячи участников! Окунуться в атмосферу Yandex Neuro Scale можно по ссылкам ниже ⬇️

➖ Фото
➖ Презентации
➖ Доклады

🔶 А полный разбор нашего техноперформанса вы можете почитать на Хабре.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🎙 Приходите на Backend Talks

Привет! А у нас новость: команда Яндекс 360 зовёт бэкенд-разработчиков и архитекторов на митап.

🧬 На нём разберём архитектуру облачной записи встреч, наведём порядок в API и покажем, как простые решения спасают сервисы.

🗺 Санкт-Петербург
📆 13 ноября, 19:00–23:00

В программе:

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

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

🟢 Никита Ломакин, разработчик в команде Техплатформы. Расскажет, почему важно следить за качеством API, и поделится практиками, которыми пользуются в Яндекс 360 и которые позволят сделать ваш API более качественным и удобным

✨ А после докладов вас будут ждать афтерпати и нетворкинг.

🔶 Регистрируйтесь по ссылке

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

💹 Как текст в логах замедляет браузер и что можно с этим сделать?

Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера и улучшаю опенсорсные решения, которые там используют.

История началась со стажировки, на которой я взялся сократить полные пути в логах до имени path/to/filename → filename. Казалось бы, простейшая задачка, но она потянула за собой целую цепочку проблем: от увеличения размера DLL до необходимости залезть в исходный код компилятора Clang, чтобы добавить в него новый макрос.

Это рассказ о том, как я решил проблему полных путей в логах, после чего получил офер на позицию мидл-разработчика. И наглядный пример того, как небольшие оптимизации помогают двигать вперёд большие проекты.

❇️ Зачем вообще сокращать полные пути до имени файла?

При запуске того же Браузера в ОЗУ загружаются разные файлы, которые необходимы для работы программы. И чем больше размер требуемых файлов, тем дольше будет идти старт приложения. Это особенно больно для пользователей без SSD. Попробуете угадать, какой процент таких среди аудитории Яндекс Браузера? Ответ: 27%.

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

❇️ Использование имени вместо пути только в одном из двух C/C++-макросов логирования (LOG и FROM_HERE) вначале показалось идеей без минусов…

Но этот подход дал обратный эффект! DLL увеличилась, потому что при одновременном использовании обоих макросов логирования в одном файле в DLL запишутся две разные строки: имя файла для модифицированного макроса LOG и полный путь для другого макроса FROM_HERE. Получается, что суммарный размер строк стал больше, а не меньше. Выходит, чтобы решить задачу, надо улучшить оба макроса одновременно.

❇️ В статье на Хабре я разбираю:

🟢 Небольшое изменение, ускорившее старт Браузера на 2%
🟢 Что такое __builtin_FILE() и чем он отличается от обычного __FILE__
🟢 Как я создал __builtin_FILE_NAME() в Clang, когда понял, что нужного макроса не существует
🟢 Почему уменьшение DLL без негативных эффектов — это успех

🔶 Читайте полную версию статьи на Хабре! Там я подробно рассказываю, как повлиял на инструмент, которым пользуются разработчики по всему миру.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend