Курс "Теория вероятностей" на Stepik

Лет шесть назад я прошел этот курс на степике и действительно могу подтвердить, что он тянет на свою оценку в 4.8 из 5, что указана на платформе:)
В самом курсе рассказывается о базовых понятиях и теоремах теории вероятностей и содержит много практических заданий для самостоятельного решения.
Курс состоит из двух частей по два модуля в каждой:
- Первая часть посвящена классической версии теорвера, где испольхуются элементарные методы и доказательства. Модули внутри первой части так и называются "Элементарная теория вероятностей: случайные события" и "Элементарная теория вероятностей: случайные величины"
- Вторая часть содержит материал посложнее. Третий модуль называется "Общая теория вероятностей" и содержит аксиоматический подход к теории вероятностей и строгое изложение общей теории. Это самый интересный и сложный модуль. Четвертый модуль "Дискретные и непрерывные случайные величины" содержит обсуждение частных случаев, которые после общей теории кажутся простыми и понятными:)

В итоге, курс мне кажется полезным для получения базовых знаний по теории вероятности, которые нужны в быту, например, чтобы понять как считается надежность системы, состоящей из кучи сервисов, если у каждого сервиса есть свой SLA по доступности и все из них нужны для работоспособности системы верхнего уровня:) Как-то я такого типа вопрос хотел добавить в скрининг SRE-инженеров:)

P.S.
Сам я теорвер люблю еще со школы - это началось после того как в 10 классе съездил в Москву посмотреть на МГУ и МФТИ, чтобы решить куда буду поступать из своего Северодвинска:) В итоге, я вернулся с набором книг, в котором была книга по теорверу, которая мне понравилась, но обложку которой я не смог найти потом в Google, чтобы узнать название этой книги и перечитать по прошествии лет.

#Math #Course

Мой доклад "Improving Software Flow" на IT-пикнике 2 сентября

Уже через неделю будет большой ИТ-пикник в Коломенском парке от Тинькофф, DevFest и Мельницы. Я на этом пикнике входу в программный комитет трека "Архитектура, надежность, качество", где будет шесть докладов. Один из докладов выпал из-за форсмажора, поэтому я внезапно стал еще и спикером, который закроет этот трек с докладом "Improving software flow", который я уже рассказывал вначале августа в Казани на нашем фестивале (расшифровка доклада есть здесь, но записи пока нет).

Если вы планируете зайти на фестиваль, то не забудьте зайти именно на наш трек, а может и на мой доклад:)
Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут.

#Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems

Специальный выпуск Code of Architecture с разбором white paper про Borg

Этот выпуск мы записывали в начале августа на Тинькофф ИТ-фесте в Казани. У нас была аутентичная обстановка - ковер на фоне, чак-чак и самовар на столе:)
И мы обсуждали научную статью 2015 года от Google "Large-scale cluster management at Google with Borg" в составе:
- Владимир Чистяков - руководитель разработки в Тинькофф, один из постоянных ведущих "Code of Architecture", который приехал на конференцию в Казань из Воронежа, где он работает в воронежском центре разработки
- Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform, который живет в Казани и работает в казанском центре разработки
- Автор этого канала, который приехал на конференцию из Москвы, где работает в Headquarters

Если вернуться к содержанию статьи, то надо сказать, что Borg - это система оркестрации рабочих нагрузок, которая используется в Google. Интересно, что именно в недрах Google родился и Kubernetes, в котором был утчен опыт создания и эксплуатации Borg. Интересно, что в 2016 году вышла статья со сравнением трех оркестраторов "Borg, Omega, and Kubernetes", которую интересно прочитать в продолжении.

#Kubernetes #SystemDesign #SoftwareArchitecture #SoftwareDevelopment #Software #Architecture #DistributedSystems

Thinking Architecturally. Lead technical change within your engineering team

Эту небольшую брошюру от Nathaniel Schutta я прочитал в далеком 2019 году, когда гораздо проще было путешествовать по зарубежным конференциям и собирать ништяки. Конкретно в этой книге 56 страниц, но это только уменьшает количество воды, которую обычно наливают авторы в книги, чтобы растянуть книгу на 200 - 250 страниц. Конкретно в этой книге получилось 7 коротких глав:
1. Technology Changes - здесь речь идет про то, что технологии меняются и мы не можем предотвратить изменения, поэтому нам надо уметь ими управлять. Автор отмечает, что изменения в технологиях часто повторяют себя и нам надо знать прошлое, чтобы распознавать будущие паттерны. Здесь автор предлагает учиться на своих ошибках и ошибках индустрии (например, постмортемы, про которые я как-то рассказывал здесь), оценивать развитие технологий и не верить в хайп с конференций. Тут автор упоминает даже про пользу legacy skillset, на примере COBOL:)
2. Thinking Strategically - основная мысль в том, что думать об изменениях в технологиях надо стратегически и также стратегически надо думать про свое развитие. Автор предлагает фокусироваться на нескольких областях, которыми вы глубоко увлечены и прокачивайте их. Дальше автор рассказывает про использование техрадаров по технологиям, которые можно использовать и для поддержания своих технологических знаний (подробнее про техрадары я говорил здесь). Дальше идет речь про структурирование потоков информации, создание планов по своему развитию с созданием пет-проектов, персональное обучение, обучение в группе, общение с коллегами по индустрии
3. Evaluating Pros and Cons - эта глава посвящена принятию решений, как оценивать компромиссы, риски. Тут же обсуждается technology hype cycle и выбор правильного инструмента
4. Evaluating and Choosing Technologies - как выбрать критерии для оценки, например: документация, коммьюнити, структуру контрибьюторов, кодовая база, тестируемость, зрелость, стабильность, расширяемость, поддержка, тренинги, возможность найма специалистов, безопасность, попадание в корпоративнудю структуру. Как это можно все свести в spreadsheet для оценки, сделать proof of concept и как на решение влияет политика организации
5. Introducing Technologies - про то, что внедрение новой технологии зачастую сложнее ее выбора:) Как митигировать изменения, как влиять на окружающих, как работать с возраениями и заниматься маркетингом своих идей
6. Maintaining Technologies - как поддерживать внедренные технологии по мере эволюции программных систем. Автор вспоминает про концепцию quality attributes (примерно то же самое, что architectural characteristics), которые надо выделить как важные для конкретного продукта, дальше отприоритизировать их и использовать подход continuous или evolutionary architecture с их фитнес-функциями для отслеживания того, что характеристики не уплывают по мере инкрементального развития продукта (вот тут подробнее про continuous architecture, эволюционную архитектуру)
7. Conclusion - в конце автор рекомендует стратегически подходить к применению новых технологий к вашему продукту/проекту.

#Architecture #Management #Leadership #Software #SoftwareArchitecture #SoftwareDevelopment

Кто такие Technical Product Manager, зачем они компаниям и как им взаимодействовать со стейкхолдерами?

Интересная статья про технических менеджеров продуктов, которые есть в некоторых компаниях (в Тинькофф они тоже есть).
По-факту, такие технические продакт-менеджеры делают внутренний платформенный продукт, у которого пользователями являются инженеры внутри, которые не всегда любят делиться своими проблемами, используя мантру "я могу решить любую проблему". В итоге, такой продакт менеджер должен уметь классно общаться с технарями, чтобы понять как сделать продукт, который им действительно поможет. В этой статье приводятся метрики таких платформенных продуктов:
- как они влияют на time to market продуктовых команд (платформы должны помогать сократить ttm)
- dimension cost или ограничение по стоимости продукта (если строить платформу слишком дорого, то это не ок)
- net promoter score (насколько инженеры довольны своей работой на платформе, по этому показателю можно оценить developer experience)
Дальше рассматривается вопрос о том, как на этой роли взаимодействовать со стейкхолдерами и доносить пользу от своих продуктов - часто признание находит только продуктовые команды, а создатели внутренних платформ часто оказываются крайними в случае проблем и невидимками в случае успехов:) В итоге, надо уметь разжевывать технические детали нетехническим стейкхолдерам и вклад своих команд в общий результат.

#Management #Leadership #ProductManagement

Техлиды и архитекторы

Осенью 2020 года на ArchDays я рассказывал как мы в Тинькофф принимаем архитектурные решения. С тех пор прошло много времени и теперь точно можно сказать, что мы действительно пишем архитектурные документы для крупных решений и обсуждаем их заранее. А результаты обсуждения обычно фиксируются в некотором логе архитектурных решений. У каждого крупного подразделения есть собственный процесс ведения такой документации, который похож в общем, но может отличатьтся деталями. Обычно самыми активными на ниве создания, проработки и ревью такой архитектурной документации являются инженеры высоких грейдов. У таких инженеров есть несколько ярко выраженных архетипов, среди которых я хотел сегодня поговорить про техлидов и архитекторов. Эти архетипы неплохо расписаны в книге "Staff Engineer" Вила Ларсона (вот тут мое краткое саммари книги). Но если говорить про эти архетипы своими словами, то
- Техлиды обычно работают в рамках одного домена с одним менеджером и одной-двумя командами. В Тинькофф такие ребята помогают улучшать инженерные метрики сервисов, за которые отвечает команда (MTTR, уровень автоматизации тестирования и деплоев, показатели SLA сервисов и так далее).
- Архитекторы обычно работают вне рамок одной команды и помогают драйвить архитектурные процессы и сложные кросс-командные проекты. В Тинькофф это может быть создание нового продукта, сложная миграция, перепроектирование старого продукта с учетом требований регуляторов и compliance.

Обычно в оба эти архетипа вырастают инженеры, которые прошли огонь, воду и медные трубы и доросли в итоге до Senior уровня. А дальше в какой-то момент они поняли, что им хочется больше сложности и больше влияния на результат и ради этого они готовы брать на себя больше ответственности. В этот момент у них обычно есть возможность попробовать себя в одной из этих двух ролей, а дальше после пары лет успешной работы можно номинироваться на следующий уровень в виде Staff Engineer, который в Тинькофф тоже есть:)

Кстати, в ветку архитекторов есть тропинка и через ветку системных аналитиков, но этот путь пока экспериментальный и содержит следующие шаги
- Подготовка заявки с архитектурными артефактами, которые были выполнены в рамках рабочих обязанностей (примерно как я рассказывал в этом докладе в части про процесс Т-Роста)
- Прохождение двух интервью: system design interview и интервью про архитектуру и процессы разработки, где мы обсуждаем как выглядят современные процессы разработки, как выстраивать архитектурные процессы в подразделении, а также как вести крупные проекты в роли архитектора

#Engineering #Management #Software #SoftwareArchitecture #Architecture #Architect

А вот и иллюстрация для предыдущего сообщения про архитекторов и техлидов

Тимлиды и как они появляются в компании

У нас в Тинькофф роль тимлида превратилась в формализованную профессию, где тимлид - это руководитель небольшой кросс-функциональной команды, которая может самостоятельно обеспечивать delivery определенной бизнес-ценности для клиента. Тимлид у нас отвечает за все, что происходит с командой: за ее delivery, за процессы разработки внутри команды, за используемые инженерные практики, за people management и так далее. Мы научились набирать таких руководителей рынка (я рассказывал про это в отдельной статье), а также мы умеем их растить внутри. И в этих подходах есть небольшое отличие:
- Мы нанимаем с рынка мы только людей с инженерным бэкграундом, которые умеют в разработку. Мы проверяем это при помощи трех интервью: языкового интервью, system design интервью и it team management интервью. На выходе мы понимаем что человек умеет писать код, умеет проектировать и умеет менеджерить
- А вот рост внутри пока до конца не стандартизован и иногда тимлидами команды становятся не только разработчики в прошлом, но и системные аналитики или qa-инженеры. В таких случаях часто продакт менеджер бывает доволен уровнем взаимодействия с тимлидом, но у этого часто бывает оборотная строна - в таких командах часто западают инженерные практики и/или архитектурные процессы. Проблема в том, что сложно удерживать баланс между бизнесовыми и техническими задачами, если бизнесовые задачи тимлид понимает хорошо, а вот в технике он плавает. В итоге, неявно технические задачи отходят на второй план и делаются по остаточному принципу. А это приводит к накоплению техдолга и замедлению команды. Правда, иногда это нарастание энтропии можно остановить, если в такой команде у тимлида не из разработки есть напарник в виде техлида, про которого я писал в прошлом посте. Но даже в этом случае accountable за инженерку в команде остается тимлид:)

#Management #Leadership #SoftwareDevelopment #Software #Engineering

Мой опыт в качестве тимлида

В продолжение прошлого поста расскажу немного про свой опыт тимлидства:
- В первый раз я стал тимлидом лет десять назад, когда работал над сайтом Woman.ru. Там была интересная конфигурация с принятием проекта от подрядчика, а дальше созданием команды inhouse для дальнейшей разработки и кастомизации сайта этого издания. В прыжке команда была порядка 10 человек, но сильно схлопнулась на рубеже 2014-2015 годов из-за финансовых потрясений
- Дальше я перешел в Банки.ру на похожую позицию, где был тимлидом команды, что отвечала за банковские, страховые, телекоммуникационные рейтинги и прочий UGC. Это был интересный опыт системной работы над техдолгом:) Но через полтора года я подустал с ним бороться, а обещанный на старте крупный продукт так и не стартовал
- Из Банки.ру я ушел в небольшой стартап про рекламу, партнерский маркетинг (CPA) про установки мобильных приложений. В этом стартапе я был аля deputy CTO, хотя по-факту это была такая же позиция тимлида, просто отвечающего за все IT в компании, включая инфраструктуру, процессы разработки, найм и обучение и так далее. За 4 месяца в стартапе я устал так, как за год в обычной компании (я понял, что хаос стартапов - это не для меня). В итоге, я покинул стартап, оставив оклад за последний месяц одному из сооснователей, который объяснил этот вычет фразой "а мы на тебя расчитывали":)

Дальше я пришел в Тинькофф, но здесь я тимлидом не был - я сразу пришел на позицию технического руководителя нескольких команд. И я ни разу не пожалел о своем приходе в компанию - мне кажется, что это самое продуктивное время за мою карьеру, как с точки зрения менеджмента, так и технического развития:)

Кстати, я достаточно часто выступал на тему тимлидов и прочих менеджеров. Вот мои выступления в хронологическом порядке
- Рост команды на порядок, или Как не сойти с ума, будучи frontend-тимлидом в привлечении Tinkoff.ru — выступление на Teamlead Conf 2018 (пример того, как я выстраивал процессы и сетапил роль тимлидов лет 6 назад в своем подразделении)
- Культура разработки глазами тимлида: переход от монопродукта к экосистеме - выступление на Codefest 2019 (здесь я рассказывал как тимлид может улучшать все внутри своей команды)
- SOLID'ный тимлид, или Основы менеджмента для технарей - выступление на Teamlead Conf 2021 (здесь я говорил про основы менеджмента с примерами из инженерных практик)
- Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - мое выступление на Highload++ про роль технического директора
- Как нанимать технических руководителей — выступление на Teamlead Conf 2023 (здесь я рассказывал как мы нанимаем тимлидов и менеджеров повыше)

#Management #Leadership #SoftwareDevelopment #Software #Engineering

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

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

Если внезапно окажитесь в Ульяновске в это время, то заходите послушать этот доклад:)

#Architect #Architecture #Software #SoftwareDevelopment #SoftwareArchitecture #Conference

The Art of Software Development • Sander Mak • GOTO 2023

Интересное обзорное выступление от Sander Mak насчет того, а насколько software engineering реально про инженрную состоавляющую, а в какой части это больше про искусство.
В выступлении примерно такая структура:
- А инженеры ли мы? Или мы ученые из сферы computer science? - Нет мы все художники (artists)
- Потому что software development - это про создание абстракций из реального мира в нашем софте
- Дальше автор обсуждает написание кода и говорит про общие принципы и подходы, а потом про вкручивание правил в линтеры, чтобы "художники" не обсуждали вопросы уровня пролемы vs табы. В общем, цель в том, чтобы не увлекаться инструментами и незначимыми деталями, а писать код, который обеспечивает работу выбранных абстракций
- Следующим идет тестирование, причем конкретно unit testing и о чем надо говориться перед написание тестов - тема раскрыта не полностью, но смысл примерно тот же - договоритесь о правилах и дальше сделайте их проверку частью инженерной культуры:)
- Потом приходит очередь дизайна и архитектуры - эта тема мне тоже показалась очень скомканной - автор говорит, что эта часть работы важна и экономит много времени за счет того, что мы сначала думаем, а помто кодим. В итоге, он дает отсылку к выступлению Саймона Брауна The lost art of software design by Simon Brown at Devoxx Belgium 2022, про которое я уже рассказывал раньше
- Предпоследняя часть посвящена процессам - тут автор по верхам задевает скрам и waterfall, но рекомендует вспомнить, что работаем мы с людьми, поэтому читайте "Peopleware: Productive Projects and Teams" от Tom DeMarco и Tim Lister, да будет вам счастье
- Ну и последняя тема посвящена тому, а как мы учимся тому, как писать код - ответ автора в том, что мы учимся на практике, а не из книг, поэтому идите и пишите код, а если вы считаете, что уже умеете, то вам стоит стать ментором для новичков

В общем, получилось интересное по структуре выступление, с интереными мыслями, но многие из которых раскрыты слишком поверхностно как мне показалось.

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems #Management #Leadership #Engineering

Remote Working Approaches That Worked (And Some That Didn’t) • Charles Humble • GOTO 2023

Интересное выступление про удаленную работу, апологетом которой является Charles Humble.
Он выступал за удаленную работу еще до ковида, на котором мы все принудительно оказались в удаленном режиме и смогли попробовать как это. Но Чарльз говорит, что этот опыт мог понравиться не всем, так как это было вынужденной и форс-мажорной мерой. Сейчас многие компании возвращают сотрудников в офис, аргументируя потребностью в повышении эффективности и/или коллаборации. Но так ли все просто...
Если подбивать итог высутпления, то основные мысли Чарльза сводятся к следующему
- Удаленная работа требует отдельного осмысленного проектирования как от компании, так и от сотрудника. Без этого она работает плохо (условно как было в ковид, когда всех отправили по домам)
- Надо отделять работу от дома, даже (особенно) если вы работаете удаленно. Например, при помощи физических границ: работая из кафе, гаража или просто символически выходить на прогулку из дома, имитируя поход на работу, а потом возвращаясь домой (но как бы на работу)
- Серьезно воспринимать свое ментальное здоровье и заниматься спортом, участвовать в социальной жизни
- Компания и менеджеры внутри нее должны позаботиться о прозрачности правил и процессов внутри организации, а также работать над flow информации, чтобы удаленные сотрудники оставались в общем контексте.

Автор вспоминает по ходу рассказа книги:
- Remote Team Interactions Workbook- книга от авторов Team Topologies, где они говорят про удаленную работу и про которую я уже рассказывал
- The Manager's Path - тут автор упоминает часть про one2one и хвалит книгу как отличный гайд для тех, кто переходит из разработчиков в менеджеры. Про эту книгу я тоже уже рассказывал в 4 частях: pre-manager, manager, engineering directors и senior leaders.

#Software #Management #Leadership #Engineering #SoftwareDevelopment

Вакансии в наши команды DBaaS (Database as a Service)

Я очень люблю распределенные системы, архитектуру, дизайн систем. А самое интересное в этом та часть, где хранится state или по простому базы данных. Причем базы данных бывают разные и сейчас у нас в компании активно разрабатывается продукты Database as a Service (пока Postgres и Cassandra). И если вы любите базы как я и еще умеете писать код на Python или Go, то вы можете присоединится к этой команды.

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

А вот какие планы по развитию этих продуктов
Сейчас мы предлагаем пользователям кластера PostgreSQL и Cassandra, однако планируем расширять список поддерживаемых БД. Запускаемые нагрузки активно растут, сейчас это сотни команд и тысячи кластеров, однако ожидаем десять+ тысяч кластеров. Одним словом - огромное количество возможностей для развития и прокачки скиллов в условиях решения нетривиальных задач, с которыми сталкиваются только крупнейшие компании. Сейчас большинство БД работает на виртуальных машинах в приватном облаке, однако в ближайшее время мы планируем запускать наши БД на Baremetal K8s для улучшения производительности.

Вот стек и конкретные задачи, которыми можно будет заняться прямо сейчас
Пишем на Python и Golang, c упором на надежность кода и полное покрытие тестами. Сейчас есть много продуктовых и технических целей как в части подключения Change Data Capturing в PostgreSQL, реализации Disaster Recovery Plan, так и в части управления конфигурациями, инфраструктуры, K8s и разработки Control Plane. Наша команда самостоятельно проектирует, декомпозирует, прототипирует и реализует такие задачи.

Немного про условия
Трудоустройство возможно как в РФ, так и в странах СНГ с Центрами Разработки Тинькофф.

Если вам хочется заниматься такими задачами, то напишите мне в личку (@apolomodov) и дальше я пообщаюсь с вами и познакомлю с коллегами.

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Материалы из Code of Architecture про базы данных и распределенные системы

В продолжении поста хочу поделиться материалами из клуба Code of Architecture
- Design Data-Intensive Applications (вот плейлист)
- Database Internals - (вот статьи с краткими саммари каждого выпуска: 1, 2, 3 и 4)
- Distributed Systems, 4th Edition (вот статья с ссылками на все выпуски и кратким саммари)
- Обсуждение white paper "Amazon Aurora" (статья с саммари)

Ради интереса я попросил модель Сбера "Кандинский 2.2" нарисовать картинку к посту по описанию "База данных как сервис с логотипами postgres и cassandra" в стиле kandinsky и получилось забавно:)

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Подкаст "Письма Лиды Таймовой". Выпуск №1: Оценивать или не оценивать

Интересный выпуск подкаста от ребят из Тинькофф про экзистенциальный вопрос про оценку задач:) Трое в лодке обсуждают варианты оценки в часах, сторипойнтих или варинат "no estimate". В выпуске участвуют ведущие: Виктор Шитов и Александр Вазюков, а также гость - Павел Ахметчанов. Все трое работают в Тинькофф и имеют прямое отношение к тюнингу процессов разработки, на основе данных:) Я спойлерить не буду, но отмечу, что как бы вы ни (не) оценивали задачи, вам полезно понимать границы применимости каждого из вариантов, а ребята в подкасте общаются именно про это.

#Software #Engineering #Processes #Project #Management