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

День рождения Насти

У моей любимой жены сегодня день рождения. За последний год она успела уйти с прошлой работы, решив сфокусироваться на учебе в Вышке. Правда, после старта магистратуры планы поменялись и Настя решила совмещать учебу с работой в качестве директора благотворительного фонда "Академия жизни", миссия которого звучит так

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

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

Информация о фонде
- годовой отчет фонда за 2022/2023
- telegram канал фонда
- группа вконтакте

#Charity

Архитектурные диаграммы с помощью LLMs (ChatGPT)

Ревьювил на выходных внутренние архитектурные документы и наткнулся на инструкцию о том как правильно писать RFC/ADR а также как можно визуализировать архитектурные диаграммы при помощи чатботов. Сама инструкция была дельной и выглядела так

Нарисуй на plantuml диаграмму

Есть postgres база. В ней есть таблица под названием XXX. Данные в эту табличку XXX пишет фронтенд YYY посредством обращения к бэкенду ZZZ, работающему с этой базой. Есть ETL процесс который перекладывает эту таблицу в clickhouse WWW, в таблицу VVV. При помощи Jupyter мы подключаемся к DWH и анализируем эту таблицу VVV

В принципе, таким макаром можно попросить LLM сгенерировать
- диаграммму классов, компонентную диаграмму, sequence или activity, если нам нужны UML диаграммы
- все виды диаграмм из C4 Model: Context, Containers, Components, and Code
- любые другие диаграммы: ER, DFD, IDEF, BPMN, ...

Правда, в этой инструкции авторы забыли, что на выходе из LLM иногда получается треш, а значит надо знать эти нотации самостоятельно и уметь их читать, а также желательно моделировать. В итоге, визуализировать с помощью ChatGPT конечно весело, но визуализация должна помогать + быть достаточно точной. А для того, чтобы проверить насколько она хороша, я бы рекомендовал не просто командовать чатботу, но еще изучить документацию пл моделированию, например, такую
- Стандарт по UML
- Документацию по platuml
- Документацию по C4 Model
- И любая другая документация по нужной вам нотации моделирования

Без таких базовых знаний сложно отвалидировать то, что выдала LLMка

#Software #SoftwareArchitecture #Architecture #Engineering #SoftwareDevelopment

Как RnD появляется в крупных IТ-компаниях

Вот и вышла запись моего выступления на конференции Teamlead++ в треке техлидов про появление research and development в крупных компаниях. В этом докладе я рассмотрел это на примерах компаний Google, Amazon, Yandex и Tinkoff. Причем сначала я показывал как выглядел рост компании, показывал как работает бизнес-модель (часто это была модель платформы с двухсторонним сетевым эффектом), а потом делал вывод, что такой экспоненциальный рост требовал ррешения большого количества технических вызовов. И разные компании к этим техническим вызовам подходили по разному
- Google многие из решенных проблем заворачивал в whitepaper, которые дали старт многим open-source проектам
- Amazon скорее делал техпродукты для себя, а потом начал их продавать в AWS, причем статьи были не про внутреннее устройство, а про то, как пользоваться этими продуктами
- Yandex часто рассказывал про свои решения, но деталей почти не было, но в 2016 году появился в open source ClickHouse, в 2017 - CatBoost, а в 2022 и 2023 публикаций стало много, среди которых самое интересное - YDB и Ytsauru, и это если говорить только про официальный open source от Yandex:)

У нас в Тинькофф все начиналось с использования коробочных продуктов, потом мы стали писать много своего кода, года 4 назад стартовала разработка своей IDP (internal developer platform) и кучи технологических продуктов:
- Managed K8s - целевой runtime для low-latency приложений
- LBaaS - балансировщик как сервис, который доводит трафик до приложений внутри Managed K8s
- DBaaS (Postgres, Cassandra, Redis) - целевые базы данных
- Kafka as a Service - платформа для messaging
- Sage - наша obsesrvabilty платформа (логи, метрики, алерты) со своим языком Mage и планом перехода с Elastic на новосозданную базу данных
- Statist и a/b платформа - общее решение для продуктовой аналитики и a/b тестов
- Куча инструментов внутри нашей data платформы - тут инструментов очень много
- и так далее

И сейчас у нас собирается RnD лаба для инженерных исследований, которой руководит Станислав Моисеев, а находится она в нашей платформе базовых технологий, которой руководит Игорь Маслов, директор этой платформы и VP. В общем и целом, для нас развитие RnD направления является стратегическим и если вы хотите заниматься инженерными исследованиями, то можете писать мне в личку, а я познакомлю вас со Стасом и Игорем:)

P.S.
В ближайший понедельник в 18.00 на стриме Code of Arcitecture мы поговорим про подходы к RnD в Google и расскажем как мы планируем это делать в Тинькофф. На стриме мы будем обсуждать это с Вовой Чистяковым, Игорем Масловым и Станиславом Моисеевым.

P.P.S.
Материалы к докладу
- Статья с расшифровкой - текстовая версия выступления, но без части про 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 #RnD #Leadership #Processes #Architecture #PlatformEngineering

ICPC Northern Eurasia Contests - победители

Не зря съездил на полуфинал ICPC - посмотрел как команда "Ёлки-палки" из МФТИ победила в соревнованиях второй год подряд. Ребята решили все задачи и выиграли очень уверенно. Ждем от них победы в финале ICPC.

#Software #Engineering

Designing A Data-Intensive Future: Expert Talk • Martin Kleppmann & Jesse Anderson • GOTO 2023

Это крутое интервью от топовых специалистов
- Мартина многие знают как автора классической книги с кабанчиком ("Designing Data-Intensive Applications"), сейчас он больше исследователь и занимается так называемым "Local-First Collaboration Software" (automerge) - подробнее можно посмотреть в выступлении Мартина, которое я разбирал месяц назад
- Jesse я узнал в качестве автора книги "Data Teams", а также автора интересного выступления "Why Most Data Projects Fail and How to Avoid It", про который я рассказывал 2 месяца назад
Оба участника превосходно шарят в теме разговора и их интересно слушать. Вот тут доступна расшифровка.

Ниже тезисно расскажу основные мысли
Мартин рассказывает про свою книгу "DDIA", котороя про основы работы с данными и широкий ландшафт технологических решений (на момент 10 лет назад, когда Мартин начинал писать книгу)
Мартин планирует написать второе издание книги, в котором он рассмотрим вопросы
- Рост популярности cloud-native приложений и разработку распределенных приложений слоями, когда одна распределенная система опирается на нижележащую распределенную систему и так далее - рекомендую про это подробнее прочитать в whitepaper от ребят из Google "Deployment Archetypes for Cloud Applications", про которую я рассказывал раньше
- Закат Map-Reduce, чью поляну забрали cloud DWH с точки зрения аналитики и стриминговые системы с точки зрения приложений с кастомной логикой
Мне нравится, что Мартин продолжить и во второй книге использовать подход

So I'm not telling people what to do, I'm telling people what questions to ask.

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

For example, you could run both consumers side by side for an amount of time, check the consistency across the two systems, and then eventually decide to switch over from the old one to the new one. Streaming systems allow that so much better than, for example, systems based on, like, doing calls to individual services. So I feel like, as you said, the streaming can help with making change easier there.

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

Дальше Мартин вспоминает про automerge, что я упоминал в начале и потом переходит на тему работы ученым и почему он переключился после 10 лет пребывания в стартапах на стезю ученого и как это позволяет ему лучше продумывать сложные идеи в области distributed systems. А также почему так мало PhD диссертаций превращаются в рабочие системы (значимое исключение Apache Flink).

Ну и напоследок участники дают советы
- Мартин: "I guess my recommendation would be to learn just enough about the internals of the systems that you're using so that you have a reasonably accurate mental model of what's going on there."
- Jesse: "There are a lot of paths out there. Pit's to look out the various paths, look at what you want to do and what your skills are and see if one of those applies to you", где приведены карьерные варианты: разработка, менеджмент, наука, консалтинг, devrel. И в зависимости от сильных сторон и предпочтений, стоит выбрать свой путь.

#Management #Data #Databases #SystemEngineering #DistributedSystems #Software #Architecture

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

Продолжу пост про структуру команд и проектный подход и в этом посте мы поговорим про продуктовую разработку. В прошлом посте я много говорил про полезность проектного подхода и возникает вопрос, а зачем нам нужна продуктовая разработка, если есть такие замечательные проекты. Но проекты хороши для старта новых инициатив или ведения кросс-командных активностей. А вот если мы хотим более планово и непрерывно поставлять ценность, то мы приходим к концепции продукта, где
- Есть конкретная целевая аудитория продукта
- Есть примерное понимание какие фичи, стори, JTBD (jobs to be done) мы хотим реализовать
- Есть желание выкатывать эти изменения небольшими порциями и тестировать как они работают
- Есть понимание, что план может гибко меняться в процессе движения
С таким набором ожиданий становится ясно, что проектный подход нам не подходит. В итоге, мы приходим к продуктовым процессам разработки, про которые я рассказывал в докладе "Совершенствование потока разработки программного обеспечения", где я рекомендовал почитать книгу "Making Work Visible" от Доминики Деграндис, про которую я писал раньше. Но вообще есть несколько подходов к тому как организовывать работу и планировать время ее выполнения. Однако важно помнить про ироничный закон Паркинсона

Работа заполняет время, отпущенное на неё

Этот закон дает понять почему планирование работы с буферными запасами проблема, а именно так часто планируют в проектном управлении. Но если планировать работу задач на команду в режиме push, то можно столкнуть с тем, что требования к командам и их производительность не сбалансированы, что не позволяет выполнить все задачи вовремя. В итоге, нам нужна система с pull режимом, когда люди вытягивают новую задачу по мере завершения предыдущей. Такой системой, например, является Kanban. Но важно понимать какие задачи попадают в такой процесс - важно не соглашаться на все подряд, а обдуманно давать добро только на самые важные в конкретный момент и делать это визуально. Для этого надо организовать систему рабочего потока, выполняющую следующие задачи
- Делает работу видимой
- Ограничивает количество незавершенной работы
- Оценивает рабочий поток и управляет им
- Эффективно определяет приоритеты
- Вносит коррективы на основе метрик и обратной связи

И проблема со временем и его утеканием обязана следующим пяти факторам
- Too WIP - история про незавершенную работу, бутылочное горлышко и закон Литтла.
- Unknown dependencies - здесь про архитектурные проблемы и зависимости между системами и разными командами.
- Unplanned work - незапланированная работа крадет время у запланированной. Этим она делает систему непредсказуемой, а главное для нас — это прогнозируемость и ожидания.
- Conflicting priorities - если все задачи приоритетные, то ни одну из них нельзя назвать реально важной. Без внятных приоритетов людям приходится пытаться сделать слишком много сразу, что автоматически приводит к росту WIP, который замедляет всю систему.
- Neglected work - часто такая работа проявляется в форме техдолга, который накапливался в системе, когда люди только клепали фичи без работы по повышению технического совершенства системы. Вообще, часто проседает важная но не срочная работа, которую так любят откладывать … пока она не перерастет в экстренную ситуацию, когда станет незапланированной работой, от которой нельзя отказаться.

В итоге, я всегда стремился выстроить продуктовые кросс-функциональные команды, используя Kanban подходы. В целевом виде эти команды являлись stream-aligned командами из Team topologies (подробнее в обзоре 1, 2, 3). Про то, как я строил продуктовую разработку я рассказывал в контексте нашего веба Tinkoff.ru в двух давних докладах
- Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения
- Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях

#Management #Leadership #Project #ProjectManagement #Software

Tinkoff TeamLead Meetup 1

Интересный митап на тему тимлидов от Тинькофф, которое прошло под знаменем наджености и в котором было 4 выступления по 20 минут + 10 минут на вопросы/ответы. Вот эти доклады

1) Как выиграть гонку с бизнесом на высоконагруженном сервисе, обеспечивая высокий уровень надежности
Выступление Владислава Хачатурова из Сбера на тему того, как выстроены внутренние процессы на самом высоконагруженном сервисе "Главный экран" для приложения Сбербанк Онлайн в условиях вечной гонки, с обеспечением высокой надежности. Тут много было про inner-source и как сделать платформенную команду, которая работает над архитектурой, надежностью, принимает сервисы в эксплуатацию от продуктовых команд, которые контрибьютят в сервисы платформенной команды.
2) Как мы падали и поднимались. И чему научились в процессе.
Выступление Ильи Барбашова из Авито, где он рассказывает про как в Авито захворали важные инфраструктурные сервисы (Kafka as a Servioce). А дальше как ребята изменили подход к оценке их надежности, и как это помогло планировать им работу и общаться с пользователями, которыми являются продуктовые разработчики.
3) Настройка окружения
Выступление Алексея Калакина из билайн, в котором он рассказал о проблемах взаимодействия с инфрой, и с интеграционно связанными приложениями. Он разобрал как настроить свзяь бизнеса и технических лидов, а также показал как решать это различными методами.
4) Стратегия управления техническим долгом
Выступление Никиты Ульшина из Тинькофф, в котором автоп рассказывает про то, откуда берётся техдолг, как он влияет на продуктивность и мотивацию команды, как правильно планировать работу над техдолгом и как избавиться от него. Дальше идет обсуждение приоритизации и того, как продавать результаты работы над техдолгом. Интересно, что Никита работает в команде, которая делает бекенд систему для нашего server driven UI для веб приложений, а про эти системы я уже раньше упоминал в других докладах:)

#Management #Engineering #Software #SoftwareDevelopment #Architecture #Processes #SRE #Leadership

Радость познания (The pleasure of finding things out) - 1

Эта книга составлена из выступлений Фейнмана на разных мероприятиях, зачастую перед студентами или другими учеными. Часть из этих выступлений не публиковалась раньше, поэтому книгу я читал с большим интересом. В отличие от книги "Вы, конечно, шутите, мистер Фейнман", про которую я рассказывал раньше, эта книга предполагает вдумчивое чтение, интерес читателя к науке и научному подходу к познанию окружающего мира, а также готовность подвергать все сомнению:)

А теперь немного про содержание книги

1. Радость познания сути вещей - статья, что дала название всей книге. В ней мы видим как подход к познанию Ричарда сформировался под влиянием отца, который не учил терминам или теориям, а учил наблюдать за окружающим и видеть суть и взаимосвязи. Мне особенно понравилось познание через аналогии ака "тиранозавр в окне" (смотри на эту тему рекомендую "Большую книгу аналогий") и разбор алгебры для практичного человека, где Ричард рассказывает про инструкции из школы про решение задач как "целый набор шагов, с помощью которых вы могли бы получить ответ, если не понимаете, что вы пытаетесь сделать". Остальная часть статьи тоже очень интересна, не даром она идет первой в книге.
2. Компьютеры будущего - в этой статье Ричард выступает провидцем и говорит о параллельных компьютерах и их миниатюризации. Достаточно интересно обсуждался вопрос обратимых и необратимых вычислений и связи скорости вычислений с потреблением энергии. Все это рассматривается не с позиции технических возможностей почти сорокалетней давности (лекция 1985 года), а скорее с точки зрения концептуальных возможностей и того, что это видение не противоречит существующим физическим законам
3. Лос-Аламос - взгляд снизу - это рассказ про времена Фейнмана в Лос-Аламосе и участие в Манхэттенском проекте. В принципе, это все обсуждалось и в уже упоминавшейся книге "Вы, конечно, шутите ..."
4. В чем состоит и в чем должна состоять роль научной культуры в жизни общества - здесь Ричард рассказывает про научный подход, выдвижение гипотез и теорий, их полезность и фальсифицируемость. Он верит в то, что и жизнь общества должна идти по пути, похожему на научный - "всегда нужно оставлять место сомнениям, дискуссиям" и что "придет время, когда люди полностью осознают, что сила власти ограничена, что правительства не уполномочены решать вопрос, ценна ли научная теория или нет ... Они не должны присваивать себе право делать выбор между различными версиями описания истории, экономической теории или философии"
5. Как много места в глубине - в 1959 году Фейнман в Калтехе рассказывал про нанотехнологии - это было провидческое выступление, где он упоминал про: хранение информации, аналог фотолитографии, выстраивание атомов для создания новых материалов. В конце он устроил конкурс по миниатюризации, который в итоге превратился в премию Фейнмана по нанотехнологиям
6. Ценность науки - лекция в формате урока для молодых ученых о том, что они несут ответственность за будущее цивилизации
7. Особое мнение Ричарда Фейнмана, касающееся следствия по делу космического корабля-челнока "Челленджер" - если говорить на it'шном, то Ричард участвовал в написании постмортема по инциденту с "Челленджер", но его мнение не хотели учитывать в официальном отчете, поэтому он написал свое "особое мнение" и добился включения его в официальный отчет (в приложении)

P.S.
Продолжение разбора в следующем посте.

#PopularScience #Physics #Biography

На корпоративе коллеги пошутили со сцены, представляя меня, что в 2024 году

Александ Поломодов научится читать книги быстрее, чем авторы их писать

С учетом плана написания своей книги, это очень вероятно:)

#Humour