Стафф-инженер

В книге "Staff Engineer: Leadership beyond the management track" Уилл Ларсон классифицирует роли стаффов по выполняемым задачам (в зависимости от особенностей и потребностей компании), выделяя 4 базовых архетипа:

1️⃣Tech Lead (технический эксперт): ведет проекты и команды, обеспечивая техническое руководство, сотрудничая как с командами так и с их менеджментом.

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

2️⃣Architect (архитектор): отвечает за направление и качество архитектурных подходов к критически важной области системы. Имея глубокую техническую экспертизу и учитывая запросы бизнеса и пользователей, проектирует гибкую, масштабируемую и устойчивую архитектуру.

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


3️⃣Solver (спецназ): глубоко погружается в сложную проблему и находит подходящий путь ее решения. Некоторые сосредотачиваются на определенной области в течение длительного времени (например выделяют сервисы из монолита 😉). Другие перемещаются из одной горячей точки в другую, руководствуясь приоритетами компании.

Может заниматься:
- исследованием узких мест в архитектуре, интеграции, коде систем с целью выявить слабые места
- выработкой возможных вариантов решения и их практической валидацией
- глубокой проработкой плана и его реализацией


4️⃣Right Hand (правая рука): оказываем помощь и поддержку руководителю команды в управлении, а так же консультирование по ключевым решениям.

Может заниматься: практически всем


🤔На мой взгляд стафф/принципал - роль очень гибкая, а решаемые задачи в первую очередь обусловлены потребностью компании.
На практике, ярко-выраженный стабильный архетип из списка для конкретного инженера выявить не получится, скорее это будет смешение разных вариантов, причем в разных пропорциях в зависимости от компании/отдела, ситуации и даже времени. Себя эпизодически вижу в каждой из категорий.

💡Дополнительно кратко отмечу ряд отличительных моментов работы стаффа/принципала, которые, по моему мнению, являются общими вне зависимости от архетипа:
- менторство: помощь коллегам в развитии, обучение (лекции, доклады, семинары), а так же поддержка команд в решении сложных задач
- исследования: прототипирование и отчетность, data-driven подход
- пропоганда: решений, технологий, участие в сообществе, формирование мнений

29 февраля в гостеприимном Санкт-Петербурге на Saint P Ruby Meetup Winter 2024 рассказал про запущенный проект "Аутентификации об монолит" (слайды и видео-запись)

💡Идея в том, чтобы дать возможность новым микро-сервисам обслуживать аутентифицированный трафик, и разблокировав реализацию новых фичей в обособленном сервисе (а не в монолите).

1️⃣Входящий трафик аутентифицируем "об монолит" отдельным запросом
2️⃣Заменяем оригинальные аутентификационный заголовки - внутренним X-Auth-Identity, в котором содержится результат аутентицикации
3️⃣Оригинальный запрос снабжаем аутентификационными данными (UUID пользователя)

На первый взгляд решение костыльное: поскольку изначально вся логика аутентификации находится в Rails-монолите, то и предлагаемое решение завязано на монолит. В этом смысле как будто ничего не меняется!

Но нет же! Можно еще хуже: пустить трафик в новый сервис через монолит, делегировав ему предварительную аутентификацию и роль API-гейтевея!

С такой перспективы все неплохо, тем более что предложенное решение:
- позволяет быстро абстрагироваться от монолита (как будто его вовсе нет)
- за счет унификации API на базе кастомных HTTP-заголовков не противоречит дальнейшему переходу к обстоятельному системному решению (чем обычно грешат временные схемы)

Более того, на личном опыт подтверждаю, что схема рабочая, как для запуска, так и для дальшейшего расширения в системное решение!

А сам подход универсальный, и может быть применен для монолитной архитектуры любого стека. Хотя в докладе добрая половина времени уделена специфике Rails-монолита.

Ссылку на слайды и видео-запись прилагаю.

Лучший друг любого профессионала (и стафф-инженера в том числе) - бесценный опыт и обширные знания, накопленные за годы работы. Удержать все в голове - не получится, и тут на помощь приходит Obsidian - редактор и навигатор для ведения заметок или даже инструмент для оформления, структуризации и работы с вашей базой знаний (зависит от степени знакомства).


1️⃣Это просто текстовый редактор (markdown) файлов на локальном компьютере. Парадоксально, что большая кривая развития сервисов заметок в итоге приводит нас обратно к файлам на локальной машине. А новизна и актуальность кроется в "принципе владения своими данными". Как пишут сами авторы:

Your thoughts are yours.

Никто не сможет отлучить Вас от знаний, когда они на локальной машине (это вам не сервер отключить)! А Если хочется поделиться - просто выгружаем заметку в PDF (экспорт работает отменно).

Простота редактирования обеспечивается форматом Markdown, знакомого любому разработчику. Нет сложности начать, никакого порога входа и противоречий.


2️⃣Заметки можно перелинковать между собой, делая отсылки к другим заметкам - киллер-фича 🔥, позволяющая выстроить работы с базой знаний по системе Цеттелькастен.


3️⃣Работа с данными не менее важна, чем формирование связной структуры. К примеру, Цеттелькастен предполагает регулярный просмотр всех заметок для освежения знаний. В реальности же чаще возникает внезапная необходимость найти определенную заметку. И тут Obsidian на высоте с быстрым и эффективным поиском и развитой навигацией.


Три пункта выше уже подкупают, хотя богатство возможностей Obsidian ими далеко не ограничивается. Если Вас заинтересовало - рекомендую цикл уроков на Youtube от "Теплицы Социальных Технологий".

Проецируя на профессиональную деятельность приведу несколько примеров использования заметок в моей базе знаний:

- 1:1 звонки с коллегами: на каждого собеседника отдельный файл, заголовками отмечаю дату звонка, фиксирую предмет обсуждения, новые для меня данные и достигнутые договоренности. Чтобы обсудить важную тему на предстоящем звонке - завожу заметку заранее.
- работа над проектами: артефакты по каждому проекту в отдельной папке. Тут складирую результаты встреч, обсуждений, ссылки на документацию, куски кода и архитектурных диаграмм. Помогает и как в случае ведения более одного проекта одновременно, так и в качестве архива знаний по завершенным проектам (к примеру, чтобы вспомнить и уточнить обоснование определенного технического решения).
- перформанс ревью: отдельные заметки, где я фиксирую успехи и достижения (свои и коллег) или просто логирую свою работу (о том, почему это важно рекомендую видео).
- подготовка к рабочим встречам: начинаю с формулирования тезисов, целей и задач, иногда доходит до написания полного текста всей речи и многократное вычитывание Если встреча важная а времени мало, нужно четко и емко формулировать мысль. После встречи документ можно переиспользовать как follow up.
- статьи/доклады на конференции: черновики, или уже оформленные. Обычно все идеи исходят из рабочих проектов. Удобно вести их рядом, снабжая ссылками на проектные активности. Даже если материал сырой - очень легко и быстро собрать все вместе, и на подготовку уходит меньше времени.
- план чтения: какие книги я планирую прочитать и в каком порядке. А так же заметки по уже прочитанным книгам, конспекты, собственные мысли или цитаты (как это делать правильно можно прочитать тут);
- план и идеи постов в этот телеграм-канал

❗️Абсолютное могущество получаем, когда с помощью Obsidian осмысленно перелинковываем заметки в связный граф собственной базы знаний!

Подготовится к докладу, ко встрече и тд - не вопрос, фактически материал уже в готовом виде, в легком доступе и всегда в вашем распоряжении!
Как говорится: "просто добавь воды" 😂.

Продолжая тему разберем теорию на вымышленном примере.

Дано:
Монолитное приложение, с историей заказов, логикой чекаута (офорление заказа) и т.д.

Задача:
Реализовать в сервисе систему лояльности с начислением бонусов клиенту:
- на каждый заказ по прогрессивной шкале начисляются бонусы (статус клиента)
- каждый месяц шкала обнуляется (статус сбрасывается)
- бонусы можно списывать при оформлении заказа.

0️⃣Монолитная реализация
Дефолтный паттерн делания фичи в монолите - внедрить в чекаут новый функционал:
- добавляем логику начисления бонусов с заказа
- шкалу определяем, обращаясь к истории заказов

1️⃣Идиоматичная реализация
Данные о заказах должны прилетать асинхронно из сервиса "Чекаута" (со-зависимый сервис) сразу после оформления заказа. Сервис лояльности (зависимый) накапливает данные о сумме заказа каждого клиента за месяц. Таким образом денормализованные данные минимальные данные о заказах клиента в лояльности являются проекцией данных на ограниченный контекст "лояльности".

Но, одновременно с запуском лояльности - требуется вынос из монолита чекаута (трудоемко), зато тех. долга минимум.

2️⃣Компромиссная реализация
На базе монолитного приложения (без выноса чекаута) запускаем топик с информацией об оформленном заказе (пунктир). Согласовываем с owner-командой чекаута: количество противоречий с идиоматичной версией контракта должно быть минимизировано.
После реализации топика (сделать его может любая из команд), продюсер в монолите передается на "баланс" команде чекаута.

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

3️⃣Синхронная реализация
Для расчета статуса клиента сервис лояльности ходит в БД монолита (может быть эндпойнт), и на базе не своих данных производит необходимые вычисления.

Сильная связность не позволяет назвать сервис автономным.

💡Но даже такой вариант - это уже первый шаг к автономности. Но дальше нужно двигаться 3, 2, 1.

Намерения реализовать новую бизнес-логику автономно за рамками монолитной архитектуры часто разбиваются об отсутствие данных (назовем это явление missing data source или сокр. MDS).

Missing Data Source - это необходимый и отсутствующий на момент выноса/реализации нового сервиса (зависимый сервис) источник данных (пр. kafka-топик, эндпойнт в монолите/сервисе, подключение к БД). В целевой архитектуре источником выступает отдельный (со-зависимый) сервис, может отсутствовать на момент реализации (не вынесен из монолита).

В такой патовой ситуации важно обозначить у обоих будущих сервисов owner-команду (на основании составленной карты bounded-контекстов).

💡Исходя из ситуации есть 3 стандартных подхода решения MDS (отсортированы от правильно-долгого к ужасно-быстрому):

1️⃣Идиоматичный
Необходимые данные передаются асинхронно в со-зависимый сервис, отвечающий за локализованную предметную область.

Плюсы: продуманная сервисная реализация, надежно, стабильно, автономно.
Минусы: долго, чтобы сделать сервис, нужно вынести сначала со-зависимый сервис.

2️⃣Компромисный (отложенный перенос)
Сделать "временный топик" на базе монолита, сделав его контракт максимально совместимым с первым вариантом. В перспективе, при выносе зависимого сервиса продюсер данных переедет в него. Вполне идиоматичный вариант, если представить монолит - как большой сервис.

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

3️⃣Синхронный
Реализуем временный API-на базе монолита (или ходим напрямую в его БД).

Минусы: получаем синхронную интеграцию и сильную связность, со всеми вытекающими

Из-за зависимости одного несуществующего сервиса от другого, на практике сделать сразу идиоматично может быть сложно.


⁉️А выбор способа отвязки сводится к решению owner-команды со-зависимого сервиса (источника данных) о степени своего участия в проекте, обратно пропорциональной объёму совокупного тех. долга:
- готова вложится во избежание тех. долга - делаем красиво (1)
- готова удилить внимание и согласовать контракт - идем на компромисс (2)
- не готова помогать - используется синхронный вариант (3)

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

Channel name was changed to «Стафф-инженер»

В книге "От монолита к микро-сервисам" Сэм Ньюман описывает несколько типовых целей перехода в микро-сервисную архитектуру:
 - повышение автономности команд
 - сокращение TTM (time-to-market)
 - эффективное масштабирование
 - повышение отказоустойчивости
 - поддержка роста компании
 - внедрение новой технологии

❗️Губительным же для проекта перехода автор считает как отсутствие цели, так и желание достичь множество целей одновременно. По этому поводу автор высказывается:

Однако в реальности люди часто пытаются изменить не одну вещь, а сразу много. Это приводит к путанице приоритетов, быстро увеличивается объем работ, задерживая получение каких-либо выгод.

К примеру, мы решаем, что изменение архи­тектуры приложения позволит справляться с  ростом трафика: "Ну, если беремся за микро-сервисы, то одновременно с этим можем сделать команды автономнее! И это дает нам отличный шанс попробовать Kotlin в качестве языка программирования!" 

Прежде чем вы придете в себя у вас уже будет масштабная инициатива внедрения множества новшеств, которые накинули к плану работ "для верности".

В такой ситуации микро-сервисы становятся запертыми как подход!

Важно отделить мотивирующий стержневой мотив от любых вто­ростепенных выгод, которые вы также хотели бы получить. В описанном примере масштабирование системы - самый важный мотив. Остальные работы, не направленные на достижение главной цели, должны отойти на задний план.

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

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

Кажется все просто, но на деле появляется ряд второстепенных требований, которые, не будучи основным мотивом, кратно увеличивают сроки проекта из-за возрастающей когнитивной нагрузки:
 - перейти на другой стек: к примеру декомпозируем Ruby-монолит в сервисы на Golang. Для выноса сервиса необходимо разобраться в текущей реализации, локализовать ее и перенести код. У рубистов дополнительная когнитивная нагрузка появится в последнем пункте, у голанг-разработчиков - сразу в первом.
 - исправить в процессе переезда ошибки и уязвимости. Изменение в поведении системы ведут к невозможности сравнить обе реализации (монолитную, как эталон, и новую сервисную). Приходится держать в уме эту "разницу". А если фиксов много?
 - улучшить перформанс или кардинально поменять бизнес-процесс, и как следствие обоих пунктов, - сделать новую систему, идеально заточенную под актуальные требования. Проблема проявится при интеграции "нового подхода" со старым, и прийдется временно адаптировать новое под старое.

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

Последний пункт не очевидный, но в разы ценней первого: регулярное обращение к приоритетам - помогает избежать расфокуса, не потерять понимание, и не упустить смысл в процессе.

Прочитал и рекомендую шикарную книгу А. Пиперски "Конструирование языков. От эсперанто до дотракийского" - лингвистический реверс-инжениринг!

Повествование строится вокруг гипотезы Сепира-Уорфа, о том, что мышление определяется языком, и когнитивные категории и ограничения мышления определяются лингвистическими факторами (язык влияет на мышление людей, говорящих на нем).

В книге приводится разбор ряда искусственных языков, разработанных для определенных целей. Мне запомнились несколько:
- Токипона - язык из 120 слов базовых слов, все остальные получаются декомпозицией смысла на простые составляющие. Само название языка "toki pona" состоит из слов toki ‘язык, говорить’ и pona ‘хороший. Назначение токипоны — научить людей разлагать мысли на базовые составные части и благодаря этому мыслить более философски и глубже понимать мир.

- Сольресоль - базирующийся на музыке универсальный язык, призванный снизить языковой барьер между носителями разных языков. Все слова в языке составлены из слогов — названий нот (до, ре, ми, фа, соль, ля, си). По замыслу создателя языка, словам можно передавать самыми разными способами: с помощью слогов, наигрывая ноты 🎼 или даже с помощью цветов.

- Ифкуиль - многогранный искусственный язык со сложной грамматикой (96 падежей) и фонетикой (7 тонов, изменение высоты голоса может изменять смысл), предполагающий - увеличение скорости мышления: выражения лаконичней, смысловая нагрузка в единицу речи - больше. Естественно при условии овладения языком в совершенстве (примеров не приводится). 😉 Если заинтригованы - читайте статью "Скорость мысли" из далекого 2004 в журнале "Компьютерра".


Так же автор выделяет и доступным языком рассказывает о различных классах языков: на основе символов, к примеру, язык дорожных знаков 🚫 ; или артленги (языки вымышленных миров в художественной литературе и кино).

❓Вы спросите, причем тут разработка и инженерия? Вот несколько разнонаправленных мыслей-проекций на проф. деятельность:
- как рубист, я под другим углом посмотрел на язык. Идеальный инструмент для прототипирования и быстрого написания бизнес логики. А раз так, требовать от "носителей" этого языка глубоких знаний виртуальной машины/аллокаций памяти, может быть не всегда уместно. Это как требовать от водителя - знания, как работает ДВС и как провести его капитальный ремонт. Если знаешь - ты крут! Но ездить можно и без этого.

- наш словарный запас во многом определяет наше сознание, представьте, если бы в лексиконе не было слова "монолит", которое имеет скрытый негативный окрас. Либо для его описания приходилось бы декомпозировать мысль: "большая-система-написанная-множеством-людей-плохо-поддающаяся-масштабированию"

- почему монолит в русском языке это он? (мужского рода), а "архитектура" - это она (женского рода). Может поэтому мы к нему суровы, а к архитектуре относимся бережно. А архитектура в монолите - это что-то непозволительное!

- дальше-больше, немного последив за собой задаешься вопросом: в чем разница между "задачей в Jira - задачкой в Jira", "сервисом - сервиском". Это уменьшительно ласково, или пренебрежительно ласково?

- насколько лично я владею русским языком, чтобы четко и ясно выражать коллегам свою мысль?

Помимо концентрированного эстетического удовольствия от чтения книги и лингвистических задач из нее, такого рода мысли вас ожидают после прочтения (ссылка на книгу).
И в заключение, цитата от автора: "В наши дни шанс стать общепринятым стандартом имеют эмодзи, но посмотрим, как сложится их судьба 🤔."

👋Привет! Меня зовут Дима Салахутдинов, я - staff-инженер и Ruby-разработчик. Занимаюсь развитием Ruby-платформы, а так же масштабированием монолитной системы через выделение из нее новых микро-сервисов.

Как разработчик, сделавший выбор в пользу развития компетенций в технической ветке (staff+ на изображении) в противовес управленческой, я столкнулся с тем, что классифицировать роль staff-инженера сложно: невозможно дать четкого и емкого определения (или оно займет целую книгу).

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

Возможно будет интересно, присоединяйтесь! 🙂

Channel photo updated

Channel created