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

TeamLead Conf++ 2023

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

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

Материалы к докладу "Как 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

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