Организованное программирование

Привет друзья Меня зовут Кирилл Мокевнин и я ведущий подкаста организованное программирование тема сегодняшнего подкаста системный дизайн который мы обсудим с Владимиром ивановым который работает си иринг менеджером в компании бол Я думаю что многие её знают потому что катались на её девайсах в первую очередь это наверно скутерах Да привет самокаты есть ещ eik А сечас это тоже популярная Тема да я СХ честно тебе скажу немножко стал этот противником всей этой истории потому что количество вот этих вот людей на скутерах стал настолько большим и например когда я с детьми иду в школу это стало прямо большой проблемой потому что тебя постоянно могут сбить у нас регулярно это происходит и всё ужесточается ужесточается законодательство есть даже смертельные случаи Проблема в том что людям которые занимаются регуляция гораздо проще запретить самокаты чем постройка и соответствующая инфраструктура Так что проблемы не в самокатах да Ну им тоже им тоже сложно с этим Да потому что ты просто пере переделать всё это конечно проблема Слушай системный дизайн вообще очень интересная штука Я небольшой вход сделаю в эту историю так получилось что я как инженер вот работая там в российских компаниях в основном А у меня не было такой истории что знаешь я застал вот рост бигтех в том виде в котором вот он сейчас есть И когда у тебя все практики европейские американские были перенятый тоже есть там многоэтапный интервью Ну раньше только Яндекс так делал Да там во многих местах когда у тебя прямо отдельная секция системного дизайна и так далее поэтому такой истории что мне когда-то надо было к этому готовиться и в этом прямо вот так формально копаться у меня не было поэтому в этом плане я буду во время нашего вот этого разговора немножко играть роль такого чувака который не очень В теме с одной стороны с другой стороны Понятное дело что в Европе там или в Штатах у тебя я не знаю сколько это лет но чёрт знает сколько лет Да просто отдельная секция не надо готовиться есть книжки где написано 1Д три да при этом есть естественно Реальная жизнь есть то есть потому что есть эта сторона собеседований Да есть Реальная жизнь где есть вот мы проектируем реально системы Угу И это не всегда одно и то же насколько я понимаю ну вот те люди с которые проводят собесы с которыми я разговаривал я говорю насколько это реально они говорят Ну всё-таки это немножко такое искусственное Да ну и ты соответственно об этом тоже упоминал и поэтому получается что мы рассмотрим эту тему сейчас вот как бы с с нескольких сторон да то есть со стороны типа со бесов что это как это как готовиться надо что надо знать что от тебя хотят и с точки зрения реального проектирование да Хорошо хорошо звучит как план Давай вообще наверное в целом с термина вообще о чём идёт речь может быть какой-то исторический вход Если ты знаешь Блин я не знаю насчёт исторических входов типа когда это появилось Э я просто обнаружил в определённый момент что нужно обладать этими навыками для того чтобы успешно играть роль там СОШ архитектора в тот момент когда работал в я паме ну то есть можно сказать что у вас все компании делятся на три больших группы наверно а Первое - это продуктовые компании в которых софт - Это непосредственно продукт Да ну там не знаю Google Spotify name it да вот дальше У тебя есть группа компании которые делают софт на заказ это там не знаю Accent ещё там кто-нибудь Вот и есть группа компаний которые занимаются какой-то оффлайновый штукой да Или просто бизнесом который непосредственно с it напрямую Не связан но it - Это большой департамент там ну там не знаю inditex например да то есть Это фирма которая продаёт одежду но тебе нужно сейчас в любой фирме иметь сильный it отдел для того чтобы информационная система поддерживать иначе у тебя не будет оптимального бизнеса как бы First Place кто-то из Google по-моему говорил много лет назад что compy Soft compy да типа сейчас каждая компания она делает софт в той или иной мере поэтому эта экспертиза она нужна везде и нужно понимать что вот этот вот вот это проектирование Да она в этих разных компаниях оно выглядит немножко по-разному и вот в сервисных компаниях это скилл без которого Ну ты вообще не можешь ничего клиенту продать что твой бизнес - это типа мы сделаем вам софт А что вы собственно делать будете ну и тут начинается вот этот вот систем дизай Да системное проектирование Ну понятно То есть как бы независимо от Термина в любом случае ты не можешь что-то делать не спроектировал Да у тебя есть там нагрузки У тебя есть Не ну нет Ты можешь ты можешь как бы просто в определённый момент ты поймёшь что ты сделал не то надо всё переделывать это скажем так плохое проектирование но оно есть то есть ты всё равно что-то придумываешь ты не ну то есть ты просто ничего физически не сделаешь если ты не купишь сервер Да и там два-три и не запустишь на нём свою вот да как бы какой какой-то набор решений тебе нужно принять типа на МСА а где крути будет а как условно ДНС будет работать и так далее и этих решений очень много Давай сначала на просто про системный дизайн опять же вот в целом без относительно со бесов да Это наверно во вторую очередь мы рассмотрим по большому счёту вот если брать современный мир то большинство разработчиков как не крути самоучки которые Ну или курсы например какие то есть вот такое что есть статистика по этому поводу есть Есть у тебя есть там у тебя есть статистика чего года 50% респондентов у них есть степень но она то есть у тебя то есть 50% опрошенных Они не имеют ну плюс опять же у меня своя школа Я занимаюсь Сколько лет с тринадцатого года я занимаюсь обучением то есть там количество людей которых я когда-то научил и которые сейчас уже технические директора их много вот и мы знаем что большинство людей не имеют профильного образования вот кстати вот сразу спойлер сделаю у меня буквально следующий один из ближайших записей с человеком которого как раз Я когда-то развернул на собеседование по-моему в тринадцатом году Он после этого пошёл в универ потому что он понял как много не знает и прошёл длинный путь и ворта сейчас работает и у меня с ним будет собственно интервью вот инте интересная такая Такой круговорот Да и когда-то я его вдохновил собственно Собес что надо базу подтянуть Но я это к чему к тому что нет такого что Люди выходят с ВУЗов даже кстати даже если ВУЗ Ты же знаешь как многие к этому относятся причём это не обязательно вгш нае ВУЗы это вполне себе и в Европе и в Штатах всякие ВУЗы бывают да то есть люди не выходят оттуда с таким типа пониманием О я знаю как делать системы как правило этого нигде нет сове это это нереально абсолютно Ну слушай у меня у меня профильная степень у меня типа буквально специализация звучит как инф э программирование информационных автоматизированных систем Что что-то такое я я забыл точно формулировку Но это буквально типа профильное образование и я вышел Я не понимал вообще типа как строить системы абсолютно то Тем более я даже готов поспорить что у тебя скорее всего и Веба там не было в плане того что есть сервера Там и так далее там скорее всего Нет нет конечно нет то что то что ты получаешь в образовании Ну в том в котором я получил да это очевидно Матан определённого уровня это мац статистика которая нужна В итоге Как это не прискорбно это теория надёжности это Безопасность это сети вот это вот типа большие блоки которые я помню которые вот полезны мне хорошо ещё бывает когда операционные системы тоже есть но они с сетями где-то близко да да операционные система Тоже тоже есть да это тоже был курс такой даже два два курса было Угу дадада да это ну в принципе та самая база которая в первую очередь нужна да и получается что по большому счёту вся эта история такая кустарная то есть ты получаешь эти знания От старших товарищей Работая в каком-то собственно проекте поэтому получается что дисциплина вроде как есть а обучение происходит полностью вот ручками на практике на вот я это видел я так вижу Да всё так всё так к сожалению это так не не очень очень мало людей учат этому системно Ну то есть у тебя есть там типа набор книжек которые говорят как готовиться к интервью Да но это не то же самое да да но но это во-первых не то же самое а во-вторых нет пособий или там не знаю курсов каких-то которые бы говорили что вот смотрите вот как на самом деле in real life да вам нужно строить системы Я кстати помню много лет назад очень много лет назад я покупал книж Я вообще был фанат книжек Я просто на Арбат ходил скупал вот каждый месяц всё что было и читал и там была такая книжка типа как будто соты что ли были изображены Если ты помнишь такая жёлтенькая книжка там рассказывалось про 30 каких-то архитектур каких-то известных решений там начиная от систем виртуализации заканчивая какими-то вот большими такими штуками не считал Да вот честно скажу мало что это дало Там скорее просто такой обзор всей фигни но как будто бы они в этом направлении двигались это знаешь это тоже самое что читать про netflix архитектуру вот есть чуваки которые в Твиттере пишут Если вы хотите типа улучшить свои навыки систем дизайна изучить вот эти системы и там знаешь там типа blueprint нетфликса или БН там Spy или что-то ещё я всегда так смеюсь с этого типа ну вот Ну вот ты узнал как netflix делает определённые вещи что ты из этого узнал что только тот факт что netfx вот одна компания Т вот эти вещи вот так почему она их так делает ты не знаешь у тебя понимание не возникло в чём польза Да Дада меня всегда тоже смущает очень Вообще в разработке такой знаешь общая история связанная с системным дизайном в том что вот например приходит на конференцию Да кто-то там рассказывает как классно они что-то спроектировали Ну и вообще в целом и ты ведь никогда на самом деле не знаешь насколько то что они сделали вообще-то является нормой потому что оно звучит красиво мы там микросервисы внедрили Мы там то всё пятое десятое А с точки зрения бизнеса вообще Вот это всё надо было то есть типа может быть был гораздо более лёгкий путь реализовать Ту же самую фигню и меня Особенно это пугало когда я точно знал людей которые выступают и я знал что не всё там так хорошо как они рассказывают и Это скорее ну как бы пыль в глаза поэтому и самая Проблема в том что это оценить сложно Потому что когда например вот бизнесмены между собой соревнуются Да там всё очень просто типа е беду Покажи свою Да там что у тебя по прибыли всё всё остальное вообще не имеет значения вообще вот просто ноль а здесь К сожалению нет такого простого фактора что потому что те не с чем сравнивать потому что одну и ту же штуку можеш сделать 50 миллиардами способов Ты даже просто банально язык другой берёшь да там не знаю на PHP пилил демонов написал их Наго Ты просто из коробки получаешь Там просто порядки производительности да да Ну вопрос Нужно ли это и и знал ли Ты гон на самом деле до этого и мог ли ты так быстро на гон описать то что тебе было нужно то есть там там на самом деле гораздо больше факторов чем там типа перформанс или стабилити или ещё что-то и в этом в этом вся сложность вот этого системного дизайна Да Ну То есть можно сказать что проектирование программных систем - это ровно такая же инженерия как и вся остальная инженерия Да условно Ты когда строишь дом или проектируемом или проектирует медицинское устройство или проектирует что угодно автомобиль Господи неважно у тебя задача на самом деле одна и та же вот у тебя есть некоторая бизнес проблема типа мне надо возить людей не за миллионы долларов Да за раз вот и дальше как ты её решаешь Ну окей у тебя будет устройство которое ездит по дорогам да по асфальту тебе нужна определённая стабильность для этого устройства Четыре колеса тебе нужна определённая вместимость пять кресел тебе нужен определённый уровень безопасности тебе нужно чтобы стоимость поездок была не очень высокая ну там типа двигатель внутреннего сгорание либо какой-то ещё двигатель и таким образом ты из кубиков как бы вот из вот этих всех требований ты собираешь автомобиль да то есть если бы у тебя хотя бы одно мне а требование поменялось например А мы не будем ездить по дорогам Мы хотим по воздуху летать у тебя максимально решение меняется и теперь у тебя нет колёс Да у тебя тип топлива меняется и у тебя вообще-то вертолёт Да который на других физических принципах летает вот и ты проектирует совершенно другую штуку тут то же самое как бы ты можешь проектировать какое-то программное решение там не знаю стриминг Да но будет это стриминг музыки или стриминг видео совершенно разные решения и что ещё хуже А если у тебя в машине всё-таки все однозначно понимают что ты не можешь просто так взять требования поменять Ну потому что она ты не можешь просто куском заменить там что-то да а то в программировании только так и происходит у тебя никогда система не конечная Она всегда развивается и знаешь что меня всегда вот пугает и как раз вот является той самой точкой после которой вот сложно понять это хорошо или плохо когда система становится достаточно большой и у тебя есть в том числе Legacy а очень часто сама система и структура компании толкает тебя к тому чтобы ещё её наращивать и усложнять вместо того чтобы например в какой-то момент понять А вот это всё вообще-то нам не нужно это наоборот надо свернуть и убрать Ну например Когда появилась какая-то разведённая система микросервисов А может оказаться что мы в принципе пошли не в ту сторону потому что либо бизнес-требования поменялись либо технологии изменились либо просто стало понять что это может было давать проще но из-за того что у тебя уже есть там сотни людей там которые вот в этой всей системе ты вот хрен её так вот просто схлопнется Что у тебя вот этот бочка она там растёт растёт растёт растёт до тех пор пока это опять же тут тут я дам небольшой Инсайт А как закон кстати называется дашь этот закон А конвея да конвея вот этот что у тебя что у тебя архитектура системы повторяет организационную структуру правда но Инсайт в том что вот вот большие изменения они движутся скорее всего не техническими требованиями задачами бизнеса да то есть условно если там какой-нибудь ректор of engineering придёт посмотрит на эти сотни микросервисов а у него цель типа там не знаю cost efficiency на следующий год да там на 20% косты срезать а он скажет О'кей этот продукт не зарабатывает много денег единственный способ как мы можем получать больше денег от этой конкретной системы это уменьшать её размер я такой ну Перепишите её таким образом чтобы у нас типа это поддерживалось только половиной персонала вот и всё и у тебя у тебя нет технических требований для того чтобы сокращать эту штуковину но есть организационные и бизнес-требования вот и ты будешь это делать ну потому что там ктор of engineering так сказал вот и всё А у тебя кстати был такой опыт Вот таких вот когда надо прямо реально подумать как упростить удешевить Да конечно Это буквально то что мы делали в прошлом году там Весь год был посвящен цели платформи Зро биллинг в болте Ну то есть буквально типа сделайте так чтобы выход на новый рынок занимал не 6 недель а две Вот это это бизнес цель Да дальше ты чешешь репу и думаешь А что надо в биллинге сделать чтобы чтобы это случилось биллинг для для слушателей для того чтобы понять чит Вы когда поездку на такси заканчиваете приходит письмо и там в фни и в нём написано там проезд на такси там 22 евро из них 4 евро - Это налоги Да вот и ты думаешь Ну это простая вещь как бы для неё один программист нужен там за неделю напишет Ну если ты подумаешь там Типа 45 стран четыре

бизнес-линча сажи Но если ты подумаешь про доставку еды У тебя есть ресторан полт курьер потребитель конечный да едок Вот и между ними на самом деле есть большое количество связи инвойсов которые они друг другу должны посылать Потому что есть ещ несколько бизнес-моделей короче 30 человек занимаются Бинго в в болте Ну у тебя ещё скидки у тебя ещё возвраты акции да да рефанды скидки плюс отчётность плюс плюс финансовая отчётность внутренняя плюс несколько бизнес-моделей потому что у тебя может быть когда ты просто Сводишь двух людей и должен водителю У тебя есть модул когда ты покупаешь у водителя поездку продаёшь его пассажиру это другой набор инвойсов вот там и там ещё куча регулятор в разных странах там во Франции SA guarding в США там другая структура налогов и так далее и так далее своий системы оплат Да и дадада именно к чему Это я к тому что когда мы говорим что мы должны выходить на новый рынок это означает поддерживать новые налоги это значит поддерживать поддерживать какие-то ивон схемы это новые требования легальные к инвойсу и так далее И вот это вот требование сокращать Time to Market оно выливается в технологические изменения то есть условно то что у нас было пом причинам там управление данными от контрагентах в инвойсе Да оно было реализовано по-разному в R helling в Delivery в rentals и так далее и нам пришлось унифицировать такие вот вещи типа управление контрагентами или там управление докумен другие ве Вот и некоторые микросервисы исчезли Да несколько новых появилось изменился и организация изменилась вместе с этим То есть как бы как я и говорю что бизнес-требования на самом деле диктуют тебе организационную структуру можем же мы сказать что конечное решение всё-таки очень сильно зависит от и квалификации и настроя вообще команды Потому что знаешь вот всегда Сколько бы не рассказывали там умные слова ходят и такие вот там подходы паттерны тра-та-та а потом у тебя каждый раз ты общаешься с людьми непосредственно и они тебе говорят у меня вот вот только я с Димой тут по расту делал этот подкаст предыдущий да Перед тем как мы с тобой он говорит у нас Лид любит Firefox и у них типа там всё на это завязано всё вокруг поддержка и так далее он просто фанат вот по какой-то там причине и у тебя как бы вся система в это выстраивается вот насколько ты с этим сталкиваешься вот этот объективность как бы решения и то что чувак конкретно не знаю фанат PHP Прости Господи я люблю говорить что не бывает плохих архитектур бывают дорогие да то есть ну условно Когда речь не идёт о том чтобы там держать меньше чем полусенсорный

вопрос в том сколько ты денег потратишь А на разработку и б на поддержку Вот и твоя задача как бизнесмена да то есть не как инженера даже А как человека который участвует в бизнесе я глубоко убеждён что разработчики - это такие же бизнесмены просто они бизнесу помогают с точки зрения технологии и всё Вот и нужно как бы свою парадигму менять в эту сторону так вот с точки зрения бизнесмена тебе нужно думать не о том что правильно Да а что будет нести большую эффективность с точки зрения вложения средств да А насколько быстро можно получить продукт Насколько качественно он выйдет Да вот с этим набором технологий Насколько быстро конкретно мы можем Имея эти технологии этот продукт построить потому что та to maret важен практически всегда и если ты такой Ну вот раз на слуху а Яни строчки кода на Расте не написал мне надо 3 месяца чтобы хотя бы вот какой-то филинг да вот это вот чувство языка получить Ну это не оптимально с точки зрения тату Маркет если у тебя инвестор который никуда не торопится у него сотни нефти Да он экспериментирует для него э игра ты можешь себе это позволить Но обычно это не так ну это к бизнесу слабое отношение имеет это просто спускание денег в унитаз дада да Именно поэтому обычно ты находишься в условиях типа смотрите через полгода нужно иметь продукт вот с такой минимальной функциональностью потому что там конкуренты или какие-то законы или просто мы видим ситуацию на рынке и так далее И вот тебе нужно находить оптимальный способ потому что тебе нужно выжить ну и уровень конечно принятия решений тоже разные бывает Потому что есть конечно вот когда ты говоришь про биллинг там болтает вообще биллинг почти в любом таком месте Это конечно супер серьёзная система слава Богу Ну те кто нас слушает Я просто хочу успокоить что далеко не всегда такие решения надо принимать и такие системы мы пилим да то есть это может быть гораздо более что-то локальное и простое а может быть и больше а а у тебя есть какое-то представление что Ну вот есть некий набор всё-таки знаний умений и квалификаций которая нужна у людей которые принимают подобное решени потому что вот опять же мы говорим нельзя знать всё и программирование настолько дико разнообразная область с ответвлениями что у тебя люди которые находятся там у руля могут быть Ну совершенно разные скилсет то есть один там там только на динамических языках писал у второго есть опыт там sre а другой вообще ничего очень слабо понимает в этих всех вещах или там devops и так далее То есть очень-очень сильно по-разному У тебя есть какой-то не знаю вещи которые вот прямо надо знать у меня есть такая штука называется Solution archit Map Ну ты наверно Сейчас берёшь всё равно такой максимальный уровень чуваков которые способны в амазоне проектировать дата-центры Нет Нет я сам не знаю как спорова дата центр у меня в рассылке Недавно была статья про railway Да вот они такие типа Нам нужен свой дата-центр и там статья на 15 минут чтения что нужно знать и уметь для того чтобы это построить Ну то есть там сети электричество пожаробезопасность короче очень интересно было читать я говорю про людей которые способны спроектировать там типа вот минимальное энтерпрайз нае приложение Ну то есть то чему я людей учу тот бизнес примерно котором мы учимся - Это доставка еды да то есть что тебе нужно тебе нужно приложение для потребителя приложение для курьера тебе нуж админка тебе нужно приложение для ресторанов тебе нужен какой-то кнд да тебе нужно чтобы это где-то крутилось обеспечивало качество Ну и там выходные документы нужны там инвойсы как бы чеки и так далее а и оплату нужно принимать Вот вот минимальный набор того что тебе нужно делать это всегда две веточки это Hard skills и Soft skills да и с точки зрения Hard skills Вот именно технических навыков У меня есть вот такая штука что тебе нужно понимать Какие тактики нужно применять для удовлетворения нефункциональных требований таких как доступность

поддерживаемое безопасность Вот это минимальный набор для который тебе нужно понимать для того чтобы успешную систему построить Да дальше тебе нужно знать об облачных технологиях Ну то есть условно тебе нужно чтобы решение у тебя где-то крутилось Да он прес Ты пойдёшь или в облако или ещё куда-то тебе нужно знать а как бы Какие решение есть для компьютера Сейчас виртуальные машины есть контейнеры есть кубернетес есть лямбды есть там что-то ещё какие системы хранения данных У тебя есть да S3 базы данных Какие базы как отличатся там типа вот мы пос берём и сём его в RDS или мы постс берём у сторонней компании или мы берём Динамо db которая у ews Да тебе нужно что-то знать про сети Да потому что через сети ты будешь реализовывать базовую безопасность в своём решении тебе нужно знать что-то про оберти Потому что если ты не знаешь что происходит с твоим решением ты не можешь никакие бизнес-решения принимать Ты должен знать что-то про facing te либо что-то про либо что-то про мобилки про там не знаю десктопные приложения если ты Steam пишешь например не знаю вот это одна большая ветка это Хард скилы а большая ветка вторая - это софт скилы Да организация вот такой работы вот большого бизнес-решения на основе программного обеспечения это всегда организация группы людей Ну то есть ты конечно можешь найти одиночек который тебе затащит такую систему самостоятельно но скорее всего Нет скорее всего тебе нужна будет команда и тебе нуж будет тебе нужно будет их координировать то есть не только там не знаю технических писателей qa стейкхолдеров твоих да то есть людей которые дадут тебе денег на производство вот этой вот штуковины и там целый список тебе нужно значит людей убеждать тебе нужно с ними договариваться То есть это negations тебе нужно будет

разруливает эти две подушки да Да pill вот вот они основные Я кстати не могу не добавить что в софт скилы когда мы говорим про менеджера такого управленца такого уровня там одна из ключевых вещей это конечно найм правильных людей которые будут принимать правильные решения Да да это правда потому что без правильных решение ральных людей ты вообще ничего не построишь Ну то есть нельзя всё самому делать дай Бог всё уметь Не дай Бог всё самому делать да Но это конечно да это прям очень серьёзно кстати вот ты можешь примерно оценить вот так чисто умозрительно вот если мы берём просто всех разработчиков сеньоров вот всех сеньоров взять сколько людей вот типа в процентном соотношении могут быть Вот такими ну в смысле не то что могут выучиться А я имею в виду вот сейчас вот прямо можно его взять и поставить на такую роль процентов 30 к сожалению Ну это много кстати я думаю ты сейчас скажешь там ноль со проце то есть 30% сеньоров - Это довольно много Ну да у них у них есть какой-то базовый набор того чтобы так делать Ну то есть там начинается же опять же разговор насколько оптимальны будут решения которые ты сделаешь смотри тут есть некоторый трюк в том что люди Они себе упрощают жизнь Ну то есть одно дело если Ты запускаешь стартап и делаешь всё с нуля Да это как бы повышенный уровень сложности но часто у тебя новые продукты запускаются уже внутри компании и дальше у тебя начинается платформ Инжиниринг тебе вообще на самом деле не нужно думать ни про CCD ни про платформу ни про базу практически ни про что да Потому что у тебя есть платформа которую ты приходишь спрашиваешь а что у вас есть они такие ну мы тебе дадим кубер сразу вот типа Просто кадильник напиши за деплой вот конфиг положи у тебя вот ранта сразу есть где ты хочешь хранить данные У нас есть на выбор постгрес И монго ты такой ну хз пошли с постгрес сом и как бы очень сильные квалификации в том как иметь надёжный кластер постгрес тебе тоже не нужно потому что платформа уже

позалар тоже там есть Best practices там уже Всё сделано там уже разделено по паролям и так далее вот поэтому находясь внутри продуктовой компании скорее всего у тебя всё уже есть и ты можешь сфокусироваться именно на бизнес задаче в этом суть платформы Да в в продуктовой компании Ну это ты прямо про бигтех конечно говоришь то есть это типа компании в которых там ну тысячи разработчиков То есть если у тебя их там 50 там явно ничего похожего не будет ты пропустил этап когда у тебя 500 разработчиков Ну я имею в виду 500 ещё ладно Ну слушай наверное сейчас же в современном мире всё-таки 500 тоже много да но у тебя опять же куб например да И вот вся облачная Эта история в принципе оно всё достаточно неплохо и так э скажем уровень абстракции подняло что в целом ты и без этого можешь неплохо просто дороже скорее всего выйдет ну это опять же вопрос потому что текущая тенденция Ну по крайней мере та которая мне видна это типа облака вас обманывают и убеждают что вы не можете просто иметь свой сервер а на самом деле это очень просто типа поиметь свою железяку Да и иметь мку и на ней всё всё рана это типа не не Космос Ну на самом деле так ты кстати Вот классно сказал про это Я думал скажешь не скажешь че же это толкает Ты наверное знаеш так с калом его вот у меня просто сейчас прямо прикол то что у нас один небольшой сервис есть который там cod basics - это основа языков и например мы вообще прошли по всем облакам вот реально мы с Amazon начали Google aure Digital oan Ну то есть просто всё что только есть

И что ты понимал вот когда ребята мои там оценивали Стоимость все дела Просто небольшой проект там буквально база пару алике серверов что-то ещ там по мелочи 10 долларов в месяц не ну не 10 Но короче мы посчитали что в Яндексе стоимость этой запуска этой хени 20 косарей А в тайбе 3.000 руб Ну если в рублях считать то есть бы вообще просто колоссальная разница вот и такие м неплохо но вообще Кстати да я согласен то есть вот это вот уровень абстракции сейчас опять же там облака докер В смысле и всё такое вот Камал Да сейчас пошёл и Я подозреваю это будет новый тренд действительно Да что ребята можно реально X просто сколько там на 10 наверное можно делить Да угу ну на на самом деле как бы да ты можешь так делать но я бы сказал что до определённой нагрузки ты можешь иметь вообще всё бесплатно если ты идёшь в обла Ну типа фтар ты имеешь в виду какой-нибудь Азовский Ну ф тир конечно он покрывает очень много Ну то есть если ты условно идёшь в лямбду Да что тебе не нужно что у тебя машинка крутится постоянно всё время у тебя не будет нагрузки с нуля 24 на 7 правда А тебе нужно код который запустится отработает и и закроется вот на лямбде можно очень долго бесплатно жить знаешь А вот я бы тут хотел адвокатом дявола и вот именно в тем улям чуть глубже копнуть потому что это очень прикольно Вот вот этот тренд он очень выгоден компаниям Ну в смысле облакам они туда толкают То есть у тебя очень многие вокруг этого строятся и они такие постоянно дадада технологии вот этот господи как он называется nextjs Если ты знаешь Да там вообще они вокруг у них самое главное - это платформа куда они собственно под неё типа фреймворк делают и Давай заходи То есть эти все интересные концепции того как людей заманивают пользоваться своими вот этими облачными продуктами все эти вендер Локи и так далее И там просто идея такая что я вот сколько в подкастах участвовал сейчас же много ран таймов делается конкретно под лям Даже например в ноде Да который там без чуть ли не ну рбш коллектор там есть О'кей Но там многое выкидывают чтобы он стартовал очень быстро и с одной стороны как бы идёт вот процесс типа Давайте больше больше лям а с другой стороны я вот сколько я не видел не читал всяких разных Архитекторов знакомых и ребят разных они все одно и тоже пишут ты типа пробуешь потому что тебе кажется что это классно потом ты в какой-то момент начинаешь с ними бороться при этом ты не осознаёшь этого Потому что ты уже внутри и знаешь бывает такой когда ты входишь уже в режим ты не понимаешь что ты вместо того чтобы делать бизнес задачу на самом деле уже борешься с системой а потом в конечном итоге выясняется что это ещё и дороже И вообще типа мы зря туда попёрли потому что попробовали всю систему построить на лямда ты не сталкивался с таким скорее Нет моё мнение по этому поводу это то что тебе нужно осознавать На какие трейдо ты идёшь и какие риски у тебя выстрелят Ну то есть у тебя не бывает Серебряной пули нет такого что я сейчас в любом случае Выру вот этот стек Да и он волшебно мне ВС решит Нет ты всё равно идёшь на какие-то трефы типа условно если я буду иметь код в лямда это во-первых vender Log да А во-вторых если мне придётся переезжать в другое облако и на Виртуальные машины то мне нужно будет что-то делать по этому поводу Мне нужно будет добавлять ранта Собственно как я это рану Да и там типа либо в контейнеры уходить либо просто ложение иметь за деплоя и так далее Вот тебе нужно просто осознавать эти риски и понимать А насколько эти риски для тебя критичны Если ты просто проверяешь идею вообще будет спрос на продукт или нет то как бы ну и Бог с ним А если продукт выстрелит у тебя будут ресурсы на переезд это правда да когда ты когда ты начинаешь решать задачу которая у тебя может не возникнуть даже через год это не оптимально Я люблю эту фразу тоже повторять что типа когда начинают про эти веи говорить А вот ели вот у тебя нагрузка там ещё что-то я говорю ребята если я доживу до момента когда у меня у проекта будут такие проблемы Это скорее всего будет говорить о том что у меня достаточно денег чтобы вот так вот ящик поставить и сказать ребята теперь переписываем Да дада да и именно Именно теперь Мы богаты мы теперь делаем правильную вещь и мы лучше понимаем бизнес Потому что ты как бы к сожалению не можешь предсказать А что тебе понадобится с точки зрения бизнеса вот вплоть до того что другой продукт понадобится вообще да И тут нельзя не сказать что бизнес хотелки тоже нужно ограничивать В каком смысле например вот когда люди проектируют сервисную систему в которой много независимы Давайте биллинг вынесем Ещё что-то ещё что-то обычно же это строится вокруг того что есть понимание вот этих dataflow типа Какие данные Куда ходят и они связаны типа с текущими бизнес задачами а потом аппетиты бизнеса всегда растут и он придумывает А давайте ещё вот так скидку сделаем базируясь на какой-нибудь тарифе ещё чем-нибудь и ты понимаешь что у тебя теперь нужны данные сервисов которые вот по всем этим структурам между собой вообще-то никак не не

коннектика в идеальном для бизнеса но в худшем с точки зрения технологий у тебя может получиться что по сути каждая точка-точка должна быть связана потому что между ними есть какой-то бизнес требование того чтобы они там переиспользовать например данные и у тебя все твои сервисы будут ходить в конечном итоге во все твои сервисы и Да это ужасно и у тебя как бы любой бизнес в какой-то момент я тут во мне уже бизнесмен заговорил ты как бы в какой-то момент понимаешь типа ограничения что вот ты выбрал некое направление что вот ты работаешь Вот так и всё Ты теперь не можешь быть другим То есть это надо было Другой бизнес строить у тебя всё какие-то модели Ну либо тебе придётся перестраиваться потому что делать всё Ты просто не сможешь но это такой как бы уже на уровне там архитектор с бизнесменами вместе решают и обсуждают типа реально или нет потому что стоимость Ну мне-то легче в этом плане потому что у меня своя компания У нас знаешь как часто бывает когда Ну это я и учу своих и мы так делаем то есть например заказчик в бизнесе свом не толь же я да там у меня маркетинг есть там разные ребята продукт и вот они например говорят Давайте такую штуку сделаем и им разработка всегда отвечает так смотрите вот если в этой штуке выкинуть вот этот элементи маленький то мы сделаем решение не за месяц А за 3 дня и мы всегда принимаем решение конечно же переработать любую задачу таким образом чтобы знаешь этот вот иксы просто сократить В разработке тоже страшная потому что ну то что я вижу это люди хотят код писать Да деплоить что-нибудь обязательно Ну это классно но как бы эту же задачу можно решить гораздо эффективнее если с бизнесом поговорить и спросить а зачем это надо да то есть во-первых ты обнаружить что на самом деле какие-то вещи даже не надо делать да другие вещи вещи нужно делать по-другому и техническое решение оно сокращается в сложности очень быстро Так что вот это самый важный навык и Это очень важный навык очень сложный и самое страшное то что его не все хотят то есть нет такого как бы общего понимания То есть например там по Каким техническим вещам всё-таки Ну вроде как надо знать алгоритмы То есть даже если ты не согласен но тебе бы сказали там давай вот я тебе сейчас не знаю там вот в гружу тебе прямо как в Сайбер панке Да там в голову и ты такой узнаешь алгоритм никто не откажется Да ну ну потому что Нафига отказываться это же понятная штука Но вот то о чём мы сейчас с тобой говорим такого понимания нет И более того как правило есть часто очень наоборот и Например у меня при найме людей это одна из самых главных проблем Потому что ты прямо в разговоре понимаешь что человеку это просто даже не интересно он так мир не видит И для него как бы важно там ну знаешь один из кейсов это есть такой класс ребят которые говорят я фреймворки Нет я хочу всё контролировать я буду делать всё сам то есть абсолютно все решения вот для меня это что-то прям не очень инженерное решение Делай всё самому Я дума ты с таким тоже сталкиваешься да это постоянно происходит Тут у них нет желания по-другому то есть наоборот они ещё больше в это тянутся и у тебя нет как бы Другого выбора кроме как не нанять таких людей Потому что если ты найм то через какое-то время ты обнаружишь что ты увяз Ну это зависит от обучения и насколько люди хотят расти вот типа не не совсем в техническую сторону Я думаю что мы туда придём Ну то есть и яй всех туда загонят потому что типа ну кадильник может любой НИР писать с чатом gpt Да ты попробуй выяснить те какой какой дильник тебе ну

это конечно интересная история Ну вот смотри давай системному дизайну в этом плане так вернёмся предположим вот человек такой думает Ребята это вот я вас слушаю Да Всё интересно прикольно там архитектура Как реально вот мне это делать что мне нужно читать что мне нужно знать что какие решения Мне нужно принимать не принимать на базе Чего мне это делать или ответ Такой типа ну устройся в компанию где ты есть и учись блин Это хороший вопрос давай его попробуем сузить С каких начальных позиций мы мы говорим ну то есть это Мидл какой-то в сервисной компании или это сеньор в продуктовый или о ком я бы сказал так вот мне кажется если всё-таки когда мы сейчас разговариваем про это да В основном мы имеем в виду конечно же веб Ну подбоем в виду может быть это интранет но смысл в том что у тебя есть сервера У тебя есть http У тебя есть как правило вот такое взаимодействие Да соответственно Ну потому что существуют же там ребята которые пилят какой-то Мега код на расти там вот эти систем где там совершенно другие проблемы они живут в другом мире вообще да А вот здесь в принципе есть некий общий набор принципов и правил банально Ну например там из серии я если с нуля что-нибудь делаю ну в смысле не я а просто кто-то вот делает Да он такой ну О'кей вот я беру сервер на него поставил базу поставил приложение запустил так так хорошо и мы такие понимаем что ну всё-таки есть некий минимальный уровень даже если вы так делаете вы должны понимать что у этого решения есть очень серьёзные недостатки для которых вам даже не нужно миллионы пользователей То есть если у вас в принципе есть платящие пользователи и вы делаете реальный продукт это решение уже на следующий день станет для вас проблемой может стать может не стать Ну зависит зависит опять же от ожиданий Ну то есть давай давай попробуй это раскрыть ну есть риск Давай минимальный риск - это типа просто вот умерло Да вот у тебя кстати на в облаках это нормальная история когда помнишь Amazon Вот например постоянно у тебя он прямо пишет эта машина всё и ушла соответственно если ты там расположил свою базу картинки там всё что угодно Ну спасибо До свидания расходимся бизнес закончился У тебя нету б капов или есть но ну это это правда Ну у меня смотри у меня у меня же есть блок вот этот вот и это просто виртуальная машинка на которой стоит а Господи ГОСТ Это смска такая с mysql базой за за пачем это всё на одном Хосте и единственное что я делаю две вещи которые я делаю У меня есть ежедневные бэкапы это раз и второе это мониторинг ап тайма Ну то есть если он там уходит в Дан на 5 минут мне приходит письмо я это увижу я пойду и поправлю Вот и 4 года полёт нормальный Там типа очень низкий rps Там как бы 2000 буквально зарегистрированных пользователей Но это работает вот этого достаточно поэтому не то чтобы там типа на следующий день начнутся проблема есть онные риски что у тебя будет Неу причина ты взял очень маленький диск у тебя типа и R of всё как бы блок недоступен как бы реальная история Вот Но это происходит тоже раз в 4 года потому что всё что тебе нужно сделать это пойти сделать SSD и всё на этом проблемы кончились Ну конкретно в этом случае всё рано мне хочется сказать что здесь ты всё-таки Приключение себе нашёл потому что ну как бы если ты делаешь блог вообще наверно не имеет смысла что-то самому запускать У тебя есть платформы У тебя есть решени да определённые специфики потому что тебе Тебе нужны были Мне нужны были подписки Мне нужны были там платные подписки в определённый момент мне нужно было ещё какой-то интерактив туда прикручивать в общем да конечно я могу просто переехать на сабск для рассылки и на это на этом всё кончится но как бы что имеем то имеем меня меня устраивает Но вообще Смотри ты очень сильно прав в том что когда ты начинаешь какое-то решение любое проектировать ты можешь начинать с банальной тёзки да тебе нужно Web тебе нужен backend тебе нужна база на этом закончили как бы один хост не один хост это там немножко можно поговорить про Кост изначальный но в принципе этих элементов хватает чтобы держать относительно приличные нагрузки только за счёт вертикального масштабирования то есть такой ну окей упёрлись там в в память в CPU взяли побольше машину и вопрос решён но проблемы начинаются тогда когда ты говоришь Окей А что если мне нужна постоянная доступность решения Ну то есть давай подумаем про людей типа вот слышал про чувака такого который делает который у Лекса фридмана был он типа делает всё в одиночку У него каждый стартап который там типа десятки тысяч долларов в месяц приносит это PP сервис Да который там захо где-то в хре там база и и всё вот каждый такой старта но при этом если жида что тебя люди Мира 24 на то одной машинки может не хватать потому что у тебя тупо гарантии по е не хватит Да и ты будешь терять типа буквально тысячи долларов Потому что люди не могут пользоваться этим продуктом поэтому одна Машинка уже не подходит те надо что-то делать Что делать Окей мне нужно две машинки А между двумя машинками как трафик распределять нуже вот потом А если меня лько пользователе в меся

накапливал ли иметь это в одной базе А если база грохнут что делать Хмм Давайте делать реплики Так теперь у нас есть репликация на уровне базы И нам нужно распределять данные да между ними а ещё нам нужно Мар СВ менять если одна из них выходит из строя Хмм о'кей и видишь как бы у тебя начинается сложность Да а потом ты говоришь у меня Требования по перформанс на самом деле вырастают у меня люди из Сингапура жалуются что хост который у меня в США стоит он долго отвечает ты такой о Окей Ну мне нужно теперь здесь кэш поставить а ещё Было бы неплохо что-нибудь на Location выложить Да чтобы вот этот вот да тут же появляется вот и вот тут ты понимаешь А какая комплексити на самом деле у проектирования систем но эта комплексити она взялась Не потому что netflix так делает или LinkedIn так делает или Google так делает или в Фейсбуке так спрашивают надию Она идт из потребно есть ты можешь начать на одной машинке но с ростом вот этой нагрузки с ростом требований по доступности по sec по по по тебя эта система будет усложняться И вот в этот момент тебе нужны все вот эти навыки системного дизайна про которые мы говорим тебе нужно понимать Окей А как мне на самом деле держать вот тут

алгоритмы кэширования Да разные способы работы с кэшем Окей с кэшем разобрались как бы но теперь ble в базе данных а что делать с базами данных индексы шардирование Да там конн вот это вот всё то есть Вот все вот эти вот вещи которые пишут про которые пишут в Твиттере и в умных книжках про подготовки систем Design интервю они на самом деле нужны Но в определённых условиях вот для того чтобы эти определённые условия удовлетворять для того чтобы решать эти задачи нужно вот этому системному дизайну учиться но это всё очень технические вещи Да меня поражают люди которые Ну знаешь типа они на интервью приходят ты им даёшь задачку И они начинают с лот балансера ты такой В смысле зачем тебе лот балансер ты нагрузку свою не знаешь ты у меня не спросил сколько у меня пользователей будет нахрена ты лот балансер кидаешь Да ну то есть люди просто используют тактики потому что они про них прочитали или Они использовали их на предыдущем месте А почему они их используют Чёрт его знает как бы об этом не задумываться Вот это моя это моя большая Боль у меня кстати в этом плане есть такое знаешь интересное наблюдение оно связано например с индексами когда очень часто ребята особенно во время вот в процессе того как они учатся они по какому-то принципу типа вешают индексы например там Ой не знаю мы вот здесь делаем какой-то типовой запрос и они такие о надо индекс повесить Ну потому что в какой-то момент станет проблема Я обычно им говорю такую вещь что вот если вы так сделаете вы никогда не поймёте В какой момент у вас на самом деле начались проблемы и что вообще в этот момент происходит то есть вы так не научитесь делать правильно Поэтому если вам можно отложить принятие подобного решения на потом что вы заранее например увидите что у вас начались деградация производительности но у вас будет время чтобы принять правильное решение лучше так и Оставьте потому что это в том числе и хороший процесс вашего роста профессионального Потому что если вы сейчас начнёте пихать подпорки до того как вы прошли это собственными руками вы никогда в жизни не поймёте где собственно граница у системы То есть вы очень много вот пропустите Да это это правда кстати именно по этой причине когда ребята приходят в компании где достаточно неплохо всё построено это может играть с ними злую шутку потому что они не видели другого И они такие типа А нахрена это надо типа и так же всё хорошо было знаешь как с прививками сейчас же ну многие отказываются по этой причине и Сколько раз я такое наблюдал и у меня даже был такой какой-то момент понимания что блин классно брать людей которые прошли огонь воду знаешь вот по полной программе поэтому кстати как Да это не только программистов касается когда набирают вот в компании людей опытные бизнесмены знают что лучше брать людей из агентств Вот кто знаешь аутсорс агентство где у тебя 500 проектов Где тебя вот так вот там всё по полной программе Вот это самые классные ребята как правило потому что они знают вот эти вот границы все А кто вот приходит из такого мира розовых пони Они часто вот такие как это архитектурные астронавты есть такое понятие Это по-моему если я не ошибаюсь кто же его ввёл то я первый раз слышу но Мне очень нравится термин джос польский по-моему Да у него по-моему в книжке это было архитектурный астронавты он это называет он там это описывал Кстати классная книга кто-нибудь читал Смотри вот ты очень быстро перешёл в шардирование такой говоришь вот балансер тра-та-та тут мне хотелось бы заострить немножко внимани побольше про это говорить потому что Честно говоря разница между поставить балансер вот когда у тебя реально это понадобилось и дойти до уровня шардирование это всё-таки прям очень разные Ну коне уровни да да то есть это типа первый это это там первый Дан то есть разница Космическая по уровню и всё-таки есть же какие-то базовые вещи да о которых надо задумываться И вот одно дело шардирование - это всё-таки знаешь это уже такой уровень когда у тебя во-первых глубокое понимание это проект дошёл далеко и ты ещё должен видеть много вариантов А есть же некий базовый стандартный набор который исходит из некоторых базовых принципов что я имею в виду Вот например одна из ключевых вещей когда вот мы только систему начинаем делать типа принцип - это понимание что такое stateful и Stat и соответственно у тебя просто вот принятие вот этих вот решений по поводу горизонтального вертикального масштабирования выноса базы и так далее оно же основывается Вот на этом то есть Типа если ты просто смотришь но не понимаешь что такое stateful Ну типа ты можешь принять неправильное решение или вообще думать не в ту сторону Вот давай немножко об этом поговорим потому что мне кажется мы можем прямо с тобой обозначить Круг Вот таких базовых конфигураций чтобы человек сразу понимал что вот на минимальном уровне есть несколько может быть не несколько может быть больше концепций зная которые ты будешь принимать Ну относительно правильные решения потому что вот эта стандартная же основа Она же везде одинаковая вынес базу сделал два апликейшн сервера поставил балансер синку и в принципе у тебя там любой проект среднего уровня укладывается вообще-то в стандартную схему по большому счёту Угу а кто-то делает stateful сейчас вообще в принципе я имею в виду даже вот само конце концептуальное понимание то есть Представь если человек никогда с этим не сталкивался понимать что у тебя application сервер ну или вот который собственно отдаёт работает с фронт с человеком он вообще понимание что это должно быть й L что у тебя например ну база данных должна быть где-то на третьем сервере Да у ну чтобы можно было к ней ходить что у тебя нельзя локально хранить картинки например да то есть для людей которые не сеньоры это вообще-то не очевидно и про это нигде не написано то есть нет такого что они пришли им дают книгу и в ней там написано вот есть базовая концепция Там и так далее Я понимаю что для тебя скорее всего это настолько очевидно Такой типа Откуда у людей вообще такие вопросы Я немножко теряюсь это знаешь это стадия компетентности Да когда у тебя есть неосознанная некомпетентность осознанная некомпетентность осознанная компетентность и неосознанная компетентность То есть мне сейчас надо будет ковыряться и и допытываться типа А что вообще Мы про что мы думаем на на этом уровне Да потому что обычно это подразумевается это такое типа у тебя есть фронтенд приложение которое независимое Ну типа Mile или react или Whatever да дальше У тебя есть stateless backend который это чистый API Ну там может быть за API gway скрыт но тем не менее да и у тебя есть база ну то есть условно там какое-то хранилище данных и вот вот вот это тво твои базовые компоненты и там Security модуль какой-то который отвечает за авторизацию идентификацию с которым AP работает вот типа вот вот это мини

огромный Пласт фронтенд разработчиков которые не знают об этом ничего Вообще да я понимаю Я сам таким был в типа шестнадцатом году да да они при этом не являются же не сеньорами То есть это профессиональные ребята но когда они Кстати меня тоже очень многие ребята смотрят ребят Напишите вот даже интересно вот эта тема которую я сейчас затронул насколько она является такой очевидной базовой или для вас это Ну то есть вы где-то на ощущениях может быть это понимали а вот чтобы некое концепции в голове их например может быть нет и нету понимания что О вот так вот можно смотреть на вещи Просто интересно Просто я по долгу службы поскольку с фронтендер часто сталкиваюсь Я конечно понимаю что там этого понимания как правило нет то есть для них всё равно это некая чёрная коробка они не очень ну для для них для них backend - это API Surface и всё на этом он кончился Да но при этом они хотят то есть мы в том числе ведь для тех ребят которые здесь рассказываем для тех кто хочет посмотреть и капнуть и поэтому давай вот я предлагаю Чуть более плавно войти в эту историю то что говорю ты немножко её проскочил понятно то что ты в этом профессионал для тебя это просто А и значит А кстати вот тоже вот эта вот история вообще понимание что надо делать вообще в принципе оно ведь появляется от задавания правильных вопросов Я здесь хочу добавить такую просто вещь м существует миф Ну многие люди так думают что некая критическое мышление - это некое знаешь типа общее свойство что ты вот умеешь критически мыслить и ты значит это везде применяет критическое мышление зависит от твоей экспертности в теме потому что как только ты уходишь в тему Где ты не разбираешься ты правильные вопросы не задашь потому что у тебя нету моделей в голове никаких и вот здесь вот то есть для тебя вот эта история когда ты рассказываешь видно что насколько это очевидно то есть такой А если у нас там упадёт там значит надо бэкапы там А если у нас тратата Значит надо гео какую-то штуку и так далее Она вся появляется только потому что не потому что это естественные вопросы которые надо задать а потому что ты имеешь соответствующий опыт И это хорошо понимаешь И вот я как раз хотел такую немножко как знаешь игру поиграть что типа А откуда вообще В голове у людей появятся такие концепции то есть вот вот у них На одном сервере всё находится какой он должен себе в первую очередь задать вопрос то есть вот у него нет нагрузки но он например начал зарабатывать и он как минимум понимает Ну если у меня ну то есть наверно базовый вопрос который у него в голове Ну всё-таки у меня сервис не должен падать Потому что люди будут Ну я потеряю клиентов правильный вопрос что должно случиться чтобы я начал терять деньги да или перестал их зарабатывать вот это как бы дальше Да ну то есть ты смотришь а ты делаешь В итоге как бы что Что может случиться что мой продукт перестанет людям пользу приносить Да И вот отсюда Ты начинаешь спрашивать себя Глядя на своё решение Ну то есть каким образом люди вообще пользу получают Ну у них мобильное приложение например да или там не знаю вебсайт Окей Что будет если вебсайт будет недоступен Ну ВС кончится Да люди не смогут ничем пользоваться как это может случи во-первых может ДНС сломаться Ну почему Потому что заплатили забыли заплатить за Доми Да первая причина вторая прекрасная Прости помнишь недавно было такое то ли github то ли кто-то забыл заплатить там какой-то мегасервис отрубился к чертям вот прям Microsoft что ли Да да и кто-то и кто-то купил Дон сразу короче но его вернули его вернули типа сразу же но как бы тем не менее то есть первое Да тупо заплатить за Доми то есть мы ещё не начали вообще ничего технического делать как бы уже проиграли Вторая причина у тебя сертификаты на https протухли да со мной случалось такое вот Вторая причина тоже как бы мало техническое вещи скорее организационная третье Что может случиться Ну как бы хостинг с которого мы получаем собственно содержимое вебсайта с ним может что-то пойти не так что может пойти не так Ну тут надо смотреть А мы делаем Ну если мы в в Дант

у тебя может интернет пропасть у дата центра питание может пропасть может конкретно твоя машинка с жёстким диском вырубиться потому что жёсткий диск сломался может не знаю кто-то заделал провод и от от стойки отключили питание Да а что ты по этому поводу можешь сделать Ну на самом деле Мало чего Да ты скорее всего просто выбираешь дата-центр у них там есть какие-то определённые гарантии Да и может быть они что-то предложат в этом плане ночно более-менее там и питание интернет и так далее любимая моя история про это дело это про про рокетбанк Ты ты помнишь да что с ними случилось Слушай какой-то вот очень смутно у них был да какой-то фейл да да у них Ну у них у них был дата-центр в Москве и они модный Молодёжный банк никаких отделений ничего всё через мобильное приложение лучший customer support Ever и так далее и они такие Ну мы типа в курсе про там проблемы потенциальные поэтому у нас не один резервный канал в дата центр идёт а два О это всё отлично но понимаешь приехал экскаватор копнул и оба канала короче понимаешь ну то есть мало мало иметь резервный канал надо его ещё подальше закапывать от от первого Так что одного экскаватора хватает вот но как бы на эти вещи ты не сильно можешь повлиять как Рядовой разработчик ты можешь просто как бы выбрать там дата-центр с историей надёжности это типа на этом всё либо либо идти в облако в котором как бы там те не ну главно же гарантии выше но то есть да облако по итогу это всё равно дата-центры Но типа там там есть определённые вещи Да ну имеется в виду что чтоб ты не выбрал у тебя всегда есть риск и соответственно наверное первое минимальное Что ты можешь делать Ну б капчики надо делать да потому что оно может упасть Я хочу тоже историю Рассказать значит 2011 по-моему год или двенадцатый ул Camp есть такая штука это у нас там на Волге под ульяновском собираются айтишники в палатках значит в трусах обсуждают девопс и всё остальное чтобы ты понимал там например приезжает там создатель mysql и Значит мы там под пивко с ним обсуждаем значит база данных всё такое то есть вот такого формата мероприятия есть такой проект Эт это Ульяновский проект Это после shopify Второй в мире штука для создания магазинов мерчантом там миллионы все дела они сейчас продались в канадцам за полмиллиарда ну там целая история короче про этих ребят в общем я с фаундер знаком потому что мы из одного города и там команда все дела И в общем они были на амазоне всегда про что я хотел сказать Вот Представь значит мы пьём пивасик у нас значит начались отдых все дела И вдруг пацанам А значит из команды разработки их там ну команда кстати не очень большая Там чек 30 может быть 50 было а система огромная и вдруг им приходит новость что наводнение смыло амазонок дата-центр в котором У них проект А у них на этот момент Они с 2007 года там у них уже там сотни тысяч мерчантом ну то есть это очень крупный международный проект номер один в магазин в Фейсбуке внутри вот знаешь продажи А через него делаются и Они садятся пытаются восстановить но они потом вот в итоге 3 дня вот фестиваль сидели короче в труселях там где-то с мухами значит пытались это востановить Но знаешь в чём прикол на тот момент Они тоже были не очень опытные и при всех их объёмах они взяли РДС без мультизона Молодцы и они просто не смогли восстановить То есть у них какие-то старые бэкапы были они после этого ещё несколько месяцев всё это там восстанавливали но смысл в том что вот это страшная история одна из самых страшных То есть это даже не про бкп это то что называется Disaster Recovery Это буквально Что будет если в вашем дата-центре пожара или наводнения А это бывает это бывает это бывает да достаточно часто бывает ещё как бы не только не только пожарное наводнение несколько месяцев назад у Гугла была история они потёрли весь аккаунт одного из клиентов весь капами Ну у тебя Ты смотри ты как бы делит кто-то что ли сделал по табличке Нет они воспользовались старой туой для Там раскатывания чего-то как бы которая была там заброшена некоторое время и плохо документированная то посмотрела такая не увидела статус подписки у у аккаунта и такая А ну подписки нет я всё гроха короче с бэкапа понимаешь и чуваки восстановились только потому что они делали бэкапы ещё вне Google клауда и поэтому смогли восстановиться Поэтому да В общем то то про что мы говорим это Disaster Recovery на самом деле Да это что будет если что-то кардинально прямо пойдёт не так вот прям прям гигантский и тогда да у тебя должны быть копии где-то где-то асай у тебя должна быть процедура восстановления у тебя должны быть SL на

это Recovery это сные все понятия Правильно я понимаю на самом деле они бизне О ну то есть Это буквально н загоре с торения для

времени допустимо восстанавливаться Да ну то есть если ты условно каждый час зарабатываешь по миллиону как бы тебе нужно держать Это минимальное время Поэтому ты в это инвестирует не так важно и ты там потеряешь буквально там типа по то зарплата шника который будет проектировать систему она как бы не окупится поэтому это очень бизнесом деле Вот это РТО Как быстро ты восстановишь и вторая штуковина это Recovery это сколько данных ты можешь потерять от клиентов в некоторых бизнесах это типа сутки в некоторых бизнесах Это неделя в некоторых бизнеса 3 секунды и ты потерял уже много вот поэтому это бизнесом и они уже транслируются в требования к к архитектуре да то есть у тебя там будет мастер мастер в разных регионах в и так далее и так далее вот там много тактик которые нужно применять и люди намерено строят как бы системы которые автоматически будут восстанавливаться Но это дорого Поэтому я и говорю что не бывает плохих архитектур бывают дорогие Ты можешь построить очень дешёвую архитектуру но потом у тебя будет дизастер и ты будешь полгода восстанавливаться и как бы потеряешь Бизнес за это время Ну тут баланс Да да кстати в этом плане вот насколько я знаю в Яндексе э там очень простая установка для большинства сервисов Да у тебя просто вот мульти дата-центр поддержка всегда Ну во-первых то есть ты любое приложение обязан так делать Ну давай не любое Ну короче вот все ключевые точно в таком образе независимо от его размера всего остального просто уже платформа так работает и ты должен как бы следовать этим правилам насколько я понимаю если индексом слушают поправьте если не так и мне ещё когда-то давно понравилась концепция которую я тоже люблю использую для того чтобы периодически это всё практиковать Потому что если этого не делать всё будет плохо Чистый понедельник Да когда у тебя например там в понедельник не знаю там сносим всё ну Хаус тестирование да да по сути Хаус маки какой-нибудь и дата-центр типа рубильник да да Выключаем и смотрим Что происходит на самом деле А можем ли мы установиться это тоже была какая-то история что ти типа чуваки делали несколько лет бэкапы а потом оказалось что они нерабочие и не могут из них ничего восстановить Да поэтому восстановление с бэкапа надо проверять Вот кстати я не знаю может ты порекомендовать или нет Вот что что вот когда мы говорим про построение такой системы Я не могу не отметить что если мы говорим именно про базу данных то например в тех местах где у меня нету в команде вот прямо профессионалов которые этим занимаются Я всегда делаю так что только менеджмент базу данных в облаках потому что самому как бы не имея внутри людей которые конкретно за это отвечают держать где-то данные и надеяться на чудо что у тебя там бэкапы что это всё восстановится Это безумие почти наверняка убьёт бизнес поэтому Лучше пусть дороже то есть это самая дорогая Часть системы как правило и она самая вот закрытая Да самоя интересное что ты когда проектирует систему тебе нужно думать о том как ты будешь её восстанавливать в случае чего Ну то есть чего тебе будет стоить восстановить данные восстановить работоспособность системы условно в другом регионе вот если ты особенно находишься в US 1 да то как бы это регулярная история что он падает потому что туда новые сервисы раскатывают и как бы что ты будешь делать ели у тебя процедура сколько времени займёт процедура восстановления и так далее Я согласен с теком про промед базы данных естественно Вот Но их всё равно надо проверять Ну то есть условно Даже если ты в Динамо db идёшь как бы которая serverless Database Там бэкапы они не то чтобы типа идут из коробки их надо включать надо пойти каждую коллекцию включить расписание эпов и протестировать восстановление Ну то есть он же тебе не восстанавливает просто состояние коллекции на определённый момент он тебе создаёт копию коллекции Да вот и дальше тебе нужно либо её переключить либо переименовывать либо что-то ещё делать то есть это не просто всё волшебным образом восстановилось так проверяйте сво

свои чтобы Пони знае Фишка в том что у Вас поскольку база не стоит напрямую на сервере в смысле она стоит конечно но вам не даёт никто доступ они благодаря этому много всяких могут делать классных оптимизаций начиная от конфигурации что вам вообще не надо об этом думать что у вас там что-то случится заканчивая апгрейдом лёгким То есть вы можете там там галочку поставить у вас там перезагрузилась и стало больше памяти что-то ещё и самое главное То что у вас там как правило на фоне есть реплика которую вы не видите и соответственно данные там лежат и поэтому если у вас даже помрёт основной основная база оно там динамически переключится и так далее Это не освобождает от всех проблем но оно типа снапшоты за вас делает и у вас там одной кнопкой востановление и так далее Короче оно того стоит вот просто если вы с этим не работали и сами делайте это лучше самим базой не заниматься е особенно если вы не профессионал потому что это всегда кончится плохо Ну если это если это важный проект Да просто база - это вот тут Важно Вот это понимать Да stateless stateful вот если у вас есть сервера с прило пото у вас код в репозитории выкатил запустил никаких проблем но если у вас база падает это почти наверняка бизнес как бы есть правда тут нельзя не упомянуть такую проблему с облаками знаеш вот э лёгкость Она же даёт обратную эффект ты помнишь был кейс когда на Реди писали про компанию в которой чувак уволился обиделся зашёл внут обла и пря одло Уда

Всё я в своём курсе рассказываю про это Но в лекции про внутренние угрозы что если вы доступ не отнимается автоматически при увольнении человека это чревато бизнес рисками Так что да галочки там типа у бас 100% в облаках всегда есть галочка Да там типа не удалять Да конечно их надо включать обязательно особенно в форме нид там перепутал сдел

например для некоторых ресурсов это включено автоматически например когда ты Балан создаёшь терраформ ты не можешь его же терраформ удалить тебе нужно пойти сказать ему типа разрешаю удаление И после этого грохнуть ну то есть это не имеет отношения к Del это имеет отношение к случайному удалению Что у тебя на каждый ресурс будь то таблица в Динамо db или файлы В3 либо ещё где-то либо база там ВН те показывает диалог и говорит Да чтобы оно удалилось что ты не просто тыкнул случайно что ты осознанно это удаляешь Я тоже представляю как у них Саппорт разрывается от ситуации ой ребят у меня тут случайно нажали не то Помогите Ну всё как бы не поможем Окей вот да по поводу базы Ну и база в целом как бы довольно долгое время ведь фактически масштабируется именно вертикально да то есть мы просто наращиваем мощности ставим индексы и при необходимости ставим перед ней то есть для того чтобы её уже раки это прям надо дойти до серьёзного уровня если ты говоришь только про перформанс а не про Надёжность то то да по сути говоря Это всё что те нужно делать кстати вот из такой мелочи которую тоже можно обозначить про базу что какой-то момент к базе Ну у вас приходят ребята аналитики и говорят нам нужно аналитику есть такое просто правило что типа база которая у вас занимается данными записью Туда нельзя пускать людей которые будут делать на ней аналитические зас там Давай это элемент собеседования внутри Да у нас есть несколько причин начиная от банального что всегда есть понятие оптимизация данных под запись и по чтение потому что витрины - это сильно другая штука Но это даже не главное главное что ты кэши вымывать начинаешь потому что Как только они начинают делать свои Мега селекты они во-первых повесить херам могут всё А во-вторых у тебя вся память тратится под их запросы и соответственно кэш который использовался для этого приложения он уехал вот поэтому очень это разделять довольно быстро происходит то есть кстати не все Это же вот тоже знаешь вот эта штука Я бы не сказал что кто-то где-то Про это мне написал это вот как-то в течение инженерной моей жизни Да это приходит кто-то там рассказал ты это узнал И всё И теперь это знаешь Смотри мой по в том что э Потребность у бизнеса возникла они такие у нас [ __ ] клиентов мы хотим понимать средний чек на клиенте да или там Мы хотим понимать А насколько хорошо работают скидки для женской аудитории в возрасте до 30 лет и твоя РД БМС она как бы во-первых по тем причинам которые ты назвал как бы неподходящее место Потому что ты перформанс сам себе испортишь Да а во-вторых они просто лежат не в том виде чтобы это быстро можно было получить То есть даже если допустим мы туда полезли мы будем каждый отчёт строить по 30 минут это ну не очень хочется чтобы это хотя бы в пару минут выливалась и ты такой О'кей теперь мне нужна другая база Мне нужен на самом деле Data W House Да который в другой модели построен и который заточен пода литические данные дадада да тут ты садишь такой о Big quy О кликхаус ну и соответственно позвал ребят R Shift какой-нибудь Да слушай я забыл одну вещь ещё сказать Вот когда мы говорили про риски есть ещё один офигенный риск который особенно сейчас Мега актуален потому что мы его словили просто вот просто вот на 100% этот риск называется Роскомнадзор и друзья когда у тебя начинают вот по разным совершенно во всех странах это не какая-то чисто Российская фигня это во всех странах происходит у тебя просто начинают сбои ДНС потому что какие-то где-то идут блокировки и когда вы где-то размещаете надо исходить не из того что о Amazon - это круто а надо исходить из того В каком регионе вы работаете потому что во-первых в любой стране есть требования почти в любой то есть Чем более развитая страна тем больше требований например к тому что хранить данные нужно в этой стране вы обязаны их копировать потом у вас есть история про то что сегодня у вас работает блок IP адресов завтра он не работает у нас например в лата сейчас есть бы мы в лата тоже работаем Ну там чуть-чуть немножко Там постоянно какая-то [ __ ] что у половины не открывается сайт что-то самое главное что мы просто знаем что там конкретно вот такие проблемы с инетом и у тебя оно то работает то не работает и Это конечно очень сильно бесит всю команду Потому что ты просто непрерывно тебе надо этим заниматься смотреть А в конечном итоге никаких решений Ты просто тупо 3 дня потратил на попытку это отреть А заканчивается тем что ой заработало такой ну нахрена мы это делаем вот починить никак Поэтому у тебя ток фла ну подожди подожди а по Почему ты не можешь починить Ну то есть у тебя там какие-нибудь ED locations VPN Не знаю ещё что-нибудь Слушай давай так я опять же поскольку всё-таки Это моя команда занимается а не я Я с их слов скорее говорю Мы просто знаем что мы работаем на все страны ла тама у тебя всё равно есть история что определённые страны у них есть проблемы Просто именно какие-то сетевые и у тебя вот просто Может сегодня работать а завтра не работать И ты ничего с этим не сделаешь вот поэтому мы как бы там следим какие-то вещи можем делать где-то говорю там где-то фру поставили где-то убрали где-то ещё что-то Понятно локально перенесли Но у тебя сбои там происходят регулярно и они вот на другом уровне это печа ты убрать это не можешь просто никак Вот не можешь это убрать Да и понятно что в России тоже там какой-нибудь тест или ещё что-нибудь произошло у тебя пол интернет отрубило о недавно Где же это было фру кто-то рубанул и тоже по-моему там полегло просто всё ну потому что через что-то было такое но полгода назад уже по-моему что-то было полгода назад Да да И тогда кстати очень многие узнали что внезапно Cloud FL НМ стоит просто везде это правда но они они Мега удобные Ну то есть я для для персонального сайта использую и там у меня там есть пара стартап которые я консультирую я тоже рекомендую Cloud Flare там 20 баксов стоит в месяц там есть тир и 20 баксов нужен тогда когда ты хочешь strict Security включить на Cloud Flare Ну то есть проверка заголовков проверка куда веб-сайт ходит за внешними ресурсами И так далее Вот для этого ну буквально да типа 20 баксов В месяц да да Ну вот вот мы про базу поговорили Давай тут как раз вот я бы ифру обсудил как фронт для решения определённых задач и например собственно балансер и Application сервера да то есть когда мы говорим про две наверное вещи да В первую очередь это я кстати сейчас могу перепутать это же входит в том числе в отказы устойчивость Да когда мы понимаем что если у нас одна машина она у нас может умереть И всё да и соответственно мы нам нужно две машины и здесь вот подчеркну что благодаря тому что это й это очень важно Это Кстати от программистов зависит То есть если программисты неправильно делают у них будут с этим проблемы понимаешь тут есть хитрость одно дело понимание й на уровне типа ну файлы нельзя там хранить у вас просто если две машины у вас на о F5 Значит есть файл на другом нет плюс Понятное дело что как собственно с этим работать но там есть ещё одна проблема существуют фреймворки это вот на уровне кода Когда у вас люди начинают опять же не понимая этой концепции они начинают стейт хранить именно в апликейшн

надо бить за такое По рукам есть фреймворки которые к этому толкают которые например хранят фронтенд часть например Частично на сервере и если ты не делаешь ки Session Да кто не знает Вот например есть у вас веб сокеты или какие-то вещи Когда у вас есть всё-таки какой-то стейт даже если это сессионный стейт временный да вам придётся его не нужно на сервере хранить его нужно хранить в редисе в каком-нибудь если вам нужна [аплодисменты] са слать Да ну видишь опять это вот это знание которое есть но просто надо вообще саму проблему понимать Короче как только у вас в апликейшн внутри оказывается некий локальный стейт вы вам просто и вы такие О'кей надо отказа устойчивость обеспечить что если одна машина умрёт вторая Да ну и плюс производительность предположим Да ну потому что две машины лучше чем одна в этом смысле но вы сразу попадаете в то что если у вас есть этот стейт балансировка нагрузки типа балансер же как он по раунд рону Да у тебя в одну вторую Ну по дефолту зависит от того как ты его сконфигурирован на Ну по дефолту да Обычно раунд Робин вы делаете F5 он вас раз как бы отправил на другую тачку и вы такие у меня типа вообще хрень какая-то это кстати ещё и это ещё и супер неприятно потому что такие ошибки они ещё и супер сложные Потому что когда у вас типа F5 работает а F5 не работает Это не всегда очевидно что происходит это и с Шами же ещё связано да А и что у нас в этот момент получается в этот момент получается люди понимают Ага а стейт хранить нельзя здесь и что у нас файлы выносим А в S3 как правило Ну или Аля сейчас же получается что у тебя любой object storage он как правило соответствует интерфейсу S3 да потому что все фреймворки ожидают S3 compatible да да это кстати круто это редкий случай когда у тебя полная унификация Да по это вообще восхитительная вещь прямо по интерфейсу Угу Да так что то есть ты даже не можешь сказать что использование S3 - Это vender lck потому что у тебя есть S3 compatible в каждом облаке и всё все Да да поэтому кстати когда люди говорят слово S3 не воспринимайте это как сервис именно амазона то есть речь идёт про то что ну просто типа хранилище вот такого типа это уже всё это знаешь как гуглить слово да S3 - это уже всё просто им положи на S3 да хотя при этом мы тоже называем S3 хотя мы в Яндексе храним да как бы ну Яндекс тоже предоставляет S3 Так что да да да да ну Digital все все У кого это есть Ну видишь да то есть опять же у тебя Вот Все эти решения Они же в индустрии тоже взялись Не с потолка потому что кому-то очень захотелось а потому что возникла реальная бизнес проблема Да а как от масштабироваться обеспечить Надёжность несколько инстан сов а а State Ну externalize your State Да вот и дошло до того что мы пришли в кубер в котором типа стейт вообще не нужен да ну буквально ты можешь базу данных крутить в кубе у тебя будет внешний сторедж под диски да А сам движок будет крутиться на крутиться в кубе в подах и и вот да именно кстати Поэтому собственно и появились вот хероку как один из первых пасов да который придумал 12 факторов в которых собственно вот эти концепции описаны для масштабирования Как должно быть и действительно Если вы например на хероку пытайтесь заехать это Кстати классный знаешь я вот считаю что с точки зрения обучения это офигенно потому что он тебя заставляет делать правильно То есть ты туда едешь и такой думаешь О а мне нужно файлы хранить они говорят сорян ребят у нас нет диска вот пожалуйста пять сервисов интегрируйте сами тоже самое внешний сервис и так далее и так далее и у тебя как бы вот эта вот картинка Она более-менее правильно формируется благодаря таким сервисом потому сам делае Я бы поспорил и сказал бы что облако делает Тоже самое особенно если ты в серверс идёшь такой это оно есть просто у меня лямда так у тебя локального диска Нет ну там кроме Фора Но его нет поэтому либо в иди либо В3

Poison Так что да и И точно также начинается история про все остальные аспекты типа Security Да а как мне проверять что у меня пользователь есть Ну у тебя есть глобально два варианта либо ты хранишь пользователей в базе и делаешь всё руками либо у тебя вот есть API Gateway есть когнито есть Ред пользователей которые тебе обеспечивают некоторую штуковину либо что-то ты заменяешь сам когнито на там azero например да то есть это внешний identity провайдер Вот и так далее То есть вот эти вот блоки из которых ты решение строишь Да облако тебе и там внешний са сервис они тебе предлагают типа вот ты можешь здесь Взять вот это здесь вот это и самый главный вопрос да который ты себе должен задавать это А чем я жертвую вот если я беру там не знаю API Gateway чем я жертвую Ну возможно он будет дороже чем какие-то другие решения да Или я беру типа я выигрываю очень сильно в скорости потому что я сразу получаю нужный мне возможности Но при этом опять же мне нужно будет платить деньги за это А если бюджета нет но есть время можно написать самому как бы потому что тебе не нужен весь API Surf Тебе нужно там типа три фичи из него Вот то есть это всегда трейды такие ну бывает такое что у тебя есть И решение которые ты внутри Можешь использовать и с возможностью знаешь съехать на Self решение то есть в этом плане кстати тоже интересно с точки зрения бизнеса могу так сказать современ мир Да он же во многом про интеграцию у тебя маркетинг CRM системы аналитика и у тебя огромное количество времени уходит то есть типа вроде Казалось бы ты платформу делаешь фичи На самом деле ты сидишь интеграция занимаешься да большую часть времени во многих проектах Мы в какой-то момент когда знаешь Вот начало всё сыпаться с началом войны и у тебя значит ты сидел на одних сервисах у тебя резко они все перестали работать мы там и со страй на Cloud Pay там тос То есть просто 2 года сплошных У меня в жизни Такого не было Мы научились просто вот брать знаешь вот всё что у нас есть и там силком пересаживать на всё другое и ты после этого по-другому кстати начинаешь это вот очень классный с точки зрения такого инженерного подхода момент например знаешь как есть вот Одна из таких задач это собственно события Когда знаешь типа сервисы типа запи который позволяет интегрировать любой сервис с любым да то есть у тебя там вот ну это во-первых дорого во-вторых это очень сильный венло плюс эти сервисы они очень быстро дорогие становятся со временем пото что событий количество растёт и в какой-то момент ещё они опять же там типа Россия не Россия начало всё это блочить и мы такие чёрт побери задрало и мы знаешь как начали сейчас сказать мы в основном стараемся использовать решения желательно не свои но такие которые можно типа если что перевести к себе К себе поставить себе да да то есть мы по дефолту поэтому Например у нас для аналитики вот было время когда амплитудой все пользовались амплитуда сделала они такие уних бы ный план на миллион там миллионы событий прям реально классный они такие типа Ну хорош ребят всё бесплатный план закрываем И не только мы все такие Ай что делать типа ну потому что такие продуктовая аналитика - это дорогая штука у тебя нет особо альтернатив Окей полезли по Реди ту искать находим есть пост хок например та такое решение которое очень похоже при этом у тебя у них есть прямо вот Open Source всё Ты можешь е все поставить поэтому например последние годы все сервисы которые мы используем или решения принимаем они всегда такие в идеале облако с возможностью Ну в смысле Облачное решение с возможностью к себе его если что переставить и работать вот как альтернатива запи это N8 у нас

пришёл у меняй в школе Дай пришёл Я хотел сказать что я сталкивался с этой проб е 10 лет назад когда мы нетели там одном из рений использовать Google потому что и с ним может что-то случиться всё что угодно и мы ставили локально пик это типа оффлайн ну как бы это такая же аналитика но которую ты можешь себе в контур поставить и и наслаждаться А с Google аналитикой есть маленькая проблема тут не могу не сказать от неё иногда В некоторых случаях отказаться Физически невозможно знаешь по какой причине потому что ну например контекстная реклама обучение её Да оно связано с аналитикой То есть у тебя Facebook там и другие штуки если ты рекламу запускаешь ты обязан Ставить их код чтобы у тебя обучались рекламные компании Значит ты просто Ну работать с ними не сможешь поэтому тут немножко сложнее ситуация да да вот это ещё тоже такой Пласт решений который надо принимать и нужно быть аккуратным потому что если часто это пытаются сами всё делать И конечно это превращается в десятки разработчиков сложные системы и всё такое Слушай мы про балансер прямо в двух словах сказали но всё-таки тоже надо оговориться а балансер же обычно всё-таки да это некая абстракция которую мы используем в облаках потому что ну самому типа машину ставить у тебя ещё одна точка отказа То есть тут тоже Надо всё-таки разбираться и понимать и уметь и в этом смысле я наверное просто в двух словах скажу для аудитории кто с этим не знаком Я просто помню сам когда знаешь я только учился программированию там девятый Например год и для меня всё звучало там балансер я думал Ну какие-то сложные технологии как вообще вы всё это делаете А потом оказалось что ты в облако заходишь нажимаешь создать балансер и указываешь две тачки которые под ним сидят и такой всё думаешь всё это же это Ну типа как ну типа это вообще максимально просто да и для тех кто думает что это страшное слово это не страшное слово Действительно это так и работает Это вы создаёте некую штуку которой нет физического Ну для вас да этого восприятия А и соответственно главное ну грубо говоря мы просто её айпишник везде указываем в ДНСе Да и на неё идёт запрос она уже там сама разруливает и вот тут интересно а то есть во-первых мы таким образом горизонтально

он её там убирает Да вот у нас плюсы Ну тут тут надо поговорить да балансер А как балансер узнаёт что тачка умерла А что такое что такое типа Давай немножко поговорим по тоже классная штука да как это сконфигурировать на тачке чтобы эти сигналы на самом деле уходили Да ну то есть это это всё разговор То есть тебе кажется что ба простая штука Да особенно знаеш ты открываешь

таки ребёнку скучно родители сидят за компьютерами за своими Да мне повезло у меня в школе один Второй спи Вот ты пишешь типа бан Он такой Он такой хорошо А что мне надо в прописать Ну ты пишешь алгоритм Да там типа L connections например и пишешь сервера типа один айпишник Второй айпишник третий АШК и conne он может сам разрулить Но если тебе нужна нужен какой-то Более сложный протокол там который основывается на там CPU consumption или Memory consumption то тебе нужно прямо обели делать тебе нужно чтобы твоё приложение давало метрики чтобы ти метрики куда-то в прометеус складывали чтобы у тебя н смог в этот прометеус посмотреть на вот эти метрики и так далее ну то есть это то что тебе например даёт облако когда ты про виртуальные машины про groups смотришь И там проче ты можешь прям выбрать просто C чек чек там трешхолд задать как бы и там Т балансер будет это делать но вообще говоря если ты собираешься делать это руками это как бы займёт некоторое время чтобы

[музыка] сконфигурировано ну да то есть грубо говоря есть определённые способы проверять живость серверов опять же в облаках это всё как правило реализовано Да оно всё это делает ну и соответственно под один лот балансер мы То есть это наверное самая простая часть всей этой системы потому что именно эта вещь обеспечивает нам Ну довольно серьёзное масштабирование то есть давай так бесконечно если мы не упирается в базу Ну это очень грубо конечно но по факту мы можем там 100 серверов разместить и если у нас Мы всё-таки в базу Не упрётся а скорее всего мы упр то это очень Простая история Вот они у тебя ещё Ты ночью спишь У тебя три умерло два поднялось если ты ещ автоматику настроил особенно если у тебя куб то соответственно это е всё сам делает и ты такой смотришь и глазам своим не веришь это прикольно кстати наблюдать Да когда у тебя такая живая система которая сама тут выпала встала поднял нагрузка увеличилась плюс 50 серверов да это Это очень прикольно и потом на графике смотришь ну правда ну то из того что я видел там у одних ребят у них монго кластер стоит и ты когда в атлас заходишь там там графики стоят по нагрузки и ты видишь что у тебя большая алике загрузка Да там типа Рай А на двух других это просторе примерно почти Прямая линия по графику это просто репликация а потом в определённый момент как бы у тебя твоя нода она перестаёт это делать и превращается в реплику другая нода становится главной То есть у тебя атлас переключил сам ноды потому что что-то пошло не так в определённый момент у тебя такой вообще класс то есть вот куб его уровень уров п Облака Вот это вме это коне про просто космический живой такой системы которая сама там скели масштабируется разворачивается сворачивается проверяет все нужные параметры и так далее но по факту вот то что мы сейчас с тобой разобрали это Ну можно же сказать что это некий наверное не то что минимальный уровень Но это вот стандартные механики масштабирования обеспечения надёжности и так далее которые подходят для подавляющего большинства проектов и хватит на очень-очень Большом объёме То есть в принципе типа Все говорят not Google Да не надо решать проблемы для Гугла которых не существует в вашем проекте типа базовые тактики их обычно хватает Ну видишь на интервью то тебя спрашивают типа про космические корабли Вот кстати сейчас мы к интервью перейдём есть наверное только ещё пару моментов которые Ну чтобы завершить эту картинку А 100% сюда ещё Сиде Но как правило опять же во-первых в облаках он есть даже если нет мы можем вот мы уже говорили несколько раз есть Cloud фра берёте её ставите стоит копейки и вас от доса защищает и кэширование включает и кстати что ещё классно https тоже если вам это нужно Он всё сам делает вот ну либо кстати опять же это можно использовать в облаках Если вы на облаках там тоже всё это есть Ну кстати не настолько Круто как ВФ но большая часть вещей есть тут правда по настраивать придётся покопаться вот с этим знание конкретного облака И что ещ в эту А ну Слушай наверно вот Единственное что ещ можно упомянуть всё-таки есть Вот ты говорил про проблему 10к конечно ещё вся эта система она всё-таки зависит от технологии Поэтому если у вас какое-то асинхронное м используется фреймворк какой-нибудь асинхронный то Естественно он будет выдавать гораздо больше рпсо чем это делает какой-то такой классический там не знам классическая JAVA да со своими то есть вот тут Вы конечно можете помимо вот того что мы описали масштабирование получить просто тоже там десятки иксов в производительности просто за счёт того что использую этой штуки и в конечном итоге скорее всего вся эта система упрётся в базу поэтому что бы у вас там ни было все так или иначе начинают работать с базой начинают с индексов и поверх кэшировать кстати вот по кэширования тоже есть такой знаешь Поинт я очень боюсь знаешь чего когда вот работа идёт с такими системами люди слишком кэширование слишком упрощает путь часто и они вместо того чтобы вс-таки подумать и принять правильное решение начинают втыкать этот кэш просто везде кэширование часто это как бы следствие они ну подчинить следствие О не причи то есть Есть места конечно Где оно нужно и где-то нужно очень сильно но я вижу что тенденцию типа ну это же проще чем делать что-то другое у тебя просто обвешивают везде кэша и в конечном итоге это на самом деле вредит системе у тебя бывает такое или ты я сталкивался скорее не с тем что кэш стоит не там где надо а с более глубокой проблемой это то что люди не понимают свою дату модель Ну то есть не понимают модель запросов типа А что что пользователи на самом деле просят и второе неправильно используют базу данных ну то есть базы данных сейчас это очень крутые инструменты и ты часто можешь обойтись без кэше и конечно нужно тогда когда у тебя ну реально данные не меняются и вот ты можешь их использовать там не знаю если мы говорим про Food Delivery Service Да меню у ресторана меняется редко может быть раз в месяц у кого-то годами оно может не меняться кэш прекрасно прекрасное решение Да но если вы не понимаете дата модель и там вам для одного экрана нужно дёрнуть типа десяток разных несвязанных с собой таблиц то у вас проблемы с тем что А может быть вы дата модель спроектировали не так как вам нужно для приложения и вот там начинаются гигантские вот перформанс проблемы которые связаны не с тем что у вас база плохая или хост слабо или ещ что-то А с тем что вы просто делаете вообще не то Ну это может быть и оно могло просто исторически поменяться Но кстати в этом плане всё-таки грамотный инженер может понимать что например сейчас кэш надо всё-таки поставить чтобы это закрыть но долгосрочно на фоне они например там рефакторинга занимаются это конечно круто если так Потому что далеко не всегда люди до этого доходят это надо иметь всё-таки и Стальные яйца потому что такие решения и проталкивать следить за ними на протяжении долгого времени Да что мы что-то меняем как будто бы всё да то есть вот некий минимальный такой Блок Мы с тобой разобрали то есть дальше это уже супер такие специфические техники и применение например шардирование и так далее гарантированно говорит о том что в вашей команде 100% есть профессионалы Ну да хочется надеяться что они есть Не ну шардирование делать без таких ребят Это конечно за гранью Мне кажется уже немножко ну там на самом деле большое количество драйверов баз данных поддерживает эти штуковины тебе ну коне те Конечно нужна экспертиза по поводу того как настраивать Хосты для этих баз и как за ними ухаживать Поэтому да но если ты там идёшь в РДС который делает там 60% за тебя Ты можешь шардирование в этом РДС намутить да Ну опять же это уже всё-таки речь идёт о том что вы выжили Если всё остальное То вы уже крупные ребята Хорошо давай теперь перед тем как про собесы поговорить да вот прямо последний момент мы точно с тобой не можем пропустить тему микросервисов потому что вот мы сейчас говорим и мы так много обсуждали что столько у тебя есть потенциала для роста А микросервисов ещё и

Нет не надо надо Вот скажи про это да а Некоторые сразу начинают с них типа ребята нам надо вот смотри да смотри микросервисы они решают очень определённую проблему То есть это не просто типа идти by default а определённая проблема с тем чтобы тебе нужно там не знаю у тебя на разных технологиях вещи написаны А у тебя есть проблема с там не знаю типичное приложение которое ты там на ноде написал или на PHP и есть Machine Learning pipeline который тебе там модельки нужно гонять и ты не будешь его на PHP писать поэтому ты будешь на пайне делать И вообще там типа профиль вызова этого пайплайн другой другая причина для для микросервисов это того что у тебя есть несколько команд и они у них разный релиз цикл Да и там разные требования поэтому Там микросервисы могут быть J да оправданны да потому что у тебя разные команды разные бизнес-требования разные там перформанс требования и так далее Но обычно этого нифига нет как бы и у вас в системном дизайне это называется архитектурная Кванта да у вас эта Кванта одна у вас единый набор нефункциональных требований которые вам нужно удовлетворять Пусть это будет Монолит да А когда вы увидите другую квантування

[музыка]

билин 100% - это прямо отдельный некий продукт который внутри делается потому что это прямо продукт Зачем вообще тут слово микросервисы использовать То есть у тебя просто вот конкретно биллинг - это отдельная команда Вот они отдельно сидят его пилят и это как бы похоже Ну там там там ну там там десяток микросервисов внутри по Ну это внутри Да но я имею в виду что как бы я знаешь про что имею в виду то есть с точки зрения вот как бы команды потребителей биллинга это ничем не отличается от того что если бы я в Страйп пошёл то есть там миллиарды этих микросервисов но токо мне какая разница у меня есть просто понятная пишка Я работаю с сервисом То есть я имею в виду что на уровне всё-таки таком архитектурном высокоуровневым микросервис - это проблема внутреннего продукта это типа вот это кишки но с точки зрения системы есть крупные сервисы которые вы выделяется потому что они вот прямо продукты отдельные С ними надо отдельно работать а дальше у вас IP gway там всё что хочешь да естественно и кстати вот я ещё знаешь такое мнение периодически слышу что вот микросервисы производительность там типа я такой блин ребят по дефолту Если вы начинаете с них делать вы наоборот у вас всё будет сложнее и хуже конечно Time to Market будет наоборот больше потому что в тех случаях когда вам нужно просто функцию вызвать вам нужна интеграция между сервисами А это контракты это там очереди не знаю что ещё и сквозные транзакции Да там Раде ой ой транзакции это это нерешаемая проблема вообще Несмотря на все там типа двухфазные коты трёхфазные коты Саги Там и так далее Это в итоге не решённая проблема поэтому её лучше избе Да короче микросервисы штука наверное ну Да не наверное важная хорошая но явно не Не сначала не первостепенная Да чтобы её втыкать и исходить из того что она вам поможет знаешь у меня вот есть к некоторым вещам отношение такое типа мы когда про кэши про индексы там вот Про некоторые вещи я всегда пытаюсь своей команде объяснять что вы должны это воспринимать как зло То есть это типа надо использовать иногда Но только потому что не осталось Другого выбора это не надо воспринимать как добро типа О классно сейчас мы это в тащим наоборот избегайте этого должна быть очень очень весомая причина чтобы это использовать дада да То есть вы 100% где-то уже должны были упереться у вас должна была быть проблема которую эта штука решает если у вас нет проблем и вы такие типа О это классно у меня плохие новости Ну слушай CV никто не отменял типа Давайте поставим кафку потому что Ну кто же без каки Да в современном мире Естественно да хорошо ребят кто вот сейчас нас слышал опять же Расскажите Поделитесь потому что я не знаю какой у вас уровень он разный то есть насколько это были базовые вещи или для вас это что-то откры потому что я точно знаю что для фронтенде например было известно ребята которые делают большие системы конечно для них это тоже база но в общем добавьте сюда а если мы что-то упустили Напишите Что вы об этом думаете нам будет очень интересно почитать про ваш опыт особенно если вы встречались со всякими разными решениями которые странные и были приняты не на основе каких-то разумных доводов вот я обожаю эти истории всегда их собираю и потом рассказываю смотри При всём при этом системный дизайн вот конкретно ты приходишь на Собес и ты знаешь что он там будет насколько я могу судить вот тут точно скажу что я сам в этом не участвовал вот в таком виде формальном поэтому могу ошибаться там очень много уделяется внимания Ну типа например там не знаю а пропускной способности там каким-то вот таким расчётом цифровым когда надо вот типа посчитать Да да это правда и всё Это слабо имеет отношение в реальности Это не совсем так не совсем Расскажи пожалуйста нужно понимать одну Большую разницу между Сим дизай интервью и реальным проектированием Разница в том что у тебя не совсем реальный бизнес-кейс и у тебя всего час времени Ну может быть полтора часа на то чтобы это спроектировать на работе Нет никогда дедлайна что вот у тебя есть по ча Принт Да того как мы будем делать Ну это так не работает ты там общаешься с несколькими людьми выясняется какие-то ограничения смотришь на там ограничения которые есть в компании что-то проектирует берёшь первоначальный фидбек делаешь proof of Concept собираешь больше фидбека делаешь там первую версию у тебя что-то получается ты дальше эволюционируешь и так далее да то есть это процесс который растянут на недели и месяцы вот как бы в в в живом кейсе то что тебе нужно сделать там типа обычно за первую неделю это какой-то блюпринт собрать написать там какие-то большие предположения выделить основные архитектурно значимые требования Да и согласовать со стейкхолдерами типа вот мы делаем вот так чтобы они сказали ну там типа там Инжиниринг менеджер тво или там Главный заказчик проекта там или ещё кто-то сказали да Нас устраивает как бы трейдо которые ты выбрал подходящие поехали типа вот бюджет Да но тебе при этом в этом проектирования тебе всё равно нужно посчитать затраты на ресурсы типа сколько тебе сервисов понадобится какую ты квоту отнимешь у там кубер кластера Нужен ли тебе отдельный кубер кластер это вот одно из решений Да какие роли тебе будут нужны там какие люди в команде тебе понадобятся Чтобы это делать В первую очередь и так далее То есть это эти решения они вот все из вот из этого дизайна Выходит то что происходит на собеседовании это тебя просят вот весь этот много недельный процесс сжать до полутора часов чтобы понять что ты можешь это в принципе вытащить Да это одна идея вторая идея System Design интервю это в том чтобы через него понять Твою синьори Ну то есть условно с размером какой сложности ты сталкивался в принципе вот это выяснить Ну потому что банально А сколько тебе денег платить Как это понять По лит коду Ну сейчас как бы все либо решают Т код либо не решают код это как бы бинарный фильтр такой ти разговаривать с тобой дальше или нет а вот System Design - это способ собрать некоторые сигналы про твою Сень как это по-русски сказать про твою зрелость Вот давай так скажем вот и дальше выясняется что ну кто-то типа круд писал На одном сервере как бы его ничего не волновало он ни про балансе не знает ни про шардирование не знает ни про CL не слышал ничего Ну типа какая тут как бы п как бы вот шофер спасибо Ну то есть это не то чтобы мы откидывать человека а мы выясняем как бы а какой уровень ответственности мы ему сможем дать да либо Потом приходит человек и говорит ну типа у меня была производительность на 10.000 ПС вот типа вот как мы это делаем Ну то есть это выясняется через не просто про то не просто человек тебе рассказывает как он якобы делал да А типа вот Вот задачка Вот сделай и ты собираешь очень много разных синьори сигналов типа А Спрашивает ли человек а что мы вообще делаем Ну вот как я уже говорил некоторые люди такие ставим ло балансер Нахрена тебе ло балансер У тебя внутренняя система в которой три обращения в день будет Типа какой балансер О чём ты вот то есть Первое - это сбор требований типа выяснить бизнес задачу попытаться понять бизнес А что для этого бизнеса важно потому что из этого ты будешь дальше вычленять А какой профиль нагрузки Да опять же если у тебя внутренний пользователь в аналитике Например у тебя будет три чтения в день но при этом у тебя будет гигантский объём на те нужно технические решения выбирать с ум записи Да ты условно вместо постс ты возьмёшь кликхаус Да потому что тебе из этого аналитику надо делать Вот вот у тебя связь между бизнес задачей и техническими решениями Вот это первое То есть как как ты выясняет бно требования собираешь второе Каким образом ты можешь связать вот эти вот потребности с техническими решениями да И тут вот ты сказал расч типа они не нужны они нужны ты по те ставить сервера или 10 как ты пойм нужно тебе базу выбирать или не нужно как ты поймёшь сколько серверов этой базы тебе нужно Да а как ты там будешь решать более глубинные задачи А как ты будешь фре Да решать вот вот это вот всё имеет значение и за счёт вот всех вот этих вот челленже которые те встречаются може Да сделать вывод Ало самом рабо Да Слот балансера Он про них только в книжке прочитал Ну типа мы не можем ему сеньора дать потому что наше ожидание от сеньора что он может Вот такие системы строить на раз-два да Или наоборот это блин прямо такой высокий уровень у нас сеньоры так не делают это наверное стаф Давай ему там ещё больше денег дадим Вот вот так вот то есть ты как бы пытаешься понять с какой зоной ответственности человек столкнётся и вот вот поэтому это сиди интервю он такой странный я имел вду про цифры немножко другое что это всё такое чуть-чуть с потолка берётся потому что там линейно считать например количество rps которое у тебя выдаёт там одна машина а потом Такой типа просто линейно сложил оно ну оно так не работает ты там будешь упираться ну оно так не работает но смотри тут же задача не в том чтобы точно сказать Типа сколько мегабайт оперативной памяти тебе нужно потому что каждый мегабайт очень дорого стоит это не про это Это про то чтобы помочь тебе сориентироваться системой како масштаба ты имеешь дело в первую очередь какая-то очень высокая нагрузка Да ну Cloud Play например или с который тебе нужно с нуля сделать Да вот либо это локальное решение на там на на тысячу пользователей с которым с которой справится одна машинка либо это что-то посередине там не знаю тысяч на 50 на 100 Вот потому что цена у каждого решения Она будет очень сильно разниться у тебя экспоненциально цена растёт от роста количест Так что что вот ну то есть понимаешь то есть ты с одной стороны выясняет вообще в принципе спроектировать большую сложную систему а с другой стороны выясняет на деньги посадить условно Ну то есть опять же ты будешь делать админку на трёх пользователей А он тебе туда десяток микросервисов и в кафку поставит и ты такой Почему у меня типа Кост этого кластера 10.000 долларов в месяц Ну пото что инженерно проектировал бы Слушай а вот интересно не разумность всех этих штук она понятна сущест при этом видишь в чём прикол Дело в том что как я это вижу со стороны есть просто готовый набор типа стандартных неких Практик ожидаемых то есть вот такого же что каждый раз кто-то придумывает и классно там проводит Собес это очень сильно зависит от инженера и поэтому есть по сути практики подготовки к этому интервью какие-то стандартные кейсы типа серии проектируем Twitter и так далее поэтому у меня вопрос такой насколько это на практике Классная штука То есть я понимаю что например ты как профессионал скорее всего вот конкретно ты да ты можешь Там классно задать вопрос и проверить но вот если в массе мы берём не превратилось ли оно в такую Аля вот как алгоритмы там задрал их и получилось Ну я бы сказал что превратилось на половинку Да ну то есть в болте проводится System Design интервью у нас есть определённый список задач и у нас есть список критериев по которым мы решение задачи оцениваем Ну то есть условно подумал человек про durability подумал Про retention продумал про avab продумал про Single Point of Fail подумал Про там остальные атрибуты Да там требования собрал адекватно эти требования за адреси как бы и так далее вот ну то есть но у тебя есть типа идея о том как это проходить Да собери требования начни с одной машинки дальше Начни решать каждую задачу и типа Расскажи как как это работает под капотом вот плюс там типа доно специфичные проблемы Но тут есть трюк в том что если ты сам реально не делал и ты просто прочитал книжку о том как готовиться к интервью Да это будет видно ну то есть люди начинают говорить типа ну там типа мы тут кластер поставим базы данных ты такой О'кей А зачем он такой Ну вот то есть у тебя должен быть чёткий ответ А нафига тебе кластер какую ты проблему решаешь конкретно Да и и правильный ответ - Это всегда Ну вот смотри я же из требований собрал нам нужна доступность чере девятки да То есть даже даже двумя инстанса Мы её не закроем нам нужно M по что ты иначе 4ре девятки не получишь вот плюс к этому У нас есть требования по по там перформанс и типа исходя из вот этих чисел ты не сможешь нужный перформанс получить Поэтому ты там сюда ставишь кэш да а здесь делаешь шардирование и так далее То есть как только ты види Челове использует Като решения которые не основа требования пони superficial да то есть он может тактику правильно назвал но он не понимает почему почему это правильно вот и это видно вот так А как по твоему опыту вообще насколько прохождение этого этапа коррелирует со всем остальным что э происходит на собеседовании или может быть так типа всё остальное Классно а тут посыпался целиком то есть насколько это вообще сложный этап для большинства людей с которыми ты сталкиваешься я бы сказал что основная сложность э в том что люди не понимают ожиданий как бы а что они должны там делать то есть от тебя даже не не то чтобы ожидают что ты вот прямо лай систему сейчас спроектируем которую можно программистам отдать они её сделают и всё будет работать ожидают Понять насколько ты можешь понять задачу и применить соответствующие это не паттерны а соответствующие тактики да для их решения Вот выясняют именно именно эту причинно-следственную связь есть она у тебя в голове или нет И вот люди Скорее всего Скорее Вот это не умеют нежели Ну то есть условно если ты мне скажешь что типа вот твоя нагрузка Да у тебя один инстанс сервиса не справится тебе нужно несколько Да и там какие-то цифры релевантные Приведёшь там типа вот у нас Java сервис он отрабатывал 1500 запросов в секунду но в конкретно этой ситуации мы берём jav но нам нужно 10.000 запросов в секунду поэтому один сервер один сервер не вынет Да поэтому мы ставим L balancer и дальше я спрошу типа а а какой алгоритм ло балансинг нужно использовать и ты скажешь Ну я не знаю ничего кроме РАУ Робина я скажу perfly with me Да ну то есть про алгоритмы ло баланга можно почитать Мне важно что ты понимаешь А нахрена этот Т балансер тебе нужен в первую очередь вот всё остальное Ну типан за полчаса ты можешь это понять знаешь что хочу по этому поводу сказать Вот есть мнение частое вот всё что ты сейчас обсуждаешь всё что ты сейчас говоришь Да ты сталкивался с таким что есть не группа А есть программисты которые вот когда таки слышат они говорят Ребят вы типа с ума сошли это вообще Причём здесь я я пишу код А вот это всё это вон туда кто у ва Как вы их там называете да типа это вообще не задача программиста что ты про это скажешь это ужасно Я считаю что это большая боль индустрии что почему-то многие разработчики считают что их задача писать код ребята код - Это последняя веь которую от Вас ожидают задача программиста техническим пум часто это значит что надо написать код но также часто Это означает что А здесь не надо писать код здесь надо взять сторонний сервис Да часто Это означает что здесь не надо писать код надо Полежи продуктовые ректы и сказать что давайте мы сделаем вот это да потому что не знаю потому что тогда вообще ничего делать не при Оно просто заработает из коробки технологию которая которая решит задачу за вас вот это ожидается да а то что вы ещё код умеете писать Ну хорошо Да это часто надо но это ну как бы кодик теперь мки могут писать если вы умеете только писать код вы не нужны Так что Так что когда мне программисты говорят что типа ой там эшники про это что-то должны знать типа иди и выучи иди разберись как бы не совсем пром Диза мне часто такое говорят про продуктовые требования типа вот прит а что делать надо а шку мне дайте да да шку мне дайте ужас просто как бы я такой типа ну я не говорю что Я уволю тебя сейчас я говорю Слушай ожидания от разработчика другие вот такие поэтому как бы часто бывает что у тебя не хватает продукт менеджеров в команде И тебе приходится это закрывать и тогда эта проблема ещё острее встаёт Да ну то есть люди которые не могут поговорить даже с продукт менеджером поговорить и как-то обсудить продуктовую задачу типа А зачем мы это делаем а какая польза от этого юзеру ну это не удовлетворение моих ожиданий Вот и и я скажу что ваша ценность на рынке она будет сильно выше Если вы сможете как бы вот вот эти вещи обсуждать нежели типа дайте мне знать что написать я напишу и это правда то есть Э это для меня например прина мни одна из Ну наверное самая большая боль потому что именно я знаю что не все со мной согласны и некоторые даже очень со мной не согласны когда про это говорю то есть вот я когда собеседуем человека программиста Я не говорю что это прямо влияет капец на моё решение Но мне интересно про это поговорить Я спрашиваю всегда А я про компанию Ну кто где Чем занимался и знаешь я обычно что спрашиваю вообще на чём компания зарабатывает то есть в чём её бизнес в чём деньги и вот тут особенно именно те кто претендует на лидерские какие-то позиции и действительно Забавно наблюдать как очень многие вообще не представляют Откуда берутся деньги то есть для них есть какой-то вот просто космос и вот оттуда они значит их вытягивают это конечно чаще встречается особенно в корпоративной культуре большой энтерпрайз потому что там Ну действительно люди далековато бывают от центра принятия решений и для меня например иногда это бывает критично потому что я понимаю что человек с таким то есть это не значит что он плохой программист или вот там плохо что справляется но конкретно в моём случае с таким майндсет не получится хорошо потому что тут действительно надо постоянно задавать эти вопросы и челленджи абсолютно всё что тебе приносят потому что в большинстве случаев делать не надо то есть Бывает даже так что удаление кода - это И решение задачи это правда да кстати я знаешь заметил что почти ничего не является чисто рациональным принятием решений то есть Вот я например по себе знаю что А я обожаю Фактори удалять код Мне нравятся простые системы но это не связано с тем что я типа знаешь этому учился что О вот в какой-то момент я это было во мне всегда вот в самом начала Как только я начал программировать Я почувствовал что во мне есть такое влечение и поэтому когда Я смотрю на программистов которые делать любят всё без фреймворков Я тоже понимаю что это не просто м его какой-то путь развития это откуда-то вот не знаю там из генов из души это вот какая-то внутренняя штука да потому что я уверен что это проявляется ещё в других местах это проявляется в том как ты дома какие-то вещи Может быть делаешь Как ты в игрушки играешь в конце концов вот а какие-то там предпочитаешь так далее поэтому это интересно это всегда вот такой комплекс Ну Ну конечно потому что потому что люди не являются стопроцентно рациональными существами потому что наша природа она не в том чтобы строить сложные системы Да наша природа она в том чтобы выживать помощью разума Ну то есть не за счёт там скорости или выносливости или ещё что-то за счёт разума и как общество выживать Вот и поэтому когда мы начинаем делать чи технические штуки вот все все басы типа А мне вот тот чечено

не знаю в не знаю в детстве мне чего-то не хватало поэтому я сейчас что-то компенсируют на то на то что ты выбираешь Ну то есть вплоть до того что ты можешь это не осознавать что ты там не зна Ну как бы у меня есть примеры женщин которые строили успешную карьеру только на топливе того что у них отец ушёл в детстве рано и там были с ним проблемы теперь вот она чувствует что она обязана не зависеть вообще ни от кого и что она должна мочь всё сама Ну у неё там типа нервные срывы там и всё остальное но она продолжает работать вот Вот потому что есть внутренняя нужда и как бы разработчики Вот они такие люди Да они будут как бы спорить там у меня сейчас есть разработчик в команде который типа просто стоит на своём на своих мнениях вплоть до того как мы класс какой-то будем называть и вот они неделю сру понимаешь с другими с другим разработчиком типа А как назвать там типа это адаптер или репозиторий короче и так далее и там типа книжками Мартина фаулера друг друга кидают но я прил Ну там команда была сформирована до меня пришёл к ним как менеджер Я говорю ребят какую бизнес мы сейчас для продукта получаем они такие ну надо правильно А им интересно об этом говорить я уверен Да какой ты что класс надо назвать Ну типа Надо же правильно называть это же имеет последствия я говорю да но типа эти последствия они могут занять гораздо меньше времени чем вы просто спорите поэтому примите рение и Поли опыта консультации подготовлю ито сделал Вывод что людям не хватает систематических знаний да о том как интервью подходить и вообще Как проектировать Да программные системы поэтому у меня есть целый курс Business oriented System Design course сейчас идёт четвёртая группа Она займёт 2 с по месяца Но типа в апреле я буду набирать новую вот туда можно записаться в вейтинг лист и за 2 с по месяца научиться хотя бы идее о том как походить к проектированию какие есть тактики как их связывать с требованиями и как получать что-то жиз способна вот отлично Приходите записывайтесь проходите становитесь лучше мне кажется мы неплохо с тобой и поговорили подвели черту будет интересно посмотреть ребят на вашу реакцию обязательно подписывайтесь на канал на YouTube на ВК там где это выходит Не забывайте про Telegram мой канал организованное программирование в котором я тоже вас жду где я пишу всякие интересные разные штуки большое тебе спасибо все спасибо Кирилл Спасибо увидимся пока-пока

а

[музыка]