1. Ускорение. Accelerate: Building and Scaling High Performing Technology Organizations.

А вот и заметки по первой главе. Она про то, что именно компаниям необходимо ускорять, чтобы оставаться успешными на рынке, а так же сравнивает модели зрелости(maturity models) с моделями возможностей(capability models).

Заметки по главе: http://telegra.ph/1-Uskorenie-Accelerate-Building-and-Scaling-High-Performing-Technology-Organizations-Nicole-Forsgren-PhD-Jez-Humble-Gene-Kim-04-23

Содержание: http://telegra.ph/Accelerate-Building-and-Scaling-High-Performing-Technology-Organizations-Nicole-Forsgren-PhD-Jez-Humble-Gene-Kim-04-19

Контейнеры в Firefox

Не так давно Mozilla зарелизила расширение, которое выносит Facebook в “контейнер”. Это значит что фейсбук находится в отдельном пространстве и все что он там делает остается в этом пространстве. Делалось это для того, чтобы фейсбук не смог отслеживать, через встраемые элементы на сайтах, ваши блуждания по интернету.

Сегодня я наткнулся то, что сами контейнеры это полноценная фича Firefox, которая аж с октября доступна в виде расширения. Расширение позволяет вам создавать свои собственные контейнеры(просто нажав +). По дефолту доступны: Personal, Work, Banking, Shopping. У каждого такого контейнера свое собственное пространство(куки, сторадж и т.д.), друг о друге они ничего не знают. Это позволяет вам одном пространстве открыть сайт и войти под, например, рабочими кредами, а в соседнем контейнере с другими. По цвету вкладки можно понять, в каком контейнере открыт сайт.

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

Респект мозилловцам 🙏
Не зря я им каждый месяц бабла засылаю)

https://blog.mozilla.org/tanvi/2017/10/03/update-firefox-containers/

Ого, Карина Истомина обзавелась плейлистом на Apple Music!

https://itunes.apple.com/ru/playlist/karina-istomina-current-obsessions/pl.7adcd3934333404ca11a1b25a578fc12?l=en

28/29 мая в Сколково, в рамках РИТ++, я буду на конференции Whale Rider с докладом “Как начать DevOps-трансформацию”.

Приходите 🙂

https://ritfest.ru/moscow/2018

Смотрел сегодня доклад Curtis Yanko - The Difference Between DevOps and Everything Else с последнего DevOpsDays Denver

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

Лично меня больше всего порадовал ответ вопрос из аудитории.
- Мы вкладываем в людей, они вырастают и уходят. Что делать?
- ... What happens if we train our people and they leave? An alternative is what if we don’t train our people and they stay? If you create a place where they want to work, they won’t leave. People leave because they don’t want to be there. So you have to create an environment, where they want to be.

https://youtu.be/NI69ts4wNuw

Экономьте на спичках!

Оказывается, когда вы вводите данные карты для оплаты в интернете, поле card holder можно вообще не заполнять. Никто и никак не может его верифицировать и спрашивают его чисто для галочки.

Расплачивался вчера картой, а в поле вставил пробел, чтобы проверку на пустое поле пройти. Вуаля, оплата прошла.

Минус две секунды при оплате картой!!! 😂

РИТ++

В начале этой недели прошел РИТ++, для меня там произошло два ключевых момента.

Во-первых, я первый раз выступал с докладом на конференции такого масштаба. Доклад назывался “Как начать DevOps-трансформацию”. Загрузил презентацию на GDrive, на SlideShare пока какие-то проблемы :(

Во-вторых, дебютировал в качестве нового ведущего DevOps Deflope! Беседовал с Leon Fayer вице-президентом OmniTI о необходимости мониторинга бизнес-показателей и коммуникации между техническими и бизнесовыми отделами. Опубликовать планирую уже на следующей неделе и уже веду переговоры с другими участниками для будущих эпизодов, так что следите за новостями 🔥

Помимо двух дебютов, посмотрел полтора доклада 😂 Все остальное время общался с участниками, чего и вам советую делать, в кулуарах всегда самое интересное происходит)

DevOps Deflope: https://xn--r1a.website/devops_deflope

Презентация: https://drive.google.com/open?id=14qdao-VwajOKlMSZ0Z9068VWOE3BUNs6

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

Измерение эффективности. 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