Про "Искусство войны"

На днях дочитал книгу Сунь-Цзы "Искусство войны" и вот какие мысли почерпнул для себя и какими хочу поделиться с вами.
- Хоть автор и говорит о войне в буквальном смысле, дальше в посте я буду писать о войне как конкуренции за клиентов, рынок, ресурсы, время и влияние в бизнес-среде.

Война — путь обмана. Поэтому, если можешь что-то — показывай противнику, что не можешь; если используешь что-то — показывай, что не используешь

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

Знание положения противника можно получить только от людей.

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

Ведя войско, следует ставить его в такие условия, как если бы, забравшись на высоту, убрали лестницы.

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

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

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

Это я все к чему. Я тут решил поучаствовать в конкурсе авторских телеграм-каналов - https://tg-contest.tilda.ws/. Там опытные авторы собирают авторов менее опытных и дают им площадку, чтобы их увидела широкая аудитория и люди оттуда могли подобрать каналы себе по душе. Так что, если на досуге захочется посмотреть на авторские каналы - полистайте канал, где будет проходить конкурс @tg_contest_main. Вдруг найдете для себя что-то интересное.

Голосовать за себя я НЕ призываю - у меня нет стремления там бороться и побеждать. Рассматриваю это скорее как новый интересный опыт и возможность сделать шаг в сфере развития канала. Every step counts.

Пост про фокус на результатах

"Мы довольны своей работой МАКСИМАЛЬНО, но, к сожалению, наша работа не дала результат" (с)

- каждый раз хихикаю с этого видео (ютуб, вк), и каждый же раз где-то на заднем плане возникает мысль о важности результатов, а не просто упорной работы. Как пелось у Linkin Park - "I tried so hard and got so far But in the end, it doesn't even matter". Ладно, хватит цитат, тем более, что песня "In the End" была совсем не об этом.

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

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

1/ Лучше показывать, чем рассказывать
Можно рассказывать разные концепции, обсуждать уровни реализации, но если есть что-то, что можно показать - код, дизайн, прототип - это точно ускорит получение обратной связи и сделает ее более релеватной. Кроме того такие штуки лучше запоминаются людям - в момент перфоманс-ревью коллега Вася вспомнит скорее ваш первый прототип системы авторизации и то, как это продвинуло диалог, чем десятое обсуждение процесса резолвинга идентификаторов в человекочитаемые строки. Отчасти это связано с тем, что людям проще сказать, что "не так", чем "как именно надо".

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

3/ "Better done than мать его perfect”
Другими словами лучше сделать НОРМ и заданные сроки, чем полировать до совершенства непойми сколько. Ох, сколько раз я себе говорил это - вот еще одно интервью проведу и все будет совсем понятно, вот еще тут формулировки на слайде дополирую и все будет как надо. И ведь все равно не наступает тот счастливый момент, когда все прям супер-пупер! Все равно всегда находится еще одна мелочь, которую надо поправить. Именно поэтому эта фраза так засела в голове - она немного возвращает перфекциониста с небес на землю.

Крч, побочным эффектом (в хорошем смысле!) участия в этом конкурсе стало знакомство с другими авторами каналов в категории управления продуктами.

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

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

Про отдых и выгорание

Совсем скоро я планирую отправиться в недолгий отпуск. И сколько себя помню - всегда относился к своим отпускам стратегически: рассматривал их не сколько как развлекуху, сколько как инвестицию в свою будущую работоспособность и энергичность, ведь если я норм отдохну, то у меня появятся силы достигать! Этот подход не лишен недостатков - например, слишком серьезное отношение к отдыху создает напряженность, что в свою очередь только вредит его качеству. Однако мне 30+, я сохранил работоспособность и энтузиазм - значит это как-то работает:)

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

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

Как одну из небольших мер против заценил для себя практику вечерних прогулок - выхожу гулять и по ходу дела мысленно отвечаю себе на 3 вопроса:
1. Что хорошего было в этом дне?
2. За что я благодарен сегодня?
3. В чем бы я мог быть получше сегодня?
Иногда сам удивляюсь тому, какие цепочки мыслей возникают. Такое внутреннее обсуждение помогает осмыслить и переживать каждый конкретный день со всеми его вопросиками. Попробуйте, вдруг и вам зайдет.

Про перебивания

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

И ведь интересно, что при обоих подходах я НЕ наблюдаю, что бы хоть один из них радикально негативно влиял на результативность общего дела. Казалось бы, если перебивать и не давать высказать важную мысль, то это может сыграть в минус дважды:
1. Страдает вовлеченность человека. Он видит, что его мнение не слушают и перестанет вовлекаться в обсуждения.
2. Можно упустить действительно важный комментарий, который окажет негативное влияние на ход событий.

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

Для себя я вывел пару принципов поведения в таких ситуациях:
1. Для достижения результата мне нужно уметь подстроиться под собеседников, а не ломать их своим представлением о коммуникации. Если принято перебивать - штош, надо тоже не стесняться (мне это дается сложно) Если принято давать больше пространства - тоже ок.

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

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

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

Про кастомные доработки в платформах

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

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

Универсального ответа тут не существует, но мне кажется, что смысл имеет следующее:
0. Потрогать траву и успокоиться
1. В каком-то виде заручиться поддержкой руководства т.к. возможно будет эскалация - будет круто, если руководство вам доверяет и знает, что вы не сделаете хрень.

2. Проверить расчеты ценности от кастомной доработки, если они вообще есть. Может оказаться так, что на деле они основаны на очень оптимистичных предположениях или не учитывают какие-то факторы. Если тут обнаружатся несостыковки, они пригодятся на следующих этапах. Например, может оказаться, что в основе предположение роста x3 в год, а на деле вы ждете x1,5.

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

4. Достаточно подробно объяснить важному клиенту почему именно вы отказали ему в фиче. Важно, чтобы он понял, что вы не самодур, а действительно его цените (цените же?) и при этом следите за качеством платформы для всех пользователей. Если у вас будут на руках те самые несостыковки и какие-то цифры, которые покажут потенциал последствия от кастома - покажите их, хоть они тут и не главные.

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

А вообще, работа в платформах это довольно специфичная история. Надо будет об этом еще написать что ли...

Про сон

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

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

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

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

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

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

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

Например, 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 декабря (в пятницу) с помощью рандомайзера.

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