⭐️ Управление рисками by ITKatya.

👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).

💵 Недавно в её блоге был анонсирован Master Mind по управлению рисками в IT проектах. Тема меня заинтересовала так как в последнее время выступаю на архитектурных хакатонах. Понял, что прокачка в этой составляющей может дать дополнительные баллы)

📕 Встреча началась с небольшого куска теории. Где рассказывалось про негативные и позитивные(!) риски. Приведена собственная типизация:
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).

🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.

🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄

❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)

⏳ Говорили про бизнес, сроки. Что заранее невозможно всё просчитать. И с этим надо смириться 😌

🙋‍♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.

🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.

🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.

▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)

👩🏻‍🦰 Из декрета в финалисты хакатона.

🚶‍♂️ Открываем новую страницу в развитие нашего канала - жизненные истории в IT.

☝️ Какие-то из них будут за именем человека, другие выкладываться анонимно. Если есть что-то интересное, захватывающее или неожиданное - пиши!

⚙️ С аналитиком Элеонорой мы познакомились на платформе проведения хакатона. Она вступила в ряды команды System_Design_World. За счёт упорства и энтузиазма закрыла большой спектр задач в процессе всего мероприятия и при подготовке финального решения. Отрисовала одну из самых крутых схем данных среди всех решений. Лаконично представила наш итоговый архитектурный дизайн. При том, что аналитиком она стала совсем недавно...

—

Элеонора, привет! Представься, пожалуйста :)

👩🏻‍🦰 Я специалист по государственным закупкам, который, на период мамского отпуска, ищет себя в новой профессии.

Недавно проходил Архитектурный Хакатон от ВТБ. Здорово поработали в одной команде и заняли достойное место!
Ты создала очень крутую детальную архитектуру данных. Я думаю на уровне призёров хакатона. Откуда такие знания и навыки по проектированию схем данных, досконального изучения доменов?

👩🏻‍🦰 Я только закончила курсы системных аналитиков, даже более того, начало Хакатона пришлось на дедлайны защиты диплома. Схемы данных разминочной задачи проектировала одновременно с проектированием дипломного проекта. Знания и навыки в основном учебные. Схема данных, спроектированная на Хакатоне для меня на текущий момент самая большая.

Подскажи, пожалуйста, откуда ты узнала о Хакатоне и почему решила участвовать?

👩🏻‍🦰 О Хакатоне я узнала абсолютно случайно, увидев баннер над статьей ВТБ на Хабре. До этого только слышала о подобных мероприятиях. И так как я сейчас в поисках опыта, большого и малого, решила участвовать. Спасибо, Владимир, что позвал в команду.

👍 Как ты оцениваешь проведение Хакатона - его подачу, атмосферу, задачи, оценки?

👩🏻‍🦰 Мне не с чем сравнивать, но мне понравилось: и позитивные включения организаторов, и своевременные напоминания куратора, и холивары в чате, и интенсивная работа команды, особенно в последние минуты перед сдачей проекта. Из того, что лично мне не хватило, это развернутого фидбека по проекту.

Что ты получила для себя от Хакатона и участвовала бы в подобном будущем?

👩🏻‍🦰 Я получила опыт работы в команде, познакомилась, пусть и шапочно, с новыми инструментами, а с некоторые пришлось оперативно освоить. И я безусловно, с большим удовольствием, приму участие в подобном в будущем.

Спасибо, Элеонора, за твоё участие, вклад и интервью!

—

Если понравилась IT история и хочешь больше, ставь лайк 👍
Если есть своя - пиши в личку, оформим 👌

🧐 А как ты учился новой профессии? Всё ли проходило гладко и давалось легко? :)

⚡️ Блажен, кто посетил сей мир в его минуты роковые!

😇 Дорогие коллеги, подписчики, друзья!
Со многими из вас я знаком лично.

📈 Канал System Design World рос неустанно на протяжение 1 года с момента своего основания и достиг 1242 подписчиков!
Без единой внешней оплаченной рекламы!

🎓 Канал стал местом сбора крутых специалистов. Неожиданно для меня в момент знакомства на крутейшей конференции по высоким нагрузкам Saint HighLoad++ случалось, что специалисты уже подписаны на канал. К каналу подключались также спикеры.

➕ Стартовала авторская колонка крутых специалистов по темам, находящимся в контексте архитектуры. Из недавнего - была проведена своя архитектурная ката, офлайн встреча. Ещё ранее - интервью про создание System Design Интервью, сами мок интервью, #cheat_sheets, освящение хакатона и другое...

▶️ Скоро должна была состояться онлайн встреча... Новая ката или же мини-хакатон, на судейство в котором уже согласились специалисты, архитекторы, с которыми познакомился на профильных встречах. Да и хотелось делится новыми постами с уникальным контентом, устраивать встречи...

🤔 Я думал, что после фактической потери развиваемого youtube канала можно двигаться дальше. Ведь есть основное ядро заинтересованных в теме архитектуры и System Design членов нашего сообщества в рамках мессенджера Телеграм.

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

☝️ Я знаю, что не легко менять комфортную среду.
Чтобы двигаться дальше я создаю резервы, на которые постепенно будет происходить миграция:
rutube - vladimir_v_it - для видео контента
vk - System_Design_World - наше сообщество
boosty - vladimir_v_it - для желающих донатить на канал в это время на сломе эпох.

Подписывайтесь, чтобы оставаться на связи!
И берегите себя и своих близких.

🪚❌💚System Design Interview. Казнить нельзя помиловать!

🆒 Все привыкли к классному формату HighLoad++:
1) Крутые доклады
2) Мастер-классы
3) Доброжелательное сообщество
4) Интересные компании, квесты, мерч
5) Кулуарное общение о том, как оно работает на самом деле :)

А что если прокачать эту мощнейшую конференцию ещё?!
Есть идеи как? 💡

Не так давно я познакомился с топовыми спикерами IT сообщества:
Александр Поломодов - СТО Т-банка - пост, видео, книжный клуб
Филипп Дельгядо - архитектор lekton - видео, выступления

📗 Кто интересуется темой IT не раз сталкивался с их докладами в теме управления, технологий.
У каждого своё мнение на обязательность System Design Интервью при устройстве на работу. Которое они готовы отстаивать топя аргументами противоположную сторону.

❓ А что если... Мы их посадим друг напротив друга? Зададим эту тему. И посмотрим, что будет 🍿

✈️ Окрыленный описанной идеей предложил им такой батл. Оба с энтузиазмом ответили "Да!".

▶️ В итоге необычная идея, заявка прошла входной конкурс на зимний HighLoad++ 2024 😊

Я буду модерировать дискуссию, вовлекать участников, подкидывать в топку новые тезисы 😏
Кто будет офлайн - отмечайте её в форме "собираюсь пойти", чтобы организаторы угадали с размером зала.
Для онлайна - увидимся на экранах :)

📝 Обсудим эту тему на нашей скорой встречи.
А пока... Как считаешь - казнить или помиловать? И почему? :)

https://highload.ru/moscow/2024/abstracts/12699

😲 WOW эффект для жюри хакатона!

➕ Участвую в очередном хакатоне.
ТЗ: разработать сервис для удобного добавления и тестирование страховых продуктов.
Прилагается отчётность, БД.
Команда дополнила решение фичами AI для тестирование гипотез в процессе добавления.

☝️ В ТЗ отдельным пунктом есть требование к масштабированию архитектуры.
Решил для финального питча показать его с элементами анимации для WOW эффекта 😊
Ведь в ограниченное время нужно продемонстрировать основной функционал и сделать это красиво)
🙂 Посмотрим, как в итоге зайдёт такое решение)

▶️ Как считаете, на питче нужно защищать решение спокойно, убедительно и сухо? Или с эмоциями, вау эффектами, явно демонстрируя исключительную крутость созданного сервиса?

P.S. Подробный отчёт выложу после подведения итогов👌

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

📆 Закончилась 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

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