Is Software Engineering Real Engineering? • Hillel Wayne • GOTO 2023

Это выступление Hillel Wayne пытается ответить на философский вопрос: software engineer - это тварь дрожащая или право имеет называться инженером:) Этот вопрос появился из цитат ученых по computer science навроде цитаты Gerald Weinberg

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.

Ну и в тему этой цитаты автор вспоминает историю с leftpad.

Для поиска ответа автор пошел через опросы настоящих инженеров, которые одновременно работали в области software engineering, а дальше устроил им интервью с тремя вопросами

I. Are we really engineers?
II. How similar are we to engineers?
III. What can we learn from each other?

1) Первый вопрос потянул за собой выяснение термина "engineering", на который было три варианта ответа: physical, consequential, licensed. Дальше автор разбирает каждый пункт и приводит примеры, отвергая все гипотезы. В итоге, остается самое простое, что engineering - это то, что делают инженеры ("what engineers do"). Забавная рекурсия:) Тут еще автор проходится по подходу "Software craftmanship", в котором авторы пытались отстроится от традиционных инженерных дисциплин (без понимания того, как они работают).

2) Дальше автор переходит к сходствам и отличиям между software engineering и традиционными инженерными областями. В итоге, получается, что
- В сходствах: итеративность, высокая степень непредсказуемости, неформальность (в традиционных дисциплинах не всегда)
- В различиях: скорость изменений - быстрая в software и медленная в традиционных инженерных дисциплинах, наличие жестких ограничений (в традиционных дисциплинах - это законы физики), консистентность - в диджитал мире корректно написанная программа будет работать, а в реальном мире работоспособность зависит от окружающих условий (температура, давление, ветер, ...)
В общем, тут тоже отличия не критичны.

3) Ну и последний вопрос, а чему мы можем научиться друг у друга
Здесь автор отмечает два момента:
- Up-front planning time
- Responsibility
Забавно, что с этим сталкиваются все, кто проектируют API и контракты, систему плагинов или любой as-a-Service продукт.

В итоге, автор приходит к выводу о том, что если мы хотим себя называть инженерами, то никто нам не может помешать это делать:)

#Management #Leadership #Engineering #Software #Philosophy

Code of Leadership #6 Staff+ инженеры, архитектура и SDLC

Вот только дошли руки сесть и написать статью с расшифровкой нашего общения с Лешей Тарасовым про инженеров высоких грейдов, которые в западной практике называются Staff+. В этом выпуске мы вместе с Лешей обсуждали как выглядит матрица SDE (software development engineer), какие треки развития есть у инженеров, как выглядит процесс роста внутри и найм сотрудников снаружи. Также ближе к концу дискуссии мы обсуждаем один из этапов собеседований, который называется "Architecture & SDLC", который мы проводим для кандидатов на Staff+ уровень.

Для любителей послушать выпуск есть аудиоверсия, а для любителей посмотреть - видеоверсия подкаста.

Ну и напомню, что многое из этого выпуска я уже рассказывал в других выступлениях и статьях
- Архитектура в масштабе на ArchDays 2020
- System Design Interview на ArchDays 2021
- Как подготовиться и пройти System Design Interview на ArchDays 2022
- Варианты роста инженера, если он уже Senior на Tinkoff Meetup 2023
- Как нанимать технических руководителей на Teamlead Conf 2023
- Книга Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2

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

Code of Leadership #8 - Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)

В восьмом выпуске подкаста Code of Leadership я пообщался со своим коллегой, Андреем Цыбиным, техническим директором продуктовой аналитики и a/b платформы в Тинькофф. В этом интервью Андрей вспоминает с чего начинался его путь в компании, как он занялся Statist, который изначально предназначался для метрик производительности, а потом стал полноценной заменой Amplitude и стандартом де-факто в Tinkoff. В этом выпуске мы не стали говорить про нашу a/b платформу, поэтому в следующем интервью где-то через полгода Андрей расскажет про нее отдельно.

#Management #Software #Processes #Analytics #Engineering #Leadership #Architecture

Стажировки в Тинькофф (Тинькофф Старт)

Открылась очередная программа стажировок в Тинькофф. В этот раз набор идет на 16 направлений: ML-разработка, Java, Python, Go, SRE, .NET, Scala, Android, iOS, Frontend, QA, DWH, Аналитика, Маркетинг, Дизайн, помощник персонального менеджера в Инвестиции.
Стажировки у нас оплачиваются и во время них вы будете работать над реальными задачами, у вас будет ментор, который поможет вам адаптироваться, а по итогам лучшие стажеры будут приглашены в штат компании. Стажироваться можно в рамках гибкого графика - от 20 часов в неделю, удаленно или в офисе, в России или в соседних странах (Беларусь, Казахстан).

Для попадания на стажировку надо будет пройти экзамены, которые начнутся в конце марта. Экзамены для разных направлений различаютсяя, подробнее можно почитать на странице с описанием программы. А стартовать стажировку можно будет ближе к лету (это позволит совмещать это с учебой).

#Career #Software #Engineering

Modern Platform Engineering: 9 Secrets of Generative Teams • Liz Fong-Jones • GOTO 2023

Интересный доклад от Liz Fong-Jones, Field CTO из Honeycomb. Сначала Liza вспоминает что такое DevOps, потом SRE, а потом переходит к теме Platform Engineering.
В части про devops идет речь про стремление к culture, automation, lean, measurement и sharing. А DORA метрики позволяют измерить насколько хорошо это получается у команд. Но эти метрики имеют ряд проблем:
- Путь улучшений не слишком ясный
- Сами улучшения сложно померить (плюс мы измеряем запаздывающие показатели)
- Есть дилемма с самой моделью зрелости и непрерывными улучшениями (модели зрелости предполагают, что можно попасть на определенный уровень зрелости, а дальше уже улучшаться не требуется - кстати, в "Accelerate" для решения этой проблемы предлагали использовать capabilities model - я рассказывал про это в обзоре книги)
- Как достигать консистентности в разных командах

В итоге, Liz предлагает модель с 9 секретами, что способствуют генеративной культуре по Веструму (я уже писал про этот подход к типизации культур)
1. Reproducible deploys (If it ain't in Git it don't exist!) - нам нужна повторяемость в сборках и деплоях. Про это шла речь еще во времена появления 12 factor app, а сейчас это стандарт де-факто:)
2. Fast CI/CD (I wanna go fast!) - ускоряем циклы обратной связи, помогаем разработчикам быстрее видеть результаты своего труда.
3. Observability (Don't drive with snow on your windshield!) - дефолт для понимания того, что происходит с нашим приложением. Без этого не ясно как определять наличие проблем, а также траблшутить их.
4. Feature flagging (Smaller boom, less fear!) - в комплекте с TBD (trunk-based development) позволяет правильно делать CI (подробнее в докладе)
5. Code ownership (You build it, you run it! (with a twist)) - мантра, которая убирает забор между dev и ops (sre) командами. По-факту, SDEs (software development engineers) владеют не только кодом, но и самим приложением, что крутится в продакшене
6. Blameless culture (No one wins the shame game!) - здесь посоветую сразу несколько статей и выступлений
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)
Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
7. Service level objectives (SLOs) (If you liked it you shoulda put an SLO on it!) - про это я говорил в докладе "Проектируем надежные системы - стоит ли игра свеч"
8. Chaos Engineering (Test your assumptions!) - рекомендую на эту тему глянуть выступление Kelly Shortridge "Practical Magic: The Resilience Potion & Security Chaos Engineering"
9. Platform teams (to tie it all together and systematise it) - рекомендую почитать книгу Team Topologies про team-first подход при проектировании архитектуры программных систем, так и организации. В ней очень хорошо рассказывается про платформенные команды. А вот как сама Liz характеризует эти команды

Platform teams outsource as much as possible, write as little code as possible.
Platform teams are experts in outsourcing. It’s a very high-leverage role; they use their infra expertise to offload as much operational burden as possible.

В итоге, в модели Liz платформенные команды помогают всем остальным 8 пунктам и позволяют построить генеративную культуру и высокоэффективные команды.

#Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #Devops #PlatformEngineering #Process #Culture #SRE

Аудиоподкаст "Code of Leadership" на Я.Музыке

Многие просили сделать аудиподкаст в каком-то удобном месте. Я сначала завел его на podster.fm, а потом заполнил заявку в Яндекс Музыке на добавление подкаста и ... забыл об этом. Но ребята из Я.Музыки не забыли ... Вчера после очередного комментария на Youtube на тему того, что нужна аудиоверсия в VK или Яндекс Музыке, я решил проверить как поживает моя заявка и увидел, что подкаст уже есть:) Так что теперь можно слушать аудиоверсию подкаста в фоне и в привычном интерфейсе.

#Management #Leadership #Processes #Software #Engineering #Architecture

Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023

В этом докладе Gregor Hohpe говорит про абстракции и их пользу, а также как чрезмерное абстрагирование и исключение важных вещей приводит к созданию иллюзий (и протекающих абстракций).
- Intro - автор показывает свой стандартный пример с различными географическими картами, которые отличаются в зависимости от цели и аудитории.
- Platform abstraction - автор переходит к platform abstraction и вспоминает про уменьшение когнитивной нагрузки для пользователей платформы. И тут появляется аналогия с машинами и платформами, которые использовались в автомобильной индустрии для выпуска машин разных марок на базе одной "платформы". Это позволяло экономить, разработав качественную платформу и переиспользовать ее для разных продуктов
- Abstractions vs composition - Автор продолжает приводить примеры из области автомобилестроения и говорит про педаль газа (хотя это скорее не педаль газа, а педаль ускорения, что еще очевиднее, если мы рассматриваем элетрические автомобили). Дальша он приводит SQS-Lambda-SQS из AWS, а потом переходит к паттерну scatter-gather pattern, который изначально назывался broadcast aggregate. Проблема в том, что в этих случаях описывается не сама абстракция, а ее реализация. Дальше автор рассказывает про электрическую розетку, которая является отличной абстракцией и автор объясняет почему (разделение интерфейса и реализации, стандартизация интерфейса, ...). Но даже электрическая розетка протекает как абстракция, если происходит глобальное отлючение энергии (в розетке заканчивается ток). Ну и напоследок автор говорит про абстракцию сокетов (sockets и packet routing). В итоге, автор говорит про то, что композиция бывает полезна, но она отличается от абстракции, так как объединение элементов в этом случае не предоставляет новую абстракцию
- Abstractions vs Illusions - Автор описывает абстракции, которые зашли слишком далеко. Например RPC (remote procedure call), который он описывает так, как было принято в начале 2000х, когда RPC пытались сделать похожим на локальный вызов и скрыть всю сложность. С тех пор утекло много воды и так никто не делает, но вьетнамские флешбеки Грегора тут выглядят странно. В итоге, проблема описывает так, что в иллюзиях мы выкидываем важные детали или излишком обобщаем до состояния, когда наша модель начичнает вводить людей в заблуждение. Дальше автор рассказыывает про абстракцию платформ. Интересно, что как представитель AWS он катит бочку на создателей IDP (internal developer platform) внутри компаний поверх публичных облаков - по мнению Грегора часто это не добавляет никакого value, а только отнимает его (мне эти аргументы кажутся очень biased). И дальше Грегор показывает хорошую по его мнению абстракцию в виде ledger database из двух dynamo db и event bridge pipes посередине. Суть этих размышлений сводится к тому, что IDP внутри компаний должны не просто уменьшать возможности публичных сервисов, закручивая гайки, а скорее создавать новые абстракции, которые полезны для пользователей внутри компании. И дальше автор говорит, что "good abstractions support broad usage".
- Distributed system abstractions - В этой части автор напирает на асинхронную работу с сообщениями (asynchronous messaging) и добавляет к абстракции data flow еще и control flow, который бывает полезно понимать. Речь идет примерно про puller, pusher, pool и driver
Ну а дальше Грегор показывает как понимание работы control flow позволяет сделать стандартные абстракции полезными
- Summary - в заключение Грегор подводит итог и говорит, что

Good abstractions reduce cognitive load because they form a cohesive language and a mental model.
Omitting relevant details is tempting but leads to dangerous illusions.

#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems

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