0b111 лет в Тинькофф

Семь - это красивое число, что помещается в три бита:) А еще ровно столько лет назад я вышел на новую работу в Тинькофф. Я пришел на позицию engineering manager заниматься проектами привлечения. Моим руководителем был Кирилл Бобров, наш VP of Acquisition в то время. У Кирилла были наполеоновские планы и я точно знал, что скучно мне не будет. Но 7 лет назад я и не предполагал, что задержусь в компании на 7 лет. Проблема была в том, что с самого детства мне было важно, чтобы мне было интересно - я глотал книги пачками, занимался шахматами, участвовал в олимпиадах по всем предметам, ближе к концу школы учился в ЗФТШ при Физтехе, ... в общем, делал все, чтобы не было скучно. Еще в универе я пошел работать и обычно получалось так, что работу в среднем до Тинькофф я менял раз в 2 года.

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

#Management #SelfDevelopment #Engineering #Processes #Software

Creating Local-First Collaboration Software with Automerge • Martin Kleppmann • GOTO 2023

Интересное выступление Мартина Клеппмана, который еще в 2017 году написал уже классическую книгу с кабанчиком (Designing Data-Intensive Applications). Уже в момент издания DDIA Мартин был скорее исследователем распределенных систем, чем промышленным разработчиком. А в конце своей книги он рассказывал про использование CRDT (Conflict-free Replicated Data Type) для решения проблем синхронизации изменений на разных нодах распределенной системы. Мартин долго работал в этом направлении и в этом докладе рассказывает о том
1) как его библиотека automerge прошла путь от версии 0.1 в 2017 году до версии 2.1 в 2023 году
2) и почему нам есть до этого дело

Доклад состоял из следующих частей
- Мартин рассказал для начала о том, как мы сейчас делаем распределенные системы в вебе - круто выглядит картинка из 6 разных представлений состояния приложения (HTML DOM, JS app state, JSON REST API, model objects, database, persistent layer)
- Дальше Мартин предложил альтернативу в виде local-first software, которая напоминает старые добрые десктопные приложения ... но к ним добавляется библиотека automerge
- Эта библиотека дает JSON like интерфейс для работы с данными, работа с которыми напоминает git, но уже не для исходного кода, а для данных наших приложений
- Суть в том, чтобы хранить не просто конечный state данных, а некоторый набор изменений (в git это коммиты), а дальше при параллельном изменении уметь автоматически объединять эти изменения (отсюда название automerge)
- При таком подходе приложения работают в local-first формате со своими данными, используя библиотеку automerge, плюс эта библиотека забирает на себя сложности распространения и синхронизации изменений по разным нодам
- Мартин отметил, что этот подход не универсален и не во всех типах приложений стоит его использовать, но для создания коллаборативных сервисов это может быть удобно - например, для того, чтобы сделать свои версии сервисов навроде Google Docs, Miro, Slack, ...
- Напоследок Мартин рассказал про текущую работу над алгоритмом для работы с rich текстом, который нужен для коллаборативного инструмента для редактирования текста (как раз Google Docs). Здесь Мартин на пальцах объяснил сложность и показал как они планируют ее преодолеть

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

#DistirbutedSystems #Architecture #SoftwareDevelopment #SoftwareArchitecture #SystemDesign #RnD

Generative AI Overview for Project Managers

Нашел интересные документы на сайте PMI, которые были посвящены введению в ChatGPT для проджект менеджеров. Они состояли из двух документов (приложил их к посту)
- Suggested GenAI Tools for Project Work v1.1
- ChatGPT Prompt Engineering Guide

В первом ребята говорили про инструменты, которые полезны для руководителей проектов, среди которых интересны следующие
- Для планирования: плагин "Show Me Diagrams" в GPTStore - может помочь рисовать диаграммы Ганта и network diagrams, визуализации прогресса
- Для создания прототипов: Autodesk Fusion 360, Catia, Ansys Discovery
- Для time и cost management: Smartsheet
- Для мониторинга и отслеживания движения по проекту: плагин "WebPilot" в GPTStore
- Для риск менеджмента: "ChatGPT AI Assistant for Jira"
- Для управления workflow и автоматизации: ClickUp
- Для генерации кода, текстов и изображений: MidJourney, Azure AI, GitHub Copilot, Microsoft 365 Copilot, Google Bard, ChatGPT by OpenAI

Во втором документе показаны примеры промтов, которые могут быть полезны проджект менеджерам, например:
- Провести cost-management analysis проекта и помочь принять решение
- Помочь описать бизнес кейс и убедить стейкхолдеров о старте проекта по лояльности
- Создать устав проекта (project charter)
- Обработать расползание работ по проекту (scope creep) с использованием traceability matrix
- Провести расчеты в рамках EVM (Earned Value Management)
и так далее

Мне показалось интересным, что обычно неповоротливый институт выпустил достаточно актуальные документы по AI, которые позволяют увеличить эффективность менеджеров проектов, сняв с них часть рутинной работы и переложив на ботов:)

#Management #Project #AI #ML #Processes

Industry Myth Busting • Joris Kuipers • GOTO 2023

Забавное выступление в стиле разрушителей легенд, в котором автор говорит про
- развитие технологий и какая зеленая трава и голубое небо было раньше
- микросервисы и монолиты
- feature branches vs trunk based development
- подходы к тестированию, юнит тесты, пирамиды тестирования, перевернутой пирамиды и honeycomb (наверное есть и дргуие фигуры)
Через все эти примеры сквозит мысль про то, что перед тем как выбирать лучший способ действий, стоит сначала определиться со своими целями, а дальше уже появятся критерии оценки конкретных решений:)
В конце автор подвешивает вопросы, которые он мог бы еще обсудить, но не хватило времени
- интерфейсы и конкретные классы
- сервисы и serverless
- the right programming language
- и в будущем обсуждение что лучше: писать код руками или при помощи AI

#Conference #Engineering #Software #SoftwareDevelopment

Deep Learning от MIT Press

Эта книга John D. Kelleher вышла в серии Essential Knowledge Series и содержит интересное введение в deep learning. Я уже рассказывал про другую книгу "Data Science" из этой же серии, в которой он выступал в качестве соавтора. В этой книге автор рассказывает про нейронные сети на пальцах и только в одной главе (про backpropagation) он погружается немного в математику. И хоть с издания книги в 2019 году утекло много воды, но она мне кажется до сих пор неплохим обзором deep learning для людей далеких от ml. Сама книга состоит из 7 глав
1. Introduction to deep learning - введение начинается с того, что deep learning помогает принимать решения на основе данных. Автор вспоминает про тройку терминов AI (artificial intelligence), ML (machine learning), deep learning и показывает их вложенность друг в друга: deep learning ⊂ ML ⊂ AI. Дальше приводится пример с простым dataset, функцией как детерминированным маппингом входных значений в выходные, а дальше перехода от детерминизма к угадыванию функции по доступным в датасете inputs и outputs (объяснение ml на пальцах). Конечно угадать точно можно не всегда и многое зависит от доступного датасета. Дальше на пальцах разбирается обучение с учителем, без него, а также reinforcement learning. А к концу главы автор рассказывает про причины успешности deep learning: что нам не приходится самим заниматься выделением значимых фич (feature engineering), также это хорошо работает в домене с большим количеством фич (размерность задачи) и большим объемом данных (добавлю от себя про важность большого количества GPU). Кстати, в этом тексте упоминается AlphaGo, про которая есть крутая документалка.
2. Conceptual foundations - здесь рассказывается про то, что такое модель, как можно подобрать параметры модели с использованием доступных данных, как комбинируя простые модели можно получить комплексную модель
3. Neural networks: the building blocks of deep learning - краткое объяснение нейронных сетей, того как они работают и откуда появилось название глубоких нейронных сетей (от наличия hidden layers, которые расположены между input и output layers)
4. A Brief history of deep learning - здесь автор дает выжимку из истории развития нейронных сетей, причем фокус здесь как на концептуальных, так и на практических прорывах. Это описание истории показалось мне меньше biased, чем в книге "Антология машинного обучения" ("The Deep Learning Revolution"), про которую я писал раньше. Отдельно автор рассказывает почему deep learning стало так развивается в последнее время - тут работает цикл из трех элементов, что усиливают друг друга: big data, улучшение алгоритмов, улучшение железа
5. Convolutional and recurrent neural networks - здесь описывается работы сверточных и рекуррентных нейронных сетей, где первые отлично подходят для работы с изображениями, а вторые лучше для работы с текстом. Причем описание нейронных сетей дается буквально на пальцах (мне кажется, что его поймут и люди, что далеки от математики)
6. Learning functions - эта глава самая математическая из всех и здесь идет речь про градиентный спуск и backpropagation algorithm. Первый алгоритм абсолютно стандартен для задач поиска минимума/максимума функции, а вот алгоритм обратного распространения ошибки в 80х годах сильно продвинул глубокие нейронные сети в популярности, так как этот способ позволял определять как менять веса hidden layers в нейронной сети при обучении. Собственно, именно при рассмотрении backpropagation надо немного знать про частные производные
7. The future of deep learning - здесь автор описывает светлое будущее deep learning, которое за 4 прошедших года кажется наступило в виде пришествия LLM (large language models)

В общем, книга достаточно легко читается и классно подойдет для первоначального знакомства с этой областью на уровне научпоп литературы:)

#ML #Data #Learning #DataScience #Software #PopularScience

CAP Theorem

Знаменитой CAP теореме исполнилось 25 лет, поэтому хотелось что это такое, зачем она и как появилась. Про это есть отличная статья от Eric Brewer, автора теоремы, который написал ее больше 10 лет назад, которую хотелось вспомнить, так как она хороша:)
Начнем с самого утверждения теоремы (цитата из статьи выше)

The CAP theorem states that any networked shared-data system can have at most two of three desirable properties:
- consistency (C) equivalent to having a single up-to-date copy of the data;
- high availability (A) of that data (for updates); and
- tolerance to network partitions (P).

Дальше надо вспомнить про ее появление
- 25 лет назад, осенью 1998 года была сформулирована CAP теорема
- в 1999 году она была опубликована в статье "Harvest, Yield, and Scalable Tolerant Systems" в ACM
- в 2000 представлена на Симпоузиуме "Symposium on Principles of Distributed Computing" (презентация здесь)
- в 2002 доказана формально (где консистентность из теоремы превратилась в линеаризуемость)
Потом теорема пошла в массы и превратилась в условные "выберите 2 свойства из трех: C, A, P", что является сильным упрощением по трем причинам, что указывает Эрик в уже упоминавшейся статье:
1. Из-за редкости partition нет смысла выбирать между C и A (про это подробнее в следующий раз при обсуждении PACELC Theorem)
2. Решение о C или A принимается не единоразово для всех компонентов и всех данных, а на другом уровне гранулярности и может зависеть от типа операции или данных
3. C, A, P - это не бинарные свойства, а скорее непрерывные - availability от 0 до 100%, уровни консистентности тоже бывают разные и даже partitions имеют нюансы:)

В итоге, Эрик говорит о том, что в отсутствии разделения системы мы можем выбирать A или C, а во время проблем у нас должен быть понятный алгоритм
- определения, что случился partition
- перехода в явный partition режим, в котором часть операций может быть лимитирована
- запуска процесса восстановления консистентности и компенсации ошибок, что возможно были в рамках partition

Потом Эрик рассказывает про связь акронимов ACID, BASE и CAP
- BASE расшифровывается как Basic Availability, Soft state и Eventually consistency. Первые два из свойств помогают достигать доступности при разделении системы на части
- ACID расшифровывается как Atomicity, Consistency, Isolation, Durability. Этот акроним знают многие, кто работал с реляционными базами данных, но как я писал выше Consistency из CAP и из ACID - это про разное и это добавляет сложности в понимании:)

Следом идет часть про latency, которая отсутствует в классической формулировке, но неявно присутствует. Ведь выполняя операцию в разделенной системе, мы в какой-то момент должны принять решение
- отменить операцию и уменьшить доступность
- продолжить операцию, но принять риск неконсистентности данных

Конечно можно попробовать повторно выполнить операцию (retries), но это просто откладывает принятие решение на некоторое время. Таким образом, с прагматической точки зрения разделение — это ограничение по времени (таймаут), который мы закладываем в свое общение. А из этого следует несколько последствий
1. Не существует глобального понятия partition, поскольку некоторые узлы могут обнаружить partition, а другие — нет.
2. Те узлы, что обнаружили partition входят в режим partition-mode, собственно ту часть, где нам надо выбирать между C и A
В итоге, проектировщики системы выставляют time bounds так, чтобы соответствовать целевым скоростям ответа системы на запросы, а чем жестче эти time bounds, тем выше вероятность попадания в partition mode, причем даже просто при медленной сети, но без реального ее разделения.

В приведенной выше статье есть еще много интересных мыслей про scope консистентности и как это соотносится с датацентрами, как явно управлять процессами перехода в partition mode и восстанавливаться после partition. Очень рекомендую ее к прочтению.

#Software #Architecture #DistributedSystems #SystemDesign

Ну и картинка для иллюстрации поста

[SafeCode Live] Secure by design

Сходил недавно на запись выпуска SafeCode Live, где мы говорили про подход Secure by design (SBD) или конструктивную безопасность в разработке продукта.

Мы интересно пообщались на темы что это такое, зачем нужно, что делать "если уже все сделано небезопасно", как прокачаться в безопасности и так далее:)

На стрим нас было четверо
- Алексей Федулаев, ведущий подкаста, руководитель направления автоматизации безопасной разработки в Wildberries.
- Сергей Рогачев, руководитель отдела разработки безопасной платформы в Лаборатории Касперского.
- Екатерина Рудина, аналитик в Лаборатории Касперского. Работает в департаменте перспективных технологий в области исследования угроз, моделирования и оценки рисков.
- и автор этого канала

Достаточно непривычно было выступать на этот раз не в качестве эксперта, а скорее в качестве гостя, который заинтересован в том, чтобы практики security присутсвовали в SDLC и не в финальной стадии, а начиная с работы с требованиями, оценки рисков, проектирования решения и так далее. В итоге, я сам с удовольствием слушал других спикеров и даже добавил себе в reading list пару книг, что они рекомендовали, но начать решил с базовой «Software Security» от Mathias Payer, которую порекомендовал Сергей.

#Security #SRE #Software #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems #Architecture

В этот понедельник мы провели первый стрим клуба Code of Architecture по новой книге “Continuous Architecture in Practice”. В этом выпуске мы обсудили темы
- важности архитектуры здесь и сейчас, а конкретно про вызовы, что стоят перед архитекторами, а дальше то, как continuous architecture поможет с ними. На самом деле нет, вызовы шли отдельно, а принципы continuous architecture отдельно
- про принятие и governing архитектурных решений, про атрибуты качества, технический долг, про циклы обратной связи (фитнес функции, continuous testing), модели и нотации для описания архитектуры, паттерны проектирования и архитектурные стили, концепцию архитектуры как потока принятия решений. Тут тоже все это не было объединено бесшовно сквозной идеей, что показывает, что спроектировать консистентную по содержанию главу у авторов не совсем получилось
Гостем стрима был Максим Смирнов — ИТ-архитектор и автор «Архитектура ИТ-решений».

На самом выпуске мы упоминали книги:
- Building Evolutionary Architecture - уже разбирали это в CoA
- Technology Strategy Patterns - уже разбирали это в CoA
- Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World - предыдущая версия книги, которая потом превратилась в Continuous Architecture in Practice
- серию книг Вернона - Addison-Wesley Signature Series (Vernon), которые интересны и куда входит Continuous Architecture in Practice

Отдельно мы обсудили то, что Continuous Architecture - это хороший нейминг для темы. Потом я зашел на сайт continuous-architecture.org и нашел набор документов, которые застолбили тему непрерывной архитектуры за авторами:
- манифест по типу agile manifesto
- фреймворк в виде набора инструментов для continuous architecture в организациях
- инструкция как внедрять ее в организациях

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

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

6 декабря в Москве я буду выступать на конференции Яндекса с докладом-саморефлексией примерно с такими тезизами

В последние годы Tinkoff растет взрывным образом, что приводит к большим количествам изменений: организационных, продуктовых и инженерных. Я с компанией уже семь лет и не просто застал времена перемен, а участвовал во многих из них со стороны IT, причем про многие из них я рассказывал публично на конференциях и в своих статьях. Но в этом докладе я хотел бы вернуться к основам и поговорить про те принципы дизайна команд и управленческой структуры, которые помогали мне все это время. Плюс я хотел бы рассказать примеры того, как я использую их сейчас в редизайне структуры своего подразделения почти в тысячу человек:)

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

#Management #Conference #Processes #Architecture #Project #Engineering #SoftwareDevelopment

Несведущий маэстро (The ignorant maestro: How great leaders inspire unpredictable brilliance) - I

Эта книга лежала у меня на полке больше года, пока ее не порекомендовали моей жене, Насте, в рамках ее магистратуры "Психоанализ и психоаналитическое бизнес-консультирование". И мне стало интересно прочитать эту книгу, которая написана дирижером и бизнес-консультантом, Итаем Талгаем. Он рассказывает в этой книге про свой подход к консультированию по менеджменту, который основан на музыкальных концепциях и демонстрируется на стилях руководства шести великих дирижеров.

Часть 1. Музыка бизнеса
В этой части автор рассказывает про музыку, которая окружает нас повсюду и почему анализируя работу музыкальных коллективов можно много узнать про лидерство. В конце части автор задает вопрос

Существует ли универсальное звучание, подходящее всем организациям на каждой стадии развития?

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

Часть 2. Три мелодии лидерства
Автор предлагает свой рецепт из трех ингредиентов
1. Блестящее неведение
Здесь идет речь про философию Жака Рансьера, который написал книгу "Невежественный учитель" и популяризировал мысль педагога 19 века Жакото

Невежда может научить другого невежду тому, чего не знает сам

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

Лишь человек, который не знает, способен научиться чему-то неожиданному и добиться непредсказуемого

2. Не бойтесь пустот
Глава начинается с цитаты великого пианиста, Артура Шнабеля

Я умею играть ноты не лучше и не хуже других пианистов, но паузы между нотами - ах вот где искусство

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

3. Мотивационное слушание
В отличие от мотивационного спикера, мотивационный слушатель не просто транслирует свои знания, а скорее создает диалог. Он знает, что результат любого взаимодействия будет разным для всех участников. Один из главных плюсов мотивационного слушания для руководителя - вдохновение людей и говорить, и слушать. Мотивационный слушатель создает для говорящего безопасное пространство, в котором ошибки вместе анализируют и используют для обучения. А это значит, что слушатель признает собеседника равноправным и равноценным участником диалога и это много меняет в общении.

В следующем посте я расскажу про третью часть книги, где автор говорит про стили лидерства 6 великих дирижеров.

P.S.
Меня давно интересовало как дирижеры и хореографы управляют своими коллективами и как это связано с управлением software engineering. Несколько лет даже написал статью про это:)

#Management #Processes #Leadership #Self

Code of Architecture - Continuous Architecture in Practice - II

Сегодня в 18:00 по Москве мы обсудим третью и четвертую главу книги Continuous Architecture in Practice. Эти главы посвящены архитектуре данных и безопасности.
- В третьей главе авторы вспоминают про DDD в контексте ubiquitous language и bounded contexts для проектирования самой доменной модели, дальше про polyglot persistance в разрезе использования sql/nosql решений, вспоминают про модели консистентности (по-факту, только про eventual consistency), кратко пробегаются по event sourcing, а дальше приходит к концепции data ownership и отгрузке данных для построения аналитических моделей, ну и напоследок обсуждают вопросы эволюции схемы в sql и nosql решениях.
- В четвертой главе наступает очередь безопасности и авторы говорят про основные вызовы, вспоминают триаду CIA (Confidentiality, Availability, Integrity), рассказывают про идентификацию и приоритизацию угроз, а в конце доходят до shift-left security.

В рамках эфира к нам присоединяться 2 гостя
- Вацлав Довнар, независимый консультант по процессам безопасной разработки. Он помогает компаниям создавать процессы безопасности которые не тормозят разработку.
- Дмитрий Гаевский, мой коллега , инженер dev-to-dev-решений на больших масштабах, RnD-решений и event-driven-систем.

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

Yandex Platform Engineering

Крутой ресурс с описанием технологий и команд отдела Yandex Platform Engineering, который делает инфраструктуру для разработки и эксплуатации продуктов Яндекса.
Я первый раз вижу настолько круто сделанную страничку с описанием разных команд, их продуктов, а также технические параметры: основные языки, фреймворки, базы данных и других параметров, важных для разработчиков. И хоть я не собираюсь устраиваться в Яндекс, но мне было интересно побродить по странице и вдохновиться относительно того, как надо описывать свои команды, чтобы инженеры хотели попасть в них:)
Обычно страничка каждого продукта содержит как минимум следующие пункты
- важность продукта для пользователей (обычно других инженеров)
- инженерные вызовы, что стоят перед командой с объяснением почему именно так
- процессы, что приняты в команде - часто тут приводится принцип "you build it, you run it" с упоминанием про дежурства
- как выглядит команда и ее взаимодействие

P.S.
Думаю, что этот подход и нам стоит взять на вооружение

#PlatformEngineering #Engineering #Software