Стрим с Сергеем Щербининым про инженерную культуру в Тинькофф

Вчера вечером мы вместе с Сергеем пообщались в рамках "безвотэтоговотвсего" и обсудили большое количество вопросов, среди которых самыми интересными были:
- Что поменялось в Тинькофф за 7 лет, что я уже в компании
- Как мы выглядим внутри с точки зрения управления и организации работы и что позволяет разным нашим продуктам двигаться вместе (я рассказывал об этом на примере мобильного приложения Тинькофф на Highload++ 2022)
- Как устроены архитектурные подходы в компании (я про это рассказывал как-то на ArchDays 2020)
- Как можно смотреть на эффективность разработки (тут я вспомнил про темп разработки и качество продукта, см. подробнее в книге "Accelerate" и моем выступлении "Improving software flow" на нашем фестивале в Казани неделю назад)
- Какие культурные ценности в компании и почему именно такие (про это я пока только планирую дописать статью)
- Какие еще есть компании в России с крутой инженерной культурой

#Management #Leadership #Engineering #SoftwareDevelopment #Architecture #Podcast #Software

Трек "Архитектура, надежность, качество" на ИТ-пикнике

Через 2 недели, 2 сентября в Коломенском пройдет большой ИТ-пикник от Тинькофф, DevFest и Мельницы. Там будет музыка, научпоп, выступления про AI, менеджмент и конечно про архитектуру. И как раз в последнем треке получилось собрать крутых ребят в программный комитет: Олег Бондарь - CPO Yandex DB, Максим Смирнов - архитектор и автор популярного канала "Архитектура ИТ-решений", Дмитрий Масленников - руководитель центра надежности в Тинькофф, плюс последний участник - это автор этого канала.

А дальше уже мы собрали отличных спикеров с крутыми выступлениями в программу нашего трека. В итоге, получилась такая dream team:
- Дима Крутик из Тинькофф расскажет про то, как мы оцениваем качество услуг глазами глазами клиентов
- Сергей Баранов из Scrumtrak расскажет про восстановление архитектурных знаний
- Михаил Кабищев из Озон расскажет про internal developer platform в Озоне, зачем она нужна и как помогает эффективнее разрабатывать
- Егор Гордовский из Яндекс расскажет про то, как устроены датацентры Яндекса
- Павел Лакосников из Авито расскажет про паттерны отказоустойчивой архитектуры на примерах
- Андрей Якушев из VK расскажет про архитектуру ленты и рекомендаций в VK

Если вас заинтересовали эти темы, то приходите на фестиваль именно на наш трек:)
Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут.

#Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems

Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • GOTO 2023

Интересный доклад от Jez Humble, техлида SRE команды, которая поддерживает сервисы serverless платформы в Google Cloud. Основная проблематика следующая: в рамках этой платформы надо отслеживать ее работоспособность, но
- Ориентироваться при этом на восприятие клиентов того, насколько хорошо работают их приложения поверх платформы
- Можно ориентироваться на 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

Dream Team. Как создать команду мечты

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

В общем, читать книгу мне было интересно, но ... вот со второй половиной книги надо быть аккуратнее:)

Типичные ошибки проектирования (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

Meet For Charity

Сегодня стартовал благотворительный аукцион Meet For Charity, где в качестве лота предлагается встреча со мной:)

Формат аукциона следующий
- для победителя аукциона я проведу небольшую экскурсию по офису Тинькофф и дальше мы пообщаемся за обедом в нашем ТЦ Водный
- собранные по итогам аукциона средства будут направлены в фонд «Нить добра»

В принципе, я готов обсудить разные темы, например, такие:
- почему сейчас бизнес и IT должны быть на одной волне;
- как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта;
- как выстроить архитектурные процессы в компании;
- как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.);
- как появление искусственного интеллекта изменило расклад на рынке разработки.
Но если у победителя будет своя тема на обсуждение, то я попробую обсудить и ее:)

P.S.
Ну и немного формальной части про меня:
- я работаю в Тинькофф почти семь лет и являюсь техническим директором юнита клиентские интерфейсы, маркетинг и вовлечение в Тинькофф
- до этого успел побыть руководителем группы разработки в Банки.ру и Woman.ru
- когда-то был software development engineer, а до этого успел закончить Физтех (МФТИ)

P.P.S.
Плюс победителю я подарю книгу Олега Тинькова "Революция. Как построить крупнейший онлайн-банк в мире", в одной из глав которой рассказывается про машину привлечения клиентов, к строительству которой я приложил руку:)

#Charity #Software #Management #Leadership