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

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

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

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

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

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

Манифест:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про 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, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!

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 лет. Но либо вы с машиной друг другу доверяете и уважаете друг друга, либо надо разбегаться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сабджект: Сделать ручку (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) и опираться на цифры и риски?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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