Книжный куб

Thinking Architecturally. Lead technical change within your engineering team Эту небольшую брошюру от Nathaniel Schutta я прочитал в далеком 2019 году, когда гораздо проще было путешествовать по зарубежным конференциям и собирать ништяки. Конкретно в этой книге 56 страниц, но это только уменьшает количество воды, которую обычно наливают авторы в книги, чтобы растянуть книгу на 200 - 250 страниц. Конкретно в этой книге получилось 7 коротких глав: 1. Technology Changes - здесь речь идет про то, что технологии меняются и мы не можем предотвратить изменения, поэтому нам надо уметь ими управлять. Автор отмечает, что изменения в технологиях часто повторяют себя и нам надо знать прошлое, чтобы распознавать будущие паттерны. Здесь автор предлагает учиться на своих ошибках и ошибках индустрии (например, постмортемы, про которые я как-то рассказывал здесь), оценивать развитие технологий и не верить в хайп с конференций. Тут автор упоминает даже про пользу legacy skillset, на примере COBOL:) 2. Thinking Strategically - основная мысль в том, что думать об изменениях в технологиях надо стратегически и также стратегически надо думать про свое развитие. Автор предлагает фокусироваться на нескольких областях, которыми вы глубоко увлечены и прокачивайте их. Дальше автор рассказывает про использование техрадаров по технологиям, которые можно использовать и для поддержания своих технологических знаний (подробнее про техрадары я говорил здесь). Дальше идет речь про структурирование потоков информации, создание планов по своему развитию с созданием пет-проектов, персональное обучение, обучение в группе, общение с коллегами по индустрии 3. Evaluating Pros and Cons - эта глава посвящена принятию решений, как оценивать компромиссы, риски. Тут же обсуждается technology hype cycle и выбор правильного инструмента 4. Evaluating and Choosing Technologies - как выбрать критерии для оценки, например: документация, коммьюнити, структуру контрибьюторов, кодовая база, тестируемость, зрелость, стабильность, расширяемость, поддержка, тренинги, возможность найма специалистов, безопасность, попадание в корпоративнудю структуру. Как это можно все свести в spreadsheet для оценки, сделать proof of concept и как на решение влияет политика организации 5. Introducing Technologies - про то, что внедрение новой технологии зачастую сложнее ее выбора:) Как митигировать изменения, как влиять на окружающих, как работать с возраениями и заниматься маркетингом своих идей 6. Maintaining Technologies - как поддерживать внедренные технологии по мере эволюции программных систем. Автор вспоминает про концепцию quality attributes (примерно то же самое, что architectural characteristics), которые надо выделить как важные для конкретного продукта, дальше отприоритизировать их и использовать подход continuous или evolutionary architecture с их фитнес-функциями для отслеживания того, что характеристики не уплывают по мере инкрементального развития продукта (вот тут подробнее про continuous architecture, эволюционную архитектуру) 7. Conclusion - в конце автор рекомендует стратегически подходить к применению новых технологий к вашему продукту/проекту. #Architecture #Management #Leadership #Software #SoftwareArchitecture #SoftwareDevelopment

Специальный выпуск Code of Architecture с разбором white paper про Borg Этот выпуск мы записывали в начале августа на Тинькофф ИТ-фесте в Казани. У нас была аутентичная обстановка - ковер на фоне, чак-чак и самовар на столе:) И мы обсуждали научную статью 2015 года от Google "Large-scale cluster management at Google with Borg" в составе: - Владимир Чистяков - руководитель разработки в Тинькофф, один из постоянных ведущих "Code of Architecture", который приехал на конференцию в Казань из Воронежа, где он работает в воронежском центре разработки - Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform, который живет в Казани и работает в казанском центре разработки - Автор этого канала, который приехал на конференцию из Москвы, где работает в Headquarters Если вернуться к содержанию статьи, то надо сказать, что Borg - это система оркестрации рабочих нагрузок, которая используется в Google. Интересно, что именно в недрах Google родился и Kubernetes, в котором был утчен опыт создания и эксплуатации Borg. Интересно, что в 2016 году вышла статья со сравнением трех оркестраторов "Borg, Omega, and Kubernetes", которую интересно прочитать в продолжении. #Kubernetes #SystemDesign #SoftwareArchitecture #SoftwareDevelopment #Software #Architecture #DistributedSystems

Мой доклад "Improving Software Flow" на IT-пикнике 2 сентября Уже через неделю будет большой ИТ-пикник в Коломенском парке от Тинькофф, DevFest и Мельницы. Я на этом пикнике входу в программный комитет трека "Архитектура, надежность, качество", где будет шесть докладов. Один из докладов выпал из-за форсмажора, поэтому я внезапно стал еще и спикером, который закроет этот трек с докладом "Improving software flow", который я уже рассказывал вначале августа в Казани на нашем фестивале (расшифровка доклада есть здесь, но записи пока нет). Если вы планируете зайти на фестиваль, то не забудьте зайти именно на наш трек, а может и на мой доклад:) Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут. #Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems

Курс "Теория вероятностей" на Stepik Лет шесть назад я прошел этот курс на степике и действительно могу подтвердить, что он тянет на свою оценку в 4.8 из 5, что указана на платформе:) В самом курсе рассказывается о базовых понятиях и теоремах теории вероятностей и содержит много практических заданий для самостоятельного решения. Курс состоит из двух частей по два модуля в каждой: - Первая часть посвящена классической версии теорвера, где испольхуются элементарные методы и доказательства. Модули внутри первой части так и называются "Элементарная теория вероятностей: случайные события" и "Элементарная теория вероятностей: случайные величины" - Вторая часть содержит материал посложнее. Третий модуль называется "Общая теория вероятностей" и содержит аксиоматический подход к теории вероятностей и строгое изложение общей теории. Это самый интересный и сложный модуль. Четвертый модуль "Дискретные и непрерывные случайные величины" содержит обсуждение частных случаев, которые после общей теории кажутся простыми и понятными:) В итоге, курс мне кажется полезным для получения базовых знаний по теории вероятности, которые нужны в быту, например, чтобы понять как считается надежность системы, состоящей из кучи сервисов, если у каждого сервиса есть свой SLA по доступности и все из них нужны для работоспособности системы верхнего уровня:) Как-то я такого типа вопрос хотел добавить в скрининг SRE-инженеров:) P.S. Сам я теорвер люблю еще со школы - это началось после того как в 10 классе съездил в Москву посмотреть на МГУ и МФТИ, чтобы решить куда буду поступать из своего Северодвинска:) В итоге, я вернулся с набором книг, в котором была книга по теорверу, которая мне понравилась, но обложку которой я не смог найти потом в Google, чтобы узнать название этой книги и перечитать по прошествии лет. #Math #Course

Выборы новой книги для изучения в рамках клуба "Code of Architecture" Уже в сентябре мы начнем читать новую книгу в книжном клубе Code of Architecture и это будет как обычно та книга, которую выберете вы:) На выбор представлены 4 книги, три из которых я уже прочитал и рекомендовал вам их. Вот мои впечатления по каждой из них 1) Building Secure and Reliable Systems - крутая, но тяжелая книга от Google про проектирование надежных систем. Подробнее про эту книгу я рассказывал здесь 2) Continuos Architectere in Practice — крутая и практичная книга по архитектуре, что мне показалась на голову выше творчества Нила Форда и его друзей (это отсылка к книге Software Architecture. The hard parts). Кратко про принципы continuous architecture я рассказывал здесь, но я очень хочу эту книгу полноценно разобрать в рамках Code of Architecture - это будет точно бомба:) 3) The Software Architect Elevator — интересная книга про роль архитектора в digital enterprise. Про нее я рассказывал здесь 4) Machine Learning Design Patterns — книга от ребят из Google про то, как готовить данные, строить модели и делать MLOps. Тема для меня интересная, но пока это единственная книга из спика, которую я не дочитал:) Рекомендую выбрать вариант 2:) #SoftwareDevelopment #Architecture #SoftwareArchitecture #Software #Leadership #SystemDesign

Frontend Architecture for Design Systems. A modern blueprint for scalable and sustainable websites Лет 5 назад я прочитал эту книгу с интригующим названием "Frontend Architecture for Design Systems", ожидая от нее многого. Книга написана Micah Godbolt на основании его многолетнего опыта работы в качестве фронтендера на разнообразных проектах. Один из последних проектов был в том, чтобы переделать сайт RedHat.com, которая славилась тем, что научилась зарабатывать на open source решениях, но особых достижений во фронтенде раньше отмечено не было. Что особенно радует в книге, что автор не скатывается до выбора одной из библиотек и фреймворков и не объявляет его/ее серебрянной пулей, например, говоря, что Angular/React/Vue животворящий поможет решить вам все проблемы:) Фактически, автор борется за то, чтобы фронтенд-архитектура тоже была жителем первого класса в проекте разработки программного обеспечения. Для этого автор выделяет 4 столпа, а именно: - Код (сладкое трио html, css, javascript) - Процессы (инструменты и процессы для создания эффективного workflow) - Тестирование (создание устойчивого решения) - Документация В первой части книги, а именно во вступлении автор поднимает интересный вопрос того как мы оказались в текущем положении, от появления www до появления понятия фронтенд-архитектура. Дальше он расматривает составные части этого понятия, а именно: - Design ("By designing a system all frontend developers are going to work within, the architect sets a clear vision of what the end product, the code, will look like") - Planning - Oversight ("Frontend architecture is never a “set it and forget it” proposition ... A key talent of a frontend architect is the ability to continually make needed adjustments") Вводная часть завершается мыслью о роли фронтового архитектора: "Without the early input of a frontend architect, projects run the risk of having to choose between reworking designs, platform, or infra‐ structure and telling the frontend developers to make do" Вторая часть содержит главы относительно того, как надо структурировать код, а именно писать html, css и javascript'а. Но забавно, что в этой книге я в первый раз увидел изложение принципа единственной ответственности (Single Responsibility Principle) в переложении на фронт, а именно в главе, где рассматривались правила работы с CSS:) Следующая часть относится к процессам. В ней рассказывается про старый и новый workflow. Также обсуждаются вопросы CI/CD в общем и сборки asset'ов в частности. В главе 10, где обсуждается процесс Red Hat, где раскрывается schema-driven design система, в которой имеются: - JSON schema - схема компонентов - Template file - шаблон компонента - Sass partial - стили компонента - Visual regression tests - тесты для визуального регресса - Testing data - тестовые данные - Documentation - документация компонента - Documentation data - данные для документации В общем, этот подход "schema-driven design system" мне до боли знаком:) И по опыту могу сказать, что он работает куда лучше, чем альтернативные варианты. В части, относящейся к тестрованию рассматривались: - юнит-тесты - performance-тесты - визуальное регресс-тестирования - интеграция всего этого в процесс тестирования в Red Hat:) В части, относящейся к документированию основной акцент идет на том, как организовать в модульной дизайн системе набор компонентов, доступных для переиспользования. Опять идет отсылка к Brad Frost’s Atomic Design principles (хоть это и убогое название для стандартного компонентого подхода от автора, который не разбирается ни в химии, ни в биологии). В итоге, книга действительно неплохая и хорошо раскрывает подход к рендерингу фронтового отображения семилетней давности:) Но книга явно не дотягивает до рассказа об архитектуре всего приложения и если вы делаете изоморфное приложение, одновременно отвечая за бекенд (даже довольно тонкий), то одной этой книги вам не хватит. #Architecture #Software #SoftwareArchitecture #SoftwareDevelopment #Engineering

Макет Золотого кольца России В воскресенье мы успеои посмотреть макет Золотого кольца России. Мы оказались в Ярославле по дороге в яхтенный парк "Точка Немо", куда мы ездили в миниотпуск. Честно говоря, я люблю эти минигорода и видел макет Москвы в ВДНХ и гранд макет в Питере, поэтому не посетить миниатюрный музей в Ярославле я не мог:) В этом макете Золотого кольца интересно сделана геймификация для детей, которые могут взять задание на поиск пасхалок - знаменитых мультяшных персонажей, что раскиданы по мини-версиям Ярославля, Костромы, Иваново, Ростова и других городов, что входят в кольцо. Наших детей эти поиски захватили на час, но к концу часа они отчаявшись запросили помощи у тетушек, что продавали сувениры у выхода и получили подсказки по остальным персонажам. Именно так они выполнили свой квест и получили подарки в виде трех колокольчиков 1) в форме кота с гитарой, 2) волка из мультика "Жил был пес" и 3) кота, который сидит на колокольчике. В общем, всем в этом миниатюрном музее (он действительно небольшой) понравилось:) #Holidays

Выбор. Правила Голдратта (The Choice) Я прочитал эту книгу лет семь назад и мне она понравилась. В ней автор рассказывает про новейшие методы активизации мышления и показывает как они работают на практике. Книга выстроена в форме диалога с дочерью, где разбираются конкретные ситуации, для решения в которых требуется обеспечить совместную работу логики, интуиции и эмоций. Сложно сказать что нового я вынес из книги, но мне понравился подход автора. Он с видимой легкостью смог донести читателям свои идеи о использовании научного подхода в жизни. Особо понравились следующие моменты в его рассужденияъ: - о простоте систем и о том, что степень простоты зависит от формулировки того что же это такое:) - о причинах и следствиях, а также как понять что является причиной, а что нет - о гармонии в отношениях элементов системыи о том, что компромисы при конфликтах часто являются злом, т.к. устраняются симптомы проблемы, а не ее корень - о том, что надо верить в людей:) P.S. Подробнее про концепции Голдратта можно почитать в других постах - Теория ограничений Голдратта (Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement) - Критическая цепь (Critical Chain) #Management #Processes #Project #ProjectManagement

Практика визуального мышления. Оригинальный метод решения сложных проблем (Unfolding the Napkin. The Hands-On Method for Solving Complex Problems with Simple Pictures) Эта книга Дэна Роэма продолжает книу «Визуальное мышление», в которой рассказывалось как простые рисунки могут играть в деле генерации идей и коммуникациях в целом. Она представила новую интересную методику решения совершенно различных проблем — от стратегических вопросов топ-менеджмента до самых прозаичных офисных проблем. А в книге-продолжении помогает читателям внедрить свою методику в ежедневную практику. Книга полна подробных примеров, упражнений и пустого места для ваших рисунков. Я прочитал эту книгу с удовольствием. Единственная проблема - надо было продраться через скучные повторы первых пятидесяти страниц (ощущение, что их писали для страдающих от провалов в памяти). Как только вводная часть с большим количеством повторов закончилась, все стало очень интересно и полезно, например - Мне понравилось то, что автор выделил 6 вопросов для решения любой проблемы, на которые надо ответить при помощи картинок. Я запомнил эти вопросы в таком порядке Что, Где, Когда (по названию знаменитой телепередачи) и оставшиеся 3 - Сколько, Как, Почему. - Мне зашла концепция о глубине проработки проблемы для разных людей, которым ты хочешь донести свои мысли. Т.е. для кого-то требуется подготовить верхнеуровневую картину без погружения в детали, а другим же требуется детализированное отображение. Если не понимать потребности этих людей, то первые посчитают, что ты их перегружаешь ненужными деталями, а вторые решат, что ты не разбираешься в рассматриваемом вопросе:) В общем, книгу можно порекомендовать всем, кому требуется анализировать проблемы, в качестве еще одного метода для использования такого мощного инструмента как человеческий мозг:) #SelfDevelopment #Brain #Patterns #Creativity

Meet For Charity Сегодня стартовал благотворительный аукцион Meet For Charity, где в качестве лота предлагается встреча со мной:) Формат аукциона следующий - для победителя аукциона я проведу небольшую экскурсию по офису Тинькофф и дальше мы пообщаемся за обедом в нашем ТЦ Водный - собранные по итогам аукциона средства будут направлены в фонд «Нить добра» В принципе, я готов обсудить разные темы, например, такие: - почему сейчас бизнес и IT должны быть на одной волне; - как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта; - как выстроить архитектурные процессы в компании; - как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.); - как появление искусственного интеллекта изменило расклад на рынке разработки. Но если у победителя будет своя тема на обсуждение, то я попробую обсудить и ее:) P.S. Ну и немного формальной части про меня: - я работаю в Тинькофф почти семь лет и являюсь техническим директором юнита клиентские интерфейсы, маркетинг и вовлечение в Тинькофф - до этого успел побыть руководителем группы разработки в Банки.ру и Woman.ru - когда-то был software development engineer, а до этого успел закончить Физтех (МФТИ) P.P.S. Плюс победителю я подарю книгу Олега Тинькова "Революция. Как построить крупнейший онлайн-банк в мире", в одной из глав которой рассказывается про машину привлечения клиентов, к строительству которой я приложил руку:) #Charity #Software #Management #Leadership

Яхтенный глэмпинг парк "Точка Немо" Вместе с женой и тремя сыновьями уехали на 4 дня в глэмпинг, который в отличие от названия, расположен не в южной части Тихого океана, а под Ярославлем:) Мы живем в лесу на берегу реки в двух домиках: шарообразный купол для жены, самого мелкого сына и меня, а также домик на дереве для старшего и среднего сына. Домики достаточно комфортные и удобные для проживания, а рядом с домиками есть купели в виде большой бочки, где можно отдохнуть вечером в горячей воде. У детишек днем и вечером плотная программа - они учатся ходить под парусом, ходят в походы, жарят маршмелоу на костре, а мы с женой и самым маленким гуляем по территории:) В общем, тут действительно можно отдохнуть на природе с детьми и чуток выдохнуть перед началом нового учебного года:) #Holidays

Скрапинг веб-сайтов с помощью Python 2 издание (Web Scraping with Python: Collecting More Data from the Modern Web 2nd Edition) Несколько лет назад я прочитал эту книгу, которая оказалась рассчитанной на уровень новичка. Я не расстроился, потому что я её и покупал в качестве обучающего пособия для новичков. Первая половина книги называется "Построение скраперов" и является аналогом "Hello world" в мире скраперов на Python. Здесь основное внимание уделено механике веб-скрапинга: как с помощью Python запрашивать информацию с веб-сервера, производить базовую обработку серверного отклика и организовать автоматизированное взаимодействие с сайтами. Вторая часть называется "Продвинутый скрапинг", где рассмотрены более специфичные инструменты и приложения, которые пригодятся при любом сценарии веб-скрапинга. Но этот продвинутый скрапинг является продвинутым только относительно первой части этой же книги:) Плюс мне реально понравился список вопросов, напоминающий чеклист, которые стоит задать при появлении проекта по скрапингу: - На какой вопрос я хочу ответить или какую проблему я хочу решить? - Какие данные помогут мне достичь этого и где они находятся? - В каком виде эти данные представлены на сайте?... - Как я могу отделить нужные данные от ненужных и извлечь их? - Какие операции по обработке и анализу нужно выполнить, чтобы использовать данные с максимальной пользой? - Как я могу сделать этот процесс лучше, быстрее, надежнее? #SoftwareDevelopment #Software #Architecture #Engineering

Обзор книги "Team Geek. A Software Developer’s Guide to Working Well With Others" Эта книга Брайана Фитцпатрика и Бена Коллинз-Сассмэна посвящена вышла больше 10 лет назад, но прочитал я ее лет 6 назад. Авторы заявляют целью помощь программистам эффективнее и продуктивнее разрабатывать программы за счет развития способности понимать других людей, общаться и сотрудничать с ними. Но издательство Питер в своем переводе указывает подзаголовком "Как из гиков собрать команду программистов" — чего не сделаешь ради того, чтобы книга лучше продавалась:) Авторы хотели рассказать про важность софт-скиллов для разработчиков, а ребята из Питера хотели продать эту книгу большему количеству технических руководителей и сместили фокус на сбор команды. Но книга все равно получилась интересной, поэтому я написал краткое саммари в своем блоге. #SoftwareDevelopment #SelfDevelopment #Engineering #Management #Leadership #ExternalReview

Типичные ошибки проектирования (Bug Patterns In Java) Эта книга из начала моей карьеры. На английском она вышла в 2002 году, а уже в 2003 году издательство Питер применило креатив при переводе и "Bug Patterns in Java", которые можно было перевести как паттерны багов в Java превратилась в типичные ошибки проектирования:) Но несмотря на креатив в названии, книга показалась мне тогда полезной и объемной. В ней всего 23 части 1. Agile Methods in a Chaotic Environment - здесь речь шла про гибкие подходы, концепцию паттерно в общем в и паттернов багов конкретно, а также зачем их изучать 2. Bugs, Specifications, and Implementations - объяснение как понять что такое баг, а что такое фича. После прочтения легко становится понятна фраза "Это не баг, это фича":) 3. Debugging and the Development Process - как отлаживаются программы, про парное программирование, про общее владение кодом и про написание тестов для "всего, что может сломаться" 4. Debugging and the Testing Process - как писать тестируемые программы, про статический контроль типов, правильные абстракции и инкапсуляцию, хорошие интерфейсы 5. The Scientific Method of Debugging - обсуждение научного подхода к дебагу - наблюдение, построение гипотез, проверка гипотез при помощи экспериментов, повторение этих шагов в цикле, пока не исправим проблему 6. About the Bug Patterns - расказ про важность паттернов багов, объяснение как выглядит такой антипаттерн и большой справочник по отладке программ 7. The Rogue Tile - это антипаттерн фальшивая черепица, в котором программа после исправления ведет себя так, как будто баг не был исправлен. Причина может быть в том, что проблемная логика растиражирована внутри приложения и ее нужно вынести в общее место и починить один раз там:) 8. Null Pointers Everywhere! - стандартная история с Java:) 9. The Dangling Composite - болтающийся компонент, который характерен для рекурсивно определенных типов данных, где некоторым базовым случаям не выделяются классы, а используются null pointers 10. The Null Flag - когда программа вместо выкидывания значимого исключения кидает null pointer exception. 11. The Double Descent - проблема с рекурсивным обходом составной структуры, когда мы прыгам более чем на один щаг вниз 12. The Liar View - антипаттерн "лживое представление" на случай, когда используется паттерн MVC и работа представления и модели расходится 13. Saboteur Data - история про косяки с валидацией входных данных и дальнейшим их использованием внтури приложения 14. The Broken Dispatch - косяки с полиморфизмом и перегрузкой методов 15. The Impostor Type - тип-самозванец, когда программа одинаково обрабатывает принципиально разные типы данных. Про такую проблему рассказывал Джон Остерхут в книге "A philosophy of software design" как о проблеме, которую он пытался найти полгода:) 16. The Split Cleaner - проблемы при некорректном управлении ресурсами, когда они или не освобождаются или наоборот делают это слишком рано 17. The Fictitious Implementation - проблема, когда реализация интерфейса не удовлетворяет некоторым содержащимся в нем инвариантам 18. The Orphaned Thread - проблема в многопоточном приложении, когда потоки остановились в ожидании данных от поттока, что прекратил свою работу 19. The Run-On Initialization - проблема при инициализации атрибутов класса, когда конструктор инициализировал не все из них 20. Platform-Dependent Patterns - платформо-зависимые ошибки 21. A Diagnostic Checklist - список вопросов и симптомов некорректного поведения, который можно использовать для дебага 22. Design Patterns for Debugging - паттерны проектирования, которые помогают в отладке (первый паттерн в использовании статической типизации) 23. References - ссылки на ресурсы, что были полезны 20 лет назад:) #Software #SoftwareArchitecture #Patterns #Design #Architecture #SoftwareDevelopment #Engineering

Dream Team. Как создать команду мечты Забавная книжка, которую я прочитал десять лет назад. В ней речь идет про рефакторинг отдела продаж российского подразделения крупной зарубежной фирмы. И хоть книга наполнена рекламными вставками о тренингах одного из соавторов, первая половина книги читается хорошо - в ней изложен довольно аналитический подход к вопросам дистрибьюции, развития отделов внутри фирмы, обучения сотрудников внутри компании, организации выделенных отделов. А вот вторая половина книги показалась мне трешем - в ней рассказывается о том, как надо зомбировать своих сотрудников, используя методы по типу разнообразных сект. В общем, читать книгу мне было интересно, но ... вот со второй половиной книги надо быть аккуратнее:)

Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • GOTO 2023 Интересный доклад от Jez Humble, техлида SRE команды, которая поддерживает сервисы serverless платформы. Основная проблематика следующая: в рамках этой платформы надо отслеживать ее работоспособность, но - Ориентироваться при этом на восприятие клиентов того, насколько хорошо работают их приложения поверх платформы - Можно ориентироваться на latency приложений, но у них разброс latency в пять порядков (от миллисекунд до сотен секунд) - Можно ориентироваться на request delivery metrics, которые мерят время от попадания в сетевой слой 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 И они нашли ее опираясь на понимание статистики и используя концепцию стационарности (свойство процесса не менять свои характеристики со временем). Если кратко, то они выделил отдельные когорты запросов по версии приложений, развернутых в serverless платформе. Дальше для каждой когорты проверили укладывается ли распределение ее latency в логнормальное распределение. Если укладывается, то сохранили параметры распределения в базу, если нет, то откинули эту когорту. В итоге, половина нагрузок укладывается в логнормальное распределение. Дальше ребята используют подход 2 сигма для измерения 2 стандартных отклонений от среднего для каждой из когорт и собирают это в график, гда видно каков процент таких рабочих нагрузок с таким большим отклонением. Нормальное состояние платформы характеризуется 2% -5% рабочих нагрузок с отклонениями больше 2 сигма, а вот если этот показатель поднимается до 10%, то это повод для беспокойства. Для построения такого распределения обычно используется 15 минутное окно. Дальше автор рассказывает как это работает в деталях, но мне интересно рассказать еще о выводах, которые Jez подводит в самом конце доклада - We can reliably detect and measure the impact of platorm regressions - Reliability is a shared property (between customer & service) -- Reconstruction of end to end behavior is critical - Metric combinability is critical for analysis - Variability is what customers actually care about - Distributed systems ofen produce decorrelation -- We can measure it, and its absence - Workload correlation can identify proximate causes Итого, это интересный доклад для тех, кто строит платформы и хочет выстроить SLO/SLA/SLI с учетом не только своих технических метрик, но и том, как себя чувствуют пользовательские нагрузки внутри платформы. P.S. Слайды презентации доступны здесь. #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Math #ContinuousDelivery

Трек "Архитектура, надежность, качество" на ИТ-пикнике Через 2 недели, 2 сентября в Коломенском пройдет большой ИТ-пикник от Тинькофф, DevFest и Мельницы. Там будет музыка, научпоп, выступления про AI, менеджмент и конечно про архитектуру. И как раз в последнем треке получилось собрать крутых ребят в программный комитет: Олег Бондарь - CPO Yandex DB, Максим Смирнов - архитектор и автор популярного канала "Архитектура ИТ-решений", Дмитрий Масленников - руководитель центра надежности в Тинькофф, автор этого канала. А дальше уже мы собрали отличных спикеров с крутыми выступлениями в программу нашего трека. В итоге, получилась такая dream team: - Дима Крутик из Тинькофф расскажет про то, как мы оцениваем качество услуг глазами глазами клиентов - Сергей Баранов из Scrumtrak расскажет про восстановление архитектурных знаний - Михаил Кабищев из Озон расскажет про internal developer platform в Озоне, зачем она нужна и как помогает эффективнее разрабатывать - Егор Гордовский из Яндекс расскажет про то, как устроены датацентры Яндекса - Павел Лакосников из Авито расскажет про паттерны отказоустойчивой архитектуры на примерах - Андрей Якушев из VK расскажет про архитектуру ленты и рекомендаций в VK Если вас заинтересовали эти темы, то приходите на фестиваль именно на наш трек:) Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут. #Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems