Энциклопедия менеджера. Алгоритмы эффективной работы 3rd edition (Fast Thinking Manager's Manual)

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

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

Каждый из алгоритмов расписан для трех вариантов, которые зависят от доступного времени, начиная с 1 дня на подготовку, проходя через 1 час и заканчивая 15 минутами. В общем и целом, эту книгу действительно можно использовать как энциклопедию. Я многие из этих тем познавал сам, изучая другие книги, посещая конференции, собирая шишки на практике и могу сказать, что качество советов в этой книге отличное. Рекомендую!

P.S.
В этой книге нет специфики относительно разработки программного обеспечения, но кажется, что это и не требуется:)

#Management #Leadership #Career #SelfDevelopment

Ряд наград в мобильном приложении Тинькофф

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

P.S.
Это игра от создателей Монополии, 5 букв и других игровых проектов в нашей экосистеме. Ребята - молодцы и растут в плане сложности проектов и игровых механик, которые они уже научились использовать в таких играх. Я помню с чего все начиналось и что мы умеем сейчас - это небо и земля. А дальше будет еще круче:)

Resilience как архитектурная характеристика (из книги Continuous Architecture in Practice)

Я уже упоминал несколько раз книгу "Continuous Architecture in Practice" как достойный изучения труд по архитектуре (посты: 1 и 2). А сегодня я решил поделиться кратким саммари того, как авторы подходят к устойчивости и надежности систем. Для начала авторы определяются с терминологией

- A fault is an accidental condition that, if encountered, may cause the system or a system component to fail to perform as required.
- A failure is when a system or system component deviates from its required behavior. So, a fault is something that has gone wrong and that may cause a failure to occur.
- Availability is a measurable quality attribute of a system, defined as the ratio of the time when the system is available to the overall time when it could have been available.
- Reliability builds on availability and adds the constraint of correct operation, not just availability. A widely used definition of the reliability of software is “the probability of failure-free software operation for a specified period of time in a specified environment.”

Дальше авторы рассказывают про старый подход к обеспечению надежности, который обычно назывался high-availability и был основан на создании кластеров приложений, кластеров баз данных, использования cross-site репликации данных. Суть подхода была в том, чтобы в случае проблем с одной из нод в кластере, рабочая нагрузка могла переехать на другую ноду. А если падал кластер целиком, то можно было перенести нагрузку в другой кластер, который всегда стоял наготове (hot standby), в котором уже были все (или большинство) данных, благодаря репликации данных. И все было бы хорошо с этим подходом, удобным для разработчиков приложений, но
- эти механизмы повышения доступности запутанны и сложны в использовании
- зачастую они достаточно дорогие (даже в плане работающего вхолостую hot standby)
- failover процессы могут занимать много времени и требовать много работы
- во время восстановления система может быть полностью недоступна
В общем, эти high-availability подходы были расчитаны на монолитные on-premise системы и плохо подходят для распределенных микросервисных систем, которые могут быть развернуты как on-premise, так и в облаках.

Дальше авторы переходят к resilience как другому подходу для обеспечения reliability. В этом подходе каждая часть системы сама отвечает за свой вклад в обеспечение общесистемной availability за счет адаптации своего поведения к происходящим faults, например, распознавая сбои и используя, повторные запросы, автоматический перезапуск процессов, ограничивая распространение ошибки, правильно работая с latency запросов. В итоге, инженерам стоит знать и использовать такие механизмы обеспечения надежности, а не надеяться на технологии обеспечения high-availability из прошлого. Если использовать их правильно, то итоговая система будет более устойчива к ошибкам и сбоям и сможет более гибко приспособиться к проблемам во время эксплуатации систем.

Интересно еще рассмотреть эти подходы в контексте стандартных показателей
- Mean time between failures (MTBF) - среднее время наработки на отказ
- Mean time to recover (MTTR) - среднее время восстановления

В подходе с high-availability предполагалось, что время между сбоями у нас большое и когда сбой все-таки случается, то мы просто задействуем механизмы high-availability. И когда-то это было неплохим подходом. Но в текущих условиях у нас сбои частей систем могут происходить достаточно часто и тут на сцену выходит MTTR и умение этих частей системы ограничивать blast radius проблемы и не влиять на общую reliability всей системы.

#SRE #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #SystemDesign #SystemThinking

Алексей Савватеев | Теория игр вокруг нас

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

P.S.
На тему теории игр еще можно почитать:
- "Теория игр в комиксах"
- "Теория игр. Искусство стратегического мышления в бизнесе и жизни"

#Thinking #Math #SelfDevelopment #PopularScience

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

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

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

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

Обзор white-paper "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google"

Одна из моих областей интересов — это проектирования сложных систем и построение архитектурных процессов. Несколько месяцев назад я нашел эту статью от ребят из Google, которая вышла в 2023 году. В этой статье авторы (Qin Jia, Yuanfang Cai, Onur Çakmak) рассказывают про структурированный процесс редизайна крупной системы (Monarch) с использованием сценариев атрибутов качества (quality attribute scenario), а также с использованием моделирования системы при помощи UML. Я прочитал эту статью на выходных и готов поделиться кратким обзором.

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #ExternalReview

The Engineering executive’s role in hiring от Will Larson

У Will Larson есть интересная рассылка, в которой он поднимает важные темы. И вот в конце августа он написал пост про то, как условные CTO и VP of Engineering могут участвовать в найме. Статья получилась большой, потому что это неотредактированная версия главы из новой книги Wll "The Engineering Executive’s Primer" (на сайте O'Reilly есть ранний доступ к этой книге, которую можно читать в процессе написания).

Но если возвращаться к статье, то в ней были рассмотрены следующие темы
- Как выстроить в общем процесс найма, включая описание позиций, цикла найма и т.д.
- Какова роль executives в мониторинге и дебаге процесса найма
- Как помогать финализировать найм ключевых кандидатов в вашей организации
- Как оценивать уровень кандидатов
- Как управлять headcount и что это ключевая часть управления наймом
- Как тренировать нанимающих менеджеров
- Как калибровать наем как извне, так и внутри, включая внутренних кандидатов
- Как оценивать и развивать инженерный бренд компании (что влияет на найм)
- Когда и как вводить комитет по найму
- Как помнить о том, что выстроенная система служит вам, а не наоборот

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

#Management #Leadership #Engineering #Software #SoftwareDevelopment

Architecture Anti-patterns: Automatically Detectable Violations of Design Principles (Рубрика #Architecture)

Эта статья посвящена интересной для меня теме architecture governance. В ней авторы рассказывают о своих подходах для автоматического нахождения архитектурных анти-паттернов в больших системах. Суть в том, что файлы, которые подвержены изменениям и ошибкам редко в таких системах живут поодиночке - обычно они архитектурно связаны и эти связи отображают архитектурные проблемы, которые приводят к распространению подверженности ошибкам. В этой статье авторы определяют набор антипаттернов, взяв за основу фундаментальные принципы дизайна и Baldwin and Clark’s design rule theory. Дальше они валидируют на опыте набор архитектурных анти-паттернов, которые можно автоматически находить анализируя структурные взаимоотношения в проекте, а также историю изменений. Для этого авторы проанализировали 19 крупномасштабрных системы и показали
1. Files involved in these architecture anti-patterns are more error-prone and change-prone;
2. The more anti-patterns a file is involved in, the more error-prone and change-prone it is; and
3. While all of our defined architecture anti-patterns contribute to file’s error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.

В итоге, у авторов получилось 6 антипаттернов:
1. Unstable Interface - интерфейсы, от которых многие зависят, должны оставаться стабильными
2. Modularity Violation Groups - независимые модули должны и эволюционировать независимо
3. Unhealthy Inheritance Hierarchy - этот антипаттерн про нарушение Liskov Substitution principle
4. Crossing - a file that has both high fan-in and high fan-out, and changes often together with its dependents and the files it depends on, is often at the center of maintenance activities.
5. Clique - набор файлов, которые формируют сильно-связный граф, что приводит к tight coupling между файлами (расширение истории с циклическими зависимостями)
6. Package Cycle - циклы в графах зависимостей, который нарушают базовые принципы дизайна для формирования иерархических структур. Такие нарушения приводят к тому, что изменения в файле одного package часто вызывают неожиданные изменения файлов в других пакетах из-за циклических зависимостей между ними.

Интересно, что я заинтересовался этим white-paper из-за статьи "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google", про которую я рассказывал пару дней назад. Суть в том, что там авторы анализировали кодовую базу Monarch, описанным в этой статье способом, и нашли много анти-паттернов в кодовой базе компонентав Leaves, на которых было слишком много ответственности и которые было сложно поддерживать. Дальше в прошлой статье они заредизайнили этот компонент для повышения availability и maintainability.

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems

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

Сегодня я выступаю на конференции "Стачка" с одноименным докладом и поэтому по традиции делюсь списком материалов

- "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 (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем
- "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, где мы проверяем на практике работу инженеров в рамках инцидента

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

Совершенствование потока разработки программного обеспечения (Improving software flow)

Появилась запись моего выступления в Казани с этим докладом, где я рассказываю о том, как разрабатывать программное обеспечение эффективно. И разбираю вопрос с точки зрения пяти идеалов из книги The Unicorn Project. А также рассказываю о том, как мы это используем у себя внутри Тинькофф.
Расшифровка доклада есть в моем блоге, а рекомендуемые материалы приведены ниже.

--------------------

4 основные книги, из которых родилась идея доклада
- The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта.
- The DevOps Handbook (2016 год) - книга с популяризацией devops подхода
- Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент.
- The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс

Связанные книги
- Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации.
- Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта.
- A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке.
- Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов
- SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них
- "Lean Software Development" - книга про lean практики в разработке

Исследования
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)

Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
- Эволюция подходов к развитию мобильного банка Тинькофф
- Эволюция web Tinkoff на ArchDays

#Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture