Gregor Hohpe (AWS Senior Principal Evangelist и автор популярных книг)

В продолжении предыдущего поста про доклад "Build Abstractions Not Illusions" хотелось вспомнить в общем про Грегора, который
1) Больше 20 лет назад написал книгу "Enterprise Integration Patterns", про которую я уже рассказывал. Эта книга описывала паттерны интеграции и до сих пор концепции из нее достаточно полезны
2) Успел поработать в Google, а сейчас работает в AWS в области FaaS (function as a service) и евангелирует использование AWS
3) Написал книгу "Cloud Strategy", но я ее еще не читал
4) В 2020 году написал книгу "The Software Architect Elevator ", про которую я тоже рассказывал. Книга посвящена роли архитектора в современных условиях, когда крупные компании занимаются переводом на цифру всего и вся
5) Недавно написал книгу "Platform strategy", что я только планирую прочиать

Но Грегор не только пишет книги, но и выступает на конференциях, причем про пару выступлений я уже рассказывал раньше
- The Magic of Platforms
- I Made Everything Loosely Coupled. Does My App Fall Apart?

#Architect #Person

Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part I

Постоянные читатели канала могли заметить, что я часто говорю про инженерные процессы и упоминаю так или иначе DevOps, SRE, Platform Engineering. Но у термина DevOps, который был про сближение разработки и эксплуатации очень быстро появлялись похожие по смыслу термины, но из своих областей: DevSecOps, DataOps, FinOps, ..., MLOps. Подробнее про эти метаморфозы можно посмотреть в докладе "The Pipeline-Driven Organization • Roy Osherove • GOTO 2022", про который я уже рассказывал. Но сегодня я хотел рассказать про простенький whitepaper 2021 года от Google Cloud на тему MLOps, раз уж у нас сейчас расцвет AI и ML:)

Сам документ состоит из трех частей
- Overview of MLOps lifecycle and core capabilities
- Deep dive of MLOps processes
- Putting it all together

В первой части приводится определение MLOps

MLOps is a methodology for ML engineering that unifies ML system development (the ML element) with ML system operations (the Ops element). It advocates formalizing and (when beneficial) automating critical steps of ML system construction. MLOps provides a set of standardized processes and technology capabilities for building, deploying, and operationalizing ML systems rapidly and reliably.

И показывается четкая связь между data engineering, app engineering и собственно ml engineering. Причем выстроенные процессы работы с данными нам нужны как пререквизиты для эффективной работы над ML моделями, а app engineering нужен для того, чтобы обученные модели хорошо работали в проде и сервили свои запросы.
В документе рассказывается про этапы процесса, которые напоминают стандартные истории из app engineering и devops, но с небольшой спецификой
- ML development - эксперименты с данными, выбор модели и архитектуры, оценка вариантов и выбор лучшего
- Training operationalization - выстраивание пайплайна обучения модели
- Continuous training - непрерывное обучение в ответ на новые данные, изменения кода или просто по расписанию
- Model deployment - развертывание модели (очень напоминает развертывание обычных приложений)
- Prediction serving - модель работает в проде и обрабатывает запросы (онлайн/оффлайн)
- Continuous monitoring - мониторинг работы модели (тут как обычные параметры работы приложения, так и отслеживание метрик эффективности модели, дрифта данных, изменения распределения процесса, что мы предсказываем)
- Data and model management - это центральная, сквозная функция управления артефактами ML, обеспечивающая возможность аудита, отслеживания и соответствия требованиям. Эта функция помогает с совместной работой, повторным использованием,и возможностью обнаружения какие ML модели уже есть и работают.

Продолжение про capabilties ML платформ во второй части поста.

#ML #Devops #Data #AI #Software #Architecture #Processes

Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning - Part II

Продолжая первый пост про этот whitepaper, надо рассказать про capabilities ML платформ, которые нужны для того, чтобы выстроить хорошие MLOps процессы:
- Experimentation - совместное выполнение исследовательского анализа данных, создание архитектуры прототипов моделей и реализация процедур обучения
- Data processing - возможность обработки данных, что позволяют готовить и преобразовывать большие объемы данных в конвейерах непрерывного обучения
- Model training - возможность эффективно и экономично запускать мощные алгоритмы для обучения моделей машинного обучения
- Model evaluation - возможность оценки модели в интерактивном режиме во время экспериментов
- Model serving - возможность развертывать и обслуживать модели в продакшен
- Online experimentation - возможность провести онлайн-эксперименты, чтобы понять, как недавно обученные модели работают в продакшене по сравнению с текущими моделями (если таковые имеются) перед выпуском новой модели в производство
- Model monitoring - возможность мониторинга моделей позволяет отслеживать эффективность и результативность развернутых моделей для обеспечения прогнозируемого качества
- ML pipelines - возможность выстроить сложные пайпланы для тренировки и эксплуатации моделей в проде
- Model registry - централизованный реестр моделей (регистрация моделей, описание зависимостей, документации и метаданные, интеграция с экспериментами и мониторингом, а также раскаткой и откаткой моделей)
- Dataset and feature repository - хранилище наборов данных и фичей позволяют унифицировать определение и хранение данных для ML моделей. Наличие центрального хранилища свежих высококачественных данных обеспечивает возможность совместного использования, обнаружения и повторного использования.
- ML metadata and artifact tracking - хренение различные типов артефактов ML, что создаются в разных процессах жизненного цикла MLOps, включая включая описательную статистику и схемы данных, обученные модели и результаты оценки

В итоге, объединяя capabilities платформ и понимая целевой необходимые шаги конвейра, можно собрать отличный процесс, где ML не будет оторван от работы с данными и разработки, а значит строить и эксплуатировать ML системы станет проще.

P.S.
Конечно читая между строк этого документа можно понять, что внутри Google Cloud есть ML платфома со всеми этими возможностями, что позволяет из коробки выстроить MLOps ... если вы используете нужное облако:) Но это не умаляет хорошего описания фреймворка для MLOps, который приведен в этой статье

#ML #Devops #Data #AI #Software #Architecture #Processes

Инструменты надежности Такси \ Александр Фишер, Яндекс Такси

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

Ну и в конце выступления автор рассказывает про экспериментальные инструменты
- Autorecovery - робот, что автоматически чинит инциденты (он пока в dry run работает и проходит обкатку)
- SRE GPT - инструмент для помощи в поиске root cause

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

#SRE #DistributedSystems #Reliability #Architecture #Software #Processes #Management

Как выглядит роль SDE в tech компаниях

Сегодня выступаю на нашем мероприятии для студентов из МФТИ, где я учился много лет назад.
У меня есть полчаса и я планировал обсудить кучу тем:
- Современные процессы разработки и инженерные практики в российских tech компаниях - расскажу про то, как все начиналось, потом появилась история с devops, потом shift-left everything и X+Ops:)
- Как выглядит карьерный путь SDE (software development engineer) с развилкой в менеджмент и путь individual contributor высоких грейдов
- Как выглядит матрица компетенций для SDE в Tinkoff
- Как выглядит процесс роста сотрудников внутри (Tinkoff рост)
- И другие полезные мысли про саморазвитие и рост внутри компании:
-- Как использование Cynefin фреймворка
-- Как работать над сложной проблемой (и создавать артефакты RFC/ADR)
-- Как приоритизировать задачи используя матрицу Эйзенхауэра
-- Как работать со своей мотивацией
-- Как планировать работу используя backcasting (это примерно тоже самое, что working backwards от Amazon)
-- Как работает мантра "You build it, you run it" и почему она помогает инженерам расти над собой быстрее

Интересно, что многое из сегодняшнего доклада мы обсуждали с Алексеем Тарасовым в рамках выпуска Code of Leadership пару недель назад.

P.S. Материалы к выступлению

Материалы по процессам разработки
- Современные подходы к разработке программного обеспечения
- Совершенствование потока разработки программного обеспечения
- Проектируем надежные системы — стоит ли игра свеч
- Про управление проектами и продуктами
- The Pipeline-Driven Organization • Roy Osherove • GOTO 2022
- Code of Architecture — “Distributed Systems, 4th Ed” #2 (Architecture)
- Архитектура в масштабе на ArchDays 2020
- Devops культура: мифы и реальность
- Про MLOps
- The State of Application Security 2023 • Sebastian Brandes • GOTO 2023
- Как RnD появляется в крупных ИТ-компаниях

Материалы по проектированию и system design
- Статья про System Design Interview в общем
- Статья про то, как мы оцениваем System Design Interview
- Статья о том, как подготовиться и пройти System Design Interview
- Публичное System Design Interview на C++ Russia 2022
- Публичное System Design Interview на конференции ArchDays 2022
- Статья со списком книг о проектировании программного обеспечения
- Курс Essential Architecture #Code
- Курс Essential Architecture #Data

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

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

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Software development engineers в tech компаниях

Вчера я выступал на конференции "IT PurpleConf" с докладом для студентов про современные ожидания от software development engineers в технологических компаниях. Само выступление в виде трансляции будет еще не скоро, поэтому я ближе к ночи записал выпуск подкаста и выложил на свой youtube канал TellMeAboutTech:) Подробнее про темы выступления во вчерашнем посте и там же есть список рекомендованных материалов.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career