В выходные у нашего младшего сына Кирилла был день рождения, ему исполнилось 4 года. На день рождения мы придумали активность для него и всех гостей - пойти в детский клуб, где дети побесились 3 часа в сумме, причему последний час был посвящен раскаршиванию помещения и друг друга. Так у меня появилась новая красочная аватарка:)

Кем может стать системный аналитик - подкаст InSAйт (Рубрика #Career)

Недавно сходил в гости к своим коллегам на подкаст InSAйт, который ведут Павел Каравашкин, руководитель группы разработки T-API, и Есения Киселева, старший системный аналитик, управление разработки продуктов эквайринга в Т-Банке. Темой разговора было карьерное развитие системных аналитиков, о котором я когда-то размышлял на конференции Flow. В итоге, мы обсудили темы
- Почему я когда-то не захотел быть системным аналитиком, а Паша – системным архитектором;
- Можно ли одновременно сохранять фокус на менеджерских и технических скиллах;
- Кем может стать системный аналитик и какие навыки ему важно качать;
- Что такое white paper и чем этот формат может быть полезнее книг;
- Как сделать доменные области более понятными для разработчика.

У этого подкаста есть свой канал в tg (@insight_t_bank), подписавшись на который можно узнавать о новых выпусках.

#Analyst #SoftwareDevelopment #Career #Podcast #SystemDesign #SystemThinking

The Engineering Executive's Primer - Part III (Рубрика #Management)

Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы.

7) Participating in Mergers and Acquisitions
В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом.

😍 Developing Leadership Styles
Автор предлагает модель из трех подходов к управлению
- Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации
- Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами.
- Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию
В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:)

9) Managing Your Priorities and Energy
В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой.

В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей.

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

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 (Рубрика #Architecture)

Интересный доклад про аналитическую реляционную базу данных DuckDB, которую можно запускать на своем ноутбуке и успешно обрабатывать объемы где-то до 1 Tb сильно эффективнее, чем на кластере Apache Spark. DuckDB имеет полную поддержку SQL и может читать/писать такие форматы, как CSV, Parquet и JSON. Он построен в соответствии с современной архитектурой, которая позволяет выполнять сложные запросы параллельно и выгружать на диск рабочие нагрузки, превышающие объем памяти.

В этом докладе Габор, технический писатель из DuckDb, рассказывает про ключевые составляющие DuckDB и демонстрирует, как DuckDB может обрабатывать сотни ГБ данных на ноутбуке или терабайты данных на одном сервере. Основные моменты следующие

1) Демо работы с CSV файлом на 15 Gb для анализа информации о задержках прибытия поездов - в демке видно, что все работает очень быстро. В продолжении демки Габор показывает, что можно увеличить количество данных в 40 раз и дальше после 15 минут загрузки данных те же самые запросы будут уже занимать десятки секунд, но это все равно быстрее, чем грузить данные в облако и дальше выполнять их там. Потом Габор показывает как DuckDB поддерживает стандартные SQL функции вида rank over, pivot, unpivot
2) Архитектура DuckDB выглядит как single-file database:) Условно, вы взаимодействуете с ней внутри вашего приложения и отдельного сервера как такового нет. Здесь она похожа на SQLite, который похожим образом работает для OLTP нагрузок, а DuckDB предназначен для аналитических нагрузок
3) Дальше автор переходит к обсуждению хранения и обработке данных и вспоминает про строчное и колоночное хранение (row-oriented vs column-oriented)
- Транзакционные системы используют строчное хранение, а системы на основе столбцов — столбцовое.
- Столбцовое хранение позволяет эффективно сжимать данные и удалять ненужные столбцы.
- Выполнение по столбцам удобно для аналитики, но может привести к нехватке памяти.
И дальше он рассказывает про векторизацию и кеш процессора, которая позволяет обрабатывать данные векторами, что экономит память. Векторы выбираются такого размера, чтобы помещаться в кэш процессора. Вообще, векторизация кода усложняет перенос между архитектурами, но современные компиляторы автоматически векторизуют код. И в DuckDB используются zonemaps для оптимизации индексации, а также DuckDB не имеет внешних зависимостей, что делает его портируемым на разные архитектуры.
4) DuckDB поддерживает множество форматов и протоколов, включая CSV, Spark, JSON, Delta и Iceberg. Есть поддержка протоколов HTTPS, AWS S3 и Azure Blob. Существует возможность подключения к транзакционным базам данных и интеграция с Pandas и NumPy.
5) У DuckDB есть интеграция с Pandas и NumPy что позволяет читать данные без создания копий. DuckDB работает параллельно, что ускоряет чтение данных по сравнению с самим Pandas
6) DuckDB в июне выпустил обновление и достиг 19 тысяч звезд на GitHub и 30 тысяч подписчиков в LinkedIn и Twitter. Недавно вышла версия Snow Duck с акцентом на стабильность и обратную совместимость.
7) У DuckDB есть множество расширений, которые основаны на механизме для добавления новых функций, типов данных и операторов. Примеры расширений: HTTPFS, JSON, Parquet
😍 DuckDB можно использовать для сокращения расходов на облачные хранилища данных за счет выполнения части вычислений локально. Автор показал TPC-H эксперимент с обработкой Parquet файлов через DuckDB и Apache Spark. Если файл небольшой, то затраты на координацию в Spark убиывают всю производительность
9) У DuckDB есть ограничения - она не поддерживает параллельные запросы на запись, а также работает на одной ноде
10) DuckDB финансируется за счет прибыли и консультирует крупные компании, фонд DuckDB обладает правами на код, а MotherDuck сооздает облачную версию DuckDB

#Database #Architecure #Software #Data #SystemDesign

ЦЕХ 4 - Урок #21 "Ведение блога и его продвижение в Телеграме. Эксперт — Олеся Полянская" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области ведения блога в telegram. Интересно было послушать этот урок и сравнить со своим опытом:) Мне запомнились следующие тезисы из этой лекции:

1) Telegram по разному используют люди разных возрастов - молодые люди больше общаются, а люди постарше читают каналы
2) После бана части других соцсетей пользователей в tg в последнее стало больше
3) Часть каналов в tg фокусируются на новостях, а другие говорят про "вечные темы"
4) Часто важна не сама информация, а ее интерпретация автором канала, у которого есть свой голос и мнение
5) В tg не очень много алгоритмов, которые рекомендуют контент - это отличает tg от других соцсетей. Поэтому авторам важно сарафанное радио и/или стратегия промотирования через рекламу
6) Важно понимать зачем создаешь канал, какая у него будет аудитория и сколько времени получится на него уделять
7) Логотип канала очень важен, также важны контакты автора, а также способ форматирования текста для его удоства
😍 Теперь есть истории и видео-кружочки, их надо использовать с умом, учитывая ожидания аудитории. В tg также можно вести прямые эфиры
9) Важно писать о том, что интересно автору, а также писать регулярно, чтобы поддерживать доверие и интерес аудитории
10) Каналы в tg можно монетизировать через рекламу в них, но скорее всего и самому придется потратиться на рекламу канала
11) Зарабатывать можно не только на рекламе, но и на консультациях, продаже своих книг и всему остальному - популярный канал поможет этому

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Корпоративный мессенджер Time

Около полугода назад я уже рассказывал про наш корпоративный мессенджер Time, на который мы оперативно переехали, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение разным заказчикам сначала в on-prem варианте, а за последние полгода добавился SaaS вариант, а также mvp для видео-конференц связи. С учетом такого большого количества изменений коллеги решили провести вебинар с продактом и парой клиентов (Атом и Юрент), чтобы рассказать про плюсы и минусы продукта, а также поделится опытом переезда в Time и тем, как они выбирали из доступных на рынке решений.

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

P.S.
Кстати, сайт сильно обновился и стал содержать больше полезной информации навроде базового описания стека решений и интеграций
- Time - это cloud-native решение, которое у нас развернуто в наших целевых runtime окружениях (kubernetes кластерах)
- TIme можно развернуть в геораспределенном режиме (у нас, например, он развернут на 2 геораспределенных дата центра)
- Под капотом используются стандартные стек: Postgres, Kafka, Redis, Open search / Elastic search
- Есть разные виды авторизаций (SAML, AD/LDAP, openID)
- Есть возможность мигрировать с других мессенджеров (Slack, MM, RocketChat)

А также есть чиселки для технарей про один из наших инстансов Time
- 45 тысяч пользователей на инстансе в день
- 2 миллиона cообщений в день
- 80 тыс пользователей
- 5,4 миллиона диалогов создали пользователи
- 186 тысяч каналов создано этими пользователями
- более 1200 ботов создано пользователями благодаря удобной документации
- 99,9% - SLA на доступность

#Software

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture)

Как-то раньше я не писал о том, что помимо книг есть большое количество архитектурных материалов у главной тройки cloud провайдеров.

1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов
- Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов.
- Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов.
- Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев.
- Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы.
- Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности.
- Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления.

2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability)
- Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов.
- Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов.
- Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений.
- Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев.
- Security (безопасность): Защита данных и систем через надежные методы безопасности.

3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов:
- Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками.
- Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований.
- Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои.
- Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов.
- Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности.

Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах.

Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге.

#DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

Ководство (Рубрика #Design)

Недавно я прочитал седьмое издание книги Артемия Лебедева, которое доступно на его сайте онлайн под названием ".ру/Ководство". Если кратко, то кажется в далеком детстве Рунета Артемий Лебедев был достаточно интересен как в плане дизайна, так и текстов. Условно, если бы я читал его мысли в начале двухтысячных, когда только начинал свой путь в софтостроении, то это было бы полезно. Сейчас же эти статьи читаются скорее как байки о старых временах от интересного человека из той эпохи ... они пахнут нафталином как в детстве, когда шубу или пальто доставали из шкафа с зимней одеждой. В общем, почитать книгу можно ради воспоминаний ... и интересных мыслей про типографику. Кстати, книгу покупать не обязательно - их можно почитать и на сайте автора.

P.S.
Мне книга скорее понравилась, но допускаю, что это из-за того, что я помню как все начиналось ... в рунете:)

#Design #Visualization

What Is This OpenTelemetry Thing? • Martin Thwaites • GOTO 2024 (Рубрика #Architecture)

Интересное выступление на goto конференции от Martin Thwaites, Principal Developer Advocate из Honeycomb. Основная суть выступления примерно такая
1) Автор начинает с истоков наблюдаемости, когда люди ориентировались еще на мигающие лампочки на самих устройствах:)
2) В 2000х годах использовались метрики для мониторинга производственных систем, так как места было мало и производительность систем была не слишком большой. Тут важно было правильно предагрегировать данные, изначально понимая какая информация будет нужна, так как метрики расчитывались заранее, а оригинальные события не хранились. Где-то в 2010х годах для хранения метрик стали использовать time-series базы данных
3) Дальше стали популярны логи, для которых зачастую использовался ELK стек (Elastic, Logstach, Kibana). Это позволило уйти от предварительной агрегации данных и улучшить наблюдаемость. По-факту, в Kibana можно было пост-фактум строить красивые дашборды, агрегируя данные так, как необходимо
4) Где-то с середины 2010х годов системы стали сложнее и распределеннее и дальше появились инструменты для распределенной трассировки и стандарты OpenTracing и OpenCensus
5) В какой-то момент они объединились и превратились в OpenTelemetry - это проект CNCF в статусе incubating, что наряду с graduated считается стабильным и пригодным для использования в проде
6) OpenTelemetry хорош тем, что он пришел на смену двум предыдущим стандартам, что со временем стали deprecated и позволил отвязать инструментализацию телеметрии от бекендов, в которые она отправляется. У этого стандарта есть протокол и SDK для всех популярных языков программирования
7) У OpenTelemetry есть и проблемы - он развивается через комитеты, что замедляет процесс доработок и расширений стандарта
😍 В OpenTelemetry есть логи, метрики, трейсы. Трейсы - это способ для описания взаимодействия сервисов с учетом причинно-следственных связей (это делается через связи между спанами). Вообще, трейсы позволяют очень удобно разбираться с поведением сложной распределенной системы.
9) Логи предназначены для людей и имеют шаблон сообщения, они полезны для локальной отладки и проверки работы трассировок
10) Метрики - это агрегированные временные ряды данных. Они используются для измерения и анализа производительности. Дешевы в хранении и быстры в обработке, но ограничены в контексте и размерности.
11) OpenTelemetry позволяет думать о соединениях между системами. Распространение данных включает корреляцию и передачу информации о состоянии. Спецификация контекста трассировки W3C определяет заголовки и данные для передачи.
12) Автор подробно говорит про W3C Baggage, propagation format for distributed context. Он как раз позволяет передавать дополнительный контекст между службами, но есть там и проблемки, например, передача данных через сторонние API может привести к утечке конфиденциальной информации.
13) Круто, когда инструментализация OpenTelemetry встроена в шаблоны ваших приложений - это помогает командам SRE получать стандартизированные observability данные
14) У OpenTelemetry есть collector, который используется для проксирования и обработки данных телеметрии. Он позволяет централизовать конфигурацию и отправку данных нескольким поставщикам, а также обеспечить центральную точку для инфобезов или обогощения данных
15) В OpenTelemetry можно настраивать семплинг для уменьшения затрат на наблюдаемость
16) Прикольно семплировать не с головы, а с хвоста, когда мы знаем что попало в трейсинг. Хвостовой сэмплер может сообщать о медленных процессах и ошибках, но компромисс здесь в том, что задержка отправки данных и большие затраты памяти.
17) У OpenTelemetry есть и проблемки - отправка данных через перекрестные зоны доступности может быть дорогой. Решения по отправке данных требуют компромиссов. OpenTelemetry требует постоянного внимания и настройки.
18) В будещем в OpenTelemetry ожидается больше семантических соглашений и библиотек

#SRE #Architecture #DistributedSystems #Software

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Интересная информация от канала "эйай ньюз", за которым я слежу, чтобы не отставать от новостей AI.
Здесь интересна информация о том, а как крупные компании используют AI в своих процессах и оказалось, что все просто
1) Customer support/service - тут всеми "любимые" чатботы и не только
2) Marketing/content generation - генерация маркетингового контента, рекомендаций продуктов (eBay)
3) Document processing / infromation retrieval - обработка документов, суммаризация встреч, поиск по данным
4) Development/code generation - генерация кода (Gitlab, Autodesk), теста (Notion), ...
5) Employee/internal tools - внутренние инструменты для сотрудников

В принципе, список неполный, но достаточно полезный. У нас, например, по всем из этих направлений тоже ведется работа.

T=Математика (#PopularScience)

1 декабря будет день математики и мои коллеги из Т-Образования устраивают большой праздник с кучей активностей: лекции, математические игры, интенсив по финграмотности и многое другое
- 11 — 24 ноября - Интенсив по олимпиадным задачам (онлайн) - подготовка к муниципальному этапу ВсОШ (разборы от опытных преподавателей, тренировки в решении задач
- 16 ноября - Интенсив по финграмотности (оффлайн и онлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будет несколько докладов
- 28-30 ноября - Турнир по математическим играм (онлайн) - на турнире будут командные игры: «Математический квадрат», «Математическая карусель» и «Семь чудес». Победители получат памятные призы от Т-Образования
- 1 декабря в T-Space в Москве - День математика (оффлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будут лекции, нетворкинг и фуршет.

#PopularScience #Math