Ворчливый IT-дед

Больше пикселей!

Обновился тут до ios26. Весь этот стеклянный дизайн, конечно, полная шляпа. Зато картинка стала намного более четкая, резкая, красочная! Как будто пикселей прибавилось. Аж глаза режет. Тексты стали контрастнее, графика четче. Как они этого добились чисто программно?

Хотя, возможно, дело в том, что через несколько часов после обновления я сделал лазерную коррекцию зрения. Штука, кстати, классная, и не такая страшная и ужасная, как многие думают. Рекомендую. Если вы давно ждали знак, чтобы решиться - считайте, что это он. А я теперь вижу больше деталей, на которые можно поворчать.

Все, что нужно знать о поиске через чатгпт

Подбирали с коллегой вариант для командообразующего выезда на природу.
Он, по привычке, доверился чатгпт. А я не перепроверил.
Дабл-чекайте все за ллмками! А то они бог знает куда вас заведут.

Продам Mazda MX-5

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

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

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

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

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

Немного скучных ТТХ:
Mazda MX-5 ND soft-top 2019, пробег 36 000.
Куплена мной в апреле, я наездил 2500км и 1 трек-день.
Покупал ее свежеобслуженной, и сам даже ни разу не ездил в сервис, не было повода.
Состояние - околоидеальное (повторюсь - диагностику не делал, но сам неисправностей никаких в ней не вижу).
Мотор 2.0л, 184 л.с., МКПП шестиступка.
Салон - двухместный, я с ростом 192см нормально сижу. Багажник - ну, он есть.
Привезена пару лет назад из Германии (не американский биток!).
Два комплекта резины (летняя - держаковая адван спорт с пробегом 1 сезон, зимняя - ну, она есть).

Цена - 3.3млн (на сколько взял, за столько же и отдам).
Посмотреть можно в БЦ Нева (Сити) или в Хорошёво-Мнёвниках. Пишите в личку @jkennedy

Найм зумеров в эпоху вайб-кодинга

Разгоняли тут с Женей Кадомец про трудности найма в наше неспокойное время перегретого рынка, необоснованных зарплатных ожиданий и злоупотребления ИИшкой.
(https://t.me/jeny_ka - подпишитесь! Там про рекрутмент, карьеру, тренды и котиков)
Женя была рекрутером моей команды уже почти 10 лет назад (страшно подумать), а сейчас она руководит рекрутментом в Финтехе Яндекса.

Решили тут с ней посмотреть с разных сторон на один вопрос.
Я - со стороны нанимающего менеджера, Женя - со стороны рекрутмента.
Моя точка зрения, конечно, важнее ;) Ей-то надо лишь найти человека, а мне с ним еще годами работать.

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

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

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

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

Я считаю, что искать нужно в первую очередь мотивированных инженеров. Тех, для кого программирование - не только способ заработка, но и страсть. Тех, кто получает удовольствие от процесса, а не только по 5-м и 20-м. Кто любит технологии и готов много учиться. Кому интересно развивать инструменты, а не просто использовать их.

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

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

Надежность: импакт

Завершу цикл постов с разбором стратегии надежности несколькими мыслями про минимизацию ущерба.

В предыдущих сериях:
- повышение надежности релизов
- предотвращение инцидентов из-за потенциально известных проблем
- реагирование

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

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

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

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

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

Вывод - купируйтесь и деградируйте. Хотя странно звучит, забейте.

big tech night

Кстати, сегодня конфа big tech night. Программа довольно интересная.

Там и онлайн будет https://bigtechnight.ru/online/ - если не попали на оффлайн. Если еще не решили, чем занять вечер пятницы - вариант.

Кто будет в Красной Розе - при желании можем увидеться, я буду там нетворкаться где-то в районе стенда Городских Сервисов Яндекса.

Лидеры компетенций

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

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

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

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

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

Для пущей структурности и организованности есть также некоторая иерархия - существуют шеф-лиды компетенций (chief competence lead, CSL), по одному на каждую функцию. Они консолидируют экспертизу и ведут комплексные, сквозные проекты. Координируют лидеров компетенций разных частей компании. Формируют повестку и направляют стратегию технологического развития своей функции. В общем, главные по своим областям.

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

Буткемп, или как не толкаться локтями при найме

Предположим, есть 5 смежных команд. И в каждой есть вакансия C++-разработчика (или ios/android/web/qa - не суть, лишь бы одинаковые). Команды в целом схожи, просто за разные части системы отвечают. А значит, требования к кандидатам у них тоже плюс-минус одинаковые - стек, опыт, профиль.

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

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

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

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

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

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

Можете сделать так же у себя. А можете попробовать у нас - https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)

Игра с ненулевой суммой

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

Простой пример: вам предлагают подбросить монетку. Орел - вам дают 2000 рублей. Решка - у вас забирают 1000. Вроде бы, статистически, надо играть. Но перспектива расстаться с тысячей рублей как-то не радует, и вы, скорее всего, откажетесь. Дело в неприятии потерь - мы склонны интуитивно увеличивать вес потерь относительно выгоды.

Однако, если предложить вам 20 раз подряд сыграть в эту игру, вы наверняка согласитесь. Потому что вероятность остаться в минусе сокращается до морально-приемлемых ~13%, что перекрывается средним ожидаемым выигрышем в 10 000 рублей. Хотя броски монетки независимы, и каждая итерация игры осталась та же. Но вы расширили рамки и оперируете рисками в более широких рамках.

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

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

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

Не нужно обдумывать каждое решение как единственное - расширяйте рамки и оперируйте портфелем в целом и на дистанции.

(Не является инвестиционной рекомендацией. Автор не поощряет азартные игры. Мотивационный питч, направленный на построение аналогий с принятием профессиональных или бытовых решений. Инспирировано книгой Даниэля Канемана.)

Надежность: реагирование

Продолжаем разбор стратегии надежности .
Ранее уже писал про
повышение надежности релизов и про
предотвращение инцидентов из-за потенциально известных проблем.

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

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

А не надо так. Привычное игнорирование некритичных алертов приводит к слепоте - вы не отличите крит от не-крита. Уже горящий алерт ярче не загорится, если системе станет реально хуже. Замьюченный - тем более. Вы летите без приборов и узнаете об инциденте из газет. Поэтому нужно держать высокий alerts uptime (доля времени, когда не горит ни один алерт, должна приближаться к желаемому аптайму системы в целом - 99.??). А еще полезно визуализировать это в виде полотна с плитками, где каждый не-зеленый кусочек должен вас искренне триггерить. Некритичные алерты нужно перенаправить куда-то в отдельный диагностический канал, а реально критичные - настроить так, чтобы их невозможно было не заметить.

Аналогия из автомобильного мира - лампочка check-engine (она же джеки-чан, она же мясорубка). Не понимаю людей, которые ездят с ней годами. Даже если зажглась она из-за ерунды, вы пропустите индикацию реально важной поломки. А заклеивают чек только перекупы. Я же на некоторых авто каждое утро начинал с подключения обд-сканера (elm) и сброса некритичных ошибок.

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

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

Здоровья вашим сервисам, а если что-то все же бомбанет - не проморгайте. И не слепните.

55.973146, 37.414863: Как починить "перебрасывание" геопозиции в iOS без регистрации и смс

Жители крупных городов России в последнее время частенько страдают от "перебрасывания" геопозиции в различных приложениях. Например, в Шереметьево. Это сильно мешает - навигатор бессилен, погоду ты видишь в Химках, даже еду заказать сложнее.

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

Достаточно лишь
.
.
.
поехать в Шереметьево. (фьюить-ха!)

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

Зато на гарантии

Один мой друг недавно приобрел себе автомобиль одного из труднопроизносимых китайских брендов. Мотивация простая (и единственно верная) - "нравится". Новый, дилерский, с гарантией! Но вот незадача - за 3 недели владения гарантией пришлось воспользоваться ... 3 раза.

Во-первых, дилер выдал авто с неработающим кондиционером. Была течь фреоновой магистрали. Залили подкрашенный фреон, покатался, течь нашли и устранили. Ура!

Во-вторых, оказалось, что бампер на заводе был собран неправильно. Пересобрали по гарантии - ура!

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

И самый кек. Я, как известный душнила, проинструктировал друга, что нужно проверять во время приемки (15 пунктов контроля), включая толщину лако-красочного покрытия. Известны случаи, когда авто при логистике повреждали, покоцанную деталь красили, и выдавали новый авто со вторичным окрасом. Одолжил ему свой толщиномер. Друг вернулся в замешательстве - вся машина покрашена нормально (120-150 мкм), а одно крыло - под 300! Налицо вторичный окрас. Пошел он с продавцом по парковке смотреть другие экземпляры. И вы не поверите - у всех машин этой модели переднее левое крыло бьется в 300 микрон. Это вообще как? Науке сие пока неизвестно. Китайские нано-технологии, не иначе.

Мораль. Гарантия - хорошо. Повод ей воспользоваться - уже не очень хорошо. Китайский автопром - совсем плохо.

Надежность: предотвращение инцидентов из-за потенциально известных проблем

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

Инциденты неизбежно случаются. Но нет ничего хуже, чем наступить на те же грабли. Поэтому каждый инцидент проходит процедуру разбора и выявления экшн-айтемов. Но их еще надо сделать. И чем раньше - тем меньше вероятность рецидива. Поэтому мы постепенно сокращаем SLA на выполнение экшн-айтемов. Тут важно не пережестить - не нужно вешать SLA на всевозможные nice-to-have идеи по мотивам. Только на задачи, "в лоб" предотвращающие повторное падение, или драматически снижающие импакт от оного.

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

Очень важно регулярно проводить разного рода учения. Например, по имитации потери одного из дата-центров. Это поможет в условиях сохранения контроля найти те проблемы, которые нас похоронят в случае реальной потери ДЦ. И речь не только о запасе прочности - само изменение топологии может вызвать "бум" - от автофейловера БД до metastable failure.

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

Архитектурное ревью

Сегодня в нашем официальном канале Yandex for Backend вышел мой пост про архревью.
Как я там и обещал, выкладываю артефакт к одному из пунктов - шаблон-опросник.

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

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

Энциклопедические знания

Раз уж сегодня день знаний, поздравлю вас с ним следующей аллюзией.

Из недавнего разговора с коллегами:
- А от Тунгусского метеорита кто вымер - динозавры или мамонты?
- Можно глянуть в Википедии
- Не, спрошу у чат-гпт

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

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

Сила - в знаниях. Читайте энциклопедии.

Автор колонки уходит в отпуск до сентября, не теряйте.
Но на случай, если вы что-то пропустили, вот дайджест прошлых постов:

Важный дисклеймер (есть в закрепе)

Рабочее, серьезное:
И снова про алгоритмы
Стратегия надежности 1 2 3
Надежность: качество релизов
Про BDUI
Вредные советы для продактов, ставящих задачи разработке
Должен ли тимлид писать код?

Околорабочее, несерьезное:
О дипломированных специалистах
Зирвак как платформа надежности
Доверьте работу профессионалам
Трудности перевода
Командный дух

Про тачки:
Автопуть
Mercedes-Benz Panamera WRX
Trust issues
Обратная связь

В порядке бреда:
О пользе караоке
Бизнес-план
Распределенный бог

Предыдущий дайджест

А если вам нравятся мои тексты, поделитесь ими по-братски с друзьями/коллегами. Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков). Спасибо)

Обратная связь

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

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

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

Со стороны пользователя все выглядит чуть иначе. Услуга оказана некачественно. Диагностика авто после покупки выявила существенные недостатки, которые эксперт-диагност не заметил. Впрочем, не очень-то и старался, судя по косвенным признакам, включающим записи видеонаблюдения у продавца. Что ж, бывает, донесу обратную связь.

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

Должен ли тимлид писать код?

Я считаю, что да. Хотя частенько слышу иное мнение.

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

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

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

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

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

Как же он успеет и лидить хорошо, и код писать - спросите вы. Если мы говорим о руководителе небольшой (5-7 человек) команды, то руководство ей не должно занимать фулл-тайм. А если занимает - это тоже звоночек. Возможно, лиду приходится с людьми нянчиться, и тогда нужно вложиться в их самостоятельность, укомплектоваться ребятами посильнее, делегировать что-то и высвободить себе время. Если команда большая (10-15 человек), то либо можно кодить поменьше (условно, 10% времени вместо 40), либо попилить команду на две, либо вырастить себе зама.

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

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

Вредные советы для продактов, ставящих задачи разработке

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

Сабджект: Та фича, про которую я тебе говорил в коридоре
Описание: <отсутствует>
А на самом деле: и как это понимать? Когда ты что кому говорил? "Нет времени объяснять"? А ты уверен, что я тебя правильно услышал и запомнил? А когда я сделаю что-то по-другому, опять я буду виноват?

Сабджект: Новая фича
Описание: <скриншот макета из фигмы>
А на самом деле: А что именно из этого, простите, надо делать? А как оно сейчас выглядит с учетом вариативности экспериментов? Как оно должно работать? Кто это вообще рисовал??

Сабджект: Сделать ручку (endpoint - прим.ред.)
Описание: Нужна ручка, которая принимает id юзера и возвращает жсон со статусом и eta текущего заказа.
А на самом деле: А какую задачу ты решаешь? Можно хоть какой-то контекст и цель? Все же разделение труда придумали не просто так, оставь нам решать, как именно технически решить эту задачу и какой контракт будет у ручки, пожалуйста.

Сабджект: Вырастить GMV на 3%
Описание: Мы отстаем от бюджета 6+6, нужно догнать GMV. Поэтому нужно повысить конверсию с главной в заказ на 2% и средний чек на 6%.
А на самом деле: Спасибо, тут есть какой-то контекст "зачем". Но не хватает "как", а вот это уже, в продуктовом смысле - твоя вотчина.

Сабджект: Писать на трекинге "доставили раньше на Х минут".
Описание: Если заказ завершается раньше промиса, писать об этом на экране трекинга.
А на самом деле: А если раньше на 1 минуту, все равно писать? А если заказ отменился? А считать от прибытия курьера или от передачи заказа? Кто должен продумывать корнер-кейсы, ты или я?

Сабджект: Трансляция на трекинге, чтобы клиент не скучал
Описание: Если курьер опаздывает более, чем на 10 минут, клиент скучает и злится. Чтобы его развлечь, будем показывать на экране трансляцию с фронтальной камеры марсохода Curiosity с задежкой не более 3с - покорение космоса это круто. Срок - до пятницы хард, заказана реклама на ТВ.
А на самом деле: Ммм, а у нас нет sdk для потокового видео, нужно затаскивать. Еще с NASA надо договориться об API. Доступы проковырять. А задержка в 3с немножко невозможна - расстояние до Марса колеблется в диапазоне от 3 до 22 световых минут. Может, стоило обсудить техническую возможность до того, как ставить задачу и прибивать гвоздями сроки?

Сабджект: Пофиксить краш на корзине
Описание: BLOCKER ASAP (проявляется у Ромы!!!)
А на самом деле: По приборам этих крашей было 8. На двух униках. Три - у Ромы, 5 - у нашего qa. Это точно достаточно критичная задача, чтобы отложить ради нее все остальное? Давайте реже следовать методологии RDD (Roma-Driven-Development) и опираться на цифры и риски?

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

Командный дух

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

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

Одна из уже сложившихся традиций у нас - раз в год ездить на какой-то не-московский этап RDS GP, притом заодно делать из уикенда какую-то запоминающуюся тусовку. Поначалу я знал лишь одного коллегу, кто тоже болеет за дрифт. Сейчас мы второй год ездим всемером. У нас в тусовке есть тимлид (и практикующий бекендер), три продакта, проджект (ex-qa), рукль разработки и CEO. Нужно завербовать еще хотя бы одного фронта и сможем за выходные под пиво запускать проекты! (Чрезмерное употребление алкоголя вредит вашему здоровью)

В прошлом году ездили на питерский этап. Сняли на Игора-драйв домик с сауной, пожарили шашлыки под корону (салют ми фамилия!), поиграли в коднеймс, посмотрели этап. Было офигенно! Заодно притащили в офис мерчовый ковер Forward racing, чтобы напоминал о поездке. И весь год ждали новый сезон.

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

Fresco - очень хорошо.
Тунгуска - невероятно хорошо. Настолько, что, пожалуй, это самый вкусный ресторан, где я был.
Hello wine - классные завтраки (со слов ребят, я пораньше уехал на кольцо).
Formagio - пойти туда на завтрак было ошибкой - это оказался шведский стол...
Brisket boys на фудкорте RDS - как обычно, ван лав. Верните похлебку!
Spaten в аэропорту - вполне неплохо по аэропортовым меркам.
Общественная баня №6 на речном - если вы ностальгируете по совку. Попариться можно, Нарзан имеется.

Сам этап выдался мокрым, но интересным. Суббота - квалификация и топ-32 - шли по сухо-мокро (нестабильное покрытие в пятнышку - ад дрифтера), что добавило много непредсказуемости. Было валидольно, но заезды не самые жирные. В воскресенье лил сильный дождь весь день. На трассе было столько воды, что организаторы рыли дренажные канавы, а пилоты снимали передние бампера, иначе их отрывало потоками воды. Но то, как в этих условиях показали себя пилоты - это просто восторг! Такого коммитмента по сухому-то редко увидишь.

Отдельно зацепила мудрость от комментаторов: "В первом повороте гонка не выигрывается, но очень легко проигрывается".

Это снова было незабываемо. Спасибо вам, дорогие! Люблю вас) В следующем году повторим.

Trust issues

Для меня важно доверять своему автомобилю. Быть уверенным, что он довезет. Знать, что на ходу ничего критичного не отвалится. Я после покупки очередного авто не езжу быстро и агрессивно, пока тщательно не обслужу его (и пока не "вкачусь" в машину, чтобы хорошо ее знать и чувствовать, но это другая тема). Но это вопрос не только надежности машины "в лоб", но и ее характера.

У меня было много машин, которые частенько просили ремонта (с моей любовью к некрухам - немудрено). Но некоторые из них всегда сначала довозили, а потом просились в сервис (например, mercedes s-klasse w220). Некоторые сразу никуда не ехали, оставаясь у дома в духе "мам, мне ко второй паре" (например, bmw 325 e90). Но хуже всего - те, которые подводили меня в самые неподходящие моменты. Например, Cadillac Escalade GMT900. Как вы просили в комментах к прошлому авто-посту, пилю прохладные.

Но сначала обрисую персонажа. Что же из себя представляет эскалейд? Бешенный белый носорог, готовый с ревом броситься на любую газель. Слабоадекватное трехтонное жывотное, которое послушно следует за педалью газа примерно в направлении поворота руля. Мотор V8 6.2л, 409 л.с. прям тащит. Настоящее американское лакшери (но только в комплектации platinum), притягивает взгляды. Однако, на ходу она не такая плавная и мягкая, как ожидаешь (как минимум на 20-х тапочках). Очень просторный салон и огромный багажник. В целом-то, машина кайфовая. Но не лояльная, а я этого не прощаю.

Конец августа 2020, заканчивается дачный сезон. С дачи надо вывезти жену, ребенка, кошку, тёщу и несколько кубометров скарба. Даже в эскалейд все это за один раз не влезет. Принимаю решение сделать две ходки. В первый заход гружу тёщу и часть вещей, еду в город. Ливень, на дороге много воды. И вот этими потоками отрывает трубку маслообменника коробки. Заметить это сразу - трудно. Зато, когда через 80км коробка без масла сплавилась в один чугунок, проблема становится весьма заметна. Становится ясно, что не то что вернуться на дачу за второй партией - до сервиса то доехать затруднительно! А надо вывозить семью. Тачка - в сервис, я - за грузовым каршерингом.

Октябрьское воскресное утро. Через полчаса начнется трансляция финального этапа RDS GP в Сочи. Все настроено, чипари закуплены, я предвкушаю жирные заезды. Но тут вспоминаю, что в эскалейде бак почти пустой (с расходом 25л это довольно частое явление), а утром везти сына в садик, заправка не по пути. Ладно, еще же полчаса есть, заправка в 5 минутах, успею! Однако, с АЗС уехать уже не смог - не двигается рычаг КПП. Как позже выяснилось, сдохла лягушка под педалью тормоза, разблокирующая рычаг кпп, а режима принудительного перевода рычага у машины просто нет. Отдельный прикол - машина под навесом заправки, и эвакуатору-манипулятору не хватает высоты навеса, чтобы поднять авто. Поэтому он сначала меня зацепил за переднюю ось, приподнял и вытянул за заблокированных задних колесах из-под козырька, после чего уже грузил целиком. Половину этапа RDS пропустил.

Морозный январь 2021. Зачем-то поехал в командировку в Питер на машине. Приехал, оставил машину у отеля, пару дней поработал. В день отъезда планировал доехать на тачке от отеля до офиса, поработать, и вечером стартовать домой. Но у машины были другие планы - она не завелась. А мне в этот день как бы домой надо. Да и не планировал я в СПб задерживаться. Чужой город, эвакуатор, сервис. Хорошо хоть мастер к концу дня справился с проблемой, которая оказалась в растрескавшихся от мороза бронепроводах зажигания.

Спустя два дня машина была выставлена в продажу, ибо нефиг. Означает ли это, что Cadillac Escalade - сыпучая шляпа? Пожалуй, нет. Ну с кем не бывает - трубочка, датчик, провода - ерунда же, машине 10 лет. Но либо вы с машиной друг другу доверяете и уважаете друг друга, либо надо разбегаться.

Про BDUI

Не будем уходить далеко от темы backend-driven-UI и попробуем разобраться, хорошо это или плохо. Но сначала - краткий исторический экскурс в бдуй Яндекс Еды.

Когда я пришел в Еду в начале 2021 года, BDUI уже был. Но простенький такой, на минималках. Можно было через так называемый Layout Constructor задавать с бекенда вид некоторых экранов (в первую очередь - главной страницы с каталогом). Было понятие блоков/виджетов. Это было нужно для того, чтобы продакт мог сам немного поменять вид главной в поисках оптимального сетапа. Мог запустить эксперимент с альтернативной главной на сегмент аудитории без кода. Мог развести фичи по сегментам или географиям. Но вот незадача - админка была написана чужими для хищников, и пользоваться ей умело 2-3 человека.

Поэтому появилась вторая генерация - с Layout Configurator-ом и виджетами-без-кода. Тут уже все было по-людски, плюс реализация логики виджетов стала выезжать из LC, в котором можно было через админку задать правила обхода источников и формирования выдачи из их ответов. Хорошее проявление лоу-код/ноу-код подхода. Без всякого там богомерзкого ИИ.

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

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

А минусы будут? Куда без них.
Во-первых, сокращается гибкость, особенно в вопросах сложных визуалов. Не может такой фреймворк уметь во все те фишечки, что заложены в натив вендором платформы. Всякие красивости-анимации, всякие глубоко-платформенные look&feel особенности (в большей степени характерные для ios) в таких SDK по большей части недоступны. Но не беда - всегда же можно оставить какие-то части, где это важно, нативными. Или допилить SDK.
Во-вторых, некоторые разработчики слишком сильно любят те самые нативные фишечки и не хотят уходить в бекендно-фреймворковую разработку. Типа это не то. Ну камон, если ты - в первую очередь, инженер, то ты должен понимать, что это более эффективный способ достигать целей. Это инструмент, который про make things done, про результат. Кому важнее процесс - такая работа тоже никуда не денется. Или пилить сам SDK.

Есть и другие плюсы-минусы, можете дополнять меня в комментариях. Но конъюнктура момента такова, что бизнесу нужен bdui, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!

Надежность: качество релизов

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

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

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

Например, сделать в ci-пайплайне автоматическое нагрузочное тестирование микросервиса в изолированном load-окружении перед каждой выкладкой. Если ваш сервис поработает хотя бы 10-15 минут под полной нагрузкой, у вас будут шансы увидеть намного больше, чем при функциональном тестировании - обычные тесты не смогут спровоцировать корки (сегфолты), утечки или проезды по памяти. Вы сможете убедиться, что утилизация ресурсов и тайминги ответов не ухудшаются vs прошлый релиз. Что вы нигде не наворотили с алгоритмической сложностью, сделав вложенный цикл или выбрав неудачную структуру данных. Да, внедрение требует усилий. Да, нужно поддерживать патроны (запросы) в актуальном и релевантном состоянии. Да, отсутствие проблем в релизе это не гарантирует. Но это хорошая солома, которую лучше подстелить.

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

Разумеется, у вас есть тестирование. Но если оно по большей части ручное, вам не избежать ошибок из-за человеческого фактора. А если у вас в добавок очень много тесткейсов, вряд ли вы сможете при каждом релизе проверять их все. Скорее всего, вы придумаете какой-то подход с чередованием паков тестов от релиза к релизу. Но автоматизировав 75-80-90% тестов, вы получите и снижение пропусков, и возможность всегда гонять весь пак регресс-тестов. Без этого - никак.

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

Mercedes-Benz Panamera WRX

Что общего у Mercedes-Benz W124, Porsche Panamera и Subaru Impreza WRX? Во-первых, они все классные. А во-вторых, про них меня попросили рассказать подробнее в комментах к посту про мой автопуть

Mercedes-Benz W124. Легенда и живая классика. Эстетика 90-х, притягивающая взгляды ценителей и не только. Автомобиль с душой и характером, комфортный и благородный. В нем чувствуется какая-то внутренняя интеллигентность, а на ходу она больше напоминает небольшой дорогой катер. В конце концов, получаешь удовольствие от самого факта обладания ей. В ней качественные материалы, монументальная тяжесть и фишечки, которых не ожидаешь от 90-х (например, ИК-ключ или автоподача ремня).

Мой экземпляр был 1995 года, купе-хардтоп, в состоянии "булочка" (не "музей", но вид имеет). Притом я за ней ездил в Питер - именно там нашелся интересный вариант. Были сомнения, доеду ли я на ней до Москвы, поэтому в дорогу были запасены: все жидкости, набор инструментов, вэдэшка, скотч, стяжки, насос и многое другое. Однако, ничего не пригодилось. И в последствии машина показала себя надежным агрегатом, хотя внимания и требовала. Впрочем, как и другие мерседесы - сначала довозила до пункта назначения (в отличие, например, от Эскалейда, который меня трижды подвел в самые неподходящие моменты - если хотите эти кул-стори, пишите в комменты). Главное - избегайте моторов на каеджетронике.

Porsche Panamera. Тоже катер, даже более премиальный, но еще и быстроходный. Редкий компромисс между комфортом и драйвом. С одной стороны, это пятиметровая баржа на пневме с потрясным качеством салона и материалов. Реальный премиум, на голову выше большой немецкой тройки. С другой - это все-таки Порше, и 400-сильный V8 отлично сочетается с отточенным шасси. Машина управляется превосходно (по меркам двухтонного бегемотика) и дает много удовольствия за рулем.

Мой экземпляр 2012 года был куплен полтора года назад меньше, чем за 3 миллиона рублей - на мой взгяд, очень неплохое вложение. Даже на пробеге чуть за 100 тысяч, состояние прекрасное, машина имеет лютый запас прочности. Хотя обслуживание недешево - за год тысяч 200 она вполне может просить. Главное - не берите из-под горячих ребят, которые на них ураганят и плохо обслуживают. Лучше воспользоваться подбором и обязательно проверять движок с эндоскопом - они склонны к задирам.

Subaru Impreza WRX. Продолжая морские метафоры - это бешеная тайская лодка на джейзете, избыточно быстрая, шумная, неуправляемая, некомфортная. Но очень нравится. Харизма так и прет - начиная с фирменного бу-бу-бу от неравнодлинного коллектора оппозитника, и заканчивая фирменным же полным приводом, позволяющим грести на всех парах по любому покрытию. Старая японская школа - аскетизм в сочетании с диким кайфом от вождения. Зимой прямо едет редко, но ты удивительно быстро добираешься до пункта назначения.

Мой экземпляр был 2001 года - так называемый, "лупатый". Естественно, синий. Разумеется, на золотых дисках (правда, только летних). Первым делом поменял лавку на высокую от sti (да еще и с распорками в духе wrc). Вторым - сделал подсветку под днищем в духе форсажа и need for speed. Непременно поставил blow-off. Выря вполне хватает, сти - даже перебор. Увы, машина пала в неравной борбе с бетонной стеной развязки ТТК в условиях гололедицы, поворота, уклона, обратного бенкинга и хреновой липучки.

Трудности перевода

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

Я все чаще встречаю в разных местах фразы типа "запустили каталог готовых промтов", "self-service аналитика с конкретными промтами", "поделились промтами", "отладили промты и стало хорошо" и так далее.

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

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

Ну как переход от ассемблера к сям ("ого, можно самому не мувать регистры!") или от сей к го/джаве ("ого, можно не выделять и не освобождать память!"), так и тут - "ого, можно не писать руками for, офигеть".

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

В общем, магии снова не случилось. Никакого вайба.

Стратегия надежности (3/3)

Проекты, задачи, процессы:

Качество релизов:
- автоматические стрельбы по сервисам тира А в ci-пайплайне при каждой сборке (поможет отловить снижение производительности из-за неаккуратных изменений в коде, корки и утечки, снижение капасити, повышение таймингов)
- регулярное нагрузочное тестирование в продакшне танком (читающие сценарии) и виртуальными заказами (цикл заказа) (поможет контролировать капасити системы в целом в реальных условиях)
- автоматизация тестирования, близкая к 80% (снижает человеческий фактор, повышает полноту регресса)
- модуляризация, флексизация (bdui-механика), микрофронты (позволят кататься меньшими кусочками и не ломать смежную функциональность)

Предотвращение инцидентов из-за потенциально известных проблем:
- снижаем SLA на блокирующие action-item-ы к инцидентам (позволит снизить вероятность рецидива)
- держим SLA по дьюти (обращения пользователей и коллег) first-touch&full-resolve и ZBP blockers (ибо любой дьютик или багрепорт - потенциальный предвестник инцидента)
- регулярные учения -дц (помогает находить валенки на пульте в тепличных условиях)
- автоскейлер (помогает автомагически держать нужное капасити для cpu-bound сервисов с быстрым стартом)
- помогаем партнерам быть стабильнее (детали - <censored>)

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

Улучшаем реагирование:
- повышаем alerts uptime (чтобы не было слепоты к алертам)
- держим тримап (инструмент визуализации алертов) зеленым (также для снижения слепоты)
- автопротоколы там, где их еще нет (+эскалация)
- растим обзервабилити клиентских ошибок (детали - <censored>)

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

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

Стратегия надежности (2/3)

Манифест:

Как гласит девиз МЧС, "Предупреждение, спасение, помощь".
Так и с надежностью - инциденты нужно предотвращать, купировать и выносить из них уроки.

Цель.
- 99.95% в заказах по атласу (внутренняя система детекта аномалий). 99.99% rps-uptime по сервисам tier A (сервисы, влияющие на цикл заказа).
- Соответствие тира критичности и тира надежности сервисов по модели 9999 (внутренняя классификация тиров надежности и требования к ним).
- Фокус на спасение заказов на более поздних стадиях, когда в случае потери будут большие инсентивы (сопутствующие потери на компенсации).

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

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

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

Стратегия надежности (1/3)

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

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

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

Кстати, если вы классно умеете делать такие штуки, го к нам! https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)

Доверьте работу профессионалам

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

В закулисье Формулы-1 я разбираюсь чуть хуже, чем в медицине (Drive to survive я посмотрел только 5 сезонов против 8 в House M.D.), но все же докопаться было особо не до чего. А участие реальных действующих лиц из Ф1 в фильме и вовсе считаю прекрасным режиссерским ходом.

А знаете, почему им это удалось? Потому что со-продюсером фильма выступил Льюис Хэмилтон, 7-кратный чемпион Ф1. Доверьте работу профессионалам!

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

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

Главное - не давайте бекендерам делать UI/UX, даже для админки ;)

Это я к чему? T-shape - это хорошо. Fullstack - уже, обычно, не так хорошо. Некомпетентность - совсем плохо. Используйте свои сильные стороны, чтобы нанести пользу, даже за пределами своего основного проекта. А там, где вам не хватает хардов - не всегда получится залить все софтами, призовите на помощь более компетентного спеца.

Распределенный бог

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

Через это объясняется и отсутствие монокаузальности в наших действиях. Вот стоишь ты на кухне, занеся газету над мухой, в желании ее прихлопнуть. Кто виновен в неизбежной смерти насекомого? Ты, который не любит мух? Почтальон, принесший газету? Издание, выпустившее номер? А может, сама муха, залетевшая не в то окно? Ты с газетой в руке - это режущая кромка истории, а меч судьбы целиком так огромен, что никому его не увидеть. Это весь космос. Нет единопричинности, есть конъюнктура момента.

Та же философия применима к понятию счастья. Мы все хотим быть счастливы. Если разобрать эту интенцию до конца, мы желаем вот чего: чтобы нам немедленно стало хорошо. Другого счастья не бывает, потому что не бывает другого момента времени. Но как ни старайся, невозможно гарантированно приехать в точку под называнием "счастье" в результате лишь собственных усилий. Хотя бы потому, что в каждом нашем миге участвует весь остальной мир. А мы над ним не властны.

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

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

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

(Инспирировано (и частично процитировано) произведениями В. Пелевина)