Про сон

Фундаментом здоровой продуктивности (в смысле без веществ) является нормальный сон. Если спишь хорошо - это даёт базу, на которой можно уже строить другие дела. Если спишь плохо - все техники продуктивности мира будут иметь минимальный эффект.

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

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

Ну ладно, я пошел спать, всем спокойной ночи)

Еще немного про платформы

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

Платформа - это такая ИТ-система, которая решает комплексные задачи, решения которых в свою очередь важны другим системам для предоставления ценности конечному пользователю. По-простому, это такая система, которая дает некий функциональный фундамент, используя который другие системы могут сделать что-то, что даст ценность уже конечному клиенту. А клиент за нее заплатит.

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

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

Например, многим системам нужна ролевая модель и управление доступами - го сделаем IAM-платформу (Identity and Access Management), чтобы каждый не изобретал свой велосипед. Или многим системам нужен качественный мониторинг - го сделаем платформу наблюдаемости, чтобы к ней легко подключались и не ломали голову над своими мониторингами каждый раз. Или нам нужно каждый раз поддерживать мультиязычность в UI в наших продуктах - го уже сделаем платформу локализации и будем управлять текстами централизованно. В общем, принцип вы поняли.

Важной чертой платформы является простота и скорость интеграции с ней. Это когда каждый новый продукт может просто и без доработок в платформе интегрироваться с ней, и начать получать ценность. Это становится возможным, когда платформа задает общие стандарты и контракты - вот тебе общий API, вот тебе хорошие гайды, вот тебе лучшие практики. Команда продукта делает все как написано и, вуаля, начинает получать ценность от платформы!

Конечно, я описываю утрированно идеальный случай - на деле в платформе могут быть какие-то неочевидности, гайды могут терять актуальность и т.д. Но для команды, которая делает конечных продукт, преодолеть эти шероховатности в 100 раз проще, чем самим решать изначальную задачу (например, получить норм мониторинг). И вот мера того, как легко и просто интегрироваться (условный time-to-value), это одна из качественных характеристик платформы.

Про трагедию общин

Кстати, одной из предпосылок появления ИТ-платформ является существование такого явления, как трагедия общих ресурсов или, как его еще называют, трагедия общин (tragedy of the commons). Этот термин пришел из экономики, где так назвали ситуацию, когда каждый человек или группа, действуя в своих личных интересах и используя какой-то общий ресурс, в итоге истощает его настолько, что в проигрыше остаются все.

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

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

Еще один пример - это уведомления клиентам в виде пушей, email и т.д. Толерантность клиента к этим уведомлениям это как бы общий ограниченный ресурс. Если каждая команда будет фигачить пуши только ради увеличения собственных метрик, в итоге клиент задолбается получать по 5 пушей в день от маркетинга про супер акции, привлечение про новые продукты, технической команды о новых фичах, от комплаенса о документах и т.д. В моменте у каждой из этих команд могут вырасти целевые метрики, но через время клиенты просто отключат эти уведомления нафиг, и мы потеряем целый канал коммуникации. Одним из решений может являться выделение платформы уведомлений, в которой помимо прочего будут закреплены контактные политики, которые не позволят заспамить клиента больше положенного. Даже если продакту Васе очень надо нагнать трафик на свой экран.

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

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

Кто-то спокойно участвует во всех звонках прямо из общего опенспейса, его не сильно парит, что окружающие вынуждены его слушать. Кому-то он этим мешает, а кому-то нет. А кто-то созванивается только в переговорках, парится с их бронью, но зато не создаёт шум в рабочем пространстве.

Какой подход вам ближе? И как вы относитесь к тем, кто болтает на звонках прямо в опенспейсе?

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

Мини-разбор крупного сбоя AWS: как гонка потоков в DNS обрушила половину интернета. Часть 1

На днях Amazon выкатили что-то типа постмортема по нашумевшему сбою 19-20 октября в регионе us-east-1 — одном из их самых важных регионов всего AWS. Напомню, тогда тысячи сервисов по всему миру, включая Reddit, The Washington Post и Perplexity, были недоступны или работали с перебоями. Масштаб был колоссальный. Нам в РФ немного "повезло", как и прошлогоднем сбое в Windows и Crowdstrike, о котором я писал раньше - у нас AWS заблокирован, поэтому бизнес там ничего не хостил.
Что там было.

Часть 1: Падение DynamoDB

Коревая причина - скрытый баг в виде гонки состояний (race condition) в системе управления DNS сервиса DynamoDB (NoSQL БД). Для управления тьмой DNS записей (пишут, что записей сотни тысяч, охотно верю), у ребят был написан собственный сервис автоматизации управления. В нём два компонента:

- DNS Planner. Как я понял, это штука, которая мониторит состояние входных балансировщиков DynamoDB и менеджерит все DNS записи в регионе. Это единая точка управления, которая позволяет менять DNSы сразу по огромной инфре DynamoDB. Ребята пишут, что недавно они не без помощи этой системы смогли внедрить IPv6 эндоинты - кто забыл, для IPv6 нужны записи типа AAAA (я не ору, это тип записей так называется), запустить такую фичу на их масштабах просто невозможно без подобной системы.

- DNS Enactor. Это система типа рук DNS Planner'а. Планер планирует, а Enactor фактически выполняет сформированный план. Для отказоустойчивости (хе хе) Enactor'ов три штуки в разных зонах доступности.​ Они мониторят появление новых планов и транзакционно их применяют. Поэтому если один Enactor сломался, другие все равно все сделают.

Что именно пошло не так, следите за руками:
1. Медленный Enactor. Первый Enactor'ов взял план в работу и чуть завис, пытаясь применить DNS-план.​ Пишут, что такое обычно не случается и все работает быстро, ага. В самом начале своей работы Enactor чекает, что у него в работе ДЕЙСТВИТЕЛЬНО новейший DNS-план. Делает он это через походы в несколько эндпоинтов, и вот в этот раз он тут задержался. Скорее всего, какие-то их них отвечали дольше обычного, он делал ретраи, но в целом, в этот момент задержка была значительно дольше обычного.

2. Быстрый и везучий Enactor. Пока первый Enactor тормозил, Planner успел создал несколько новых планов, новейший из которых подхватил второй Enactor и успешно применил. Тут ему повезло, он не словил таких задержек, как словил первый.

3. Очистка прошлых планов. В конце своей работы быстрый Enactor, как и обычно, запустил очистку старых планов (они не нужны, он ведь уже применил новейший), и потер план, который был уже в работе у первого Enactor'а.

4. Неконсистентое состояние. Тут «зависший» Enactor наконец-то отмирает и идет выполнять свой очень старый план. Напомню, он уже типа успешно проверил, что у него самая актуальная версия плана. Судя по всему, за деталями плана он идет в БД, а там плана уже нет. И он выставляет пустые DNS по всем управляемым записям.​

В итоге куча DNS записей DynamoDB оказались пустыми. Никто не может к ним подключиться и дальше начинается эффект домино, о котором напишу в следующей части.

Мини-разбор крупного сбоя AWS: как гонка потоков в DNS обрушила пол-интернета. Часть 2

В прошлой части я начал разбирать постмортем сбоя в AWS, в этом продолжу.

Часть 2: Эффект домино
Тут-то и началось самое интересное. Оказалось, что DynamoDB это фундамент для многих других сервисов AWS, и его отказ запустил цепную реакцию:

- EC2 (виртуальные серверы): для начала, какое-то время совсем не работало создание новых ВМ. Как пишут, DynamoDB использовалось в Control Plane системе, которая управляла железными кластерами, на которых крутились ВМ. Для синхронизации состояния (например, перезагрузка, запуск новой ВМ и т.д.) использовалась логика, которая хранила данные в сервисной БД. Базы больше нет, синки не происходит и, как следствие, в Control Plane накопилась дикая очередь задач на синхронизацию. Примечательно, что очередь в какой-то момент начала расти лавинообразно: сервер не создавался за заданный таймаут, поэтому система ставила новую задачу в очередь на создание, и т.д.

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

- NLB (балансировщик нагрузки): новые ВМки попадали в конфиги балансировщиков КУЧИ разных сервисов, но мы помним, что многие из них все еще недоступны по сети. Это привело к очень интересной ситуации. Для health check'ов была своя собственная подсистема - это логично, на таких масштабах health check'и это так еще задача. Из-за того, что неадекватно много нод EC2 были недоступны и не проходили проверку на health check, система этих самых health check'ов автоматически масштабировалась под рост нагрузки. И самое прикольное, что для этого она создавала серверы из...EC2!
Таким образом, уже в работе самой подсистемы health check'ов были недоступные ВМки. Это приводило к тому, что часть задач health check'ов распределялись и на них и помечались FAILED, хотя вполне возможно, что целевой сервис был жив и здоров.
Ситуацию осложняло то, что из-за таких "флапающих" проверок - то сервис доступен, то недоступен, смотря какая нода будет делать health check - срабатывала другая автоматика, которая выполняла всякие failover операции. Это приводило к другим каскадным изменениям в системах🫠

- Из-за проблем на таком фундаментальном и платформенном уровне, страдать каскадно начали вообще все сервисы AWS. Из "прикольного" отмечу разве что IAM (система аутентификации и авторизации) - пока она лежала, никто не мог никуда залогиниться, а чтобы оживить сервисы надо было что-то сделать, а для этого надо залогиниться:) ​

Сбой длился примерно 15 часов. В интернетах пишут о разных выводах, которые люди сделали для себя - кто-то о важности multi-cloud, чтобы не зависеть от одного провайдера, кто-то о важности настроенных процессов инцидент-менеджмента и ранбуков в командах, кто-то о хрупкости всех этих гигантских систем и том, что ИИ нас тут спасет.
Я тоже сделал некоторые выводы, о них напишу в следующей части.

- "Я менеджер, а не разработчик, зачем мне лезть в такие технические дебри?"
- "Ой, это архитектурный вопрос, у меня для этого есть сеньоры, пусть они разбираются"

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

И я тут не говорю, что технический менеджер обязан быть архитектором - нет, это, как правило, отдельные люди с особым складом ума, большим опытом и глубокими техническими навыками. Но понимать базовые темы в архитектуре ПО считаю менеджеру необходимым еще и потому, что оно помогает в общении с инженерами. Когда они говорят про eventual consistency, паттерн "сага" или хореографию, а вы думаете причем тут танцы — это чувствуется. Команде приходится упрощать объяснения, переводить технические нюансы на "менеджерский язык". Именно в этот момент неизбежно где-то пропадут важные детали, которые в итоге могут серьезно повлиять на пользовательский опыт или стоимость разработки.

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

1. Пилить свои pet-проекты
Мало что может заменить реальную практику построения систем. И если в рабочей обстановке есть жесткие ограничения, то написать свой микро-продукт, развернуть его и попытаться его запустить на пользователей - это доступно почти каждому. За это время вв гарантированно узнаете много нового не только с технической стороны, но и с продуктовой.

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

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

Кстати, 18 ноября в 12:00 будет один такой - "Архитектурные стили и паттерны ПО" от компании ЛИИС (Лаборатория Интеллектуальных Инженерных Систем).

Там расскажут:
- Что такое Clean Architecture на практике,
- Как выбрать свой архитектурный стиль (и не пожалеть об этом).
- Монолит, модульный монолит, EDA, SOA, MSA Onion, Hexagonal, Pipes & Filters и чем они все отличаются, кроме названий из Википедии

Подходит для техлидов, тимлидов, разработчиков и аналитиков, у которых болит от архитектуры — и тех, кто просто хочет понять, почему она вообще болит.

Участие бесплатное, а зарегистрироваться можно по ссылке.

Готовлюсь сейчас к закрытому выступлению на большую аудиторию - более 2 тыс. человек. Нюанс в том, что на доклад у меня будет буквально 5 минут и еще пару минут на ответы на вопросы. Задержаться нельзя.

И вот, казалось бы, всего 5 минут, а подготовить такой доклад немногим проще, чем получасовой. Плотность информации на единицу времени намного больше, а потерять 30 сек. на какое-нибудь отвлечение мысли - непозволительная роскошь. В большом докладе даже если сбился, то через минуту можно вырулить на нужную ветку повествования и все норм, а в таком коротком - это почти катастрофа. С другой стороны, когда выступаешь на такое кол-во людей, по-другому быть и не может - все выступления должны быть хорошо подготовленными и без лишней воды т.к. компании дорого обходятся такие встречи.

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

2. Доклад нужно хорошенько отрепетировать
И речь тут не о том, чтобы заучить его дословно, а о том, что нужно уверенно ориентироваться в докладе, думать на пару слайдов вперед, чтобы к каждой последующей мысли проговаривать логичные и продуманные переходы. Это невозможно сделать, если не прогонять доклад с презентацией и не репетировать его вслух. По ходу подготовки я часто в мыслях прогоняю разные его кусочки, думаю, какие смыслы вложить и как их лучше сформулировать. Но много раз бывало так, что те обороты, которые в голове звучат круто, ощущаются тупо/сухо/неуместно, когда проговариваешь их вслух.

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

4. Любой публичный доклад - это миниатюрное шоу
Спикер стоит на виду и внимание людей устремлено на него. Они следят за его лицом, телом и интонацией. Они молчат, позволяя ему говорить и задавать тон. Все элементы шоу на месте, так почему бы не относиться к этому как к небольшому шоу? Конечно, не всегда это уместно, но если формат мероприятия позволяет, мне нравится играть с этим - особая интонация в кульминации, резкое изменение ритма речи, инсценировка какой-то ситуации и подобное.

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

За Ильей я наблюдаю давно: слушал его подкаст Айти Самурай, читаю его тг-канал, где он пишет интересное про технический и "обычный" менеджмент. Пару раз мы даже кратко переписывались.

Илья вообще довольно опытный и разносторонний человек - сменил несколько стран, долгое время жил в Штатах, работал продактом в Google и Amazon, запускал свой стартап, а сейчас он CPO API Яндекс Карт, это если говорить о внешних регалиях.

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

Про догфудинг

Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".

А причём тут технический менеджмент, спросите вы?

А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.

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

Честно говоря, однозначного ответа я не нашёл. Я вижу в этом границы использования этой практики - если продукт неактуален для меня, как для клиента, то насколько глубокую обратную связь по его использованию я смогу дать? Это как просить водителя автобуса пользоваться штурвалом от самолета.

Однако уверенное базовое понимание ценности системы для пользователей, способность осмысленно пройти основные сценарии использования - всё это минимум, который я бы ожидал от любого технического менеджера.
---
Пост из марта 2024

Про продуктовые решения на интуиции

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

Я видел как продакты генерировали и приоритезировали гипотезы, проводили качественные и количественные исследования. А на выходе получалась посредственная серая ерунда. И видел противоположные примеры - когда "на чуйке" делали такие штуки, которые всем заходили и были полезны пользователям. Наоборот, кстати, тоже видал. Второй подход принято шеймить в продуктовом комьюнити и, конечно, не без оснований.

Но блин.

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

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

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

А что вы думаете насчет этой продуктовой "чуйки" ? Правда есть такое или просто везение?

Знакомство и розыгрыш книги

UPD: розыгрыш состоялся! Поздравляю @avzarkov!

На мой канал подписано уже больше 400 человек. И это офигеть как много! Кого-то я хорошо знаю, с кем-то где-то пересекался, но с большей частью я никак не знаком. А познакомиться хочется:)

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

А чтобы было интереснее, среди комментаторов я разыграю каноничную продуктовую книгу Марти Кагана "Вдохновленные" (Inspired) в бумажном формате (отправлю бесплатно Яндекс Доставкой). Победителя выберу 26 декабря (в пятницу) с помощью рандомайзера.

Штош, давайте тогда я начну первым комментом.