А вот и обещанный выпуск!

Измерение эффективности. Measuring performance.

Заметка по второй главе книги Accelerate: Building and Scaling High Performing Technology Organizations. Какие ошибки мы совершаем при измерении эффективности, какие измерения нужны для оценки эффективности поставки ПО и как эта самая эффективность поставки ПО влияет на компанию.

В этот раз применил подход Progressive Summurization, так что в заметке ты найдешь и оглавление, и краткое содержание, а все ключевые мысли выделены жирным шрифтом.

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


telegra.ph/2-Izmerenie-ehffektivnosti-Measuring-Performance-Accelerate-Building-and-Scaling-High-Performing-Technology-Organizations-07-22

Почта как база знаний

Игорь Курочкин(мой коллега в Express42) поделился сегодня со мной наикрутейшим способом использования почты как базы знаний.

Идея Игоря заключается в складывании всех рассылок в папочку на почте, по которой мы можем искать. Читать мы их все равно не успеваем, а так они накапливаются и получается наша собственная база знаний под наши собственные нужды.
Как пример, получали мы письма про инфраструктуру и devops, складывали в папочку. Через какое-то время захотели узнать что-то про Kubernetes, ввели его в поиск и получили наисвежайшие статьи по теме и все что вокруг него сейчас вообще происходит.

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

Ops должны уметь в Dev, а Dev должны уметь в Ops.

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

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

В общем, вывод: ops давно включили программирование в свой джентльменский набор, пора бы уже и dev подтянуться и научиться эксплуатации.

На эту тему можно послушать второй выпуск o11ycast: https://www.heavybit.com/category/library/podcasts/o11ycast/feed/

Почему UX Designer в роли Product Manager — здравая идея

Evil Martians рассказали, что когда один из их проектов начал быстро расти и бизнес уже больше не мог общаться с разработчиками в необходимом объеме, вместо того, чтобы нанять Product Manager, они отдали эту роль UX-дизайнеру! 🔥

С одной стороны, звучит, конечно, дико. Где дизайн, а где менеджмент. Но, на самом то деле, идея довольно здравая, и вот почему.

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

Это тот образ мышления, который как раз и необходим хорошему Product Manager'у. Он должен думать о пользователе, понимать что ему нравится, понимать его нужды. UX-дизайнеры занимаются этим каждый день. Так что ставить задачи, приоретизировать их и выдвигать гипотезы он будет именно исходя из мыслей о пользователях, что нам как раз и нужно)

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

Подробнее о том, что делали Evil Martians с растущим проектом в их блоге: https://evilmartians.com/chronicles/lean-by-design-5-wins-for-one-product

Нет воронки — нет продаж!

Сегодня в очередной раз слышал о продажах через сарафанное радио. И… Нет, это не продажи 😉

Что вообще такое продажи. Продать что-то это взять продукт, найти потребителя, обменять продукт на денежку.

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

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

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

Если процесс не описан и не повторяем, то компания не умеет это делать.

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

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

В случае, если какая-то деятельность в компании не описана и не делается постоянно, то, либо компания вовсе не умеет ее делать, либо делает очень-очень хреново.

Например. Если у вас нет инструкции, как и когда писать документацию, значит компания не умеет писать документацию. Люди тупо не будут понимать как это делать правильно и как оценить результат. В итоге, документацией либо не пользуются вообще, либо она сильно отстает от реальности, либо так организована, что пользоваться ей сложно. В общем, все печально 🙂

И похоже, что так со всем. Нет описания процесса и постоянных повторений — совсем не умеем, либо делаем хреново.

Анонс статей о security и просьба покидать ссылочки

Недавно сел писать статью о месте security в DevOps. В итоге, решил разделить на две: про процессы и про инструменты, которые можно встроить в pipeline.

Первая статья уже на подходе и увидет свет в ближайшее время)

Хочется сделать эти статьи как можно более содержательными, поэтому если вам на эту тему известны книжки, доклады, статьи или примеры, скиньте пожалуйста в личку @aladmit

Как измерить качество архитектуры приложения

В книге Clean Architecture мне попалась интересная метричка. Там говориться, что основная задача архитектуры приложения это легкое внесение изменений. Т.е. чем проще нам добавить/исправить фичу, тем круче.

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

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

В общем, пробуйте метричку, рассказывайте как оно)

Мерить качество архитектуры за промежуток времени

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

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

Конспект доклада "Страх и ненависть DevSecOps Шабалин Юрий, Swordfish Security"

Недавно я просил покидать ссылочки на доклады, статьи, книги про security. Первое, что мне прислали, это запись доклаша Шабалина Юрия с DevOps Moscow.

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

Конспект доклада: http://aladmit.com/summary/2018/11/18/summary-fear-and-hate-devsecops.html

Митинги — отстой

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

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

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

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

Был сегодня на митапе DevOps Moscow, законспектировал доклад о Concource CI. http://aladmit.com/summary/2018/11/21/summary-devops-moscow-concource.html

Оказывается, записи докладов с DevOps Moscow уже выложили!

Concourse. CI с кубиками и на чистом YAML // Максим Залысин, Devino Telecom: https://youtu.be/4PRWZBgUDxU

Hastic. Поиск паттернов и детекция аномалий в CI/CD // Алексей Великий, CorpGlory Inc: https://youtu.be/3RH6ydyB5Hg

Hangops и Канбан

На прошлой неделе Олег Сорока рассказывал в hangops про принятие решений в IT. Обсуждали, что нельзя трекать меря на разработку, нужен беклог или нет, с какими CTO мы чаще всего встречаемся и какими они должны быть на самом деле.

Олег так же рекомендовал посмотреть доклад Алексея Пименова. Честно говоря, этот доклад полностью перевернул мое представление о том, а что же такое Kanban. Я думал, что это просто досочка с задачами, но, как оказалось, там все куда интереснее!

Конспект доклада про канбан с ссылками на литературу, запись и слайды: http://aladmit.com/summary/2018/11/25/kanban.html

Запись доклада: https://www.youtube.com/watch?v=lrDLbp0XeFA

Запись встречи hangops с Олегом Сорокой: https://www.youtube.com/watch?v=Oh5tAvq-ysQ

It Doesn't Have to Be Crazy at Work

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

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

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

https://www.goodreads.com/book/show/38900866-it-doesn-t-have-to-be-crazy-at-work

Добавляйтесь в goodreads, кстати, будем книжечками и отзывами обмениваться. https://www.goodreads.com/user/show/59573971-andrey-alexandrov

DevOps Moscow New Year Party

Открылась регистрация на новогодний DevOps Moscow митап, выступаю там с мини-докладом “Почему Trunk Based Development — лучшая модель ветвления”.

Приходите :) Пообщамся, обсудим TBD, пиво попьем 😉

https://devops-moscow.timepad.ru/event/872315/

ТЖ сделал клевый калькулятор, который подскажет как вам выгоднее покупать хату в Москве. Через ипотеку или собственные накопления.

https://journal.tinkoff.ru/rent-or-buy/

Трансляция DevOps Moscow

https://www.youtube.com/watch?v=Iq0Nm_cc0wo

19:05 — 19:20 «Зачем нужно сообщество, или каково это быть оргом?», Александр Титов (Express 42)

19:20 — 19:35 «Rsyslog — как я перестал бояться и полюбил обработку логов», Сергей Печенко (Райффайзенбанк)

19:35 — 19:50 «Что нужно, чтобы DevOps работал в enterprise компаниях», Никита Борзых (Express 42)

20:05 — 20:20 «Решение выдуманных проблем реальными способами», Александр Усков (МРОО АРСИБ)

20:20 — 20:35 «В мире, где существуют DevOps-инженеры — мы вынуждены создавать процессы», Максим Фоминов (Леруа Мерлен)

20:35 — 20:50 «Почему Trunk Based Development — лучшая модель ветвления», Андрей Александров (Express 42)