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

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

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

9. Будьте проактивными. В реактивном подходе на решения человека сильно влияют внешние раздражители. Что-то происходит вовне и именно это определяет то, что будет делать человек. На проактивных людей действуют те же самые силы, но они не управляют действиями человека - он способен как бы переломить ход и делать то, что нужно для достижения нужного ему результата. Для пояснения я привёл историю с аналитиком, которому сообщили, что заказчик забраковал его ТЗ, а коллега успел записать только пару замечаний.
- Реактивный: okay, не звали на встречу по обсуждению ТЗ - нечего и проситься. Записали только 2 замечания, ну ладно, исправлю их.
- Проактивный: ты че, пёс. Написать самому и попросить полный список замечаний. Напроситься в след. раз самому презентовать своё ТЗ заказчику, чтобы сразу отвечать на замечания.

10. Сдерживайте обещания. Казалось бы - капитанство, но чтобы его чуть раскрыть я предложил 4 подсовета о том, как это делать.
- Не обещайте сразу. Иногда мы склонны пообещать что-то под влиянием эмоций. Тут я предлагаю брать паузы, чтобы лучше обдумать обещание.
- Уточните просьбу. Важно убедиться, что вы правильно поняли, что от вас хотят. Намного лучше переспросить лишний раз, чем сделать не то.
- Обещайте в рамках возможностей. Вроде очевидно, но особенность в том, что если обещание не по силам, сейчас хорошая возможность обозначить риски. Вполне возможно, что обещание можно скорректировать с их учётом.
- Своевременно говорите, если обещания под угрозой. Нет ничего хуже в день Х ВНЕЗАПНО узнать, что нужная работа не сделана (конечно, есть вещи несравнимо хуже). Поэтому о срыве обещания лучше сказать ASAP. (1) Это просто честно. (2) Вероятно, обещание можно скорректировать по срокам/объему.

Вот такой у меня был доклад:)

Моя прошлогодняя статья на Хабре (и единственная, к слову) ВНЕЗАПНО попала в шорт лист конкурса лучших статей - Технотекст 2023🦄
Статья написана про особенности SRE и Observability в мобильных приложениях, так что если какие-то из этих тем вам интересны - you're welcome
https://habr.com/ru/companies/tinkoff/articles/762058

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

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

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

При обоих формах переработок (вынужденных или добровольных) нам, как менеджерам, важно особенно следить за двумя моментами:
1. Инженеры могут сами не заметить приближающееся выгорание.
Там посидел на выходных, тут задержался на пару часов вечером - и вот уже работа вызывает больше отвращения, чем интереса. Уже нет никакой инициативы, все задачи одинаково безразличны, а любые трудности в команде бесят максимально. "Так, а может бросить все это и уйти куда-нибудь?!" - такие мысли посещают подгорающего все чаще. У разных людей разный уровень осознанности, но от менеджера у меня более высокие ожидания. Поэтому считаю важным менеджеру быть особенно чутким к команде, когда появляются переработки. По возможности, стоит вообще защитить команду от них (сменить приоритеты или подвинуть сроки). А если кто-то начинает проявлять первые признаки выгорания - такому человеку нужно уделить особое внимание. Конечно, менеджер не психотерапевт, но с т.з. достижения результатов, кажется, проще включиться на этом этапе, чем потом искать нового человека на освободившуюся вакансию.
2. Переработки не должны проходить бесследно.
Наличие переработки - индикатор, что где-то ошиблись с планированием. Если это единичные случаи, то ок. Но если это становится системой - надо разбираться. Хитрость - если люди перерабатывают добровольно, то их переработки могут оказаться незаметными для руководства. Они задерживаются вечерам, сидят на выходных и вообще из кожи вон лезут - а руководство не видит этих усилий. Руководство видит сделанные в срок задачи с приемлемым качеством. И когда к ним потом приходят и просят еще людей в команду, возникает ожидаемый вопрос - а зачем, вы же и так норм справляетесь? И тут прямая задача менеджера правильно подать руководству тему с переработками. Отдельное искусство в таком случае - так позвоkить факапить задачи без переработок, чтобы нужда в расширении команды стала очевидной и в то же время это не нанести особого ущерба бизнесу. Но это совсем другая история...

P.S. Все переработки, которые инициирует компания, должны быть оплачены!

Про AI в работе менеджера

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

1. Role-playing
Суть подхода в том, чтобы попросить модель отвечать на вопрос из определенной роли. В эту роль я вкладываю описание человека, его должность и опыт, с которым я бы хотел обсудить мой вопрос. "Отвечай как технический менеджер продукта, развивающий observability-платформу..." или "Отвечай как тимлид команды SRE, jотвечающий за высоконагруженную систему...". И что самое классное - ChatGPT (и подобные модели) действительно подстраиваются под эту роль и учитывают ее как доп. контекст для ответа. Таким образом, одну и ту же тему можно "обстучать" об разные роли - концепт идеи обсуждаю с менеджером продукта, метрики - с продуктовым аналитиком, реализацию - с тимлидом. Конечно, все это НЕ заменит обсуждения с реальными людьми, но точно дает шире взглянуть на задачу. У меня МНОГО РАЗ случалось такое, что на этом этапе я видел вопросы, которые изначально я не учитывал.

2. Написание говно-кода
Сейчас мне не нужно писать код, но иногда с помощью кода задачу можно решить более эффективно. Если использовать прошлый пункт и попросить модель "Отвечай как опытный разработчик на bash. Напиши мне скрипт, который...", то можно за очень короткое время получить код, который, возможно, неэлегантно, но все таки выполняет поставленную задачу. Аналогичным подходом полгода назад мне удалось НАМНОГО БЫСТРЕЕ углубиться в данные, которые лежат в Clickhouse, не являясь гуру либы pandas на питоне и SQL-диалекта, на котором работает клик. Таким образом, с помощью LLM можно значительно ускоряться в задачах написания несложного кода (опыта написания production-ready с LLM у меня нет).

3. Поиск через Perplexity
Когда в мою жизнь вошел Perplexity, то я стал, наверно, раза в 2-3 меньше пользоваться поисковиками. Это потому, что с помощью Perplexity я значительно быстрее получаю нужные мне ответы, чем с Гуглом или Яндексом. Фишка этого сервиса в том, что он комбинирует поиск в Интернете и ответ LLM чат-бота. На выходе запроса вы получаете не набор ссылок, а краткое резюме того, что есть в топе Интернета по этой теме. Каждое утверждение этого саммари подкрепляется ссылкой на источник, благодаря чему снижается риск, что LLM напридумывает того, чего нет. Важная фишка этого инструмента - он держит контекст вашего поискового запроса, благодаря чему можно доуточнять что-то на основе полученной информации. Еще в Perplexity есть Pro-запросы. С помощью таких запросов модель как будто глубже пытается понять задачу и дополнительно может сама задать вам вопросы для прояснения недостающих данных. Полученные ответы потом используются для обогащения контекста. Крч, лучше просто попробуйте сами!

А какими AI-штуками пользуетесь вы?
Поделитесь, интересно ж!

27.06 буду выступать в Москве на конференции Сбера - GigaConf 2024. В своем докладе я поделюсь рефлексией одного крупного сбоя в мобильном банке, расскажу, какие выводы мы сделали (не все были приятными) и как мы на корню лечили первопричины. Попутно поделюсь набором советников для DevOps'ов и SRE о том, как они могут (да, могут!) сильно повлиять на надёжность мобильного приложения в компании.
Конференция бесплатная, будет трансляция - welcome!

https://gigaconf.ru

Про мотивацию выступать

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

Начнём с шага №0. Как мне кажется, нулевым и фундаментальным шагом будет не идея для темы доклада и даже не выбор мемов для презентации, а именно прояснение своей мотивации к выступлению. Почему я хочу выступить? Зачем мне это?
Стоит посидеть и крепко подумать об этом. Ведь путь от идеи до фактического выступления бывает непрост и хорошее понимание собственной мотивации может сильно помочь. Одно дело готовиться "по фану", "новый опыт" или "другие выступают, а я че хуже?" - как мне кажется, такая мотивация легко улетучивается при первых сложностях из-за своей поверхностности. И совсем другое дело, если вы твердо решили прокачивать экспертный бренд, чтобы получить новые карьерные возможности или вы хотите выступить, чтобы послужить продвижению своего классного продукта. Такая мотивация более основательная и она не даст вам просто соскочить.

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

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

Шаг 1. Выбор темы

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

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

2. Вы должны базово шарить в теме
Очень классно, когда спикер имеет практический опыт в той теме, о которой рассказывает, а не просто пересказывает документацию. Однако для текущего этапа НЕ ОБЯЗАТЕЛЬНО досконально все знать и быть готовым ответить на любые вопросы - достаточно будет того, что вы в целом понимаете эту тему и знаете источники, откуда сможете почерпнуть информацию на более позднем этапе подготовки. Детальная проработка будет позже. Условно, тема построения Лунной станции мне интересна, и я бы, может, даже хотел о ней рассказать (нет), но я АБСОЛЮТНО не шарю в ней, поэтому у меня нет шанса подготовить доклад для серьезной конференции.

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

Так, это все понятно, но что делать, если я не знаю о чем рассказать? Я просто работаю работу и не делаю ничего невероятного.

Об этом расскажу в следующем посте.

Шаг 1.1 Что делать, если я не знаю о чем рассказать

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

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

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

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

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

В следующем посте накину еще пару идей про темы для докладов.

Шаг 1.2 Что делать, если я не знаю о чем рассказать часть 2

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

Расскажите о свежих релизах
Например, что нового в последней Java (какая там сейчас? 21 уже?). Или какие нововведения в Android SDK 35. Основная идея в том, что бы взять что-то прям свежее-свежее, что только вышло, пропустить через себя и рассказать. Далеко не все следят за самыми последними релизами и за счет этого ваш доклад может быть актуальным. При выборе этого варианта прикольно, что основной контент уже подготовлен до вас тем, кто готовил статью или пресс-релиз о новой фиче. Вам лишь остается переработать это и нормально рассказать.

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

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

Штош. Надеюсь, эти мысли помогут нагнать идеи для докладов:)

На днях закончил читать книгу Ричарда Румельта "Хорошая стратегия плохая стратегия", и захотел поделиться некоторыми мыслями про стратегию, которые показались мне интересными.

1. Мне понравилось как автор сформулировал ядро стратегии, которое он увидел во многих успешных компаниях. И что, немаловажно, НЕ видел его у неуспешных. Хорошая стратегия, по его мнению, должна содержать постановку диагноза, направляющую политику и согласованные меры.

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

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

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

2. Автор неоднократно подчеркивает, что стратегию часто ошибочно заменяют амбициозными целями. Типа говорят, что наша стратегия это "Стать лидером рынка в течение 5 лет" или "Увеличить продажи на 50% за три года". Но такие цели он не считает стратегией прежде всего потому, что в них не раскрывается КАК ИМЕННО они будут достигнуты. Его идея в том, что что хорошая стратегия должна не только определять цели, но и предлагать четкий путь их достижения, учитывая реальные препятствия и ограничения.

3. Понравился акцент автора на использовании и созданию различного рода преимуществ, которые есть у компании по сравнению с конкурентами. Среди таких преимуществ мне больше всех запомнились такие:

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

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

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

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

Про сбой CrowdStrike и Windows

19 июля 2024 года случился один из самых больших технических сбоев в современной истории - больше 8 млн. компьютеров на Windows упали в BSOD (синий экран смерти) и без помощи кожаных мешков встать уже не смогли. Если помните, тогда это затронуло много всего - аэропорты, больницы, операторы связи, банки - куча рейсов было отменено, куча каскадных сбоев по всей инфраструктуре и прочее-прочее. Проблема с программами, которые виртуальные, ОЧЕНЬ сильно повлияла на мир физический в тот момент. Причиной этих сбоев стала проблема при работе антивирусной программы от компании Crowdstrike. Ее продуктами пользуются тысячи компаний по всему миру.

А почему вообще случился этот сбой?
Корневой причиной этого инцидента оказалось плохое обновление. Следите за руками:
- Часть проверок безопасности шла вместе с дистрибутивом очередной версии их продукта. Но это инфобез, а значит новые угрозы появляются чаще, чем клиенты привыкли обновляться. Поэтому Crowdstrike поставляли облачные обновления с библиотеками новых проверок.
- Применить эти обновления просто так нельзя, потому что антивирус Crowdstrike работает на уровне ядра ОС и ниже. Просто так "с улицы" Microsoft никому не дает выполнять код на уровне ядра, для этого нужно получить специальный сертификат Windows Hardware Quality Labs, где ваш код будет жестко проверен.
- Если для обновления проверок безопасности нужно каждый раз проходить такую сертификацию, то о "быстрых" обновлениях можно забыть - такие сертификации занимают дни и недели.
- Поэтому Crowdstrike написали драйвер, который помимо выполнения части проверок, мог динамически загружать и выполнять код из файлов обновлений т.е. они сделали некий "движок" проверок. Именно этот драйвер и отправился на сертификацию и когда-то успешно ее прошел. За счет этого хода получилось, что и сертификат от Microsoft новый получать каждый раз не нужно и все свежие данные для обнаружения угроз доставляются и применяются очень быстро. Успех!
- В феврале 2024 Crowdstrike зарелизили новый тип проверок. Одной из его особенностей стало то, что в файле обновления добавилось новое 21-е поле (раньше было 20).
- 19 июля Crowdstrike покатили обновление, которое впервые начало использовать проверку безопасности с этим самым 21 полем. И тут - БУМ!!! - BSOD из-за чтения за пределами массива, потому что никакого 21 поля в рантайме нет.
- СТОП. Но в файле обновления оно же есть? Да, есть. Но беда была в том, что логика, которая читала этот файл и инициировала дальнейшую работу проверок из обновления, читала ТОЛЬКО ПЕРВЫЕ 20 ПОЛЕЙ. ОНА ВСЕГДА ПЕРЕДАВАЛА ДАЛЬШЕ ТОЛЬКО 20 ПОЛЕЙ, КАРЛ!
- А тут впервые сработала логика, которая ожидала во входном массиве 21-е поле. Но поля этого не оказалось. Из-за чего эта логика упала и потащила за собой всю систему...

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

Почему проблему не выявили раньше, если релиз нового типа проверок был в феврале?
Это хороший вопрос к качеству тестирования в Crowdstrike. В самом постмортеме они честно говорят, что на этапе тестирования использовали в этом 21 поле wildcard типа звездочки. Вероятно, из-за этого логика работы с конкретными значениями не запускалась.

Как можно работать с массивом и не проверять его размерность и кол-во входных параметров?!
¯\_(ツ)_/¯
В своем постмортеме ребята честно выделяют это как один из action items.

P.S. Но на самом деле все это случилось из-за деплоя в пятницу.

P.PS. В комментах добавлю полный список их action items, как я его понял, а также ссылку на оригинал постмортема.

Про MongoDB и удержание пользователей

В одном pet-проекте, которым я сейчас эпизодически занимаюсь (возможно, о нем расскажу позже), в качестве БД используется MongoDB. И я заметил, что стал гореть с того, как организован язык запросов в Mongo. Кто не знает, там используется не традиционный всем известный и прекрасный SQL, а язык собственной разработки - MongoDB Query Language aka MQL.

В основе этого языка лежит оперирование json-структурой документов (это типа записи с SQL базах), которые лежат в коллекциях (типа таблицы). В своем запросе к БД нужно описывать критерии полей в json-документах в собственной нотации MQL. Например, если представить, что у нас есть коллекция users, то чтобы получить количество пользователей, сгруппированных по некоему полю provider, имеющих updatedAt позже 1 октября 2024 года, у которых в поле email есть подстрока "gmail", то нужно будет написать вот такой запрос:

db.users.aggregate([ { $match: { updatedAt: { $gt: new Date("2024-10-01") }, email: { $regex: "gmail", $options: "i" } } }, { $group: { _id: "$provider", count: { $sum: 1 } } } ])

Сравните это с SQL-версией такого же запроса:

SELECT provider, COUNT(*) as count FROM users WHERE updatedAt > '2024-10-01' AND email LIKE '%gmail%' GROUP BY provider;

Скажите же, что SQL более лаконичен и понятен, чем эти count: { $sum: 1 } и $regex: "gmail", $options: "i". Ну скажите, я же не один это вижу?

Почему другие NoSQL базы типа Elasticsearch, CouchDB, Cassandra поддержали SQL, а Mongo нет?
Конечно, я не могу залезть в голову к команде разработки Mongo и понять всех причин. Я пытался найти ответ в интернетах, но не нашел информации из первых уст. Когда я начал писать пост, то хотел сказать, что в их решении усматриваю желание создать дополнительный фактор удержания своих пользователей - юзеры УЖЕ изучили особенности самой Mongo и ее языка, зачем им этот "медленный" SQL? Расчет на то, что при прочих равных они будут выбирать Mongo из-за того, что уже инвестировали время в ее изучение.
Однако с другой стороны такое решение создает доп. барьер для новых пользователей - им придется инвестировать больше времени в изучение, переучивать команду и т.д. С продуктовой точки зрения барьеры для использования продукта лучше устранять, чем создавать.

Штош, вот такое решение приняла команда MongoDB, и оно не помешало инструменту получить популярность по всему миру. Однако кто знает, какова могла быть популярность, поддержи они SQL - тут остается только гадать.

P.S. Кстати, популярность могла быть и намного меньше, потому что для поддержки SQL, вероятно, им пришлось бы принять много архитектурных компромиссов и тогда пострадали бы другие характеристики - например, производительность. И это бы сказалось на качестве, и как следствие, популярности инструмента.

Про выступления на DevOops

Меньше недели осталось до моего выступления на конференции DevOops 2024 в Санкт-Петербурге, где 12 ноября планирую выступить с темой "Мониторинг зеленый, но у юзеров ничего не работает. Как мониторить клиентскую часть".

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

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

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

Technical Product Manager'ы не нужны

Работая уже какой год в роли Technical Product Manager (TPM), я до сих пор периодически сталкиваюсь с вопросом - а кто это вообще такой? Это типа тимлид, которой лезет в бизнес? Или это бизнес-аналитик, который поверил в свои технические навыки?

TPM = Product Manager + Technical
На текущий момент я вижу так, что TPM - это менеджер такого продукта, для развития которого критически важны технические скиллы. Скорее всего, основные клиенты этого продукта - это инженеры, поэтому TPMу особенно важно, что называется, "на кончиках пальцев" понимать их задачи и проблемы. Кроме этого, со временем такие продукты могут перерастать в целые платформы, которыми начинают пользоваться другие команды для реализации задач уже своих продуктов. Это добавляет технической сложности, которую надо уметь переваривать и учитывать в развитии своего технического продукта.

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

Какие есть примеры продуктов, где нужен TPM?
- Разработка IDE
- Система сбора и анализа крашей мобильных приложений
- Система мониторинга и наблюдаемости
- Платформа аутентификации и авторизации
- AI-ассистент для написания кода
- SDK или API для интеграции с платформой
- это все примеры, но профиль один - продукт, пользователями которого будут инженеры, которые, в свою очередь, на этой базе сделают продукты для конечных клиентов.

Когда TPM не нужон?
Не нужон он в первую очередь там, где основной клиент продукта это НЕ инженеры. Инженерные продукты - это не очень массовый сегмент, соответственно, большинству бизнесов TPMы не нужны.
Мои наблюдения говорят о том, что TPM востребованы в больших компаниях, которые строят платформы. За счет платформизации каких-то внутренних функций эти компании получают экономию - дешевле и надежнее сделать одну платформу для всех, чем в каждом случае изобретать велосипед. Например, если в компании много построено на использовании S3 - логично выделить отдельную команду с TPM, которая обернет все в S3aaS и сделает его frendly для пользователей. Другой пример это компании, которые прямо таки зарабатывают на платформах - например, Яндекс Облако. В ЯО много технических продуктов и я уверен, что у них немало людей с шильдиком TPM.

Про Meeting notes

MN (Meeting Notes), протокол встреч, MoM (Minutes of Meeting) - как только не называют заметки по результатам встречи, в которых отражают основные обсуждения и договоренности. Большинство инженеров от природы очень легко относятся к этой штуке - или пишут на скорую руку в формате потока сознания, или вовсе забивают на них. А зачем тратить время на эту бюрократию? Главное, что мы все решили и поняли друг друга на встрече! "По крайней мере, мне так показалось, что поняли... Они даже согласились с тем, что я предложил...". А потом наступает момент, когда договоренности должны быть реализованы и тут оказывается, что поняли "они" не совсем так, как надо. А часть важных моментов как-то вот упустили - "они" искренне сожалеют, "мы" тоже. В итоге результат грустный - работа в срок не сделана.

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

Так зачем нужны эти самые MN?
1. Чтобы поделиться результатами встречи с теми, кто на не быть не мог. Болезни, отпуска, кошк рожает - все мы люди и иногда можем пропустить встречу по важному нам проекту. В таком случае приятно получить MNку с выжимкой встречи и понять, что мог и не приходить ты остался в контексте.
2. Чтобы убедиться, что все стороны встречи правильно друг друга поняли.
Кто участвовал в сколько-нибудь значимых переговорах, тот знает, насколько обманчивой бывает мысль, что вы друг друга понимаете. Так вот, написанные MN создают площадку для участников встречи, чтобы оценить качество понимания друг друга. Сколько раз у меня было такое, что на встрече вроде ударили по рукам, а после MN приходят комментарии в духе "в п.3 написано, что мы сделаем Х за неделю, но мы договаривались на месяц" или "вы пишете, что Х случилось по причине Y, но так сказать будет неправильно, потому что Z". Тут, конечно, можно было бы сказать, что это именно я переговорщик так себе, поэтому так, но у других я тоже замечал такое много раз.
3. Чтобы освободить голову
Это одна из моих любимых "фич" MNок. Если после каждой значимой встречи писать MNку, то это освобождает голову от необходимости помнить, кто кому и что должен - все это записано и публично. Когда у тебя много проектов/фич/продуктов, то в голове это поместить просто нереально, поэтому я ценю MN за то, что позволяют выгрузить хоть небольшой дамп моей памяти, освободив ее для чего-то более важного (рилсы, например).
4. Чтобы прикрыть жопу.
Решил оставить этот пункт как есть:) MNки бывают очень актуальны, когда через время после встречи кто-то приходит и начинает необоснованно требовать выполнения какой-то работы - слишком рано или больший объем. В таких случаях очень полезно вместе с "просителем" заглянуть в MNку и посмотреть, о чем именно вы тогда договорились. Сколько раз это переводило разговор из русла "Вы обещали сделать нам X и Y!" в "Ой, сорри, мы договаривались только на объем X". А если бы мы не написали MN той встречи? Пришлось бы отвлекаться от других задач и тратить время и энергию на то, чтобы передоговориться с заведомо завышенными ожиданиями". Кстати, это возможно благодаря одному негласному правилу - если что-то написано в MN и ты не написал ничего против, значит ты автоматически согласен с тем, что там написано.

Подведем итог:
1. Прочитали 4 пункта о важности ведения MNок.
2. Решили бахнуть лайк посту и более дисциплинированно относиться к MNкам.

Про признание среди инженеров

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

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

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

Что может помочь техническому менеджеру получить это признание?
На этот счет у меня несколько мыслей:
0. Поработать с кодом проекта своими руками
Написать какую-нибудь полезную мелкую утилиту, до которой не доходили руки у команды; написать какие-нибудь скрипты, которые автоматизируют работу с тем, что напрашивается; вникнуть в архитектуру проекта и поспрашивать ребят о неочевидных моментах - все эти элементы объединяет работа с кодом собственным руками. Да, копание в коде это не то, зачем обычно нанимают технических менеджеров, но когда инженеры увидят, что вы реально шарите на уровне кода - вы получите 10 очков инженерного увожения. "Talk is cheap show me the code" (c) Линус Торвальдс

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

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

Как считаете, нужно это признание техническому менеджеру или и без него норм?

Эмоциональный аттач к продукту это полезно или не очень?

Или другими словами эмоциональная привязанность к результату своего труда - будь то продукт, проект или команда, которая выполняет задачи. Я имею ввиду, когда человек не просто нейтрально выполняет поставленные задачи (может быть и амбициозные), а искренне переживает за успех продукта, чувствует внутренний эмоциональный отклик, когда с его продуктом происходит что-то хорошее или что-то плохое. Например, когда кто-то из стейкхолдеров необоснованно ругает продукт. Или когда, напротив, какой-нибудь NPS продутта (Net Promoted Score, индекс лояльности клиентов) побил рекорд в этот раз. Вот такая эмоциональная вовлеченность это хорошо для продакта или не очень?

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

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

Возможно, тут уместно было бы сказать, что нужен баланс. Но обычно эта мысль, что "во всем нужен баланс" ничего толком не объясняет. По собственному опыту, я так и не пришел к однозначному ответу на изначальный вопрос. Когда мне по каким-то причинам нравится продукт, над которым я работаю - я сильно вовлекаюсь в его развитие, но неоднократно было так, что из-за такой вовлеченности я получал неприятные последствия, которые были бы менее чувствительными, будь у меня "больше баланса" или "здоровая степень пофигизма". Например, однажды я с трудом засыпал несколько ночей подряд и сильно измотался из-за того, что переживал, что мою визу в Кувейт не одобрят - я считал, что для успеха проекта мне КРАЙНЕ ВАЖНО лично встретиться с людьми от клиента, и если этого не случится - проект сильно потеряет в заинтересованности от клиентов, а моя роль в нем уменьшится. Вот такие переживания были. Визу, кстати, тогда мне дали.

Что думаете, эмоциональный аттач это полезно или не очень?

Пару недель назад вышел таки подкаст с моим участием у Лёши Гладкова (его канал Mobile Developer один из топовых в СНГ по мобильной разработке). В подкасте подробнее обсудили масштабный летний сбой у CrowdStrike (немного писал о нем) тему надёжности, производительности и наблюдаемости приложений. Правда, подкаст вышел в его закрытом сообществе, но где-то в начале года он должен стать доступным на открытых площадках (напишу об этом!).

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

Темная сторона data driven подхода

Сейчас модно быть data driven чуваками. Кто забыл - data driven это когда решения принимаются на основе данных. Юзеры часто заходят в этот раздел, значит качаем в первую очередь его, цвет Важной Кнопки не меняем пока не проведем А/Б-тест и не наберём статзначимый объем трафика. Этот подход имеет плюсы и минусы. Среди плюсов хотел бы отметить, что он снижает долю субъективщины, поскольку данные показывают сухие факты - решения на их основе меньше зависят от личного мнения. Оставим пока за скобками то, что данными можно успешно манипулировать:)

А вот о чем я хотел написать, так это о темной стороне всей этой data driven вечеринки - огромный объем совершенно никому не нужных данных. Аналитики покрывают событиями каждый чих пользователя "чтоб было" - а потом забывают про эти события через неделю, потому что есть другие важные задачи. Разработчики подключают сторонние SDK, которые помимо прочего, отливают куча информации производителю бесплатного SDK - масштаб бездумного сбора данных множится.

А ведь сбор любых данных несёт в себе вполне явные накладные расходы:
- на стороне клиента они стоят времени процессора (для сбора), пространства на диске (для буферизации) и интернет-трафика (для отправки), что в конечном итоге негативно влияет на перфоманс клиентской части
- на стороне сервера на порядок больше CPU, памяти и трафика для обработки данных, полученных с клиентов
- на стороне хранилища все тоже самое, только ещё и диски для хранения. Ой, вам еще и репликация нужна? Тогда умножаем объем данных на N.
- это уже не говоря о том, что все это нужно грамотно спроектировать, разработать и поддерживать, на что нужно время недешевых инженеров.
Таким образом, компании сливают кучу времени людей и денег на сбор и хранение бесполезных данных. Сам видел.

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

В общем, желаю всем подходить к аналитике более осознанно.

Где-то с месяц назад обещал написать, когда подкаст со мной выйдет на открытых площадках. В общем, это случилось⚡

Подкаст опубликован на Ютубе - https://youtu.be/P0yrAzqHjIQ. Смотрите, комментируйте, буду рад обратной связи! Если будут вопросы - welcome в комментарии к посту:)

В этом подкасте мы поговорили о таких темах:
- Что именно случилось у CrowdStrike, когда они положили половину компьютеров в мире летом 2024 (я уже писал об этом пост)
- Почему НА САМОМ ДЕЛЕ важно следить за надежностью и производительностью мобильных приложений
- Как технически и организационно обеспечить наблюдаемость ключевых аспектов приложения
- Как устроена работа с темами производительности и надёжности мобилок в больших продуктах на десятки команд
- Что такое Sage в Т-Банке и зачем разрабатывать СВОЮ систему мониторинга в наше время