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

Все примеры ниже — специфичные и подойдут не каждому, они построены в основном на продуктах Mindbox «Рассылки» и «Программа лояльности». Продукты помогают нашим клиентам запускать автоматические рассылки по триггерам (действиям или событиям), чтобы не спамить пользователей, выдавать промокоды и выстраивать бонусные системы. Если поймете, что чек-лист полезен, можете заменить примеры на свои и использовать.

Ниже подробнее о том, как сделать качественный грум:

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

Иногда команда разработки сталкивается с задачей, в которой у неё мало экспертного опыта, и через пробы и ошибки она находит неочевидное решение. Так произошло и с нами, когда понадобилось перенести сбор метрик из Infux в Prometheus. Их итоговая размерность оказалась 1,5 миллиона, и мы решили ее уменьшать. Инфраструктуру по сбору метрик (Prometheus, k8s, деплой через Helm) создавали DevOps-инженеры из другой команды, у которых не было ресурсов для нашей задачи. Поэтому мы заручились их советами, изучили документацию и решили снижать размерность метрик силами разработки.

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

• как в два шага уменьшить размерность метрик с помощью двух ServiceMonitor,
• какой есть эталонный способ уменьшить размерность метрик без «костылей»,
• почему не стоит тратить время на снижение размерности метрик с помощью Pushgateway.

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

Mindbox 15 лет развивает B2B-продукт и вырос с 3 до 70 человек в разработке. Мы тестировали разные подходы к масштабированию и готовы поделиться опытом, чтобы вам не пришлось наступать на те же грабли. Ниже расскажу, как попробовали полную автономию команд и централизацию, роняли надежность, демотивировали команды, как в результате с этим справились и выработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:

Об IaC под Windows пишут мало, потому что DevOps/SRE ассоциируется в основном c Linux и Kubernetes. Мы решили исправить эту ситуацию и сравнить инструменты, которыми можно управлять IaC на базе Windows. Статья будет полезна разработчикам, которые работают с Windows-инфраструктурой и выбирают способы управления, и тем, кто уже внедрил Powershell DSC или Ansible, но сомневается в своем решении. Ниже поделимся опытом и расскажем:

• как устроен Powershell DSC и чем он отличается от Ansible при управлении инфраструктурой на Windows;
• почему мы перешли на Ansible;
• с какими проблемами столкнулись и как их решали;
• как соотносятся ожидания и реальность после перехода на Ansible;
• кому стоит выбрать Powershell DSC, а кому — Ansible.