Я тут всё за правильное observability выступаю, вот и решил сделать цикл статей про то, как я делаю у себя. Сложность пойдёт по нарастающей. Любые неточности я себе заранее прощаю 😌
На волне оптимизации расходов ФОТ (увольнения айтишников на мороз), коллеги вокруг стали спрашивать про то, как сохранить тёплое место и большую премию.
Открою секрет - для бездушной корпоративной машины ты - ресурс, время которого покупают. Точно так же, как ты покупаешь время автомехаников, продавцов, курьеров, покупают и тебя. А ввиду окончания бесплатных денег и закрытия изначально провальных проектов, работодатель может позволить себе выбрать тех, кто поумней и попродуктивней.
Без конкретных фактов и достижений, произойдёт оптимизация. Причём, тебя могут как выставить на мороз, так и лишить премии и перестать повышать (дабы довести до заявления по собственному). Если ты суперкрутой спец и все в команде тебя знают, полагаться на репутацию и отзывы своего лида ты не можешь - он может просто уйти, тебя могут перевести в другую команду или оценка будет не только по отзывам.
Что является хорошим фактажом? 1. Факты с Performance Review 2. JIRA - количество тикетов, стори поинтов, часов 3. Выполненные цели (квартала/года/окры или еще что) 4. Обычный 360 (отзывы коллег) 5. NPS (отзывы от заказчика) 6. Участие в активностях (хакатоны, выступления)
Собственно, если ты нормально работаешь работу на работе и делаешь трекинг своей активности, то выгнать или лишить премии тебя будет тяжело (но не невозможно). Но может быть побочный эффект - по результатам трекинга ты увидишь, что нифига полезного в проекте и не делаешь :-)
Есть API, который создаёт заказ. В случае успеха - возвращает его ID и эхо-ответ. Вопрос: что должен вернуть сервис в случае ошибки?
Варианты ответа: 1. Нормальный ответ со специфицированной ошибкой и нормальным HTTP кодом 2. Пустое тело с id = 0 3. Эхо-ответ без id 4. Ошибку текстом (типа стектрейса или General Error без описания) 5. Отвалиться с таймаутом
Правильные ответы - 2-5. Причем, конкретный вариант зависит от данных. Писала её скрум команда мотивированных профессионалов, все на собеседовании решали задачки по кодированию. Поэтому и техлиды/архитекторы не нужны, всё просто же, зачем нам проектирование.
В итоге, вместо пары дней разработки с тестами, я страстно занимался интеграцией где-то недели три. Если не учитывать мои нервы, это стоило много денег заказчику за работу + стори, которые я не делал (упущенная выгода). А всего-то надо было взять архитектора для написания спеки ДО или сделать архитектурный надзор в процессе/после. Да, жаба давит отдавать даже кусочек ставки на дорогого специалиста, но это окупится потом многократно.
Делаю доклад на СайнтТимлидКонф 2025 и у меня скапливается как-то много материала. Поэтому буду выливать излишки в уютную группу.
Первая и самая большая проблема оценки задач в айти - это непонимание, кто есть ее потребитель и зачем она делается.
Допустим, к работяге пришел менеджер и спрашивает "оценки". Так вот, когда работяга даёт свои "эээээ нууу пусть 5 сторипоинтов" или "нуууу до конца недели сделаю, если ничего не прилетит", то что он имеет ввиду? Варианты: 1. 40 его полноценно рабочих часов чистейшей разработки 2. Срок разработки до теста + багфикс + доталкивание до приемочного стенда с учетом рисков и интеграции 3. Срок доталкивания этой задачи до теста с учётом влётов и текущих задач, что он пообещал до конца недели еще трём людям. 4. Сложность выполнения задачи в соответствии с DoD
Сообразительный читатель ответить мне - а х&* его знает зависит от контекста и будет прав. Работяга ориентируется на комбинацию своего опыты текущего/предыдущего проекта, возможных рисков, знания расписания отпусков девопсов и тестировщиков, объем входящих за сорванные сроки.
И менеджер, который собирает эти оценки и составляет план, либо не спрашивает, либо не говорит, что ему нужно. А потом в соответствии со своими детскими травмами делает расписание проекта деля 40 на 8. А потом это уходит к руководству как жесткий коммит и начинаются переработки, подвиги и выгорания.
Я наблюдал лично случай в одной крупной компании. Менеджеры собрали вот точно таким же образом оценки с работяг, составили план, расписались под ним кровью и продолбали все сроки. Когда собрали ретроспективу, то прозвучало самое топовое предложение "Ребят, а давайте договоримся, что значит - "сделано". Это докатка до теста, до прода или раскатка на всех пользователей всех платформ?"
Вот для этого и нужно создание системы оценки, про которую я и расскажу.
На одном проекте сменился техрук. В прошлой его компании всё было на автотестах, тестировщиков не было. Ну вот он и решил быть в тренде и косты порезать- взял и сократил ручных тестировщиков. На архитектуру и код он перед этим не смотрел.
Как оказалось, в той системе были большие проблемы с Testability и Configurability. Проще говоря - писать автотесты дольше, чем кодировать, а локально развернуть и протестировать невозможно - только на окружениях. Тестировщики-ручники тестировали по наитию, без внятных тест-планов или всяких трасибилити матриц. Вопрос: что будет с проектом?
На другой проекте пришел эйджайл-коуч-трансформер. Знания его в технике сводились к словам "Девопс", "Юнит-тесты" и "Континиус интегрейшн/деплоймент", но с руководством он общаться умел. Ему дали натягивать скрам и двухнедельные релизы на группу внутренней автоматизации (это те ребята, которые пишут сугубо бек-офис). К самим разработчикам претензий не было, но у ребят был нулевой показатель Deployability. Простым языком - "для раскатки нужны особые Литании Раскатки и пара техножрецов для вознесения молитв Духу Сервера". В обшем, через n месяцев мучений, скрам не взлетел. Нервов разрабам потрепали изрядно, денег потратили порядочно. Самое интересное, что эти двухнедельные релизы бизнесу были не нужны и ему дали эту группу как пилот.
А как нужно-то делать? Если вы стартуете или начинаете трансформировать проект или команду, нужно подключать грамотных технарей и выписывать все NFR, включая технические. Грубо говоря, делаем аудит и уже потом решаем, нужно ли что-то делать. Объясню на примере:
Дано: - Бизнес с очень глубокими знаниями в доменной области - Домен с очень специфическими бизнес-процессами - Группа матёрых разработчиков-сениоров и сениорит - В целом, ошибки допускаются - есть возможность откатить косяки в проде
Ход размышлений: - Аналитик не особо поможет, потому что домен начисто отбитый. Это наоборот замедлит разработку и внесёт помехи. Т.к. разрабы опытные, то даём общаться им напрямую с бизнесом. - Бизнес не будет писать портянки требований, а постоянно давать обратную связь. Значит, нам нужно делать малые каденции и часть деплоить (даже раз в день). Значит, выкручиваем на максимум Deployability. - Нам нужен постоянный регресс из-за частых поставок и сложных требований. Значит, затачиваем Testability на интеграционные автотесты. Нужен ли тестировщик? Если есть очень грамотный, то можно для UAT. Если обычный - то будет мешать. - Чтобы все было +/- стабильно, мы разрабатываем тактику Integrability (чтобы не толкаться локтями и обеспечить обратную совместимость). - У нас нет серьезных требований по Reliability, значит все, что написано выше, может работать.
Выводы: То, как у вас работало на прошлом проекте, может не взлететь в этом. Даже в той же компании, даже у того же бизнеса. Используйте цифры и здравый смысл при трансформациях и других вмешательствах в команду.
Работа на медленном интернете как критерий качества продукта
Опять абстрактная трепология про продукты, но мое горение от качества некоторых продуктов сильно повышает температуру окружающей среды. В следующем посте точно про технику будет.
Я сейчас в отпуске и при заезде получил бесплатную опцию "Интернет-целибат". У него сломался роутер в районе моего дома и за слабеньким публичным интернетом нужно идти 500 метров на рецепцию. И вот я уже почти месяц использую свои мобильные и десктопные приложения в условиях плохого качества связи.
Почему-то с точки зрения технарей и продактов, это считается редким кейсом. И я говорю не про абстрактную заграницу, когда душит жаба купить симку. Почему-то они считают, что у нас везде есть шустрый wifi, 5G и нет ни одного магазина/пункта выдачи в подвале, где ловит только 0.5 палки.
У абстрактного меня повысится NPS, если: • Я нахожу фото своего заграна в фоточках, отправленных жене за 2021 год • Точно знаю, что эта заметка синхронизируются на ближайшем интернетопое и я ее допишу с компьютера • Я открою приложение магазина для загрузки штрих-кода где-нибудь на -1 этаже и оно мне не выдаст идиотского онбординга, а быстро покажет номер заказа.
Да, это требует дополнительных когнитивных и разработческих затрат и вообще проще прикрутить какой-нибудь радужный онбординг, который якобы нальет пользователей в воронку. Только пользователям часто нужна база, а не RGB подсветка текста.
Это, кстати, касается любого микросервиса, сервиса или софтины. На меня коллеги смотрели как на колдуна, когда я предусмотрел сценарии таймаута для HTTP запросов(!) и возможности неприхода ответа в очередь.
Решил податься на конференции (нужно же пёрсонал брэнд качать!) на этот год. И утонул на час в прекрасном мире розовых пони, которые какают радугой. Один кейс позитивней другого, все взлетает, все сходу трансформируется.
Нет, оно понятно, что компании нужно качать ичар бренд, да и о своих факапах рассказывать не очень принято (рушит пёрсонал бренд и магию!). Но я бы с удовольствием сходил на что-то типа:
- Помните, мы положили прод? Это было из-за ошибки Х и вот чему научились - Вот такой микросервисный сетап не работает потому что... - Внедряли скрам, а получился срам и разбежалась вся команда. Почему так? - Попробовали такую гипотезу, уронили NPS в пол. Не делайте так.
На собеседовании я всегда спрашиваю про самый большой факап кандидата и то, как он его исправил. Ибо это показывает его уровень соображалки, стрессоустойчивости и умения делать выводы из своих ошибок.
Потому что разработка сама по себе это череда личных минифакапов и их исправлений, названных красивыми словами дебаг и рефакторинг.
Ну что, думали канал умер? Я тоже так думал :-) Сегодня расскажу про амбициозные цели и почему их ставить надо осторожно (иначе тоже пропадете с радаров на три месяца).
На НГ мы поставил себе цели и нарисовал всякие планы. Половина уже забила на их выполнение и погрузилась в рутину, а оставшимся это еще предстоит. Происходит такое от неграмотной постановки цели (начиная от мотивации, заканчивая формулировками и планом). Последствия от такой неграмотной постановки - фрустрация различной степени тяжести, временное падение самооценки и невыполнение самой цели (т.е. ничего страшного).
А вот если цель грамотно поставлена… Есть у нашей дружественной вселенной такая особенность, что она начинает накидывать вам возможности и варианты, когда вы фокусируетесь на цели. Внезапно начинают поступать интересные предложения и происходить другие приятные совпадения. И это хорошо.
Проблемы начнутся, если вы совершили акт оверкоммита - набрали много обязательств, из которых не выйти или закусились личной целью "на мужика". При возникновении любого риска (оказалось больше работы, навалились личные проблемы, проблемы с мотивацией) приходится насиловать себя и брать энергию и силы взаймы. Потому что времени на отдых не остается, отпуск отодвигается, спорт идет под нож.
Первое время это весело, потом приходится принимать стимуляторы (кофе, энергетики), дальше идет алкоголь и вредная еда. И все это время вы занимаете в долг у своего тела и психики. И в какой-то определенный момент, организм пришлет коллекторов. Сначала это будут легкие болезни/простуды/недомогания. Если в этот момент вы не возьмете паузу, то начнутся более жестокие проблемы. В итоге вы просто выпадете на несколько месяцев. И дай Бог, если вы сможете минимизировать ущерб для здоровья и карьеры.
В общем, проверьте свои цели на адекватность и чаще отдыхайте.
Как-нибудь расскажу потом, как все-таки ставить цели...
Смотрел недавно на код коллег, которые не читали "Совершенный код" и чуть не ушел в запой задумался, а как набирать людей, которые будут писать нормальный промышленный код? Т.е. не решать задачки на LeetCode, а делать то, что живет на протяжении многих лет и не вызывает ненависти у следующих поколений, обслуживающих этот код.
И придумал вот такой вопрос для будущих собесов - "Какие требования к качеству кода ты считаешь самыми важными?". В дискуссии станет сразу понятно, насколько человек сможет писать командный код.
Вот мой личный топ: - Readability/Understandability - насколько легко читать и понимать твой код. - Testability - насколько легко протестировать код и написать для него автотесты по всей пирамиде тестирования. - Maintainability - насколько просто делать новые фичи/чинить баги в коде. - Observability - насколько легко отследить текущее состояние и локализовать ошибку.
Без соблюдения этих требований будет следующая безблагодатность: - PR/MR review будет проходить более поверхностно (попробуй прочитать Stream или лямбду на два экрана). И чтение кода не будет обучать команду. - RTO/RPO (как быстро вы поднимете упавший прод) упадут! Если код понимает только условный Вася, то в его отсутствие команда первые два часа будет пытаться понять, что имел ввиду автор. - Упадет надежность приложения и заветные девятки вы не получите. Иногда хочется написать крутой тест, но время его написания сравнимо с реализацией самой фичи.
И так далее... Как следствие, у вас падает заветный Time to Market, на который яростно молятся все ведущие аджаел коучи. Да и в команде работать будет не так весело.
После десятков проведенных тренингов и проектов, я наконец-то сформулировал для себя, что же такое "DevOps мышление". Объяснить это у меня не получится, поэтому специально для тебя, работяга, я сделал тест на это самое мышление.
За каждый ответ "Да" начисляй себе балл и ты все поймешь:
1. Я пишу код без логов, потому что все понятно из кода и вообще, можно дебагом на прод залезть 2. Тесты нужны для покрытия. assert(true==true) - наше все 3. Если что-то забыли специфицировать, то это проблема бизнеса. И хрен с ним, что не работает. Я все сделал как было написано 4. Задеплоенную версию не обязательно проверять (типа, послать пинг). 5. Вообще можно не смотреть, поднялось ли все. Пофигу, что куб уже 50 раз перезапустил контейнер. Если что-то плохое будет, то прометеус мне алерт кинет 6. Ошибки на проде - это проблемы суппорта. Они сами все должны понять без документации и operation мануала 7. Интеграция - это головная боль зависимой системы. Не, ну а фигли они запросы какие-то странные шлют?
Ответы: 0 - ты красавчик и девопёс. 1-6 - ты красавчик, но не девопёс 7 - ты просто пёс
DevOps мышление - это когда тебе не похуй все равно на конечный результат. А все остальные определения нужны для продажи тренингов и коучей.
Когда я был молодым и горячим, я люто горел от корпоративных стандартов в разработке. Приходишь ты такой в Кровавый Энтерпрайз, а там огромная портянка требований к коду, совершенно идиотские правила Sonarqube и покрытия тестами.
Я небезосновательно считал это помехой для быстрой и качественной разработки. Ну что за идиотизм, когда сборка заваливается от пары идиотских Code Smellов и нужно тратить время на прописывание эксклюдов. В ту же степь - test coverage 85%.
К чему я про это пишу? Сейчас я сижу и вылизываю яйтесты своего микросервиса до характерного блеска, пока коллеги в пожаре дописывают свою часть. Потому что я не могу быстро переключиться и напилить фичу в их кодовой базе - на вникание и банальный дебаг кода у меня неделя уйдет. Потому что у нас же микросервисы и каждый из разрабов пишет свое уникальное видение этого паттерна.
Так что опытные коллеги были тогда правы. И в любом проекте, где я имею власть, я прописываю эти самые стандарты. Это можно делать через документы (самый плохой способ) или через quickstart/backbone (это когда можно запулить код и начать писать функционал).
Делал я недавно код-ревью у соседнего микросервиса . Код был с душком, я честно давал комментарии почти к каждой строчке. Минут через 15 появилось желание все реджектнуть с резолюцией "нах*р все переписать", потому что так и надо было сделать. В итоге, я сделал approve и merge. Микросервис не мой, а если совсем много проблем будет, то быстрее с нуля все переписать самому.
То рассказ не только про то, что я ленивый зажравшийся чудак, тут есть глубокая мысль.
Менторинг и обучение младшего специалиста лучше всего проводит специалист максимум на одну-две ступеньки выше. Для него это в новинку, он сам учится чему-то новому в процессе. Опытный лид будет это делать либо крайне грубо, либо на отвали. Ему банально скучно объяснять азы кодирования и очень дорого с точки зрения времени.
Есть единственное исключение - это инициатива старшего товарища. То может быть либо личная симпатия, либо обучение обучению (грубо говоря, лид учит сениора делать код-ревью без матов на примере джуна).
Так что если вы лид - не совершайте таких ошибок. Правда, если тебе лень ревьювить код, это совсем не значит, что ты мегасениор. Может, ты и правда лентяй (как я).
Где-то с середины моей карьеры я стараюсь не работать в слабых командах. Работа в них - это время в никуда. Научиться у таких коллег нечему, научить и подтянуть их - практически невозможно, да и незачем. Для менеджмента это не видно, денег за это не дают, а твои коллеги на своем перформанс ревью не будут упоминать твои старания.
В слабые команды стоит вписываться только если у тебя есть четкий план и цель. Например: - Отдохнуть после сложного проекта/поделать дела - работаешь три-четыре часа, остальное время играешь в игры, ходишь в зальчик, готовишься к собесам. Твое раздолбайство все равно никто не заметит. - Деньги - золотую клетку никто не отменял, семью кормить надо. - Отрабатываешь навыки - нужна строчка в CV, хочешь потрогать технологию или побыть тимлидом.
Чтобы не выгореть и не деградировать, я себе ставил некоторые критерии выхода. Это помогает в особо тяжелые случаи, когда хочется все послать подальше. - Временной промежуток - годик поработаю, посмотрю, что дальше будет. - Критерий выполнения цели, ради которой пошел на дауншифтинг - "Стоп-слово" - какой-то четкий критерий, что нужно валить. Например, явное выгорание или падение мотивации в плинтус даже для выполнения своих целей.
Мне этот прием помогает не выгорать и держать мотивацию и фокус.
По моему личному опыту, скрам-мастер НЕ технарь раскрывается только при наличии технического лидера в команде или если команда сама по себе сильная (типа, мотивированные профессионалы). В в таком случае он делает из хаоса систему и его помощь с фасилитацией очень в тему.
А в среднего уровня команде, ты хоть до смерти закоучи, результата не будет.
Частый вопрос на тренингах скрам-мастеров и тимлидов - "Что делать со сложными подчиненными?". Мой ответ всегда однозначный - если человек м*дак, то убирайте его с горизонта команды. Даже если вы его закоучите и зафасилитируйте до полусмерти, он все равно будет портить атмосферу и командную динамику. Из-за него группа будет меньше общаться, меньше поднимать острых вопросов, не будет доверия.
Что делать, если твой начальник м*дак? Тут все не так однозначно. Если он - пустышка, то меняйте его безжалостно. Я, обычно, ухожу сам в другую команду/компанию. Просто терпеть и игнорировать у вас долго не получится - вы потеряете мотивацию к работе и получите выгорание. Я в таком случае сразу дистанцируюсь и сворачиваю общение и начинаю искать варианты.
A если вам есть чему поучиться у этого человека, то можно заключить договор с совестью и стиснуть зубы. Гениальность и сумасшествие - они хотят вместе. Больше всего знаний и опыта я получил от крайне сложного человека, который меня практически довел до дурдома. Но оно того точно стоило. Только чтобы не выгореть, нужно вовремя соскочить. Лучше всего поставить себе какие-то четкие критерии по времени или по своему состоянию. Иначе - дурка.
