пятница, 17 июля 2020 г.

4 колонны DevOps


Книга Effective DevOps вводит концепцию четырех колонн, на которых зиждется эффективный DevOps.  

 

“Here are the four pillars of effective devops:

• Collaboration

• Affinity

• Tools

• Scaling

 


Поговорим о каждой колонне.

 

Первой берём колонну под названием коллаборация. Она же сотрудничество. Первым делом обратимся к Wikipedia.

“Коллаборация (сотрудничество) — процесс совместной деятельности в какой-либо сфере двух и более людей или организаций для достижения общих целей, при которой происходит обмен знаниями, обучение и достижение согласия (консенсуса).”

Вернёмся к книге Effective DevOps. Много страниц посвящено теме сотрудничества, аспектам, особенностям, сложностям. А так как разговор идёт о девопсе, то есть и примеры:

* асинхронный ревью кода

* документация

* апдейт тикетов

* еженедельные демо

* регулярная актуализация статуса

* парная работа

 

Вторая колонна эффективного DevOpsAffinity. Тяжело переводимое на русский язык понятие. Самый близкий перевод: близость, эмоциональное родство. Книга Effective DevOps определяет Affinity как степень силы взаимоотношений между индивидуальностями, командами, подразделениями и, даже компаниями. А в общем то это все также, как и сотрудничество, про культуру. Кого и как мы нанимаем в компанию, какое поведение поощряется, как оценивается вклад отдельного человека, команды в результат.

 

В основе взаимоотношений должны быть доверие и открытость. В конце дня каждый из нас, каждая команда будем успешны только, если компания будет успешна. Работать вместе, а не вопреки друг другу. Это не всегда просто!

 

Начинайте с себя, со своей команды! Все получится!

 

Третья колона в основании эффективного DevOps – инструменты. Чтобы не было как в том самом месте, когда есть только молоток, все проблемы кажутся гвоздями. Раньше конечно было проще, «тулов» было меньше, выбирать было особо не из чего. Сейчас с этим с одной стороны все веселее, с другой сложнее, т.к. выбор тула больше похож на вкусовщину. «На вкус и цвет все фломастеры разные». И чем больше компания, тем тяжелее будет сделать всех «счастливыми». Не говоря уже о том, что даже очень хороший тул при неправильном использовании будет приносить много боли и мало пользы. Хорошая цитата из книги «Effecctive DevOps»:

While tooling can be interesting, and the right automation can free up people’s time and energy to work on more complex problems, for tools to be effective they need to be chosen for reasons other than being interesting or new.

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

 

Последняя колонна DevOps – масштабирование (scaling). И речь не только про инфраструктурную составляющую. Масштабирование всего и вся, и кроме этого, культуры.

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

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

 

 

Всем продуктивной пятницы и отличных выходных!

 

P.S.:

Книгу можно найти вот тут: https://www.amazon.com/Effective-DevOps-Building-Collaboration-Affinity-ebook-dp-B01GGQKXOE/dp/B01GGQKXOE/ref=mt_other?_encoding=UTF8&me=&qid=

Картинки:

https://www.slideshare.net/aboullaitemohammed/effective-devops

https://smartdraw.com

https://quotefancy.com/quote/1206975/Nikki-Giovanni-Love-is-the-offspring-of-spiritual-affinity-and-unless-that-affinity-is

https://clickup.com/blog/agile-tools/

https://devops.com/five-donts-when-scaling-devops/

 

Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru

 

 

 

 

 

воскресенье, 5 июля 2020 г.

Просто разные цитаты )

Всем доброго дня! Цитируем интересные книги: 
The bus factor is a number describing how many people a team or project would have to lose in order to lose its institutional knowledge or ability to progress (or, how many people could get hit by a bus before the project/team would be unsalvagable). Lower numbers here are worse, because there is less margin for error or extenuating circumstances.  
Если коротко на русском, о том, что если что-то знает-умеет один человек, это очень опасно 😱 управляйте с умом🤗
Книга на Azaon: Клик

«Более прогрессивную модель, на которую в то время мало кто обратил внимание, выдвинула социальный работник из Массачусетса Мэри Паркер Фоллет. В статье «Отдавая приказы» (1926) Фоллет утверждала, что совместное принятие решений и сотрудничество между менеджерами и сотрудниками дает гораздо более эффективный результат. Там, где Тейлор и Форд видели иерархию, Фоллет увидела сетевую организацию.»
 
Ох как это напоминает то, что господин Курпатов говорит о семейных взаимоотношения 🤓
Книга на Ozon: Клик



Testing at the right time leads to better code.

In many projects, testing is treated as a distinct phase carried out by specialists.

However, high-quality software is only possible if testing becomes the

of everybody involved in delivering software and is practiced right from

the beginning of the project and throughout its life. Testing is primarily concerned

with establishing feedback loops that drive development, design, and release.

Any plan that defers testing to the end of the project is broken because it removes

the feedback loop that generates higher quality, higher productivity, and, most

importantly of all, any measure of how complete the project is. 


Если коротко - тестирование - это ответственность каждого, и тоже должно быть непрерывным. 

Книга на Amazon: Клик




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

Неспособность соединить идею с неудовлетворенной потребностью пользователя.

Неспособность расставить приоритеты в море идей и целей.

Неспособность создать прототип или понятную для других визуализацию.

Неспособность привлечь реальных пользователей к разработке концепции.” 


А вы думаете как 👩‍🎨 дизайнер?

Книга на ЛитРес: Клик


Всем хорошего воскресенья!


Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru