В этот понедельник мы провели третий стрим клуба Code of Architecture по книге "Continuous Architecture in Practice". Он был посвящен scalability и performance.
- в части про scalability мы погорили про архитектурные подходы к масштабированию stateless и stateful нагрузок
- в части про performance мы обсудили почему производительность важна, как ее мониторить и что делать для повышения производительности вашего решения
У нас в гостях были два гостя:
- Алексей Тарасов, который развивает архитектуру Тинькофф Инвестиций
- Даниил Кулешов, архитектор новой системы авторизации для клиентов

В рамках обсуждения мы упоминали дополнительные материалы
- Requirements Engineering for Software and Systems — книга про работу с требованиями, которую рекомендовал Даниил;
- Статья от Ozon про кеширование и мой обзор этой статьи
- Книга Architecting for Scale и обзор интервью с автором от меня
- Концепция AWS Well-Architected от Amazon, в которой хорошо рассказывается про то, как собирать из кубиков AWS надежные и масштабируемые системы
- Мое выступление про надежные системы, которые в основе используют решения, что хорошо масштабируются
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности и масштабируемости, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на нужные архитектурные характеристики

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

One Rule to Rule Them All • Pragmatic Dave Thomas • GOTO 2023

Интересное выступление от Dave Thomas, который участвовал в принятии "Manifesto for Agile Software Development" много лет назад. В этом выступлении Дейв использует много цитат Йоги Берра, который славился своими «йогизмами» - остротами, который часто имеют форму очевидной тавтологии или парадоксального противоречия вида "We're lost, but we're making good time". Кстати, эта фраза про наши процессы разработки:) Дальше автор идет по шагам
- И рассказывает про классический waterfall и почему его все перевирают, когда показывают картинку без обратных связей
- Вспоминает про type systems и theorem proving как подход к улучшению качества кода
- Высказывает неканоническое мнение про test coverage (правда, автор доводит все до абсурда с 100% coverage)
- Вспоминает научные истории для того, чтобы обсудить корректность кода и начинает с отсылки к Лапласу, который был приверженцем абсолютного детерминизмаи утверждал, что

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

Дальше Дейв вспоминает про квантовую физику с принципом неопределённости Гейзенбе‌рга, который в простом варианте можно описать так

Невозможно одновременно с точностью определить координаты и скорость квантовой частицы

А потом переходит к теореме о неполноте Геделя, которая в обобщенном виде может звучать так

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

Отсюда Дейв выводит свой первый постулат

Thomas's Postulate #1 - There is no such thing as correct code

И после этого Дейв предлагает стремиться не к корректному коду, а к коду, который готов к изменениям. А изменения бывают по куче причин.
Дальше Дейв вспоминает про старые времена, когда множество уважаемых людей съехалось на горнолыжный курорт и написали свой манифест, который Дейв назвает не Agile Manifesto, а именно "Manifesto for Agile Software Development".
Дальше Дейв вспоминает свое популярное выступление "Agile is Dead • Pragmatic Dave Thomas • GOTO 2015", где для того, чтобы быть agile предлагают не проходить кучу тренингов или приглашать коучей, а просто понимать ценности и применять их

Understand the Agile values and then apply them

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

Thomas's Postulate #2 - Make it easier to change

Дальше автор разбирается с вопросом, а как научиться предсказывать будущее для того, чтобы быть готовым к изменениям. По-факту, он предлагает прокачивать нашу интуицию и много размышляет про сознательное и бессознательное, про выработку правильных паттернов и реакций. Дальше он рекомендует книгу Даниэля Канемана "Thinking fast and slow". Потом он рассказывает про то, как работает опыт и вспоминает про книгу "The inner game of tennis", про которую я тоже слышал лет 10 назад.
Ну и напоследок автор говорит про то, как вести дневник и записывать, когда вы сталкиваетесь с изменениями
- What is the change?
- Likely effort
- Actual effort
- Observations
причем Дейв настаивает на том, чтобы писать это рукой, а не печатать, чтобы использовать мультимодальность нашего мозга:)
В итоге, это упражнение поможет прокачать вам свою интуицию, с помощью которой вы сможете принимать решения лучше.

Ну и напоследок Дейв опять вспоминает про заглавие доклада "One Rule to Rule Them All" и говорит, что это не совсем правило, но оно в том, чтобы

Makе it easier to change

#Management #SelfDevelopment #Processes #Leadership #Learning #Agile #Philosophy #Brain

Задачки про программированию от Тинькофф на Highload++

В начале этой недели был Highload++, на котором у Тинькофф был стенд с Digital Interview. Там были забавные задачи по программированию, а код можно было писать на одном из языков: C++, C#, Go, Java, JavaScript, Kotlin, Python, Swift. Цель была в том, чтобы написать код, который проходит автотесты, которых всего пять на каждую задачу. Сами задачи немного нестандартные, а каждый новый тест открывает новое условие. А иногда условие задачи вообще не известно.

Вы можете порешать эти задачи тут. Задача выбирается случайным образом при нажатии кнопки «Поехали!».

#Conference #Software #SoftwareDevelopment #SelfDevelopment

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

Продолжу пост про структуру команд, в котором поговорю про проектный менеджмент. Мне кажется, что каждый менеджер должен уметь работать в рамках проекта, который PMI (Project Management Institute) определяет как

Project is a temporary endeavor undertaken to create a unique product, service or result

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

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

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

1) Проект переезда web привлечения на новую версию Tinkoff.ru (примерно 7 лет назад)
С этого проекта началась моя карьера в Тинькофф
- Проект переезда на новое решение к моему приходу длился уже больше года
- Над ним работало 50+ человек
- Моя зона ответственности была только в страницах привлечения и формах привлечения, над которыми работало 3 человека
- До переезда оставалось 3 месяца, а на новом решении не работали ключевые вещи: не работал SSR (кто-то ошибся с расчетом нагрузки), не работала аналитика (SPA приложения требовали переделать трекинг), не работали многие механики на формах, а также релизы занимали недели из-за ручного регресса.

Мы сделали этот проект в авральном режиме, успешно переехали и дальше начали развивать приложение как продукт. За три года наши страницы привлечения выросли до всей публичной части Tinkoff.ru, включая все продукты, а команда до 50 человек в 7+ командах. Многие ребята, с которыми мы затянули этот проект и развивали продукт до сих пор со мной. Подробнее про этот проект, переросший в продукт, можно посмотреть в моем выступлении на ArchDays 2019

2) Проект запуска отдельных продуктовых команд и процессов в мобильном банке Тинькофф (примерно 4 года назад)
Этот проект стал вызовом для меня - именно с ним я вышел за границы привлечения.
- Проект перехода на продуктовую структуру команд от одной команды в 50 человек длился уже полгода, но шел с пробуксовкой
- Запрос был в том, чтобы повторить для мобильного банка путь по разъезду на отдельные продуктовые команды, который я проходил в web.
- Здесь вызовом было то, что команда была сложившаяся и требовалось гораздо лучше уметь в change management.

Проект изменений мы запустили за три месяца, но я в это время проводил в среднем по 3 интервью в день, не считая разнообразные синки. Так как эти первые три месяца я работал в режиме привлеченного руководителя, то я почувствовал как сложно идут изменения, когда ты работаешь из позиции консультанта, пускай и внутреннего. Этот проект тоже перерос в большую продуктовую историю, про которую я рассказывал в нескольких частях
- В апреле 2021 года "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В сентябре 2022 года "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

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

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

YaTalks 2023

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

Update
Проверил форму регистрации и узнал, что регистрация на оффлайн уже закончена. Так что остается только вариант с онлайном.

#Conference #Management #Leadership #Processes

eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel

Крутое документальное видео на полчаса про технологию eBPF, которая используется для безопасного и эффективного расширения возможностей операционной системы в runtime (изначально это была только Linux). Суть в том, что для такого расширения не требовались изменения в исходном коде ядра, а также не требовалось подгружать отдельные его модули. Безопасность достигалась за счет того верификатора внутри ядра, который проводил статический анализ кода. Загруженные программы, прошедшие проверку, либо интерпретируются, либо JIT-компилируются в ядре для обеспечения собственной производительности выполнения. Модель выполнения управляется событиями и, за некоторыми исключениями, выполняется до завершения. Это означает, что программы могут быть прикреплены к различным точкам перехвата в ядре операционной системы и запускаться при возникновении события.

В фильме круто рассказывается как все началось с того, что Alexei Starovoitov, работая в стартапе PLUMgrid над SDN (software defined network), придумал встроить виртуальную машину в ядро Linux

Alexei decided to invent a new instruction set based on x86 assembly and get the kernel to verify the instruction set for safety.

Но эта идея была слишком революционной и поэтому Chris Wright из RedHat (сейчас CTO RedHat) предложил ему пойти эволюционно и начать с того, чтобы

look into an existing kernel subsystem called BPF and integrate it into existing BPF to make it easier to understand and accept for the community.

Собственно отсюда появилось название "extended Berkeley Packet Filter" и дело пошло
- сначала был план сфокусироваться на сети, но как оказалось для горящей проблемы уже было решение
- дальше фокус сместился на трейсинг и к делу подключился Brendan Gregg, который сделал с использованием eBPF инструменты, что потом превратились в bcc и bpftrace
- дальше eBPF показал свою эффективность в hyperscalers (Meta, Google, Netflix, ...), собственно Alexei Starovoitov ушел в 2015 году в Fb и там показал выдающиеся результаты
- потом появилась идея компании Isovalent, которая создала Cilium, который принес возможности eBPF конечным пользователям
- дальше eBPF нашел применение в security
- а потом eBPF повторили и для других операционных систем

В итоге, изначальная задумку удалось внедрить и поменять положение дел в индустрии, когда написание кода для исполнения кода внутри ядра (а не в userspace) было крайне сложным, долгим и дорогим. Теперь это можно сделать легко и быстро, используя eBPF.

P.S.
Я про eBPF услышал только в 2019 на Kubecon в Барсе и сразу не распознал всю прелесть технологии. Возможно, дело в том, что я никогда не был системным программистом, да и сети знаю так себе:)

#Linux #Kubernetes #Networking #DistributedSystems #SystemDesign #Software #Engineering

Code of Architecture - Continuous Architecture in Practice - IV

Завтра в 18:00 мы закончим разобр книги "Continuous Architecture in Practice" и поговорим про три главы
- Resilience as architectural concerns - я достаточно подробно уже разбирал эту главу в своем посте пару месяцев назад
- Software architecture and emerging technologies - тут авторы говорят про AI и blockchain и их влияние на архитектуру софта
- Conclusion - здесь авторы подводят итоги книги, что сделаем и мы на своем стриме

Гостями выпуска станут два эксперта
- Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion.
- Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы по распределенным системам и Event Storming, пишет статьи в блоге agilemindset.ru.

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

Дополнительные материалы для выступления на дне Тинькофф в МФТИ

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

- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- Devops культура: мифы и реальность
- Как RnD появляется в крупных ИТ-компаниях
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Как подготовиться и пройти System Design Interview

P.S.
И сразу после выступления я поеду домой, чтобы успеть к началу нашего онлайн-стрима "Code of Architecture", про который я писал вчера.

#SoftwareDevelopment #Software #SoftwareArchitecture #Engineering #SystemThinking

По традиции при посещении МФТИ зашел в книжный магазин и не смог выйти без покупок - купил пачку книг Фейнмана
- Фейнмановские лекции по физике. Современная наука о природе (The Feynman Lectures on Physics. The New Millenium Edition (1-7))
- Радость познания (The pleasure of finding things out)
- Не все ли равно, что думают другие (What do You Care What Other People Think?)
- Дюжина лекций: шесть попроще и шесть посложнее (Six Easy Pieces. Six Not-So-Easy Pieces)

Но я покупал не только книги, но захватил и кружку с символикой МФТИ, что выпущена на 75-летие:)

P.S.
До этого я уже рассказывал про другие книги Фейнмана
- Вы, конечно, шутите, мистер Фейнман
- Характер физических законов
- КЭД - странная теория света и вещества
И они действительно были хороши, думаю, что и пополнение моей библиотеки меня не разочарует.

#PopularScience #Physics #Math #SelfDevelopment

Inside Envoy: The Proxy for the Future [OFFICIAL FILM]

Крутой документальный фильм про Envoy, который начинается с рассказа Matt Klein, создателя Envoy. Мэтт рассказывает про
- Свой опыт работы с TSA (Twitter Streaming Aggregator), который можно считать предшественником Enovy
- Дальше Мэтт немного нафакапил с настройкой обработки дат, а дальше миллионы людей оказались разлогинены
- Дальше Мэтт нашел искать новые возможности и ушел в Lift, куда до этого ушел его руководитель
- В Lift Мэтт занялся созданием нового прокси сервера, который из коробки давал observability и performance, сравнимый с Nginx
- Потом Envoy был выложен в open source и начался поиск adoption
Дальше рассказ переходит к сотрудникам Google, которые рассказывают как они планировали в это время делать service mesh, который потом стал Istio. И они выбрали Envoy в качестве data plane для этого нового service mesh. Интересно описывается как принималось решение о выборе в пользу Envoy по сравнению с Nginx, где одним из вопросов был, а что это за продукт, где было всего 6 пул реквестов в репозитории. Но плюсы Envoy перевесили и дальше Google засетапила 10 инженеров в отдельную команду, которая начала развивать Envoy и дальше использовать его внутри Google Cloud. И дальше проект пошел в бурный рост ...

P.S.
- Помню как лет 15 назад я работал сначала с Apache Http Server (apache httpd), где сервер на обработку запроса форкал процесс или использовал пул префоркнутых процессов
- Примерно в то же время я увидел Nginx и его модель работы показалась мне прорывной по сравнению с httpd - в Nginx были master и worker процессы, где worker processes могли обрабатывать много зпросов, используя state machine (подробнее тут)
- А теперь у нас есть Envoy, который гораздо лучше подходит к cloud native миру. Подробнее схему обработки запроса можно посмотреть здесь

#Linux #Kubernetes #Networking #DistributedSystems #SystemDesign #Software #Engineering #Architecture

Материалы к выступлению на YaTalks про то, как формировать структуру команд под запросы бизнеса

Сегодня в 12.00 я выступаю на YaTalks и традиционно выкладываю сюда материалы, которые я рекомендую для изучения после доклада
Сначала список инструментов, которые я считаю полезными в этом вопросе
- Про backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про управление проектами я рассуждал в статье про три П "Проект, продукт, процесс"
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал

Дальше идут ссылки на материалы, в который я подробнее рассказывал про изменения, о которых упоминаю в докладе на YaTalks
- Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения
- Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- Доклад на Techlead Conf 2021 про платформизацию мобильного банка Тинькофф с целью создать автономные мобильные команды для каждой бизнес-линии (есть текстовая версия в моем блоге)
- Доклад на Highload++ 2022 про создание stream-aligned команд на базе отдельных мобильных и api команд, которые уже больше похоже на кросс-функциональные, передачу их под руководство CTO бизнес-вертикали и некий technical governance от платформы мобильного банка (и текстовая версия в моем блоге)
- Книга "Learning DDD", в которой хорошо изложены стратегические концепции DDD и которую я активно использовал при проектировании новой оргсхемы своего юнита почти на тысячу человек

P.S.
Ну и можно прочитать пока пару постов из серии, в которой я сегодняшний доклад описываю в текстовом виде
- Тезисно идея доклада, описание инструментов и алгоритмов
- Про проекты и примеры из практики
Пока там только два поста, но после выступления я запилю оставшиеся части:)

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

В этот понедельник мы провели четвертый стрим клуба Code of Architecture по книге "Continuous Architecture in Practice". Он был посвящен в большой степени resilience, но кроме этого мы упомянули про emerging technologies и сделали выводы целиком по книге. Собственно вся дискуссия была вокруг надежности, отказоустойчивости, resilience как архитектурной характеристики. Я уже раньше писал про эту глааву отдельный пост.

У нас в гостях были два гостя:
- Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion.
- Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы

В рамках обсуждения мы упоминали дополнительные материалы
- Моя статья "Проектируем надежные системы — стоит ли игра свеч", которая целиком посвящена теме надежности
- "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 (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- "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" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы
- Выступление Сергея Баранова "Как принимать инженерные решения в условиях неопределенности" - упоминали в контексте связи с принципами всей книги "Continuous Architecture"
- Miro доска со всеми нашами слайдами, что мы демонстрировали все 4 серии

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #SRE #Reliability #DistributedSystems

10 Learnings From Running Production Infrastructure at Google • Christof Leng • GOTO 2023

Хороший доклад от Christof Leng, Lead for Google's SRE Engagement Model and SRE Review Programs. Доклад отлично структурирован и может служить некоторой выжимкой из SRE книг Google, которые доступны на их сайте и про которые я уже рассказывал: SRE Book и Building Secure and Reliable Systems. Если возвращаться к самому докладу, то он состоит из следующих частей

0. Culture - начинается все с знаменитой фразы "Культура ест стратегию на завтрак". Но это еще и инженерная проблема, на которую можно смотреть с точки зрения доступного тулинга, методологии, которую могут использовать инженеры для повышения надежности.
1. Reliability can't be taken for granted - про это же я рассказывал в самом начале своем докладе "Проектируем надежные системы - стоит ли игра свеч", но суть в том, чтобы помнить про надежность и риски того, если система будет недостаточно надежна - на это можно смотреть с точки зрения рисков. Плюс надо помнить, что добавить надежность после создания системы бывает невозможно или слишком дорого, поэтому требования по надежности надо обсуждать в нужный момент
2. Cattle vs. Pets - популярная метафора про то, что нам надо относиться к своим системам не как домашним животным, а как к животным из стада. Это позволяет автоматизировать действия по поддержке стада и масштабировать подходы, что не возможно с домашними животными:)
3. Blamelessness - история про правильный подход к обвинениям. Про это подробнее можно почитать у Веструма, который писал про типологию культур - "A typology of organisational cultures", а также про поток информации в них и отношение к ошибкам - "The study of information flow: A personal journey"
4. Measure what matters - рассказ про SLO (service level objectives) и что они действительно должны быть тем, что важно для пользователей сервиса
5. Failure modes - история про то, что участие в инцидентах в рамках oncall позволяет понять как системы разваливаются, почуствовать пороху и понять, что на кону многое стоит. Это не передается при чтении постмортемов ... даже в слух и по ролям:)
6. No heroes - про то, что культура героев, спасающих всех - это плохо для всех. Нас интересует не преодоление проблем, а их предотвращение.
7. Automation - тут идет речь про посто автоматизацию своей работы, которая позволит делать более сложные задачи и меньше заниматься рутинным ручным трудом - лень двигатель процесса.
8. Change is No. 1 reason for outages - все вокруг постоянно меняется и зачастую это является причиной перебоев в работе. И надо быть готовым к этому. Надо минимизировать риск каждого отдельного изменения и автоматизации их проверки и применения (например, используйте GitOps)
9. Outages are inevitable - проблемы неизбежны и надо быть к ним готовым, ограничивая импакт, частоту и вообще управляя риском.
10. No haunted graveyards - не заводите кладбищ с привидениями, под которыми Chistof понимает важные приложения, которые никто уже не трогает и на знает как они работают, а значит не может починить их в случае проблем с ними.

Напоследок автор говорит, что не надо делать сложные системы. Вместо этого надо стараться делать простые системы, хотя это гораздо сложнее, чем сделать сложную систему:) Автор превозносит simplicity и говорит, что boring is beautiful:)

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

ICPC Northern Eurasia Contests

В воскресенье еду в Питер, чтобы в понедельник поучаствовать в мероприятиях студенческого командного чемпионата по программированию ICPC в Северной Евразии, который пройдет с 11 по 13 декабря. Судя по расписанию мероприятия, оно будет плотным и насыщенным не только с точки зрения самого программирования, но и с точки зрения side активности, но мне точно надо будет присутствовать на разных церемониальных частях: Opening Ceremony, Awards Ceremony for RTO HSPC, Awards Ceremony for NEF (что удобно подсвечивается желтым в расписании если нажать Ctrl + F и поискать "Ceremony"). Правда, я думаю, что мероприятие будет интересным и я почти все 3 дня проведу на площадке, общаясь с людьми, что увлечены разработкой софта и которые могут стать отличной свежей кровью для нашей технологической компании.

#Software #SoftwareDevelopment #Conference #Engineering

Как мы в Тинькофф делали игру «три в ряд» для 3 млн клиентов

Интересное выступление от Вадима Гончарова, руководителя отдела проектных и игровых решений внутри моего юнита. В этом выступлении Вадим рассказал про то, как он и его команда создали игру "Ряд наград":
- как сделали свой детерминированный движок match3
- разработали бэкенд с системой валидации ходов, системой выполнения заданий, выдачи призов и уведомлений
- как на фронтенде не стали использовать Unity или iOS/Android
- как пошли путём применения HTML5-технологий: взяли связку Pixi.js для игры и React.js для обвеса
- как использовали технику dependency injection с помощью DI-контейнера, чтобы подружить огромное количество модулей между собой

P.S.
Помню как уговаривал Вадима выступить на Python Conf и рассказать про эволюции Тинькофф Журнала, за который он отвечал до проектов и игр. С тех пор Вадим сильно прокачался, но драйв остался все на том же высоком уровне. Кстати, Вадим ведет интересный канал, на который можно подписаться.

#Management #Software #Engineering #ProjectManagement #Architecture

Code of Architecture - Новогодный выпуск

18 декабря в 18.00 у нас будет новогодний выпуск с обсуждением white paper от Google на тему их гибридного подхода к RnD. Эта статья так и называется "Google's Hybrid Approach to Research" и вышла она в 2012 году (статья доступна в pdf версии здесь). На этот выпуск к нам придут два крутых гостя:
- Игорь Маслов, мой коллега, директор базовых технологий, вице-президент Тинькофф
- Станислав Моисеев, мой колллега, директор инженерных исследований в Тинькофф

Я думаю, что выпуск получится огненным и мы поговорим про подходы Google, а также расскажем как это соотносится с тем, как выглядит RnD в Тинькофф. Чуть ближе к делу я напишу анонс с ссылкой на трансляцию и обложкой, а пока можно почитать мой обзор этого whitepaper, а также вспомнить прошлый новогодний стрим, где мы говорили про Манифест про распределенные системы от команды Аmazon, который тоже был вокруг whitepaper и позволил нам обсудить много интересного:)

#RnD #SoftwareDevelopment #SystemDesign #Engineering #Management

Если с ребенком трудно

Эта книга Людмилы Петрановской написана простым и понятным языком про детей и для родителей. Для родителей, у которых не получается найти общий язык со своим ребенком. Сама книга состоит из 2 частей и кучи миниглав, каждая из которых с простой мыслью, примером и интерпретацией происходящего. Такая структура позволяет легко двигаться по книге и воспринимать ее как смесь теории и решебника:)

В первой части книги, которая называется "Прощай, оружие, или make love, not war" автор высутпает в качестве сапера и показывает как можно уйти от конфронтации с собственным ребенком, втянуть шипы, избавиться от дежурных фраз и негодования. Когда эта цель достигнута, то автор переходит ко второй части книги "Трудное поведение: перезагрузка" и показывает
- как можно повлиять на трудное поведение ребенка
- чем трудное поведение отличается от плохого
- в чем причина этого поведения - это зачастую самый простой способ достижения хороших целей (а сложным и конструктивным способам дети часто не успевают научиться)
Дальше автор предлагает алгоритм из 7 шагов для перезагрузки поведения
1. Определяем цель - надо выбрать то поведение ребенка, которое мешает жить больше всего. У нас должна быть одна или две цели, на которых мы решили сфокусироваться
2. Что именно происходит? - надо собрать симптомы и попробовать собрать информацию о трудном поведении (что, где, когда, ...)
3. Ищем пружину - надо понять что именно является ключевой причиной трудного поведения.
4. Объясняем, что не так - тут надо объяснить в чем проблема, используя "Я-высказывания", где мы говорим про свои чувства, потребности и проблемы. Не используем "Ты-высказывания" навроде "ты не прав" или "ты плохой"
5. Даем наступить последствиям - важно, чтобы при наступлении последствий родители не злорадствовали, а продолжали поддерживать детей, оставались на их стороне и помогали разгребать последствия. Главное, чтобы последствия не были подстроены, а наступали естественным путем
6. Помогаем добиваться своего по-другому - суть в том, что трудное поведение - это обычно примитивные технологии достижения желаемого. Поэтому нам надо показать на примере правильное поведение. Причем главное - это что вы делаете, а не что говорите. Важно быть изобретательным и помогать ребенку находить разные варианты решения проблем.
7. Закрепляем достижения - для закрепления нового поведения требуется поддерживать детей, проявлять симпатию, говорить уверенно и позитивно о будущих изменениях, хвалить и обнимать детей.

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

P.S.
Если немного модифицировать советы из книги, то их можно использовать для работы с трудными сотрудниками:)

#ForParents #ForKids #Management #Leadership #Psychology

Ruby on Rails: The Documentary

Интересная история создания фреймворка для веб-приложений на языке Ruby, которую преимущественно рассказывает сам создатель фреймворка, David Heinemeier Hansson. Сам фреймворк для своего времени был действительно прорывным - он повышал удобство и скорость разработки, позволял разработчику в одиночку накидать прототип или даже довести его до продукта.

Правда, у продукта поверх Ruby on Rails было несколько проблем:
- производительность решения - когда приложение становилось популярным и получало прирост нагрузки, то чеки за используемые мощности железа становились негуманными
- подход conventions over configurations - этот подход про имплицитно принятые решения, которые скрыты от разработчиков, но торчат наружу в виде некоторых guidelines. И все классно работает пока все коллеги разделяют и следуют конвенциям. Но по мере роста решения и команды появляется кто-то, кто, например, используя метапрограммирование (спасибо Ruby) неявно меняет базовое поведение и вся наша стройная схема ломается и надо тратить время на нетривиальный дебаг. В итоге, я персонально больше скланяюсь к мантре "Explicit is better than implicit" из The Zen of Python.

Интересно, что я впервые встретился с Ruby on Rails лет 10 назад в курсе "CS169 - Engineering Software as a Service" от Berkley. В этом курсе авторы
- с большим энтузиазмом использовали Ruby on Rails в качестве базового фреймворка
- промотировали TDD (test driven development) и высокий code coverage
- учиили использовать BDD (behavioral driven development) и именно там я познакомился с огурцом (Cucumber) и с тех пор разуверился в этом подходе (но это отдельная история)
- показывали как использовать Capistrano для деплоя кода в продакшен, потом я некоторое время использовал этот инструмент в своих продакшен проектах
- объясняли почему код, выглядящий как текст на том языке, что ты говоришь - это круто. Ну эту часть я ни тогда, ни сейчас не выкупил (хотя адепты 1С наверное прониклись бы этим объяснением)

В итоге, именно продакшен код на Ruby on Rails я особо не писал, но видел как концепции этого веб-фреймворка проникали в фреймворки на других языках (тот же паттерн ActiveRecord) и мне было интересно а куда он пропал с радаров. В этой документалке вы не найдете ответа на этот вопрос, но зато узнаете как этот фреймворк стал популярен. И вам про это расскажет не только David Heinemeier Hansson, но и куча других людей, приложивших руку к развитию этого фреймворка
- Jason Fried, Founder & CEO at 37signals
- Tobias Lütke, Co-founder and CEO Shopify (участник rails core team с 2004 по 2008 год)
- Jeremy Daer, разработчик в 37signals и участник rails core team с 2005 года
- Jamis Buck, сейчас в MongoDB (участник rails core team с 2005 по 2007 год)

#Software #Engineering #History #SoftwareDevelopment #Architecture #SystemEngineering