Книжный куб

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

В этот понедельник мы провели четвертый стрим клуба 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" - публичное интервью с разбором инцидента - Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #SRE #Reliability #DistributedSystems

Материалы к выступлению на 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

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

По традиции при посещении МФТИ зашел в книжный магазин и не смог выйти без покупок - я купил пачку книг Фейнмана - Фейнмановские лекции по физике. Современная наука о природе (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

Дополнительные материалы для выступления на дне Тинькофф в МФТИ Сегодня я еду в МФТИ, вспоминать студенческие времена (я на кампусе не был уже лет 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

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

«Племя́нник чароде́я» (англ. The Magician’s Nephew) Недавно я купил для детишек толстую книгу со всеми романами из серии «Хроник Нарнии» авторства Клайва Стейплза Льюиса. Мы использовали этот сборник для чтения сказок на ночь детям и уже успели прочитать первый роман «Племя́нник чароде́я», который по хронологии идет первым в серии, но написан он был шестым из семи книг. Мне кажется, что я в детстве начинал читать эту серию с канонической книги "Лев, кольдунья и платяной шкаф" и там сразу начиналась интересная история. Зато если начинать с приквела, то сразу становится ясно - как появилась Нарния (и не увидеть параллели с христианством не получиться) - как в неё попала Белая Колдунья (виноваты дети Адама) - почему Платяной шкаф обладал свойствами соединять разные миры Итого, мы с детьми справились с этим романом и дошли до книги Лев, кольдунья и платяной шкаф", которая пошла поинтереснее. Но я рекомендую всю серию книг:) #ForKids #Tales

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

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

Как формировать структуру команд под запросы бизнеса - часть 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

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

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

В этот понедельник мы провели третий стрим клуба 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

Материалы к докладу "Как RnD появляется в крупных IТ-компаниях" Сегодня я выступаю на Teamlead Conf с этим докладом и тут по традиции привожу список рекомендованных материалов. - Статья с расшифровкой - текстовая версия выступления, но без части про 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 #Engineering #Software #Architecture #SoftwareDevelopment #RnD

TeamLead Conf++ 2023 Завтра в 11.20 ++ я выступлю на Teamlead Conf в главном зале с темой "Как RnD появляется в крупных IТ-компаниях". Круто, что именно в главном зале, так как он будет доступен в виде публичной трансляции, но на которую надо будет зарегистрироваться. Так что если вам интересна эта тема, то приходите послушать и позадвать вопросы как online, так и offline. #Management #RnD #Leadership #Processes #Architecture #PlatformEngineering

Code of Leadership С нового года я планирую запустить видеоподкаст с обсуждением engineering management и technical leadership. Формат будет таков - один выпуск - одна книга - один выпуск - один гость с большим опытом разработки - книги для разбора пока следующие: "The Art of Leadership", "The Manager's Path", "The Staff Engineer's Path", "Team Topologies" Чуть позже закину список гостей на первые четыре серии. Если есть желание послушать про другие книги на эти темы, то закидывайте предложения в комментариях. #Management #Leadership #Software #Engineering #SelfDevelopment #Podcast

Есть контакт! Общайся продуктивно, без стресса, в любой ситуации Прочитал эту книгу для подростков, в которой рассказывается про то, как находить общий язык с собой, своими близкими, друзьями, а также научиться выступать публично, например, в школе. Книгу написал два автора: Полина Мохова и Екатерина Зиброва, которые поделили по-братски по-сестрински четыре главы между собой. Книга содержит иллюстрации Кристины Леви и выглядит скорее как комбинация лекций и учебной тетради, в которой все объясняется на пальцах и сопровождается упражнениями для закрепления теории. Книгу я читал перед тем как отдать ее одному из своих сыновей - мне она показалась крайне полезной и если бы я ее прочел в школе, то она бы мне сильно помогла. Дальше про содержание 1. Контакт с собой Здесь читатель - знакомится с самим собой и своим именем - размышляет о том, что ему важно и вещах, которые могут сказать о нем многое - думает о своих темных сторонах - оценивает свои сильные стороны и качества, что его характеризуют - учится размышлять и говорить о чувствах, понимать какие чувства можно назвать его любимыми, а какие нет - изучает что делать, когда захлестнули эмоции и как с ними справиться - учиться самопрезентации и тому, как связаны чувства и тело, как наши жесты выдают эмоции - изучает как одежда влияет на восприятие и исследует свой гардероб, чтобы понять свои предпочтения в одежде - проходит целую группу челенджей 2. Те, кто всегда рядом Здесь читатель знакомится со своим ближайшим кругом общения, учится находить взаимопонимание, исследовать окружение и вести оччень трудные разговоры. Здесь авторы вспоминаают про пирамиду потребностей (пирамиду Маслоу), говорят про конфликты как зоны роста, круги близости, помогают определить с кем из ближайшего круга можно поговорить и о чем. В части про взаимоотношение много говориться о том, что надо избегать оценочных суждений и заменять их описаниями того, почему у нас сформировалась такая оценка. Дальше авторы возвращаются к вопросу чувств и рассказывают про "ты-высказывания" и "я-высказывания", что помогает уйти от обвинительных высказываний в нейтральные. Много времени уделяется обсуждению границ и почему они нужны для комфортного общения. Дальше предлагается подумать про свои границы, а также про соблюдение чужих границ. В части исследования окружения предлагается сформулировать цедли и ожидания от общения с другими людьми (в книге предлагается подумать насчет отношений с родителями). Дальше идет переход к тому, а как обсуждать сложные вопросы и решать неразрешенные конфликты. Как сформулировать свои права и обязанности, а также общаться с друзьями. Что делать с манипуляциями, как их распознать и как ответить на попытки манипуляции. Как поддерживать собеседника при помощи активного слушания и как распознать токсичного человека, что такое буллинг и как дать отпор. 3. Общаемся в любой ситуации В этой главе раскрываются секреты успешного общения: как научиться начинать общение (использовать слова-ледоколы), какие бывают страхи при общении и как их преодолевать, как запоминать имена собеседников через аналогии, как соблюдать технику безопасности при общении с незнакомцами. Дальше авторы активно рассказывают про активное слушание и как оно помогает при общении, ведь у нас один рот и два уха, а это намекает на соотношение между говорением и слушанием. В финале авторы говорят про цели общения и соответствущее поведение, разбирают на бытовых примерах похода в магазин и поездки на поезде. Авторы предлагают подумать над сценарием общения и тем, что надо быть вежливым. Последняя часть посвящена онлайн-коммуникациям, но сейчас советы оттуда уже стали общепринятой нормой. 4. У всех на глазах Здесь авторы на пальцах объясняют правила публичных выступлений, куда входят части - цель и идея выступления, которые зависят от аудитории на которую мы планируем рассказывать - структура выступления - как подготовиться к самому выстулпению - как работать с вопросами аудитории В общем, это краткая но полезная глава про публичные выступления. #ForKids #ForParents #SelfDevelopment

Code of Architecture - Continuous Architecture in Practice - III Сегодня в 18:00 по Москве мы обсудим пятую и шестую главу книги Continuous Architecture in Practice. Эти главы посвящены вопросам scalability и performance. - в части про scalability мы погорим про архитектурные подходы к масштабированию stateless и stateful нагрузок - в части про performance мы обсудим почему производительность важна, как ее мониторить и что делать для повышения производительности вашего решения У нас будет два гостя: - Алексей Тарасов, который развивает архитектуру Тинькофф Инвестиций - Даниил Кулешов, архитектор новой системы авторизации для клиентов #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management