Как RnD появляется в крупных IТ-компаниях

Вот и вышла запись моего выступления на конференции Teamlead++ в треке техлидов про появление research and development в крупных компаниях. В этом докладе я рассмотрел это на примерах компаний Google, Amazon, Yandex и Tinkoff. Причем сначала я показывал как выглядел рост компании, показывал как работает бизнес-модель (часто это была модель платформы с двухсторонним сетевым эффектом), а потом делал вывод, что такой экспоненциальный рост требовал ррешения большого количества технических вызовов. И разные компании к этим техническим вызовам подходили по разному
- Google многие из решенных проблем заворачивал в whitepaper, которые дали старт многим open-source проектам
- Amazon скорее делал техпродукты для себя, а потом начал их продавать в AWS, причем статьи были не про внутреннее устройство, а про то, как пользоваться этими продуктами
- Yandex часто рассказывал про свои решения, но деталей почти не было, но в 2016 году появился в open source ClickHouse, в 2017 - CatBoost, а в 2022 и 2023 публикаций стало много, среди которых самое интересное - YDB и Ytsauru, и это если говорить только про официальный open source от Yandex:)

У нас в Тинькофф все начиналось с использования коробочных продуктов, потом мы стали писать много своего кода, года 4 назад стартовала разработка своей IDP (internal developer platform) и кучи технологических продуктов:
- Managed K8s - целевой runtime для low-latency приложений
- LBaaS - балансировщик как сервис, который доводит трафик до приложений внутри Managed K8s
- DBaaS (Postgres, Cassandra, Redis) - целевые базы данных
- Kafka as a Service - платформа для messaging
- Sage - наша obsesrvabilty платформа (логи, метрики, алерты) со своим языком Mage и планом перехода с Elastic на новосозданную базу данных
- Statist и a/b платформа - общее решение для продуктовой аналитики и a/b тестов
- Куча инструментов внутри нашей data платформы - тут инструментов очень много
- и так далее

И сейчас у нас собирается RnD лаба для инженерных исследований, которой руководит Станислав Моисеев, а находится она в нашей платформе базовых технологий, которой руководит Игорь Маслов, директор этой платформы и VP. В общем и целом, для нас развитие RnD направления является стратегическим и если вы хотите заниматься инженерными исследованиями, то можете писать мне в личку, а я познакомлю вас со Стасом и Игорем:)

P.S.
В ближайший понедельник в 18.00 на стриме Code of Arcitecture мы поговорим про подходы к RnD в Google и расскажем как мы планируем это делать в Тинькофф. На стриме мы будем обсуждать это с Вовой Чистяковым, Игорем Масловым и Станиславом Моисеевым.

P.P.S.
Материалы к докладу
- Статья с расшифровкой - текстовая версия выступления, но без части про Yandex (ее я добавлял именно к Teamlead Conf)
- White paper "Google's Hybrid Approach to Research" - хорошая научная статья 2012 года про гибридный подход Google к RnD
- Ключевые публикации с Google Research - подборка от меня ключевых whitepaper по техническим продуктам Google
- Invent and Wander. Избранные статьи создателя Amazon Джеффа Безоса - книга с историей Amazon через публичные письма Джеффа акционерам + другие ключевые выступления
- Письмо Джеффа Безоса акционерам 2010 года - интересно написано про важность общих подходов и инструментов для компании
- Статья от Yandex "Почему инфраструктура big tech обычно состоит из самописных решений" - крутая статья, в которой на пальцах объясняются причины и приводится примеры ввнутреннего облака и монорепозитория
- Yandex Platform Engineering - крутой ресурс с описанием технологий и команд отдела Yandex Platform Engineering, который делает инфраструктуру для разработки и эксплуатации продуктов Яндекса
- Whitepaper "Investigation of The Relationship Between Brand Value And R&D Activities: Fortune 500 Companies Analysis" - исследование про связь стоимости бренда и затрат на RnD

#Management #RnD #Leadership #Processes #Architecture #PlatformEngineering

ICPC Northern Eurasia Contests - победители

Не зря съездил на полуфинал ICPC - посмотрел как команда "Ёлки-палки" из МФТИ победила в соревнованиях второй год подряд. Ребята решили все задачи и выиграли очень уверенно. Ждем от них победы в финале ICPC.

#Software #Engineering

Designing A Data-Intensive Future: Expert Talk • Martin Kleppmann & Jesse Anderson • GOTO 2023

Это крутое интервью от топовых специалистов
- Мартина многие знают как автора классической книги с кабанчиком ("Designing Data-Intensive Applications"), сейчас он больше исследователь и занимается так называемым "Local-First Collaboration Software" (automerge) - подробнее можно посмотреть в выступлении Мартина, которое я разбирал месяц назад
- Jesse я узнал в качестве автора книги "Data Teams", а также автора интересного выступления "Why Most Data Projects Fail and How to Avoid It", про который я рассказывал 2 месяца назад
Оба участника превосходно шарят в теме разговора и их интересно слушать. Вот тут доступна расшифровка.

Ниже тезисно расскажу основные мысли
Мартин рассказывает про свою книгу "DDIA", котороя про основы работы с данными и широкий ландшафт технологических решений (на момент 10 лет назад, когда Мартин начинал писать книгу)
Мартин планирует написать второе издание книги, в котором он рассмотрим вопросы
- Рост популярности cloud-native приложений и разработку распределенных приложений слоями, когда одна распределенная система опирается на нижележащую распределенную систему и так далее - рекомендую про это подробнее прочитать в whitepaper от ребят из Google "Deployment Archetypes for Cloud Applications", про которую я рассказывал раньше
- Закат Map-Reduce, чью поляну забрали cloud DWH с точки зрения аналитики и стриминговые системы с точки зрения приложений с кастомной логикой
Мне нравится, что Мартин продолжить и во второй книге использовать подход

So I'm not telling people what to do, I'm telling people what questions to ask.

Правда, написание новой книги идет не быстро, поэтому ждать ее скоро не стоит.
Потом Martin и Jesse обсуждают концепцию единого инструмента для всех задач, связанных с данными, и приходят к выводу, что если бы такой инструмент был, то он бы делал все эти задачи плохо. Поэтому Martin говорит о том, что надо использовать правильные инструменты для конкретных задач, например, удобно начинать с реляционной базы данных, которая достаточно гибкая и производительная. Круто использовать streaming systems для того, чтобы иметь потом возможность переключиться на более удобное решение

For example, you could run both consumers side by side for an amount of time, check the consistency across the two systems, and then eventually decide to switch over from the old one to the new one. Streaming systems allow that so much better than, for example, systems based on, like, doing calls to individual services. So I feel like, as you said, the streaming can help with making change easier there.

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

Дальше Мартин вспоминает про automerge, что я упоминал в начале и потом переходит на тему работы ученым и почему он переключился после 10 лет пребывания в стартапах на стезю ученого и как это позволяет ему лучше продумывать сложные идеи в области distributed systems. А также почему так мало PhD диссертаций превращаются в рабочие системы (значимое исключение Apache Flink).

Ну и напоследок участники дают советы
- Мартин: "I guess my recommendation would be to learn just enough about the internals of the systems that you're using so that you have a reasonably accurate mental model of what's going on there."
- Jesse: "There are a lot of paths out there. Pit's to look out the various paths, look at what you want to do and what your skills are and see if one of those applies to you", где приведены карьерные варианты: разработка, менеджмент, наука, консалтинг, devrel. И в зависимости от сильных сторон и предпочтений, стоит выбрать свой путь.

#Management #Data #Databases #SystemEngineering #DistributedSystems #Software #Architecture

Как формировать структуру команд под запросы бизнеса - часть 3

Продолжу пост про структуру команд и проектный подход и в этом посте мы поговорим про продуктовую разработку. В прошлом посте я много говорил про полезность проектного подхода и возникает вопрос, а зачем нам нужна продуктовая разработка, если есть такие замечательные проекты. Но проекты хороши для старта новых инициатив или ведения кросс-командных активностей. А вот если мы хотим более планово и непрерывно поставлять ценность, то мы приходим к концепции продукта, где
- Есть конкретная целевая аудитория продукта
- Есть примерное понимание какие фичи, стори, JTBD (jobs to be done) мы хотим реализовать
- Есть желание выкатывать эти изменения небольшими порциями и тестировать как они работают
- Есть понимание, что план может гибко меняться в процессе движения
С таким набором ожиданий становится ясно, что проектный подход нам не подходит. В итоге, мы приходим к продуктовым процессам разработки, про которые я рассказывал в докладе "Совершенствование потока разработки программного обеспечения", где я рекомендовал почитать книгу "Making Work Visible" от Доминики Деграндис, про которую я писал раньше. Но вообще есть несколько подходов к тому как организовывать работу и планировать время ее выполнения. Однако важно помнить про ироничный закон Паркинсона

Работа заполняет время, отпущенное на неё

Этот закон дает понять почему планирование работы с буферными запасами проблема, а именно так часто планируют в проектном управлении. Но если планировать работу задач на команду в режиме push, то можно столкнуть с тем, что требования к командам и их производительность не сбалансированы, что не позволяет выполнить все задачи вовремя. В итоге, нам нужна система с pull режимом, когда люди вытягивают новую задачу по мере завершения предыдущей. Такой системой, например, является Kanban. Но важно понимать какие задачи попадают в такой процесс - важно не соглашаться на все подряд, а обдуманно давать добро только на самые важные в конкретный момент и делать это визуально. Для этого надо организовать систему рабочего потока, выполняющую следующие задачи
- Делает работу видимой
- Ограничивает количество незавершенной работы
- Оценивает рабочий поток и управляет им
- Эффективно определяет приоритеты
- Вносит коррективы на основе метрик и обратной связи

И проблема со временем и его утеканием обязана следующим пяти факторам
- Too WIP - история про незавершенную работу, бутылочное горлышко и закон Литтла.
- Unknown dependencies - здесь про архитектурные проблемы и зависимости между системами и разными командами.
- Unplanned work - незапланированная работа крадет время у запланированной. Этим она делает систему непредсказуемой, а главное для нас — это прогнозируемость и ожидания.
- Conflicting priorities - если все задачи приоритетные, то ни одну из них нельзя назвать реально важной. Без внятных приоритетов людям приходится пытаться сделать слишком много сразу, что автоматически приводит к росту WIP, который замедляет всю систему.
- Neglected work - часто такая работа проявляется в форме техдолга, который накапливался в системе, когда люди только клепали фичи без работы по повышению технического совершенства системы. Вообще, часто проседает важная но не срочная работа, которую так любят откладывать … пока она не перерастет в экстренную ситуацию, когда станет незапланированной работой, от которой нельзя отказаться.

В итоге, я всегда стремился выстроить продуктовые кросс-функциональные команды, используя Kanban подходы. В целевом виде эти команды являлись stream-aligned командами из Team topologies (подробнее в обзоре 1, 2, 3). Про то, как я строил продуктовую разработку я рассказывал в контексте нашего веба Tinkoff.ru в двух давних докладах
- Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения
- Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях

#Management #Leadership #Project #ProjectManagement #Software

Tinkoff TeamLead Meetup 1

Интересный митап на тему тимлидов от Тинькофф, которое прошло под знаменем наджености и в котором было 4 выступления по 20 минут + 10 минут на вопросы/ответы. Вот эти доклады

1) Как выиграть гонку с бизнесом на высоконагруженном сервисе, обеспечивая высокий уровень надежности
Выступление Владислава Хачатурова из Сбера на тему того, как выстроены внутренние процессы на самом высоконагруженном сервисе "Главный экран" для приложения Сбербанк Онлайн в условиях вечной гонки, с обеспечением высокой надежности. Тут много было про inner-source и как сделать платформенную команду, которая работает над архитектурой, надежностью, принимает сервисы в эксплуатацию от продуктовых команд, которые контрибьютят в сервисы платформенной команды.
2) Как мы падали и поднимались. И чему научились в процессе.
Выступление Ильи Барбашова из Авито, где он рассказывает про как в Авито захворали важные инфраструктурные сервисы (Kafka as a Servioce). А дальше как ребята изменили подход к оценке их надежности, и как это помогло планировать им работу и общаться с пользователями, которыми являются продуктовые разработчики.
3) Настройка окружения
Выступление Алексея Калакина из билайн, в котором он рассказал о проблемах взаимодействия с инфрой, и с интеграционно связанными приложениями. Он разобрал как настроить свзяь бизнеса и технических лидов, а также показал как решать это различными методами.
4) Стратегия управления техническим долгом
Выступление Никиты Ульшина из Тинькофф, в котором автоп рассказывает про то, откуда берётся техдолг, как он влияет на продуктивность и мотивацию команды, как правильно планировать работу над техдолгом и как избавиться от него. Дальше идет обсуждение приоритизации и того, как продавать результаты работы над техдолгом. Интересно, что Никита работает в команде, которая делает бекенд систему для нашего server driven UI для веб приложений, а про эти системы я уже раньше упоминал в других докладах:)

#Management #Engineering #Software #SoftwareDevelopment #Architecture #Processes #SRE #Leadership

Радость познания (The pleasure of finding things out) - 1

Эта книга составлена из выступлений Фейнмана на разных мероприятиях, зачастую перед студентами или другими учеными. Часть из этих выступлений не публиковалась раньше, поэтому книгу я читал с большим интересом. В отличие от книги "Вы, конечно, шутите, мистер Фейнман", про которую я рассказывал раньше, эта книга предполагает вдумчивое чтение, интерес читателя к науке и научному подходу к познанию окружающего мира, а также готовность подвергать все сомнению:)

А теперь немного про содержание книги

1. Радость познания сути вещей - статья, что дала название всей книге. В ней мы видим как подход к познанию Ричарда сформировался под влиянием отца, который не учил терминам или теориям, а учил наблюдать за окружающим и видеть суть и взаимосвязи. Мне особенно понравилось познание через аналогии ака "тиранозавр в окне" (смотри на эту тему рекомендую "Большую книгу аналогий") и разбор алгебры для практичного человека, где Ричард рассказывает про инструкции из школы про решение задач как "целый набор шагов, с помощью которых вы могли бы получить ответ, если не понимаете, что вы пытаетесь сделать". Остальная часть статьи тоже очень интересна, не даром она идет первой в книге.
2. Компьютеры будущего - в этой статье Ричард выступает провидцем и говорит о параллельных компьютерах и их миниатюризации. Достаточно интересно обсуждался вопрос обратимых и необратимых вычислений и связи скорости вычислений с потреблением энергии. Все это рассматривается не с позиции технических возможностей почти сорокалетней давности (лекция 1985 года), а скорее с точки зрения концептуальных возможностей и того, что это видение не противоречит существующим физическим законам
3. Лос-Аламос - взгляд снизу - это рассказ про времена Фейнмана в Лос-Аламосе и участие в Манхэттенском проекте. В принципе, это все обсуждалось и в уже упоминавшейся книге "Вы, конечно, шутите ..."
4. В чем состоит и в чем должна состоять роль научной культуры в жизни общества - здесь Ричард рассказывает про научный подход, выдвижение гипотез и теорий, их полезность и фальсифицируемость. Он верит в то, что и жизнь общества должна идти по пути, похожему на научный - "всегда нужно оставлять место сомнениям, дискуссиям" и что "придет время, когда люди полностью осознают, что сила власти ограничена, что правительства не уполномочены решать вопрос, ценна ли научная теория или нет ... Они не должны присваивать себе право делать выбор между различными версиями описания истории, экономической теории или философии"
5. Как много места в глубине - в 1959 году Фейнман в Калтехе рассказывал про нанотехнологии - это было провидческое выступление, где он упоминал про: хранение информации, аналог фотолитографии, выстраивание атомов для создания новых материалов. В конце он устроил конкурс по миниатюризации, который в итоге превратился в премию Фейнмана по нанотехнологиям
6. Ценность науки - лекция в формате урока для молодых ученых о том, что они несут ответственность за будущее цивилизации
7. Особое мнение Ричарда Фейнмана, касающееся следствия по делу космического корабля-челнока "Челленджер" - если говорить на it'шном, то Ричард участвовал в написании постмортема по инциденту с "Челленджер", но его мнение не хотели учитывать в официальном отчете, поэтому он написал свое "особое мнение" и добился включения его в официальный отчет (в приложении)

P.S.
Продолжение разбора в следующем посте.

#PopularScience #Physics #Biography

На корпоративе коллеги пошутили со сцены, представляя меня, что в 2024 году

Александ Поломодов научится читать книги быстрее, чем авторы их писать

С учетом плана написания своей книги, это очень вероятно:)

#Humour

Как формировать структуру команд под запросы бизнеса на YaTalks 2023

Появилась запись моего выступления на YaTalks, где я рассказывал про основы и принципы дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф.
Часть выступления уже доступна в виде расшфировок
1) пост про структуру команд
2) пост про проектный подход
3) пост про продуктовый подход
4) пост про масштабирование (пока на очереди)

В общем, для тех, кто больше любит видео, теперь оно доступно для просмотра:)

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Code of Architecture рзабор white paper «Google's Hybrid Approach to Research»

Сегодня в 18:00 мы проведем новогодний стрим по архитектуре. В рамках встречи мы поговорим про то, как устроено RnD (Research and Development) в Google
— какую цель исследований поставила для себя компания и почему;
— к каким резльтатам она привела;
— как устроен гибридный подход к исследованиям там;
— как выглядят паттерны организации взаимодействия исследовательских и продуктовых инженерных команд;
— почему и зачем компании инвестируют в Google.

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

На тему стрима можно почитать материалы
- PDF версия доступна здесь
- Мой обзор этой статьи доступен здесь
- Моя статья про RnD в крупных компаниях (Google, Amazon, Yandex, Tinkoff)

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #RnD #CoA

Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services

Я уже рассказывал про знаменитую CAP теорему за авторством Eric Brewer. А сегодня я расскажу про whitepaper 2002 года от Seth Gilbert и Nancy Lynch, в котором гипотеза стала теоремой. Сама гипотеза для доказательства звучит так

It is impossible for a web service to provide the following three guarantees: consistency, availability, partition-tolerance

Все эти свойства желательны в реальных системах. Но для того, чтобы доказать это утверждение, требуется для начала формализовать все три свойства

1) Начать стоит с consistency, где авторы идут в сторону atomic data objects или линеаризуемой консистентности (linearizable consistency)

Under this consistency guarantee, there must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time.

Такие гарантии косистентности пользователям проще воспринимать и для такой модели проще проектировать клиентское приложение, которое будет взаимодействовать с такой распределенной системой.

2) Второй характеристикой является availability, где для непрерывной доступности каждый запрос, попавший на несбойную ноду системы должен получить свой ответ. Таким образом любой алгоритм для генерации ответа сервисов должен оканчиваться в конечном счете (eventually terminate). Интересно, что это слабое определение доступности, так как нет верхней границы на время ответа - это позволяет unbounded computation. Но если рассматривать это с позиции устойчивости к разделению, то это может рассматриваться как сильное определение доступности - даже если происходят сбои в сети, каждый запрос должен завершиться.

3) Для моделирования partition-tolerance авторы предлагают считать, что в сети может теряться произвольное количество сообщений, что отправляются от одной ноде к другой. А значит мы можем моделировать любой паттерн потерь

When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. (And any pattern of message loss can be modeled as a temporary partition separating the communicating nodes at the exact instant the message is lost.)

Дальше авторы переходят к доказательствам

1) Начнем сначала с асинхронных систем

Theorem 1 It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all fair executions (including those in which messages are lost).

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

2) В реальном мире у нас используются не полностью асинхронные системы, а частично синхронные. В них у нод есть свои часы, которые позволяют замерять время и использовать таймауты. Но даже в более мощном сетапе мы получаем похожий результат

Theorem 2 It is impossible in the partially synchronous network model to
implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all executions (even those in which messages are lost).

Доказательство тут похоже на предыдущее как две капли воды:)

Оставшаяся часть white paper посвящена Delayed-t consistency в частично синхронных системах, про которую мы тут говорить не будем.

А в следующем посте поговорим про теорему PACELC.

#Software #Architecture #DistributedSystems #SystemDesign

Пара записей с поездки в Питер на ICPC и ВКОШП

Я уже писал раньше о том, как ездил в Питер на эти мероприятия, чтобы поучаствовать в них, так как Тинькофф спонсирует эти чемпионаты по программированию. Мне очень понравилась атмосфера контеста и его участники, поэтому я рад, что съездил туда + я поучаствовал не только в церемониальных частях мероприятий, но и побывал на прямых трансляциях, где обсудил с Лидией Перовской разные моменты

1) Трансляция ВКОШП - эта трансляция командных соревнований школьников и здесь мы поговорили на следующие темы
- про формат соревнований и почему они настолько интересны
- почему командные соревнования по программированию неплохо моделируют командную работу инженеров в реальной разработке
- про роль тимлида в команде
- про то, что можно успеть за 26 минут
- про выступление на YaTalks про структуру команд
- про то, как я почти не пишу код в последнее время, но стабильно читаю его
- интересно про инциденты и отсылку к публичному интервью по troubleshooting на Devoops
- про a/b платформу и продуктовую аналитику
- про найм олимпиадников в команды (тут я рассказал забавную историю из опыта)

2) Трансляции ICPC - это трансляция командных соревнований студентов и здесь мы поговорили про следующие темы
- про мою зону ответственности в Тинькофф
- про мое обучение в МФТИ
- про сложность подготовки к соревнованиям
- про стажировки в компаниях, где выстроены процессы разработки (лучше в Тинькофф)
- хорошие советы о том, как правильно работать в команде по спортивному программированию:)
- про канбан-метод и визуализацию работы
- про сложные процессы в больших компаниях и синхронизацию знаний
- про важность ретроспектив
- про современные шахматы, обучение им и как это прокачивает мышление

#Software #SoftwareDevelopment #Conference #Engineering