DevFM

Анализ источника багов как начало улучшения процессов работы в команде

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

Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.

Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?

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

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

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

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

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

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

Когда всё горит

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

На тему преодоления кризисных ситуаций с точки зрения руководителя принёс вот такую статью.

Автор предлагает сосредоточиться на следующих аспектах.

Обеспечение поставок продукта (круто звучит по-английски – Ensuring Goal-Aligned Delivery).
– жесточайше приоритизируйте: нужно сосредоточиться только на самых критических моментах
– ускоряйте работу: сократить бюрократические проволочки, выдать команде полномочия на принятие решений
– цените время: нужно максимально ограничить отвлекающие факторы, убрать лишние встречи
– управляйте техдолгом: он неизбежно будет расти, а ваша задача аккуратно фиксировать и подсвечивать проблемные места для будущих фиксов
– будьте с командой: вы как руководитель должны быть вовлечены в проблемы проекта и команды, помогать их решать

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

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

И ещё немаловажное замечание. Не забывайте о своем здоровье: вы не сможете помочь другим, если сами выгорите. Заботьтесь о себе, находите время на отдых и восстановление. В конце концов, не корову проигрываете.
#edu #teamwork

Пятничное развлекательное

Если вы не любите настолки, то пропустите этот пост. Но я совершу преступление по отношению к любителям настолок, если я не напишу об этом.

В первый раз сыграл в эту игру осенью, очень зашла, но купить было негде. Тираж лимитирован и раскуплен. Игра так выстрелила, что был организован второй тираж и, наконец, долгожданный “Шёпот за стеной” у меня.

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

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

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

Всей крутоты в посте не описать, посмотрите обзоры на ютубе.

Пишу об этой игре, потому что совсем недавно Шёпот появился в магазине издателя, но, подозреваю, вскоре будет раскуплен.
#fun

Ведение дел – мой опыт

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

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

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

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

Полезно всем, у кого есть запрос на понятное и упорядоченное ведение своих дел.

Лайки, конечно же, приветствуются.
#devfm #edu #tools

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

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

Конечно, такая табличка может разрастаться на другие области: бизнес-анализ, тестирование, дизайн. Но это уже пусть руководители проектов ведут. Я тут делаю акцент на команде разработки. Чтобы к пуговицам претензий не было.

Есть несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество
#devfm #systemdesign

Вышла Postgres 17

С небольшой задержкой добрался посмотреть, что там интересного в новой версии Postgres 17.

Не буду спойлерить :)

Для детального изучения – release notes.

Я ещё посмотрел хороший доклад с конференции PGConf, где Павел Лузанов проходится по основным изменениям и даёт свои комментарии: где-то рассказывает подробнее о том, что ещё хотелось бы докрутить, где-то о причинах нововведений, в общем, живенько получилось.

#database #skills

Снова о необходимости архитектурных схем

Продолжим пост об архитектурных схемах с более практической стороны.

– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.

– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.

– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же можно скачать pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.

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

– По моему опыту очень полезной может оказаться Deployment диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение. Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.

#devfm #systemdesign #tools

Боль от распухающей базы данных

Интересный кейс от ребят из Figma. Некоторое время назад они сидели на одной жирной Postgres.

Чтобы дать себе время на разработку целевого решения, ребята сначала подстелили сначала соломку:
– Накинули железа (ну конечно, а что ещё остается делать)
– Создали несколько read реплик
– Добавили PgBouncer в свою архитектуру
– Для новых фичей стали стараться использовать отдельные базы

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

Самая интересная задача тут – мигрировать данные без даунтайма.
Сделано это было в несколько шагов:
1. Подготовили клиентские приложения для работы с несколькими базами данных.
2. Настроили логическую репликацию таблиц для копирования данных из одной базы в другую. Тут, кстати, ещё интересный нюанс, логическая репликация может занимать ооооочень продолжительное время из-за долгого обновления индексов, поэтому на целевой бд индексы были удалены перед началом копирования и восстановлены после завершения копирования.
3. Короткая пауза активности на основной бд для полной синхронизации данных.
4. Назначение целевой бд как основной и перенаправление запросов к ней.

В общем, отличная статья в копилку насмотренности технологических решений.

На тему миграций без даунтайма у нас был отдельный практический пост.

#skills #database

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

Если читаете что-то подобное, интересное – поделитесь, очень интересно.

#edu

Для чего нужны архитектурные схемы

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

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

Пост как раз об этом.

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

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

Обсуждение и планирование больших фичей. Когда планируется разработка чего-то сложного, затрагивающего многие компоненты/сервисы. Опять же, можно собраться с командой разработки, аналитиками, обсудить и зафиксировать первичные договорённости. Эта же картинка будет полезна, когда перед стартом разработки будет презентоваться окончательное решение. При разработке разухабистых фичей, кстати, могут быть полезны design docs.

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

О том, как документировать архитектуру у нас был отдельный пост.

#devfm #systemdesign #edu

Как построить систему быстрых дашбордов

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

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

Дальше всё по делу:
– Мониторьте мониторинг – важно не только наблюдать за данными, но и следить за тем, как быстро они обрабатываются. Таким образом можно выявить медленные проблемные запросы и оптимизировать их.

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

– Банально, ноооо делайте оптимальные запросы и храните данные тоже оптимально. В этой части приводятся полезные советы для счастливчиков, которые используют ClickHouse.

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

У нас уже была на обзоре статья на тему мониторинга, загляните и туда.

#skills

Замечательный подкаст от Andrew Huberman на тему Optimal Protocols for Studying & Learning.

Насущная тема, как усвоить ту или иную информацию лучше и быстрее. Автор, опираясь на различные исследования, даёт практические советы на эту тему.

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

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

Дальше интереснее: если проверять себя, то когда это лучше сделать: сразу, через некоторое время или через достаточно продолжительное время? Если тема сна всем понятна, то выводы, к которым приходят в этих исследованиях не всегда очевидны. В общем, рекомендую!

Для особо дотошных на сайте подкаста приведены исследования, которые упоминаются в видео.

На эту тему мы уже рекомендовали очень известный курс Learning How to Learn.

#edu

Всё ли так просто с ретраями?

На первый взгляд ретраи кажутся простым способом улучшить отказоустойчивость. Что может пойти не так? Ребята из Яндекса написали на эту тему большую и захватывающую статью.

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

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

Для решения этих проблем и повышения отказоустойчивости в статье выделяется три способа:
– retry budget – ограничивает количество ретраев в зависимости от количества успешных запросов
– circuit breaker – полностью отключает ретраи, если процент ошибок превышает заданный порог
– deadline propagation – в запросе содержится таймаут, после которого сервер может прекратить обработку запроса

Ссылочка на код, чтобы самостоятельно поэкспериментировать.

В столь же интересном формате у нас был обзор на статью об идемпотентности.

На эту же тему стоит посмотреть видео.

#skills #systemdesign

Micro — консольный редактор с человеческим лицом

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

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

В нашем бесплатном курсе cli-for-dev есть урок про редакторы nano, mcedit, gedit, vim. В центре внимания горячие клавиши. Скоро допишем туда про micro.

P.S. Vim`оводам пост, конечно, будет неактуален 😄

#tools

Всё в той же статье про порядок столбцов в Postgres автор использует термин bike-shedding.

Представьте себе ситуацию: группа людей собралась обсудить важный проект, например, строительство атомной электростанции. Вместо того, чтобы сосредоточиться на ключевых вопросах безопасности и эффективности, они тратят часы на обсуждение цвета велосипедной стоянки. Звучит абсурдно? Это и есть "bike-shedding" — термин, описывающий склонность тратить много времени на обсуждение простых и незначительных деталей, оставляя без должного внимания действительно важные задачи. Подобные вопросы привлекательны ещё потому, что обычно не требуют глубоких знаний и каждому есть что сказать, а за неверное решение не будет никакой ответственности.

Честно, очень люблю этот термин, он на уровне с bus factor ёмко выражает проблематику.

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

#edu #teamwork

Пятничное развлекательное

Дождались! В качестве пятничного развлекательного у нас настолка. В первом посте такого рода не будем советовать банальности, а посоветуем недавно локализованную игру — zoollywood.

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

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

Если заинтересовались, то лучше взять побыстрее, а то тираж закончится и всё, тю-тю.
#fun

Инструмент для анализа узких мест базы данных

В статье из предыдущего поста автор приводит некоторые вспомогательные запросы для анализа порядка столбцов в таблице. Могу порекомендовать удобную тулзу postgres_dba, которая проведет проведет анализ и выдаст рекомендации, где и сколько потенциально можно сэкономить.

Также с помощью с неё можно посмотреть: коннекты, медленные запросы, неиспользуемые индексы, битые индексы, различные статистики и ещё всякое разное.

Мы обновили подборку всех наших постов по базам данных. Там много интересного.

UPD: в комментарии рассказали о еще одном полезном инструменте.

#tools #database