CTO: Порядок из хаоса

А вот и аналитика по инженерной зрелости компаний(статья на хабре), в которой многие из вас участвовали. Помните мы устраивали опрос? Большое спасибо всем кто принял в нем участие. Ответ каждого из вас сделал эту статью более глубокой и честной. А вот вам выводы для затравки 1) Для роста нужно не геройство, а системность 2) мы релизим так же хреново как ведем документацию. (такая вот авторская интерпретация подтвержденная цифрами) притяного чтения) PS. спасибо ребятам осуществлявшим информационн...

Сегодня вышел пятничный пост на Хабре — про петуха на проекте. Не с целью оскорбить тимлидов, а рассказать, какие бывают 🙂 Но кроме тимлидов у нас есть и другие роли. - Ворона (PM). Сидит на заборе, громко каркает: «Мало яиц! Лиса близко! Корм заканчивается!». Не помогает, но информирует и следит, чтобы все были в курятнике вовремя. Иногда ворует яйца, но делает вид, что не она. Петух с ней не дружит, но на заборе достать не может. - Белка (QA). Таскает яйца в разные места. «Из дупла выкатится?...

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

На заре своего становления как программиста я использовал trunk-based development (TBD). Если это подходит для Гугла, Нетфликса и Фейсбука, с их тысячами коммитов в день — подойдёт и для меня. Логично же. Там не тупые ребята сидят, между прочим. Я проработал так примерно полгода, пока на проект не пришли ещё два трейни. И этот ваш TBD оказался полной хренью. Ну неудобно же! Постоянно конфликты, постоянно что-то отваливается. Кто это вообще придумал? Мы тут с тремя коммитами справиться не можем, ...

Сегодня поговорим про закон Литтла (Little’s Law). И совсем немножко про математику. Формула простая: L = λ × W L — среднее количество элементов в системе (например запросов в обработке или элементов в очереди) λ — средняя скорость поступления элементов (запросов в секунду) W — среднее время, которое элемент проводит в системе Формула — проще некуда, но очень полезная. Сколько запросов обрабатывается одновременно? Дано: λ = 100 req/s, W = 200ms L = 100 × 0.2 = 20 запросов в системе одновременно ...

Ну что, закончили с понедельничной утренней рутиной? Вышла моя статья на Хабре "Когда дашборды лгут. Гайд по перцентилям, очередям и e2e-бюджету" (продолжение постов на канале тык и тык ) 5-7 минут на чтение, картинки, формулы и чуть чуть про способы бюджетирования e2e задержек Хорошего дня и приятного чтения)

Ребят, а вы знаете свою среднюю задержку по сервису? Если да — вы уже делаете то, чего большинство не делает. Если вы знаете задержку для каждого эндпоинта, участвующего в CUJ — это ещё круче. Правда, тут легко наступить на грабли. Начнёте мониторить каждый эндпоинт отдельно — можете случайно положить свой мониторинг от кардинальности. Или получить красивый счёт от облачного провайдера. Даже не знаю что лучше. Но главная проблема не в этом. Без p95/p99 у вас получается как в старом анекдоте — ди...

Вчера я упомянул протокол релиза. А в этом посте писал про чеклист релиза. В чём разница? Чеклист — инструмент проверки. Он помогает убедиться, что ничего не забыли и не пропустили. Протокол — инструмент управления. Он показывает, в какой последовательности выполняется, кто за что отвечает и по каким признакам, каждый шаг по отдеьности и релиз в целом, считается успешным. В аттаче — базовый шаблон протокола релиза. #GitFlowRelease

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

Серия: Gitflow & Release discipline. Пост 5/10 — трустори. Все имена и события вымышлены. Любые совпадения случайны. Далее — рассказ от имени моего воображаемого друга, который, конечно же, не я. Однажды я уронил прод одной госструктуры. Минут на пятнадцать. Но наглухо. Не то чтобы я был злоумышленником — просто мы работали по принципу «мерж, молись, деплой». Иногда связь с высшими силами пропадала. Или они были заняты. И тогда деплой, мягко говоря, получался… не очень. Мы старались, правда стар...