⚙️ Нужно больше надежности! Неделя надежности!

📆 Закончилась Podlodka TechLead Crew 7. Это онлайн конференция, посвященная техническим аспектам разработки систем.
На прошлой я победил как участник. В призах был свободный вход на любую из следующих встреч) Решил им воспользоваться)

Уровень "класс"! 👍
Сами доклады, общение Q/A, дискуссии в чате. На каких-то докладах присутствовал. Остальные посмотрю в записи.

Что посмотрел, запомнилось:
I. Александр Агейченко - «Надежный как кирпич»
Мир фронтенда чудесный и многообразный. И в возможностях. И в моментах, когда что-то может пойти не так(или всё).

• Улучшаем наблюдаемость.
Отслеживаем ошибки у клиентов:

Вы даже не представляете какие интересные тексты ошибок иногда показываются клиентам.

Жизнь.

• Crash-free.
По финтеху 99.6% нормально. Измеряют, к примеру, Firebase, Sentry. Больше крашей -> ухудшение рейтинга в поисковой выдаче.
Также советы по технологиям, ведению проекта.

• Обсуждение про бюджет ошибок, приоритеты.
Если не работает фича с низким бизнес приоритетом у малого количества пользователей - не факт, что её нужно чинить сейчас же.
Возможно, у тебя рядом ещё лёг модуль совершения банковской операции. Соберётся бизнес, тех лиды проекта. И выберут приоритет. Разработчики, зачастую, уже стоят где-то далеко в ожидание тикета.

• Как откатывать?
Задал вопрос по деплою. Оказывается, никак 🤷 Не принято в этом дивном новом мире. Если приоритет не работающей новой фичи большой, то делаем быстро хотфикс. Даже, возможно, в процессе текущей выкладки/обновления. Заставлять пользователя обновиться потом: "Не войдёшь, пока не обновишься!", - не лучшая практика. Оставляем на случаи обновления совсем старых неподдерживаемых версий.
Что ещё можно сделать? Использовать feature flags. Флагами включать, отключать функционал.

Александр дорос до этой менеджерской позиции из разработчика столкнувшись с типичными болями разработки на фронте. Поэтому смотрит на проблему уже как с технической, так и с бизнесовой стороны. Было интересно в конце уже не под запись заспамить вопросами. И что ценно - получить ответы.

Продолжение в следующем посте 👌

❓А как ты улучшаешь надежность своего сервиса?

⚙️ Куда она закатилась? Надежность. Продолжаем осмыслять.

☝️ Ты думал, что знаешь всё про архитектуру? Давай осмыслим её ещё раз!
Хотел бы осветить следующий доклад, на котором получилось присутствовать онлайн и задавать вопросы после.

Филипп Дельгядо - «Где искать надежность при взаимодействии сервисов?»
Какие реальные взаимодействия стоят за нарисованными квадратами и стрелками? Почему то что принято считается надежным by default?
Филипп предлагает задуматься над стандартными архитектурными паттернами. Разбирает их надежность. Исходя из опыта описывает различные сценарии что может произойти и как сделать лучше.

• Надежность
💻 ❌ Вдобавок к проблемам самого приложения и транспорта нужно помнить о проблемах с железом.
• Железный пример
Вводная:
Есть сервер. Живёт 55000 часов. Есть резервный. Узнаём, что сервер умер за 1 секунду. За 2 секунды можем восстановиться.
=>
Вероятность потери всех сообщений за эти 2 секунды - 1 раз в миллиард лет.☝️
• Железный пример + Приложение
Приложение падает каждый день из-за утечек памяти. Узнаём за 30 секунд(http таймаут). Вероятность потерять все сообщения за 30 секунд - 1 раз в 6 лет.
• +100 сервисов по 20 экземпляров
Взаимодействие каждый с каждым. 20 млн взаимодействий. Проблемы 4 раза в сутки. 🙁

• Взаимодействия
🤍 ⁉️ Yже давно запросы от клиента напрямую не ходят в сам сервис. Кто-то стоит посередине - api gateway, loadbalancer, service mash.
Если прошёл таймаут на обработку сообщения(клиенту нужен результат быстро или не нужен вообще), то сообщение уже не нужно обрабатывать. Такой наплыв сообщений лишним грузом повисает на плечах сервиса.
Получается, что хоть экземпляр сервиса и доступен, и service mash роутит на него запрос, но обработка уже явно займёт больше таймаута.
=>
• Нужно как минимум реализовывать механизм heartbeat - периодическая проверка, что экземпляр живой.
• И ещё лучше докрутить логику - если этот экземпляр отвечает за 20 миллисекунд вместо 10 в прошлый раз, пошлю запрос в другой. Это будет лучше, чем ожидать долгого ответа пускай от даже, вроде бы, живого экземпляра.

• Паттерны
➕Знакомая очередь посередине. Она должна развязать producer'а от consumer'а. Как бы не так!
➖Зависимости стали косвенными! Не понятно - consumer переключился на новую версию или нет!

Брокер должен знать про число партиций. Это легко не поменять.
Producer знает каким образом consumer хочет чтобы его данные партиционировались. Т.е. producer должен обладать информацией о внутренней реализации консьюмера, чтобы корректно сформировать события, отправляемые в топик.

Очень ценная мысль! В http не надо знать каким образом устроен получатель.
Упомянуты битвы в крупных компаниях про число партиций в топике, количеств топиков в целом.😣
=>
Приходит на помощь паттерн Transaction Inbox!
Вносим очередь в сам сервис, который и потребляет данные. Заход через его api.

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

Хочешь ещё разборов докладов? -> ⚡️
Насколько тебе легко работается с очередями?

🏃 В погоне за BIG TECH!

➕ Расширяем контекст подготовки к прохождению собеседований в BIG TECH компании новым каналом "Укусанный литкодом".

Знаю автора очень хорошо. Можно сказать, он мой давний друг 😊
Сейчас активно готовится в 🔤🔤🔤🔤🔤🔤. Пройдёт ли в этот раз? :) Достаточно ли 100 намеченных решенных задач для этого?

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

https://www.tgoop.com/leetcode_bytes_you/3

⭐️ System Design LeetCode / TeamLead Avito

✔️ Смонтировал для тебя состоявшийся стрим с Евгением - тимлидом из Авито. Вышло ёмкое учебное пособие по прохождению интервью за 1 час :)

➡️Канал Евгения - https://www.tgoop.com/afonasev_blog (питон, конференции, развитие языка, жизнь IT).

👍Gо прокачиваться:
youtube
rutube

❓Какой дизайн хочешь увидеть следующим?