Weekend offer для системных аналитиков в Tinkoff

Через месяц у нас состоится weekend offer для аналитиков, который позволит попасть в компанию за выходные.
Мы ищем опытных аналитиков и готовы предложить им позиции в разных командах во всей организации.
Но я рекомендую смотреть на позиции внутри моих больших команд
- мобильном банке (желтое приложение)
- маркетинговой платформе
Подробнее про мероприятие можно узнать на сайте, а также там же можно зарегестрироваться, чтобы принять в нем участие.

P.S.
Если вам интересно узнать что делают системные аналитики в Тинькофф и куда они могут развиваться, то специально для вас я недавно рассказывал именно про это на конференции Flow.

#Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering #Vacancy

Проектируем надежные системы - стоит ли игра свеч на конференции Стачка

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

P.S.
К этому докладу я подготовил солидный список материалов, который еще и увеличился за последнее время
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Почему инфраструктура big tech обычно состоит из самописных решений

Крутая статья от Дмитрия, CTO команды Yandex Platform Engineering, в которой он объясняет появление кастомных решений в больших компаниях.
Он выделяет 6 причин:
1. Инновации - крупные компании часто сталкиваются с новыми проблемами, для которых пока нет стандартных решений. А дальше им придумывать эти решения сами
2. Масштабы - этот пункт частично вкладывается в предыдущий, так как часто новые проблемы обусловлены масштабом компании и ее задач. В итоге, дефолтные решения на таком объеме не особо работают
3. Инерция - когда собственный инструмент уже сделан и заточен под решение внутренней проблемы, то при появлении общего инструмента он часто не так хорошо заточен на конкретные кейсы. В итоге, для переезда часто требуется допиливать сам общий инструмент
4. Миграция - тут идет речь про стоимость переезда пользователей. Часто такие миграции со старых инструментов на новые стоят дорого и могут тянуться очень долго, что подрывает сам смысл переезда - дешевле дальше поддерживать собственный велосипед
5. Business continuity - внутренние инструменты позволяют обеспечить независимость от решений вендоров и даже от изменений лицензий open source проектов. Что важно в текущей реальности
6. Синдром not invented here (NIH) - этот синдром влияет на решение пилить собственные велосипеды и это объективная реальность:)

Автор демонстрирует эти причины на двух примерах
- Собственное облако Яндекса, которое появилось до K8s и сейчас продолжает использоваться и развиваться
- Монорепозиторий Аркадия, который позволил решить проблему svn, git, mercurial и все таки иметь возможность хранения всего кода (2 TiB) в одном репозитории

Интересно, что я примерно про это писал в статье "Как RnD появляется в крупных ИТ-компаниях" на примере Google, Amazon и почему это нужно Тинькофф:)

#Management #RnD #PlatformEngineering #Engineering #Software #SoftwareDevelopment #Leadership

100 главных принципов презентаций (100 Things Every Presenter Needs to Know About People)

В любой деятельности, которой я занимаюсь системно, я пытаюсь повышать свой уровень мастерства. Для этого я использую книги, статьи, общение с экспертами. И сегодня я решил вспомнить о крутой книге, которую я прочитал еще до того, как начал часто выступать. Мне редко нравятся книги по типу 7 волшебных способов прийти к успеху, 12 шагов мастерства, язык XYZ за 24 часа, публичные выступления за 7 дней и им подобные. Но эта книга не такая - в ней автор действительно приводит 100 вещей, которые полезно знать про то, как думают люди, как они общаются, на что обращают внимание, как принимают решения и так далее. Мне эта книга напомнила микс из книг про мозг и мышление, про которые я писал в посте раньше.

Если говорить про структуру книги, то она разделена на следующие разделы
- Как человек думает и учится - здесь автор погружается практические советы с учетом мышления людей: зачем нужен контекст, зачем делить информацию на порции, как работает долговременная память и забывание, зачем нужны примеры, сколько элементов одновременно может держать в голове человек, почему люди любят выделять категории, как культура влияет на мышление и так далее. Это очень интересная часть, особенно если вы уже изучали эти темы, а теперь просто изучаете как это влияет на создание презентаций и публичные выступления 
- Как удержать внимание аудитории - здесь автор говорит про длительность непрерывного внимания, а также то, что человек не многозадачен, что важен ритм и частота новых порций информации и как на внимание влияет подсознание
- Как мотивировать человека на деятельность - здесь идет речь про дофамин, внутреннее и внешнее вознаграждение, усиление мотивации по мере приближения к цели, про сложность формирования правильных привычек и их пользу
- Как человек слышит и видит - здесь идет речь про конкуренцию сенсорных каналов, важность активного слушания, насколько важно зрение и как влияет направление чтения на позиционирование элементов, а также про важность хороших заголовков и правильный подбор размера шрифта, почему мы хорошо распознаем лица, а также о проценте дальтоников
- Как человек реагирует на окружающую обстановку - здесь идет речь про то, как количество людей в аудитории меняют динамику выступления, про расстановку мебели, освещенность, температуру, близость приема пищи и ожидания возможности подключиться к сети по WiFi:)
- Эмоциональная реакция человека - начинается эта глава с того, что люди лучше реагируют на истории и эта реакция зачастую эмоциональна, продолжается тем, что люди любят сюрпризы, но одновременно любят безопасность, которая достигается за счет предсказуемости. Дальше идет речь про реакцию людей на красоту, музыку, радость и печаль, а также дефицитность того, что нам предлагают
- Как люди реагируют на вас - эта глава важна для того, чтобы понять как вести себя во время выступлений. Например, тут идет речь про то, как люди реагируют на авторитеты, как реагируют на позы и движение, искренность и интонации, выражения лица и эмоции. Насколько важна правильная одежда и попадание в ожидания аудитории. И почему аудитория хочет того, чтобы спикер контролировал ситуацию во время выступления.
- Как человек принимает решение действовать - эта часть книги пересекается с книгой Канемана “Думай медленно, решай быстро”. Здесь идет речь про принятие подсознательных решений, что страх потери сильнее предвкушения выгодыы, как настроение влияет на принятие решений, про конформизм и важность соответствовать мнению группы. Как мнение лидера влияет на коллективное принятие решений и как использовать подарки для получения обратной услуги 
- Как подготовить презентацию - здесь автор рассказывает про свой пятишаговый процесс: исследование, создание, подготовка содержимого, репетиции (много репитиций), выступления (много выступлений)
- Ваш 90 дневный план совершенствования - рекомендации автора как за 100 дней прокачать свои навыки презентации

#Presentation #PublicSpeaking #SelfDevelopment

Interviewing & Hiring Like a Boss • Kristine Howard • YOW! 2023

Интересное выступление Kristine Howard из Amazon, которая рассказала про то как проводить интервью более качественно. Мне эта тема интересна из-за того, что я сильно вовлечен в процессы найма и я стараюсь улучшать их по мере своих сил. Если же возвращаться к выступлению Кристин, которая является AWS Head of Developer Relations APJ, то она начала выступление с того, что лет 8 назад ненавидела проводить интервью, но как известно от любви до ненависти один шаг и когда-то она сделала его в обратном направлении как принято в Amazon:)

Дальше она перешла к основным пунктам своего выступления
- Что делать перед интервью - рассказ про подготовку job description, про ревью CV (и их подготовку со стороны кандидатов), как выстроить структуру цепочки интервью, как проверять hard skills и leadership principles (шардируя проверку разных скиллов по разным интервьюерам), как проводить preebrief, на котором можно получить дополнительную информацию о требованиях к кандидату, как готовить конкретные вопросы к кандидату (выбирая из подготовленого списка вопросов)
- Как проводить интервью - помочь им успокоиться, рассказать про регламент проведения интервью, зачем и как просить кандидатов рассказывать истории - по-факту, спикер рассказывает про использование STAR (situation-task-action-result) и SBI (situation-behavior-impact) для проведения интервью:) Дальше она говорит о том, на что обращать внимание при общении с кандидатом: смотреть на цифры, scope, impact. Уточнять что именно делал кандидат для получения результата. Не бояться прерывать поток воды и переходить к следующему вопросу. Как написать фидбек о кандидате - здесь спикер говорит о том, как уменьшить влияние предубеждений и объективно оценить кандидата по заранее составленному списку критериев.
- Как принимать решения по итогам всех интервью - здесь идет речь про debrief и ревью итоговых результатов кандидата и стоит ли его нанимать. Здесь приводятся стандартные подходы к принятию решений в группе. А также как обсуждать сильные и слабые стороны кандидата, а также интересный вопрос про непреодолимую причину для найма кандидата. Тут же разбирается вопрос о том, как коучить интервьюеров и давать им фидбек для их роста. А заканчивается эта часть тем, что у ребят весь процесс найма обвешан метриками и существует SLA на скорость и качество каждого шага процесса.
- Подсказки - спикер рассказывает про важность менеджмента календаря и затраты по времени на проведение интервью, также про отдельное интервью, где кандидат может поспрашивать не под запись о том, как работается в компании (полезно для minority representatives), про важность процесса обучения интервьюверов, а также улучшение опыта кандидатов.

P.S.

За 7 лет в Тинькофф я провел 700+ интервью и прошел путь от фаната найма к себе в команду с кастомным интервью в один этап до человека, который понимает зачем нужен четкий и понятный процесс, разделенный на отдельные этапы с формальными критериями оценки для каждого из них. И основное отличие в размерах компании и стоимости ошибок первого и второго рода (ложноположительных и ложноотрицательных соответственно).

В итоге, теперь я часто рассказываю про наши подходы к найму:
- Про проверку навыков проектирования (system design interview) - мы спрашиваем про это у software development engineer и технических руководителей - вот тут есть материалы по этому типу интервью
- Про проверку навыков работы с инцидентами (troubleshooting interview) - мы спрашиваем про это у site reliability engineers и их руководителей - подробнее подробнее можно здесь
- Про менеджмент интервью - этот тип интервью варьируюется для тимлидов и руководителей уровнем выше - вот тут можно почитать подробнее

#Management #Hiring #Leadership #Process #Software

Why Most Data Projects Fail and How to Avoid It • Jesse Anderson • YOW! 2022

Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов
- Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations.
- What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги.
- When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать.
- Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:)
- How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана.
- Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов

Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа.

В конце автор рассказывает о том, как можно получить помощь с такими проектами за счет аутсорсинга (если у компании нет своей инженерной команды и культуры), за счет привлечения консультантов (правда, автор говорит о том, что консультанты по менеджменту типа BCG, Bain, Mckinsey зачастую не обладают компетенциями для помощи в таких data проектах). В конце автор упоминает свою книгу "Data teams", которую он написал для менеджеров, которым предстоит запускать data и AI проекты.

P.S.
Мне автор продал свою книгу, поэтому я добавлю ее в свой long list на чтение:)

#Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML

DevPlatform Party (by Yandex Infrastructure) #4 от 2023.10.17

Вчера был интересный митап Devplatform от Yandex в Белграде, на котором было 4 выступления разной степени плотности и о которых хотелось бы рассказать
1) Что же такое Capacity Planning на самом деле
2) Параллельная разработка и тестирование микросервисов через feature branches
3) Куда пропала инженерная романтика
4) Поднимаем инфраструктуру с нуля, если вы - маленький стартап

Что же такое Capacity Planning на самом деле (доклад Дмитрия Нестерова из Yandex)
На самом деле митап я решил посмотреть из-за этого выступления, так как оно рассказывает об актуальной для крупных ИТ-компаний теме, а точнее о планировании и распределеннии мощностей. Мне был интересен путь Яндекса в этой теме, так как мы внутри идем по похожему маршруту:) В Яндексе были стадии
- Появление capacity planning в 2016-2017 года - нет понятных процессов и правил, нет автоматизации, но есть excel:)
- Становление capacity planning в 2018-2019 - появление системного подхода (заявки, роль capacity planner, коммуникация с заказчиками)
- Развитие capacity planning в 2020-2021 - решены технологические проблемы, появилась автоматизация, но она неудобная
- Зрелость capacity planning в 2022-2023 - внедрен продуктовый подход (пошли от JTBD пользоватетелй), формализованы и упрощены процессы, есть статегия развития
Дальше Дмитрий показывал и рассказывал как работают эти инструменты и это было интересно.

Параллельная разработка и тестирование микросервисов через feature branches (доклад Дмитрия Костюкова из Alfa Bank)
Если бы митап начался с этого доклада, то я бы не стал его смотреть. И тут история не про качество доклада, а про подход к развитию технологий и платформы. По-факту, Дмитрий рассказывал про то, как в условном процессе gitflow с кучей микросервисов, выстроенных в цепочку, тестировать фичи. И эту проблему он через свой способ решил ...

НО, при развитии технологической платформы важно делать так, чтобы правильные вещи было делать легко, а кривые вещи было делать сложно. И в разработке программного обеспечения сейчас целевым процессом работы с кодом является TBD (trunk based development), в котором не нужны долгоживущие ветки. Для его достижения надо писать много автоматизированных тестов, уметь работать с feature toggles и так далее. Это позволяет быстрее разрабатывать и бьстрее видеть и решать конфликты в логике фичей, так как это видно внутри кода (а не как в gitflow где это видно во время merge). В такой схеме вся эта машинерия, что упоминалась в докладе не нужна, а даже вредня, так как она провоцирует делать долгоживущие ветки. В итоге, тактическую задачу ребята из платформы Alfa Bank решили, а вот стратегическую ... увы нет:)

Куда пропала инженерная романтика (доклад от Ярослава Астафьева)
Философская история, которую интересно было послушать и которая должна мотивировать на развитие.
В принципе, слушать было интересно, но это скорее софтовый доклад

Поднимаем инфраструктуру с нуля, если вы - маленький стартап (доклад от Алексея Шаграева из pora.ai)
Рассказ от Леши на тему использования AWS Fargate (Serverless compute for containers) для организации инфры для стартапа:) И простенького CI/CD для деплоя туда.
Суть в том, что стартаперам круто использовать as a Service решения, которые позволяют погрузиться в создание бизнес-логики вместо построения инфры, которая предоставляет базовые абстракции и умеют в self healing. Мне показалось, что это достаточно простая история, которую рассказывал именно Леша, потому что он когда-то работал в Yandex:)

#SoftwareDevelopment #PlatformEngineering #Engineering #SRE #Devops #Architecture