Книжный куб

ЦЕХ 4 - Урок #1 "Увидеть свое имя на обложке может каждый" На прошлой неделе прошел первый вводный урок курса для начинающих авторов, что планируют написать и издать книгу:) Этот урок напоминал самосбывающее пророчество, которое должно было вдохновить участников и вселить в них уверенность в своих силах. Екатерина Звонцова и Ренат Шагабутдинов одновременно рассказывали и про non-fiction и про художественную литературу. Были рассмотрены следующие темы 1) Как начать писать книгу - авторы блогов и статей могут начать собирать книгу из своих материалов уже опубликованных в блоге (я так и планирую сделать). Но даже если у вас нет блога, но есть соцсети, то можно поискать в своих постах материалы для старта, чтобы не сталкиваться с эффектом пустой страницы. Если мы говорим про художественную книгу, то начинать стоит когда в голову пришла идея сюжета или персонажей, которыми вы хотите поделиться с другими или поднять важную проблему. Но тут важно выбирать персонажей и тему, которая интересна как вам, так и читателю. 2) Зачем писать книгу - написание книги может помочь структурировать мысли, поделиться опытом, передать свою философию (примерно поэтому я пишу статьи и хочу написать книгу). Отдельно эксперты курса отмечают, что написание книги может быть способом стать экспертом в своей области и повысить свой статус. Но тут важно разбираться в теме, которую вы исследуете, чтобы лучше ее преподнести другим. А вот художественные книги могут помочь автору осмыслить свой опыт и преподнести его так, чтобы он обладал терапевтическим эффектом для читателей, которые тоже переживают сложный период 3) Написание книги позволяет научиться чему-то новому и творческому - через творчество автор может узнать что-то новое и интересное, а также это может быть способом общения с миром. Это может помочь найти своих единомышленников и сформировать сообщество вокруг себя. 4) Про успех - даже если успех приходит к автору, то не стоит ожидать мгновенных результатов. Важно продолжать работать над своими навыками и повышать свои шансы на успех. Часто здесь работает подход накопления авторитета - сначала автор работает на зачетку, которая затем работает на автора:) Факторами успеха могут быть: экспертиза, платформа, харизма, начитанность, структурированность текста, юмор, примеры, иллюстрации. Классно, если случается вирусный эффект: сарафанное радио, рекомендации книги другим. Иногда визуальное оформление и обложка книги тоже влияет на успех книги. 5) Самозванец и критик - Эксперты рассказывают про то, что с ростом знания темы растет осознание того, как много еще не известно. Поэтому даже у экспертов есть синдром самозванца (правда, эксперты умеют его преодолевать). Другая история основана на "проклятии знания", когда экспертам сложно передавать свои знания, так как для них все очевидно и не ясно зачем разжевывать материал (а всем остальным почти ничего не ясно). 6) Страхи и сомнения начинающих авторов - здесь эксперты говоят о том, что даже если вы не являетесь "небожителем", вы все равно можете добиться успеха, если будете развиваться и двигаться вперед. Причем если вы уже задумываетесь о проблемах и осознаете их, то вы уже на правильном пути. 7) Уникальность темы книги - есть мнение, что все уже написано до нас ... Но всегда можно найти свое и написать уникальную книгу на стыке двух тем, которые могут быть обычны и тривиальны. Кроме того, можно написать книгу под конкретных читателей, которые могут быть разными по уровню знаний и интересам. В общем, наличие уже написанных книг на выбранныю тему - это не приговор, а скорее хороший знак - люди интересуются этой темой:) Продолжение обзора урока в следующем посте. #Writing #SelfDevelopment #Management

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part II Начало обзора этого выступления есть в первом посте. А здесь надо еще расскаать про использование регулярных опросов разработчиков, чтобы узнать их мнение о различных аспектах работы. Результаты опроса помогают определить области, требующие улучшения и обсудить их с командой. В Atlassian команды используют 10% времени для исправления ошибок и улучшения производительности разработчиков. Некоторые команды проводят "week of developer joy", а другие включают планирование в спринт и работают над проблемами производительности. А также команды распространяют знания и делятся с коллегами полученными выводами - например, команда создала пост в блоге о своем решении проблемы и его использовании в других командах. В заключении автор подводит итоги и говорит, что - Измерения и результаты опроса могут помочь определить, что нужно сделать для улучшения качества разработчиков и их прогресса. - Автономные команды могут работать над улучшением качества и ценности, которую они создают для компании и клиентов. - Важно получать удовольствие от своей работы и создавать вещи, которые действительно могут быть использованы клиентами. P.S. На похожую тему я размышлял в постах про developer productivity: 1, 2 и 3. #Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part I Интересное выступление от Sven Peters из Atlassian на тему developer productivity, developer experience и developer joy:) Автор начинает с того, что возвращается в прошлое и вспоминает про Тейлора и его научный подход к менеджменту на заводе. Правда, там выполнялась однотипная работа на конвейере, но за счет измерения времени выполнения разных активностей Тейлор смог оптимизируя инструменты, время на отдых и другие вещи повысить эффективность завода в разы. Но сейчас в информационный век многие хотят научиться также повышать эффективность разработки, но разработка сейчас достаточно сложна и software development engineer должен уметь работать над quality, работать в облаке, деплоить и эксплатировать свое решение (you build it, you run it). Я говорил про эту же проблему в своем подкасте "Software development engineers в tech компаниях". Но автор предлагает уйти от термина developer productivity к developer joy и разобраться с тем, что делает работу разработчиков приятной и продуктивной и туда попадает - Dev quality - качество кодовой базы, архитектуры, отсутствие техдолга - Dev progress - темп разработки и поставки фичей - Dev value - какую пользу приносят поставленные фичи Автор рассказывает на примерах из разных команд - Команда Jira написала code of conduct для проведения ревью кода - Команда Confluence, которая написала инструмент для поиска нестабильных (флакающих) тестов во время прогонов - Команда Confluence написала бота для пушинга участвующих в code review - это уменьшило среднее время ревью PR с 3 дней до 1.2 дня Дальше автор рассказывает про зависимости между командами, что тормозят разработку. Он делает это на примере того, как разные развязки на дорогах влияют на пропускную способность шоссе. Когда мы делаем нормальные развязки, которые позволяют машинам не мешать друг другу, то мы получаем максимальный traffic flow. Этим автор обосновывает стремление к автономным командам. А дальше он рассказывает про команду Trello, где на 1 qa инженера приходится 30 software development engineer. В итоге, сами sde забирают на себя большую часть стандартных функций qa-инженеров, а потому не ждут пока qa-инженеры протестируют их фичи. Плюс автор рассказывает про подход с блиц тестированием, когда вся команда тестирует критически важную функцию. Забавно, что оставшиеся qa-инженеры отвечают за qa-тулинг, тестовые данные, базы и так далее. Продолжается история тем, что разработчикам надо понимать dev value - Инженеры (sde) и продакт менеджеры должны работать вместе над одним и тем же делом - Инженеры (sde) должны быть вовлечены в процесс создания и понимать проблему, которую нужно решить - Стоит использовать демо, которые важны для всех команд, они помогают увидеть результат и ценность, которую создают для клиентов Дальше идет речь про измерение производительности и улучшение показателей - Как помним еще Тейлор говорил о важности измерения производительности труда - Если у вас ничего нет, то стоит начать с метрик DORA - А дальше стоит начать использовать свой собственный инструмент для базовых показателей отслеживания прогресса - Раньше в офисах раньше были настенные панели и телевизоры, на которых можно было видеть состояние сборки и тестов. - Сейчас используются проверки, которые помогают определить проблемы и улучшить показатели. Автор рекомендует использовать разметку задач и оценивать время, которое команда тратит - На change бизнеса - На keep the lights on (поддержание работы) - На поддержание эффективности разработки и улучшение developer productivity

Code of Leadership #10 - An Elegant Puzzle - System of Engineering Management (часть 2) В десятом выпуске Code of Leadership заканчивается обсуждение крутой книги "An Elegant Puzzle: Systems of Engineering Management" (начало в выпуске 9), про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management. Книгу мы продолжаем разбирать с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения. В этом выпуске только вторая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за 2 часа мы успели обсудить все темы со второй половины третьей части по окончание книги, а точнее 3. Tools - как проводить инженерную реорганизацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем 4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации 5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста 6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций 7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам #Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) Эта книга подойдет даже новичкам - авторы отлично постарались, чтобы донести основы статистики максимально просто, с минимумом формул и максимумом смысла. Если вы когда-то слышали магические слова навроде a/b тесты, статзначимость, t-критерий, p-value и хотели понять что именно это значит, то эта книга для вас. Если вы знаете теорвер, матстаты, матанализ, то вам будет проще следить за мыслью авторов, но даже без этого эта книга позволит вам начать чувствовать bullshit, который иногда показывают под видом отличного эксперимента. В общем, в эпоху повсеметного data-driven эта книга всего в 150+ страниц очень хороша:) Она доступна бесплатно на сайте издательства Springer. Сама книга состоит из 3 частей и 12 глав I - Принципы статистики - эта часть must read для людей, что используют статистику для принятия решений 1 - Основы теории вероятностей - авторы говорят про вероятность, распределение вероятностей, условную вероятность и концепцию независимых событий. Дальше рассматривается вариант анализа на некоторую болезнь и дальше вводятся термины чувствительность (sensivity), специфичность (specificity), частота ложноположительных результатов (false positive rate) и частота ложноотрицательных результатов (miss rate). Дальше автор показывает как это все работает вместе и почему даже врачи не всегда понимают статистику:) 2 - Планирование эксперимента и основы статистики: теория обнаружения сигналов - авторы идут от signal detection theory и на примере желтой подводной лодки и эхолокаторов показывают как выглядит дизайн эксперимента и принятие решения. По-факту, у нас есть различимость сигнала и шума, а также некоторый порог принятия решений. В итоге, процент верных решений смешивает их вместе. Этот вывод дальше авторы показывают в части про t-критерий, где размер эффекта смешан с размером выборки:) 3 - Главная концепция статистики - здесь авторы рассказывает про канонический подход к статистике, обсуждают статистику для выборочного среднего, а дальше показывают как можно сравнивать выборочные средние при помощи одностороннего и двухстороннего t-критерия. Дальше авторы показывают, что в стандартном тесте p-value контролирует частоту ошибок первого типа или false positive, когда мы находим эффект, а его нет. Еще интереснее обсуждение рассчета мощности эксперимента, который говорит про вероятность получить значимый результат, если альтернативная гипотеза верна (то есть средние в наших совокупностях отличаются). Концепция мощности нужна в дальнейших главах, особенно в третей части книги. А вообще самая сочная часть этой главы - это следствия в конце, которые напрямую влияют на дизайн экспериментов и говорят про размер выборки, размер эффекта, нулевые результаты и так далее 4 - Вариации на тему t-критерия - это глава со звездочкой относительно третей главы, где рассматривался обычный t-критерий II - Множественная проверка гипотез - очень интересная часть, про то, насколько сложно задизайнить правильный эксперимент с множественной проверкой гипотез 5 - Задача множественной проверки гипотез 6 - Дисперсионный анализ (ANOVA) 7 - Планирование эксперимента: подгонка модели, мощность и сложные планы - очень важная глава для практика-экспериментатора, где авторы делятся правильной методикой и показывают на примере как можно отстрелить себе обе ноги и не только 8 - Корреляции - сравнение t-критерия, ANOVA и стандартной истории с поиском корреляций между относительными переменными (в ANOVA у нас независимые переменные номинальные) III - Метаанализ и кризис науки - эту часть интересно прочитать ученым и тем, кто любит читать статьи английских ученых:) Тут авторы на пальцах показывают как в погоне за результатами авторы исследований публикуют слишком хорошие результаты, чтобы они были правдой:) 9 - Метаанализ 10 - Воспроизводимость 11 - Величины избыточного успеха 12 - Предлагаемые улучшения и нерешенные проблемы #Math #Statistics #PopularScience #Science #ML #Data

Node.js: The Documentary | An origin story Вчера на канале Honeypot вышел часовой документальный фильм про историю создания Node.js. История начинается в 2008 году, когда javascript был технологий для написания кода на фронте и исполнения его в браузере. Но потом появился движок Google V8 и Ryan Dahl соединил идею неблокирующих сервисов, javascript и запуска этого в V8. Так появился Node.js. Он рос и развивался под руководством Ryan, но в какой-то момент Joyent Inc решило предложить Ryan денег и выкупить права на trademark Node.js, а также начать руководить этим open source проектом. Ryan согласился и успешно проработал в компании Joyent пока у него не завестились все обещанные плюшки, а потом он передал проект Isaac Schlueter, который когда-то создал npm, менеджер пакетов для Node.js. Дальше эта история закрутилась и привела к ситуации, когда community из ранних контрибьюторов node.js решило форкнуть проект, чтобы развивать его параллельно Joyent ... А как закончилась эта история вы узнаете из самого фильма:) P.S. Это интересная история про динамику взаимоотношений внутри open source проектов. Зачастую сложно обеспечить баланс между желаниями core контрибьюторов, запросами community, а также компанией, из которой вышел open source продукт или которая его купила на ранней стадии. В итоге, при неаккуратном развитии событий легко словить split brain и получить вместо единства кучу отдельных форков, что эффективно приводит к падению популярности технологии и скорости инноваций в mainline технологии (так как инновации теперь кусочно распределены между форками). #OpenSource #Management #Leadership #Engineering #Software

Patterns of Distributed Systems • Unmesh Joshi & James Lewis • GOTO 2024 Крутое интервью Unmesh Joshi, автора книги "Patterns of Distributed Systems". Расшифровка доступна здесь. Общение состоит из следующих моментов - Unraveling the Foundations: A Patterns-Based Exploration Автор книги рассказывает про свой путь как инженера и как он дошел до жизни такой, что написал книгу про паттерны распределенных систем. Мне особенно понравилось как Unmesh рассказывает про изучение реальных распределенных систем (Akka, Kafka, Cassandra, ...), в которых автор находил практические реализации тех концепций, что обычно описаны в whitepapers. Например, в интервью обсуждается часы Лампорта и whitepapers Барбары Лисков (ее принцип отвечает за букву L в акрониме SOLID). В общем, я бы сам с удовольствием поковырялся в реальных технологиях и попробовал сравнить как теоретические концепции реализуются на практике в разных системах и на какие trade-offs идут авторы этих систем - Should Every Software Developer Should Understand Distributed Systems? В общем, ответ да:) Но точка зрения зависит от контекста. Условные микросервисы - это тоже распределенная система. Но фокус автора книги был на данных и поддержании их консистентности на многих серверах и он фокусировался на работе систем аля Kafka, Cassandra, Amazon S3, Cosmos DB. - Comparing Patterns: Raft and Paxos Здесь ребята обсуждают модели консенсуса - они говорят про 1) Paxos, который предложил уже упоминавшийся Лампорт 2) Raft, одним из соавторов которого был Джон Остерхут, чью книгу "A Philosophy of Software Design" я уже рассказывал в постах: 1 и 2 Тут авторы вспоминают про CAP теорему (я про нее рассказывал), не вспоминают про ее расшширение в виде PACELC (я про нее рассказывал), вспоминают Jepsen с его тестированием гарантий производителей баз данных и проверкой их соответстия моделям консистентности (про них я тоже рассказывал). В обсуждении они говорят про время и вспоминают про TrueTime от Google и гибридные часы в MongoDB, YugabyteDB и CockroachDB. - Why Are Patterns Useful? Пользу от паттернов лучше описать словами автора книги

One of the goals for these patterns work as well is that someone reading this material should be able to navigate open-source code bases. And I think navigating, I mean, following open-source products and going through their code bases, trying out, maybe isolating some pieces of it and playing with it, I think that's a great way to learn about distribution. I mean, particularly topics like distributed systems, it's a great way to learn because if you go down the route of theoretical understanding, I mean, there are a lot of nice books, I would say, but you might get lost. So I think it helps a lot to remain closer to code while you are learning stuff.

- Conclusion Напоследок ребята подводят итоги и James пытается выяснить творческие планы у Unmesh, который планирует продолжать работу над паттернами, а также начать проводить воркшопы на эти темы. Думаю, что я бы на такой воркшоп бы записался:) Ну и обязательно прочту эту книгу - автор мне ее продал в этом интервью. #Software #Architecture #DistributedSystems #SystemDesign #Patterns #Engineering

ЦЕХ № 4 от МИФ На этой неделе у меня началось обучение на "курсе для тех, кто мечтает издать книгу". У меня это сейчас не на уровне мечты, а скорее на уровне задачи на этот год:) Я себя подписал на это еще в октябре 2023, о чем рассказывал раньше, а теперь пришло время начать учиться:) В итоге, вчера я почитал материалы и посмотрел первый урок в записи, так как письмо о начале курса попало в папку с рассылками от МИФа про книги, о чем я узнал постфактум:) В итоге, первый урок был посвящен - Знакомству с экспертами курса - нам показывли иконостас в виде тех редакторов и авторов, которые будут читать нам лекции - Рассказу про программу, формат и правила обучения на курсе - Рекомендациям по прохождению уроков и выполнению домашних заданий - Рассказу об условиях участия в конкурсе на издание книги в МИФе Надеюсь, что следующие уроки я смогу посмотреть не в записи:) P.S. По плану к концу лета у меня должна быть готова как минимум одна книга:) #Writing #SelfDevelopment

Statist — платформа продуктовой аналитики У нас на tinkoff.ru появилась статья про нашу платформу продуктовой аналитики Statist, которую мы обсуждали с Андреем Цыбиным в выпуске Code of Leadership #8. Собственно статью написал как раз сам Андрей. Если рассказывать кратко, то Statist - это единая платформа Тинькофф для сбора продуктовой аналитики и телеметрии с мобильных и веб-приложений - позволяет собирать, обрабатывать и визуализировать данные как о поведении клиентов, так и о технических деталях работы приложений - дает возможность отслеживать изменения в продукте, искать инсайты в UX приложений, реагировать на сбои - позволяет использовать практики data governance, а точнее разметить событиями метаданными и разделить их по клиентским приложениям, их версиям и так далее В итоге, мы можем принимать решения о развитии продуктов Тинькофф на основе данных, полученных и проанализированных при помощи Statist. Аминь! #Analytics #Architecture #DistributedSystems

Infobesity - How to Cope with the Overload of Information • Fabio Nudge • YOW! 2023 Интересный доклад про инфоожирение (или информационное ожирение) от Fabio Nudge, который написал книгу "Digital nudge". Рассказ Фабио состоит из следующих частей - Автор вспоминает про поведенческую экономику и рекомендует книги "Thinking Fast & Slow", "Predictably Irrational", "Nudge" (а также дополнительно еще три: "Building a Second Brain", "A World Without Email", "Make time") - Показывает как работают nudges на примере ранжирования поисковых ответов, а также streaks из snapchat, duolingo - Дискутирует относительно того, чем отличается push от nudges. Тут он показывает тизер сериала "The push" от Netflix, а дальше говорит, что nudge - это когда человек может отказаться от предложения:) - Потом опять идет отсылка, но уже к книге "Hooked" и моделе trigger -> action -> variable reward -> investment -> trigger -> ... - И дальше рассказывает про убеждение (persuasion) и принуждение (coercion), которые похожи, но в убеждении это то, чего хотят и то, что нужно людям, а вот в принуждении наоборот - Как пример автор показывает кусочек выступления сооснователя Duolingo "How to make learning as addictive as social media", а конкретно Фаби показывает часть про streaks - Ну и потом начинается история про избыточность информации и то, как нас ей заваливает со всех сторон - Он сравнивает это изобилие с изобилием еды, что нам доступна сейчас. Но наш мозг развивался в условиях недостатка пищи, поэтому когда мы снабжаем его пищей, то он вознаграждает нас за это ... даже если это четвертая шоколадка за день. А это легко приводит к ожирению. Ну а по отношению к информации это приводит к infobesity - А дальше автор переходит к советам о том, как блюсти цифровую диету и говорит

Being aware of your sources of dopamine and understanding what’s good and bad for you is one of the best tools to fight infobesity.

- Автор рассказывает про проект "Cognitive Loadometer" для измерения когнитивной нагрузки на команды - Дальше говорит про модель push и pull - смысл в том, что иногда в нас пушат информацию (например, присылают emails), но потреблять информацию удобнее по моделе pull - так мы можем контролировать ситуацию (фильтровать сообщения, потреблять асинхронно, когда нам удобнее, etc) - Автор показывает как можно использовать фильтры в почте, чтобы отфильтровать только важное (для этого он использует labels и дальше фильтры по булевым выражениям с ними) - Дальше автор показывает группировку вкладок в Chrome для объединение вкладок по контексту и переключения между ними - Заканчивается выступление упоминанием BMI (body mass index), который используют как метрику ожирения. А дальше Фабио предлагает пройти опрос и померить свой infobesity вес, заполнив форму в Google forms и прочитав расшифровку результата на сайте книги В общем, доклад реально интересный и многие советы реально полезны:) P.S. Больше года назад я рассказывал про другой доклад Фабио "The Psychology of UX", который можно считать предысторией к докладу про "Infobesity" #Conference #PopularScience #Software #UX #Economics #Psychology

Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • YOW! 2023 Крутое выступление от Jez Humble про то, как определять, что проблемы есть у платформы, а не у потребителей, которые ей пользуются. Jez сейчас работает SRE в serverless платформе Google, у которой большое количество клиентов с разным профилем нагрузки, разными показателями latency и так далее. В такой конфигурации есть проблема в отделении проблем клиентских нагрузок от проблем самой платформы. Но ребята в Google справились с этим, используя знания математической статистики. Если формулировать точнее, то цель была такая

A metric that represents the customer experience - Combinable across projects / cells / regions - Can be used to detect anomalies affecting multiple customers (likely platform issues) - Computationally cheap (high QPS) - Principle-based

Дальше автор говорит про три столпа reliability: - Availability - здесь основа в том, чтобы посчитать количество (долю) неуспешных запросов. Ситуация осложняется тем, что есть некая субъективность в ошибках (куча 400х и 500х ошибок, которые задаются самими владельцами пользовательских нагрузок), возможны ошибки из-за нарушенных deadlines, могут просто с ошибками плохо сформированные запросы от клиентов, retries могут усиливать количество ошибок - Performance - здесь автор говорит про установку P99 latency SLO и создании проберов. Но есть проблемы с зависимостями между нагрузками и тем, что проберы могут быть слишком узкими - Correctness - здесь есть много тестов и анализ канареечных развертываний, но проблема с тем, что покрытие ограничено Дальше авторы говорят, что можно попробовать построить функцию распределения для пользовательских нагрузок (например, log-normal), а дальше они говорят о том, что пользовательские нагрузки можно считать стационарными. А дальше они используют метод двух сигм и формулируют гипотезу

Hypothesis: Self-Similar Workloads Should Have Consistent Performance Technique Overview: - Partition workloads into Cohorts ← Approximate Intent via Workload Features - Build Performance Baselines ← Estimate Distributional Form (e.g. Normal) - Estimate Likelihood of Delivered Performance ← Test For Stationary Result: - Set of Events with Predicted Likelihoods - Time-series of summary statistics describing concentration of extreme outliers

А дальше стратегия использования в том, чтобы - Рассчитать z-scores среди нагрузок по кагортам, где z-scores = (observed-workloads - baseline-mean) / baseline-std - Отслеживать долю нагрузок, у которых z-score ≥ 2 в выбранном временном окне - Считать, что 2-5% процентов нагрузок с 2𝜎 отклонениями нормой - Тригерриться, когда этот показатель будет выше 10% В самом докладе есть еще много интересных моментов о том, как это работает и почему, но важен вывод, что такой подход позволяет надежно детектировать и измерять влияние на пользовательские нагрузки проблем на самой платформе. P.S. Мне нравятся материалы Джеза, которые бывают как в печатном виде, так и в виде докладов. Раньше я уже рассказывал про - Книгу "Accelerate" 2018 года, где Jez выступал в качестве соавтора. Подробнее в постах 1, 2, 3. - Книгу "Continuous Delivery" 2010 года, которая была важной вехой в развитии CI/CD. Подробнее в посте - Этот же доклад, но на конференции goto в 2023 году - Доклад Expert Talk: The Current State of Software Engineering • Jez Humble & Holly Cummins • GOTO 2023 - Доклад "How to Improve Developer Productivity • Jez Humble • YOW! 2020" #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Math #ContinuousDelivery

История будущего. Что ждет Землю, Вселенную и человечество миллиарды лет спустя Очень красивая и захватывающая книга для школьников по тому, что ждет нашу Землю, наше Солнце, нашу галактику Млечный Путь и нашу Вселенную в будущем. Когда-то давно я был школьником и сам с удовольствием зачитывался в библиотеками историями про рождение вселенной, появление звезд и других интересных объектов желательно со изюминкой: - гигантов, что живут быстро и заканчивают свою жизнь красочно - белых карликов, что превращаются в ледяной сверхплотный шарик через триллионы лет - пульсаров, которые как бы отбивают период - квазаров, что похожи на звезду, но являются ядрами галактик - черных дыр, концепция которых сложно заходит школьнику, но притягивает и как бы предлагает заглянуть за горизонт событий В общем, в этой книге все идет не от того, что мы видим в небе, а скорее от нашей любимой колыбели, в которой нельзя оставаться жить вечно (переиначивая Циолковского). Поэтому содержимое книги разбито на главвы - Зима близко (50 тысяч лет вперед) - Лето Неопангеи (250 миллионов лет вперед) - Бегство с суши (500 миллионов лет вперед) - Превращение в Венеру (1 миллиард лет назад) - Новый дом - Млекомеда (Млечный Путь + Андромеда) (4 миллиарда лет вперед) - Гигант по имени Солнце (6 миллиардов лет вперед) - Карлик по имени Солнце (8 миллиардов лет вперед) - Календарь космоса (триллион лет вперед) - О людях и вселенных Я очень рекомендую книгу родителям, которые хотят показать своим детям красоту науки и заинтересовать их окружающим миром:) P.S. Спасибо за книгу авторам: Антону Нелихову и Андрею Атучину, а также научному редактору, Владимиру Сурдину. #Physics #Astronomy #PopularScience #ForKids #ForParents #SelfDevelopment

Code of Leadership 9 - An Elegant Puzzle - System of Engineering Management (часть 1) Девятый выпуск Code of Leadership посвящен обсуждению крутой книги "An Elegant Puzzle: Systems of Engineering Management", про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management. Саму книгу я обсуждаю с Eugene Sergueev, senior engineering manager во Flo health, приложение для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения. В этом выпуске только первая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за час мы успели поговорить про книгу в общем и обсудить полностью вторую главу и часть третьей главы книги: 2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех 3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как драйвить технические миграции. #Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

1984. Графический роман Я читал роман Джорджа Оруэлла несколько раз, но когда появилась графическая версия от Нести Фидо, то решил обязательно прочитать и ее ... и я не прогадал. Изумительные иллюстрации отлично передают мрачный мир Океании, а точнее Лондона. Мы видим жизнь главного героя, Уинстона Смита, которая проходит в стенах Министерства Правды, где он занимается фальсификацией исторических документов, которые содержат факты, противоречащие партийной пропаганде. Для этого он элегантно использует новояз и практикует двоемыслие. Графический роман следует палитре автора и мы видим черно-белый мир, в который местами вторгается ярко-красный цвет, подсвечивающий те места, которые выделял сам автор. В общем, мне этот графический роман понравился - он верно передает всю канву и очень динамичен, что, возможно, и отличает его от полноценной книги, где мы можем глубже погрузиться в мысли и чувства главных героев. Зато графическое исполнение позволяет воображению зацепиться за отрисованные картинки и самому достроить давящее окружение, а под конец почувствовать как главный герой сходит с ума от пыток и давления. Ну и напоследок пара золотых цитат из романа

Война - это мир, свобода - это рабство, незнание - сила. Тот, кто управляет прошлым, управляет будущим. Тот, кто управляет настоящим, управляет прошлым.

P.S. Интересно, что даже в графическом романе у нас остались 2 больших по объему текста: - Главы из книги Эммануэля Голдстейна, который когда-то был почти равен Большому Брату, но потом предал идеи партии, сбежал за границу и стал врагом номер один и лидером тайного Братства (считается, что прообразом был Лев Троцкий) - Приложение "О новоязе", в котором рассказывается про сам новый язык, который партия использовала для того, чтобы сузить границы мышления и выкинуть из самого языка слова, которые могут приводить к мыслепреступлениям. Это приложение еще интереснее читать, если прочитать перед этим книгу Александра Пиперски "Конструирование языков", про которую я рассказывал в 2 постах: 1 и 2 #SciFi #Dystopia

Software development engineers в tech компаниях Вчера я выступал на конференции с докладом для студентов про современные ожидания от software development engineers в технологических компаниях. Само выступление в виде трансляции будет еще не скоро, поэтому я ближе к ночи записал выпуск подкаста и выложил на свой youtube канал TellMeAboutTech:) Подробнее про темы выступления во вчерашнем посте и там же есть список рекомендованных материалов. #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

The 12 Factor App for Data • James Bowkett • GOTO 2023 Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал -> Architecture & Design - факторы, относящиеся к проектированию решений 1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее. 2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel. 3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать 4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей 5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией) -> Quality & Validation - факторы, относящиеся к качеству данных и валидации 6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery) 7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами -> Audit & Explainability 8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas 9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только -> Consumption 10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных) 11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей 12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven. #Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Как выглядит роль SDE в tech компаниях Сегодня выступаю на нашем мероприятии для студентов из МФТИ, где я учился много лет назад. У меня есть полчаса и я планировал обсудить кучу тем: - Современные процессы разработки и инженерные практики в российских tech компаниях - расскажу про то, как все начиналось, потом появилась история с devops, потом shift-left everything и X+Ops:) - Как выглядит карьерный путь SDE (software development engineer) с развилкой в менеджмент и путь individual contributor высоких грейдов - Как выглядит матрица компетенций для SDE в Tinkoff - Как выглядит процесс роста сотрудников внутри (Tinkoff рост) - И другие полезные мысли про саморазвитие и рост внутри компании: -- Как использование Cynefin фреймворка -- Как работать над сложной проблемой (и создавать артефакты RFC/ADR) -- Как приоритизировать задачи используя матрицу Эйзенхауэра -- Как работать со своей мотивацией -- Как планировать работу используя backcasting (это примерно тоже самое, что working backwards от Amazon) -- Как работает мантра "You build it, you run it" и почему она помогает инженерам расти над собой быстрее Интересно, что многое из сегодняшнего доклада мы обсуждали с Алексеем Тарасовым в рамках выпуска Code of Leadership пару недель назад. P.S. Материалы к выступлению Материалы по процессам разработки - Современные подходы к разработке программного обеспечения - Совершенствование потока разработки программного обеспечения - Проектируем надежные системы — стоит ли игра свеч - Про управление проектами и продуктами - The Pipeline-Driven Organization • Roy Osherove • GOTO 2022 - Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture) - Архитектура в масштабе на ArchDays 2020 - Devops культура: мифы и реальность - Про MLOps - The State of Application Security 2023 • Sebastian Brandes • GOTO 2023 - Как RnD появляется в крупных ИТ-компаниях Материалы по проектированию и system design - Статья про System Design Interview в общем - Статья про то, как мы оцениваем System Design Interview - Статья о том, как подготовиться и пройти System Design Interview - Публичное System Design Interview на C++ Russia 2022 - Публичное System Design Interview на конференции ArchDays 2022 - Статья со списком книг о проектировании программного обеспечения - Курс Essential Architecture #Code - Курс Essential Architecture #Data #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Рок-опера "КарамазоВЫ" Были вчера с женой на этой рок-опере и нам понравилось. Честно говоря, я не думал, что Достоевского можно поставить так:) С одной стороны у нас минимализм на сцене, а с другой все полтора часа пока идет постановка ты погружен в музыку и легко фокусируешься на главном герое каждой сцены и проваливаешься в его исполнение. Каждый артист отлично исполнил свою партию и я получил большое удовольствие от похода в театр пятничным вечером после сложной недели:) #Theater #SelfDevelopment

Инструменты надежности Такси \ Александр Фишер, Яндекс Такси Интересное выступление Александра Фишера насчет процессов и инструментов по повышению надежности. Выступление короткое и состоит из шести частей 1. Такси и надежность Вводная про критичность сервисов такси, профиль нагрузки, кратко про архитектуру, используемые технологии. Дальше про метрики надежности: - Стандартные: SLO в девятках, MTTR (mean time to recovery) - Интересные: MTTRC (mean time to root cause) - насколько быстро находится корневая причина сбоя, ROCOF (rate of occurrences of failures) - частотность сбоев В общем, дальше посыл такой, что в следующих пунктах автор рассказывает про инструменты борьбы со сложностью 2. Хаос Подход ребят в том, что они используют fault injection, где data plane этого хаоса реализован через lua скрипты для nginx, которые балансируют трафик, а также есть control plane для управления конфигурацией этих инжектированных ошибок. Этот инструмент позволяет - Замедлять сервис (но укладываясь в propogation deadline) - Моделировать метастабильное состояние сервиса, когда сервис упал под нагрузкой и встать не может, ждет он кто ему поможет:) - Выдача 500 ошибок с заданным процентом 3. Срезание нагрузки: деградация, retries, limits У ребята есть - Gracefull degradation mode, где неосновной функционал можно отключить (это добавляет 20% мощности, но в планах 50%) - Управление retries для решения проблемы амплификации запросов во время сбоев - Есть классификация сервисов по уровням, где уровень зависит от критичности сервиса для возможности выполнить основную функцию (уехать на такси) 4. Виртуальные заказы Рассказ про тестирование нагрузки на систему через моделирование нагрузки виртуальными заказами, которые позволяют проверить нагрузку не API endpoint, а холистически для всей системы. Крутой инструмент, который решает проблему проверки нелинейных зависимостей и непредсказуемого поведения реально сложной системы в зависимости от разного типа нагрузки. 5. Observability и eventboard Тут автор показывает и рассказывает про дашборды для observability + интересный eventboard про события на проде, а также кнопку "откатить все за последние n минут", что помогает уменьшить MTTR (mean time to recover) и ускорить восстановление после сбоя. 6. Симуляция инцидентов Тут идет рассказ про координаторов сбоев + про симуляцию сбоев и тренировки по устранению сбоев, что идут каждую неделю Ну и в конце выступления автор рассказывает про экспериментальные инструменты - Autorecovery - робот, что автоматически чинит инциденты (он пока в dry run работает и проходит обкатку) - SRE GPT - инструмент для помощи в поиске root cause В общем, мне доклад понравился: интересный рассказ, прикольные мысли, достаточно практичные рекомендации, которые можно использовать и в своих процессах повышения надежности. #SRE #DistributedSystems #Reliability #Architecture #Software #Processes #Management

Иллюстрации к постам про whitepaper "Practitioners guide to MLOps" (1 и 2)