Книжный куб

Testing strategy: avoid the waterfall strategy trap with iterative refinement (Рубрика #Management)

Очередная интересная статья от Will Larson, который постепенно создает свою новую книгу про стратегию. В этой главе речь идет про гибкое тестирование стратегии и улучшение ее на основе обратной связи:) Как обычно у Вилла все очень структурно

1) Когда стоит тестировать стратегию?
Когда хочется понять насколько она достижима и сколько реально будет стоить. По-факту, автор предлагает перед ее финализацией делать аля PoC (proof of concept), который позволит собрать недостающую информацию. Но иногда это можно не делать - например, при разрешающей стратегии (ее имплементация стоит не дорого), при слишком долгом ожидании обратной связи (вопросы с наймом в разных регионах) или когда мы почти уверены в своей стратегии

2) Как тестировать стратегию?
- Выделить узкий и глубокий элемент стратегии, над которым дальше итеративно работать
- Дальше по метрикам оценить импакт изменений
- Действовать исходя из того, что людьми хорошо управляют, а неудача стратегии обусловлена избытком свободы и плохой эргономикой
- Продолжайте совершенствовать стратегию, пока не убедитесь, что детали вашей стратегии работают на практике или что ее надо поменять
Не стоит замахиваться на слишком широкую область сразу, не стоит давить слишком сильно для принятия стратегии и не надо слишком привязываться к своему подходу:)

3) Роли для тестирования стратегии
Автор выделяет роль спонсора и руководителя (guide). Собственно один авторизует стратегию и помогает ей случиться, а второй ее реализует, отслеживает выполнение и эксалирует в случае проблем. Забавно, что я успел побывать и тем и другим за время карьеры:) Важно, чтобы эта пара могла принимать сложные решения быстро, а не уходила в paralysis of analysis

4) Meetings & Metrics
Единственное обязательное требование для этапа тестирования стратегии — спонсор, руководитель и все ключевые лица, работающие над стратегией, должны встречаться каждую неделю. В ходе этой встречи надо смотреть на показатели, что отражают текущие области, которые вы пытаетесь улучшить, обсуждать, чему вы научились на основе предыдущих показателей или данных, а также планировать разовые контрольные проверки, чтобы убедиться в прогрессе.

5) Выявление стратегий, не прошедших тестирование
Хотя не все стратегии должны быть уточнены в ходе фазы тестирования, по сути, все неудачные стратегии пропускают фазу тестирования, чтобы перейти непосредственно к реализации. Стратегии, которые пропускают тестирование, звучат правильно, но не достигают многого. Один из самых стандартных паттернов провала - это "давление без плана", когда стратегия представляет собой лишь аспект «звучит правильно» без каких-либо деталей. Я видел много таких стратегий

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

В финале автор говорит о том, что тестирование не поможет понять, а может ли стратегия быть хорошей. Но оно позволит выявить недостающие детали, необходимые для перевода стратегии в работающее состояние:)

#Management #Strategy #Leadership #Software

Обложки для книг "The Tyranny of Metrics" и "Тирания показателей"

The Tyranny of Metrics (Тирания показателей) (Рубрика #Management)

Эта интересная книга за авторством Muller Jerry вышла в 2018 году в Princeton University Press, а в 2020 году ее перевели в Альпине. Мне понравилось название, которое идет наперекор стандартному подходу к измерению всего и вся:) В итоге, книга напоминает по структуре научную статью. А когда я начал читать эту книгу, то легко узнавал проблемы, которые классно описывал автор. Во многом они рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой". В итоге, автор не предлагает отказаться от показателей, а скорее говорит о том, что помимо них должны быть качественные показатели и мнение разбирающихся в теме людей, которые принимают решение. Иначе получится как с XSolla, где были уволены сотрудники с аргументацией, что "биг дата» показала их невовлеченность".

Вот содержание книги
0) Введение - автор рассказывает о том, как он, работая в сфере образования профессором и завкафедрой, оказался вынужден сдавать все больше и больше отчетов по мере обвешивания системы образования метриками. Дальше он заинтересовался историей вопроса и в итоге получилась эта книга
1) Постановка проблемы - в этой части автор рассказывает об одержимости показателями и к чему это может приводить. Делает это он в главах с кратким описанием проблемы и перечнем характерных ошибок
2) История проблемы - так как автор - это учений с интересами в истории, экономики и политики, то он глубоко погружается в историю вопроса и рассказывает про
- Происхождение системы вознаграждения в зависимости от результата (pay for performance)
- Почему количественные показатели стали такими популярными
- Принципалы, агенты, мотивация (внутренняя и внешняя)
- Философия и критика
3) Можно ли применять количественные оценки ко всему подряд - тут автор разбирает на конкретных примерах результаты применения чрезмерной количественной оценки
- В образовании - автор разбирает колледжи и университеты
- Школы - автор рассказывает про зарубежный опыт, но мы все можем видеть результаты ЕГЭ
- Здравоохранение - тут автор показывает как рейтинг хирургов на основе успешных операций приводит к тому, что они отказываются от сложных операций и предлагают сразу ехать на кладбище
- Охрана правопорядка - тут цель в снижении преступности приводит к тому, что часть преступлений классифицируют как менее тяжкие, которые не входят в рейтинг или просто не реагируют на часть обращений
- Вооруженные силы - тут гонка за показателями особенно вредна в сценариях борьбы с террористами, повстанцами и другими иррегулярами
- Бизнес и финансы - тут автор проходит по KPI, OKR, вспоминает разгон показателей для радости инвесторов, подделывание отчетности. В итоге, часто менеджеры концентрируются на операционных показателях и перестают думать о стратегии развития
- Благотворительность и помощь другим странам - автор говорит о том, что тут методы бизнеса работают не очень, так как вовлеченные в благотворительность часто ориентируются на свою внутреннюю мотивацию, а внешние KPI начинают ее подмывать:)
4) Экскурсы. Автор показывает что иногда прозрачность - это враг результативности. Он делает это на примере политики, дипломатии, разведки и браков:)
5) Выводы. Сначала автор рассказывает о непредвиденных, но предсказуемых последствиях увлечения показателями, а потом говорит о том, а когда и как применять количественные показатели. Про эту часть я расскажу отдельно позже.

В общем, книга мне очень понравилась, так как я часто вижу описанные автором проблемы и стремлюсь их исправить. Иронично, что продуктовая аналитика и a/b платформа, что нужна для контролируемых экспериментов, а также metric store, где должны считаться метрики по продуктам для всей организации, сейчас находится в моем юните, а значит правильное применение данных - это отчасти и моя профессиональная задача:)

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

#Data #Statistics #Management #Leadership #Processes

Research Insights Made Simple #1 - Обсуждение paper "API Governance at Scale" (Рубрика #Architecture)

Это первый выпуск подкаста с разбором научных статей, которые посвящены разным темам computer science и engineering management. В этом выпуске мне помогает мой коллега, Даниил Кулешов, Staff Engineer, который развивает вместе со мной в Т-Банке архитектурную функцию на уровне всей компании.

Для первого выпуска мы взяли научную статью про governance, а точнее про API governance от ребят из Google, которая вышла в 2024 году. Сама статья достаточно хорошо раскрывает тему governance, что позволяет закрыв глава подставить на место API слово architecture и многие мысли и выводы авторов останутся корректными.

Основные материалы
- Whitepaper доступен здесь - https://research.google/pubs/api-governance-at-scale/
- Мой разбор whitepaper есть в блоге - https://tellmeabout.tech/review-whitepaper-api-governance-at-scale-fdab581b8489
- Перечень Google стандартов на API доступен здесь - https://google.aip.dev/

#Software #Architecture #DistributedSystems #Whitepaper #Management #Processes #Leadership

Сервис Unidraw.io от T-Bank - наш ответ Miro - Продолжение (Рубрика #Visualisation)

Раньше я уже анонсировал этот инструмент в отдельном посте, а теперь
1) Я уже обкатал этот инструмент при создании обзоров всех whitepapers, про которые я рассказывал с сентября, а также при проведении System Design Interview
2) Пару дней назад на Хабре появился рассказ про бекстейдж развития этого инструмента у нас в компании "Unidraw — путь длиной в два года"

Если говорить про обзоры статей, то визуализаций в Unidraw мне хватает и я не часто вспоминают про Miro. Для демонстрации тезиса я решил пошарить все эти доски, чтобы вы могли проверить все сами - ближайший месяц они будут доступны и неавторизованным пользователям, а потом придется все-таки заводить аккаунт, чтобы их посмотреть:)
1) Defining, measuring and managing technical debt - статья с обзором и доска
2) API Governance at Scale - статья с обзором и доска
3) Hybrid Productivity - статья с обзором и доска
4) A Human-Centered Approach to Developer Productivity - статья с обзором и доска
5) Measuring Developer Goals - статья с обзором и доска
6) Software quality - статья с обзором и доска
7) AI-Enhanced API Design: A New Paradigm in Usability and Efficiency - статья с обзором и доска
8) Secure by Design at Google - статья с обзором и доска

В общем, я как опытный пользователь Unidraw могу отметить, что инструмент уже работает хорошо, а также в него постоянно доезжают новые фичи:) Кстати, фичу с прямоугольными стикерами сделали по моей просьбе - она мне нужна была как раз для переезда на Unidraw с моими обзорами статей и книг:) Спасибо ребятам, что создали инструмент и продолжают его дорабатывать!

У инструмента есть свой канал t.me/unidrawio и чат для пользователей t.me/unidrawiochat, так что у пользователей есть возможность быть в курсе новостей и доносить обратную связь напрямую команде.

#Data #Visualization

Architecture Modernization: Aligning Software, Strategy & Structure • Nick Tune • GOTO 2024 (Рубрика #Architecture)

Интересный и полезный доклад на тему модернизации архитектуры существующих систем от Nick Tune, principal consultant at Empathy Software. Если сократить доклад, то тезисы примерно такие:
- Успешным компаниям часто требуется модернизация архитектуры, так как их прежняя архитектура: предназначена для меньшего объема клиентов и не тяент нужную нагрузку, опирается на старые технологии, которые не позволяют добавлять фичи с нужной скоростью. В итоге, модернизация может превратить недостатки в достоинства
- Такая модернизация касается не только технических вопросов - на самом деле надо оценивать весь стек от UX до глубоких бекендов, включая огрструктуру и процессы работы сотрудников
- В модернизации могут помочь разные инструменты, но автор выделяет следующие 5 штук
1) Listening Tours - сюда обычно входят опросы, интервью с сотрудниками, фокус-группы, gemba и так далее. Задача в том, чтобы услышать своих сотрудников
2) Impact mapping - это простая методика совместного планирования для команд, которые хотят добиться большого эффекта с помощью программных продуктов.
3) Wardley mapping - это карта бизнес-стратегии, где компоненты располагаются по оси Y, что обозначает положение в цепочке создания стоимости и привязаны к потребностям пользователя, а ось X описывает эволюцию компонентов (от зарождения до commodity)
4) Event storming - это крутая техника проведения воркшопов для коллаборативного изучения сложного бизнес домена, про которую я уже рассказывал
5) Modernization strategy selector - модель выбора оптимальной стратегии модернизации для каждой подсистемы, которая позволяет использовать портфельный подход к модернизации, где оптимальный возврат инвестиций может быть определен на гранулированной основе для достижения оптимального общего возврата инвестиций в модернизацию.
- Ну и напоследок автор говорит о том, что для старта надо выбирать область, где модернизация может принести обозримые результаты за ограниченный промежуток времени. В общем, надо уметь срывать низковисящие плоды - это позволяет показать, что модернизация может приносить пользу, а не превратится в очередное бесконечное начинание без конца и без края и без ощутимых результатов:)

#Management #Software #Engineering #SoftwareDevelopment #Processes #ChangeManagement #Strategy #Architecture

A Brief Outlook of Enterprise Architecture Role in the Digital Age (Рубрика #Architecture)

Когда я выбирал научные статьи с research разделов bigtech компаний, то мне казалось, что большая часть whitepaper интересна. Но тут я решил поискать материалы про enterprise architecture в ACM Digital Library и нашел ... Пока ощущение от их чтения грустное. Конкретно в этой статье 2022 года от Ахмеда из Египта (Ahmed S. Elsheikh) сделано все достаточно топорно и как-то механистически, но давайте ниже я расскажу подробности

1) В абстракте автор начинает с того, что с 1980х годов корпоративная архитектура существует как отдельная дисциплина, которая помогала бороться со сложностью
2) Но с 2010х годов появилась отдельная волна цифровых трансформаций (digital transformation), которая привела к волне подрывных инноваций и бизнес и технологические ландшафты изменились навсегда:)
3) Автор решил исследовать как эти две волны связаны межжду собой через исследование статей на тему digital enterprise architecture
4) Для начала автор рассказывает про святую троицу: Enterprise architecture => TOGAF => Archimate, где корпоративная архитектура - это околонаучная дисциплина, TOGAF - это фреймворк, а Archimate - это фреймворк для моделирования архитектуры. Дальше автор рассказывает про application portfolio management strategy, capability architecture и capability-based planning
5) Но возникает вопрос как это все добро применять с цифровизации, цифровой трансформацией и другими историями про трансформаторов и трансформации:)
6) Автор погуглил словосочетание "digital enterprise architecture" в Clavirate "Web of science" и нашел 55 статей
7) Дальше автор взял базовую статистику по году выхода, авторам, количеству цитат и построил графики - походу статья без графиков не очень научна
😍 Из графиков видно, что с 2015 года пошли не разовые публикации, а косяком, где в 2017 году был пик в 10 публикаций, дальше небольшое проседание и в 2021 году был новый рекорд в 14 публикаций. Из этой статы видно, что исследователи корпоративной архитектуры сразу подхватили тренд цифровой трансформации:)
9) Дальше автор разбил эти 55 статей по 3 группам, выделив отсечку по количеству отсылок к публикациям (количество цитат из них)
10) Получилось 3 группы:
- Взаимное влияние корпоративной архитектуры как отдельной дисциплины и цифровой трансформации как отдельной волны подрывных технологий и бизнес потребностей в одно и то же время
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать корпорации, что цифровые и глобальные одновременно
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать цифровые трансформации в разных контекстах и секторах индустрии
11) Автор кратко буквально в одной строке характеризуют каждую статью из этих групп (очень глубокая проработка материала)
12) Напоследок автор формулирует направления для исследования примерно так
- Связь между глобальными цифровыми корпорациями и конкретные трансформации, например, корпоративная архитектура может отличаться между индустриями
- Не хватает некоторых логичных областей (указанные три категории выше не закрывают все сценарии)
- Как отличаются корпоративные архитектуры, когда в основе цифровых трансформаций разные подрывные технологии (автор делает отсылку к блокчейну и бигдата - чуток подпротухшими сейчас кажутся предложенные автором disruptive technologies)
- Как фреймворки для корпоративной архитектуры и фреймворки для цифровых трансформаций (походу и такая дичь штука есть)

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

P.S.
А я подумал, что лучше бы я прочитал еще одну научную статью от Google:)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment

Обзор paper "Defining, measuring and managing technical debt" (Рубрика #Architecture)

Я продолжаю читать и писать о статьях из серии developer productivity, о которых рассказывал в обзоре первого whitepaper "A Human-Centered Approach to Developer Productivity". В третьем whitepaper с заголовком "Defining, Measuring, and Technical Debt" речь идет про технический долг и как он влияет на продуктивность разработчиков. Эта тема часто поднимается, но редко когда можно услышать четкое определение термина, а также объяснение как его считать и что с ним делать. Авторы решили закрыть этот пробел и написать как с этим дела в Google. А я решил сделать обзор этой статьи.

#Architecture #Software #Management #Leadership #Engineering

Как формировать структуру команд под запросы бизнеса (Рубрика #Management)

Недавно меня позвали выступить на митапе с этой темой, которую я рассказывал на YaTalks в 2023 году. Это знаковое для меня выступление, так как я делился основами и принципами дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф. Это приглашение показалось мне отличной причиной рассказать сразу и продолжение о том, как за 2023 и 2024 года мы трансформировали мое подразделение в 1000 инженеров в 5 отдельных самостоятельных технических доменов со своими engineering директорами. Но оказалось, что я не сделал краткого саммари прошлого выступления. Поэтому я решил исправиться и написать расшифровку (а видео досупно на youtube).

В итоге, я сегодня выступаю на митапе в Selectel, где расскажу сокращенную версию доклада про оргдизайн с фокусом на тимлидах, а вот продолжение расскажу на одной из следующих конференций - просто вся история с продолжением не влезла в тайминг + не очень попадает в целевую аудиторию митапа.

Вот список рекомендаций для дальнейшего изучения
Принципы и подходы
- Backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про проектный и продуктовый подход у меня есть хорошая статья
- Про Kanban рекомендую почитать пару книг: “Визуализируйте работу” (“Making Work Visible”), про которую я рассказывал, а также "Канбан Метод. Базовая практика", про которую я тоже рассказывал
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал
Отдельные выступления про их применение
- В 2019 году на ArchDays я рассказывал про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- В 2021 году на Techlead Conf я рассказывал про то "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В 2022 году на Highload++ Spb я рссказывал доклад "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Обложки для книг "Continuous API Management, 2nd Edition" и "Непрерывное развитие API"

Continuous API Management, 2nd Edition (Непрерывное развитие API) (Рубрика #Architecture)

Второму изданию этой книге уже порядка 3х лет, а читал я ее последние несколько месяцев и только недавно закончил. Книга мне действительно понравилась и я решил поделиться с читателями канала. В этой книге 12 глав, которые закрывают многие вопросы, связанные с governance, которые обобщаются дальше вопросов управления API

1. The Challenge and Promise of API Management - зачем компании хотят управлять своими API, какие проблемы при этом возникают и какие возможности это дает. Здесь авторы рассказывают в общем об основных вопросах, рассмотренных в книге. Отдельно отмечу важность разделения для API интерфейсов (контракты), имплементации (код) и развертывания (инфра)
2. API Governance - глава с фундаментальными концепциями для управления API и какое это значение имеет для принятия решений
3. The API as a Product - глава про важность восприятия API как продуктов (API as a Product). При этом на API можно смотреть с точки зрения целевой аудитории и принимать решения, которые являются лучшими для них
4. The Pillars of an API Product - основные колонны, на которых основаны API. Авторы выделяют следующие области, которые рассматривают детально: strategy, design, documentation, development, testing, deployment, security, monitoring, discovery, change management
5. Continuous API Improvement - глава про то, как жить с непрерывными изменениями и как ими управлять
6. API Styles - здесь авторы рассказывают об основных стилях, которых они насчитывают 5. Вот они: tunnel style (RPC), resource style (REST), hypermedia style (RESTful), query style (graphql), event-based style
7. The API Product Lifecycle - жизненный цикл одного API, который состоит из этапов: create => publish => realize => maintain => retire ... Авторы подробно разбирают как на каждом этапе требуется прорабатывать конкретные pillars
8. API Teams - какие роли нужны в командах для эффективного развития API как продукта. Причем не просто в вакууме, а в зависимости от зрелости самого API
9. API Landscapes - здесь авторы переходят от единичных API к их множеству, которое можно воспринимать как ландшафт. Авторы рассказывают про API Management at Scale, который опирается на принципы, протоколы и практики. Это очень сильно пересекается с paper "API Governance at Scale" от Google, про которое я рассказывал раньше. Плюс авторы вводят модель 8v, которая позволяет управлять ландшафтом, ориентируясь на разные ракурсы. Вот эти восемь V: variety, vocabulary, volume, velocity, vulnerability, visibility, versioning, volatility
10. API Landscape Journey - рассказ о том, а как внедрять API Governance. Авторы предлагают модель enabling team, которая поможет внедрить и раскатить процессы API Governance на всю организацию
11. Managing the API Lifecycle in an Evolving Landscape - здесь авторы пересекают pillars и 8vs и рассказывают о том, как они связаны между собой
12. Continuing the Journey - последняя глава подводит итог книге и готовит читателей к старту Continuous API Management внутри компании

P.S.
Обложки книг представлены в следующем посте.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Обзор whitepaper "API Governance at Scale" (Рубрика #Architecture)

Я дописал обзор статьи про API Governance от ребят из Google, про которую я уже несколько раз упоминал (1 и 2). В общем, статья получилась интересной и полезной - ее подходы хорошо масштабируются за границы governance именно API, например, мы многое из этого пытаемся применять в процессах architecture governance на уровне компании. В общем, читайте статью, а в следующий понедельник по ней выйдет первая серия подкаста "Research insights made simple", где я буду ее обсуждать со своим коллегой Даниилом Кулешовым.

#Architecture #Management #Governance #SystemDesign #Software #Leadership

Массовое вымирание стартапов: что происходит на глобал tech-рынке и как это влияет на рынок труда (Рубрика #Management)

Интересное интервью Дениса Калышкина, венчурного инвестора из фонда I2BF (инвестируют в американские стартапы) Кире Кузьменко из New HR
Обсуждение было сконцентрировано вокруг тем
— Вымирают ли стартапы или нет?
— Как инвесторы выбирают, куда инвестировать в текущей ситуации?
— Что происходит с внутренними стартапами в крупных компаниях?
— Как оценивать стартап кандидату, который хочет там работать?
— Когда будет дно кризиса и надолго ли текущий кризис с нами?
— Надо ли идти сейчас в предпринимательство вместо найма?

#Startup #Management #Leadership #Invest

Архитектура на старте: подготовка к успеху - Podlodka Techlead Crew (Рубрика #SRE)

Поучаствовал вчера в дискуссии на подлодке насчет проектирования надежных систем. В ней участвовали Олег Бондарь, Филипп Дельгядо и я. Мы поговорили про ключевые принципы для построения надежной архитектуры. Дискуссия была интересной и динамичной. Мы уделили много вопросам observability и я позвал всех участников на конфу T-Observability Day Tech 2024, что пройдет 23 октября в нашем московском офисе T-Space. Кстати, про конфу я уже рассказывал тут в канале

P.S.
Год назад я выступал на конференции с докладом "Проектируем надежные системы — стоит ли игра свеч", про который я уже рассказывал. И тот доклад был основан на солидном списке материалов
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Code of Leadership #21 "A Philosophy of Software Design" (Рубрика #Architecture)

Этот выпуск подкаста посвящен рассмотрению крутой книги Джона Остерхута "A Philosophy of Software Design". В разборе книги  помогает Григорий Скобелев, Java/Go techlead, чей основной профиль это highload приложения, также он является директором программного комитета Podlodka Techlead/Java Crew. А в свободное время он делает свой подкаст/книжный клуб - { между скобок }, LinkedIn

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

Продолжение обзора книги будет в следующей серии

#Architecture #Processes #Management #Leadership #Software #SystemDesign

Operationalize a Scalable AI With LLMOps Principles and Best Practices (Рубрика #ML)

Я уже давно заметил, что модность темы можно отследить по наличию связки somethingOps, вот дошла очередь и до LLMOps, про что рассказывается в недавней статье от DZone. Раньше уже была на хайпе темы
- DevOps - тема уже давно на хайпе (подробнее в книге "Accelerate", про которую я рассказывал), сейчас больше говорят про Platform Engineering
- DevSecOps - горячая тема, подробнее в книге "Agile Application Security", про которую я рассказывал или недавней статье "Secure by Design at Google", который я разбирал отдельно
- DataOps - давняя и актуальная тема про выстроенные процессы работы с данными. Они нужна как пререквизиты для эффективной работы над ML-моделями
- MLOps - это очень актуальная тема, которая включает набор практик, которые объединяют ML, DevOps и инженерию данных, которые направлены на создание, деплой и эксплуатацию ML систем в проде надежно и эффеективно. Интересно, что эту тему мы разбирали в выпуске подкаста "MLOps в теории и на практике"
Подробнее про XOps подходы можно посмотреть в докладе "The Pipeline-Driven Organization", про который я уже рассказывал

В этой же статье речь идет про подмножество MLOps подходов, которые сфокусированы именно на LLM приложениях, которые сейчас являются горячей темой. В приведенной ниже статье сначала приводится определение LLMOps. Дальше разбирается разница между MLOps и LLMOps по критериям на чем основной фокус, как выглядит адаптация моделей, оценка качества моделей, управление моделями, включая версионирование и метаданные, как модели деплоятся и как мониторится их работа. Дальше автор разбирает базовые характеристики LLM
- Что они существуют в разных формах: проприетарные модели с платными API, pre-training models, fine-tuned models
- Что существует так называемый prompt engineering, так как многие LLM принимают в качестве входа текст на естественном языке
- Иногда можно добавлять контекст к запросам пользователей (context-based prompt engineering:), чтобы повысить их эффективность, для чего используются новые инструменты, навроде векторных баз данных (про которые был недавно интересный доклад)
- Они достаточно большие, иногда сотни гигабайт, а также им может требоваться GPU не только для тренировок, но и для обработки real-time запросов
- Оценивать их качество достаточно сложно, поэтому часто надо встроить человеческий фидбек прямо в MLOps процесс для оценки и тестирования моделей

Ключевыми моментами приложений с LLM сейчас являются следующие моменты
- Prompt engineering, про который мы говорили выше
- RAG (retrieval augmented generation), который полагается обычно на уже упоминавшиеся векторные базы для семантического поиска, а также на feature store, где хранятся признаки.
- Fine-tuning LLMs - это процесс адаптации предварительно обученной LLM к сравнительно небольшому набору данных, специфичному для отдельной области или задачи.
- Pre-training a model from scratch - это что-то на богатом про процесс обучения языковой модели на большом массиве данных (например, тексте, коде) без использования каких-либо предварительных знаний или весов из существующей модели:)

Дальше автор показывает референсные архитектуры LLM приложений с RAG от Databrics, а финализирует плюсами и минусами LLMOps

+ Minimal changes to base model - большинство LLM приложений можно запустить поверх базовых моделей с небольшими изменениями
+ Easy to model and deploy - LLMOps как раз упрощает использование моделей
+ Advanced language models - можно начинать использовать сложные модели через API, а потом перейти open source модели
- Human feedback - в случае LLM обратная связь от людей необходима, что добавляет сложностей
- Limitations and quotas - при использовании внешних API надо понимать их ограничения и стоимость использования
- Risky and complex integration - при использовании внешних API надо понимать какими данными вы делитесь и насколько это ок

#AI #ML #Software #Architecture #Future