Подзаголовок книги «Сотрудничество в DevOps-культуре» звучит как «Лучшее программное обеспечение через лучшие взаимоотношения». Именно вокруг взаимоотношений и встроены основные идеи книги авторов Jennifer Davis и Ryn Daniels (соавторов книги Философия DevOps).
Книга поделена на две большие части: основы сотрудничества и практики сотрудничества. В первой части дается необходимый для понимания второй части фундамент знаний и понятий.
Основы сотрудничества
Раздел поделен на четыре достаточно больших главы: эмпатия, доверие, психологическая безопасность и коммуникация.
Эмпатия
Эмпатия рассматривается как навык, помогающий понять чувства других людей и улучшающий наши эмоциональные связи с другими людьми.
В книге представлены следующие практики развития эмпатии.
essay in hindi for kids here source link essay about rose in hindi buy university essays online can i take cialis with ranexa https://themauimiracle.org/bonus/generic-cialis-india/64/ example of formal business report is there life after death essay management consulting essay https://oaksofwellington.com/levitra-oakville/ cheap argumentative essay editor sites gb how does cialis cause hearing loss https://robsonranchviews.com/article/euthanasia-arguments-against-essay/4/ source link how to change font size on my ipad levitra vs viagra price follow ptlls assignments legislation https://vivianschilling.com/film/economic-naturalist-paper/61/ https://revivemedicalny.com/citrate/lexapro-teenagers/8/ mla paper format research paper https://ssmf.sewanee.edu/experience/photography-dissertations/250/ enter site foro como comprar viagra the most important day by helen keller essay source url thesis written in apa style what med to stay away fom when taking viagra source site best thesis blog designs Активное слушание. Не только слушать, но и слышать и понимать, что говорит другой человек.
Вопросы себе и другим с целью лучшего понимания. Например:
- Какой контекст я мог пропустить при принятии решения?
- Какие когнитивные искажения могли повлиять на моё решение?
- Что привело к тому, что ты выбрал X, а не Y
- Можешь рассказать чуть подробнее о том, как ты к этому пришел?
Ценить индивидуальные различия людей. Это касается как культурных отличий, так и отличии в знаниях и опыте.
Доверие
Вера в то, что те, от кого мы зависим, оправдают возлагаемые на них ожидания.
Вначале упоминается термин «Быстрое доверие» (автор термина — Dr. Debra Meyerson). Его суть в доверии по-умолчанию и адаптация уровня доверия на основе реакции на доверительные отношения в команде.
Сразу за быстрым доверием следует принцип «Доверяй, но проверяй», особенно актуальный по отношению к новым членам команды и тут же задается философский вопрос: «Как можно начать кому-то доверять, если ему не дали возможности заработать доверие?». Ответ на него не дается, но в практической части книги эта тема раскрывается чуть подробнее.
В следующей части, касающейся «самораскрытия» тема философии продолжается и несмотря на то, что хорошо бы знать побольше о коллегах, авторы нас предостерегают: «Слабое раскрытие себя может привести к ощущению неопределенности со стороны коллег, но слишком сильное может повредить доверию». Сколько нужно — авторы не уточняют и оставляют на подумать читателю.
Последняя тема главы — «восприятие справедливости». Мне она кажется достаточно важной. Это об установлении разумного уровня прозрачности в области распределения формализованных ролей и зарплаты.
Другой важный аспект при восприятии справедливости — это общие риски. Очень похоже на асимметричность рисков у Талеба. Суть в том, что если две команды делят какой-то общий ресурс или работу и только одна команда пострадает в случае негативной ситуации, то уровень недоверия этой команды к команде с меньшим уровнем риска будет выше. Факт 🙂
Психологическая безопасность
Психологическая безопасность (термин введен профессором Гарвардской школы бизнеса Amy Edmondson) — это «убеждение, что никто не будет наказан или унижен за высказывание идей, вопросов, опасений или ошибок».
В 2015-м году Google провел внутреннее исследование 180-и команд, пытаясь выяснить, что делает команды более или менее эффективными. Исследование показало, что психологическая безопасность — одна из пяти базовых основ высокоэффективных команд. При этом — самая важная.
В начале главы говорится о важности воспитания культуры, в которой люди задают вопросы. Подарок сотрудникам от лидера — спросить их о критичных вещах, даже если вы знаете, как нужно что-то делать.
Немаловажный фактор, влияющий на психологическую безопасность — найти общие интересы за пределами работы. Спорт, музыка, хобби, люди узнают друг друга лучше и начинают чувствовать себя комфортнее в обществе друг друга.
А в завершении авторы акцентируют внимание на важности обратной связи. Запрашивать мнение о себе, чтобы люди понимали, что их мнение ценится. Это воспитывает сотрудничество (в противовес соперничеству).
Коммуникация
Коммуникация позволяет людям построить общие понимание и цели, что является противоположностью работе в конкурентной среде.
Для плодотворной коммуникации важно стимулировать совместное обсуждение рабочих вопросов и публично благодарить тех, кто пришел с проблемной ситуацией. При этом авторы предостерегают, что при совместном обсуждение важно избавляться от культуры, в которой люди постоянно перебивают друг друга, так как это ведет в большей степени к конкурентному общению, чем к сотрудничеству. В заключении дается рекомендация лидерам: «Лидер может высказать свое мнение последним», ведь люди могут чувствовать себя некомфортно, высказывая несогласие с кем-то, имеющим большее влияние, чем они сами.
На этом заканчивается первая часть книги «Сотрудничество в DevOps-культуре» и начинается
Сотрудничество на практике
Эта часть книги поделена на семь основных разделов, каждый последующий в большей или меньшей степени опирается на идеи предыдущего.
Product and Engineering Collaboration
Долго думал, как перевести этот заголовок, решил оставить как есть, уж больно он емкий и отражает суть.
Каждая организация определяет собственные структуры команд и процессы, требующие различных стратегий сотрудничества. Будучи явно описанными, такие процессы проще обсуждать, доносить их до новых членов команд и, при необходимости, менять.
Авторы рекомендуют использование общих рабочих инструментов и приводят пример, когда планирование продукта ведется в Jira, а задачи разработки ведутся в GitLab.
Так же авторы рекомендуют искать пути коммуникации между группами, например участие представителей от инженеров и продуктовиков на статусных встречах друг друга.
В заключении напутствие: «убедитесь, что выполняющие работу люди, включены в определение сроков».
Взаимодействие вокруг требований
В этой главе, пожалуй, стоит выделить наборы вопросов разработке и поддержке при планировании разработки продукта или фичи.
Вопросы разработке
- Над чем еще работают инженеры и какие еще проекты или дедлайны могут повлиять на их производительность и доступность?
- Требует ли новый продукт или фича существенных изменений в существующем коде или инфраструктуре?
- Обладает ли команда необходимым опытом для разработки и поддержки новой фичи или следует подумать об обучении или найме?
- Какова общая стабильность текущих продуктов?
(Ответ на этот вопрос позволит учесть влияние устранения прод-дефектов на производительность и доступность).
Вопросы поддержке
- Достаточно ли у людей опыта для поддержки новой фичи или продукта? Сможет ли поддержка отвечать на вопросы пользователей и помогать клиентам разрешать проблемы?
- Каков текущий объем поддержки?
Сотрудничество в архитектуре и планировании
Основную мысль этого раздела тоже можно вынести из представленных в ней вопросов. Суть в том, чтобы ответы на эти вопросы дали толчок в сторону развития процессов сотрудничества, учета интересов всех вовлеченных в разработку и эксплуатацию заинтересованных лиц.
- Что значит «сделано»? Признак того, что команда закончила одну работу и может перейти к другой.
- Что важнее — соблюсти сроки и пожертвовать частью скоупа или выполнить всё, что планировалось, но с возможным опозданием?
- Кто принимает решения при возникновения проблем?
- Будут ли стейкхолдеры, работавшие над изначальной концепцией и идеей заниматься развитием продукта, или эта ответственность перейдет другим людям?
- Кому переходит владение продуктом после его выпуска? Кто будет нести ответственность за поддержку и эксплуатацию?
Сотрудничество при планировании
Основные мысли сосредоточены вокруг архитектурного и эксплуатационного ревью:
- Ревью архитектуры требуется при значительных изменениях в архитектуре или базовой инфраструктуре продуктов. То, что определяется как архитектурно-значимые требования. Пример от John Allspaw.
- Ревью эксплуатации проводятся во время всего процесса планирования для выявления на ранних этапах потенциальных проблем управления продуктами в промышленной среде и их мониторинга.
- Подготавливайте шаблоны для обсуждений. Например, если команда разработки каждый раз задает одни и те же вопросы по фиче, сделайте эти вопросы частью шаблона при обсуждении фичи продуктовой группой. Одна из целей такого подхода — снизить количество неожиданностей.
Сотрудничество при разработке
Основное внимание уделяется контролю версий и подходу Inner Sourcing (применение подходов разработки Open Source во внутренней разработке). Так же авторы упоминают подход Test Driven Development, в частности то, что совместная работа над определением критериев приемки во время фазы исследования ведет к появлению первых тестов и дальнейшему развитию практики TDD.
Завершает главу практика Непрерывной Интеграции (CI) и что важно, внимание акцентируется на том, что изменения должны непрерывно (или настолько часто, насколько это разумно) сливаться в основную ветку. Для этого авторы рекомендуют следовать нескольким принципам:
- Единая CI-платформа. Важно максимально снизить сложность использования инструментов, учитывая, что создаваемые нами сервисы сложны сами по себе (сервис может состоять из нескольких микросервисов).
- Использование Инфраструктуры как Код. Снижает различия между локальными, тестовыми и боевыми серверами. Конфигурация инфраструктуры должна быть покрыта автотестами.
- Автоматизация ручных тестов. Не полагайтесь на память людей в запуске тестов, когда это можно доверить компьютерам.
- Ивестируйте в рефакторинг и зачистку тестов. Большая часть тестов — тот же код и отношение к качеству этого кода должно быть соответствующее.
Сотрудничество при выходе релиза
Цель совместного развертывания — избавить людей от неожиданностей при изменениях. Сюрпризы подрывают доверие и снижают эмпатию. Неплохо в этом помогают практики ChatOps.
Отдельно даются рекомендации по реагированию на инциденты. Devops — это создание устойчивых методов работы и ключевой частью этого является то, что называется work-life balance, то есть баланс между работой и личной жизнью.
Например, наличие достаточного количества людей для быстрого реагирование на инциденты, их ротация, наличие смен (дневных/ночных). Дело в том, что даже краткосрочная нехватка сна ведет к падению концентрации внимания, снижению качеств работы, раздражительности и беспокойству. Кроме того, при длительной нехватке сна повышается кровяное давление и повышается риск инфаркта.
Здоровье в целом и выгорание в частности, — важнейший фактор в определении уровня здоровья всей организации. Приоритизация краткосрочных финансовых или материальных выгод над здоровьем людей неминуемо приведет к серьезным потерям в долгосрочной перспективе.
С этой точки зрения важной становится такая метрика, как «как часто конкретные люди требуются для реакции на конкретные инциденты». Метрика сигнализирует о том, что в системе существует единая точка отказа и необходимо инвестировать время в передачу требуемых для реагирования на подобный тип инцидентов знаний другим членам команды.
В завершении важная мысль о взаимной поддержки. Под тяжестью возложенной отвественности за критичный сервис без поддержки окружающих люди могут испытывать сильный стресс. В культуре DevOps очень важно, чтобы люди помогали друг другу, в частности, вместо осуждения за неверные действия, спокойно спрашивали «Чем я могу тебе помочь?».
Совместные ретроспективы и организационное обучение
Объединил эти две главы. На мой взгляд, они сильно связаны друг с другом.
В случае инцидентов, первое, что нужно сделать — это воссоздать все действия и разместить их на временной шкале. Затем происходит обзор этих действий. При обзоре важно уделять внимание не только тому, что произошло, но и почему. С культурной точки зрения в обзоре инцидента не должно быть места поиску виноватых: наблюдаем, что случилось, анализируем, применяем корректирующие действия, чтобы избежать подобного в будущем.
Предполагая, что люди не совершают ошибок преднамеренно, в ходе такого обзора мы пытаемся понять, почему они предприняли те или иные действия, считая их безопасными.
Если же во время инцидента не произошло ничего неожиданного, то это не инцидент, а плановое обслуживание. Неожиданности — вот то, на основе чего мы можем научиться новому.
Далее следует глава об организационном обучении. Без него мы будем сталкиваться с одними и теми же трудностями снова и снова. Одна из целей чередования дежурств при поддержке в том, чтобы облегчить организационное обучение.
Падение или неожиданное поведение систем открывает возможности к повышению их надежности, улучшению инструментов или документации, а главное — возможности поделиться новыми знаниями с другими людьми.
Знания не должны накапливаться в границах одной команды или, хуже того — одной головы. Требуются совместные усилия, чтобы сделать их достоянием всей организации, в чем могут помочь такие артефакты, как:
- Упоминаемая ранее временная шкала с описанием результатов обсуждения инцидента
- Конфигурации уведомлений. По-возможности они должны храниться в системе контроля версий. Это позволяет понять по комментарию к коммиту причину добавления нового уведомления.
- Инженерные решения, архитектурные и другие документы. В идеале они должны включать рассмотренные варианты, конспекты их обсуждения и любую другую информацию, позволяющую людям, обращающимся к этим материалам понять, почему были приняты те или иные решения.
Завершение
В завершении авторы еще раз напоминают, что сотрудничество как на индивидуальном, так и на командном уровне — один из ключевых элементов DevOps-культуры.
Вне зависимости от специфики вашей организации, конечная цель — это не определенное число поставок в день, использование системы контроля версий или выполнение каких-то действий просто потому, что другие компании делают это. Конечная цель — создание и развитие успешной организации, решающей проблемы ваших клиентов.
Покупка инструмента, претендующего на звание «DevOps Solution» — это не DevOps. DevOps — это постоянная и планомерная работа по созданию и поддержанию культуры, раскрывающей истинную эффективность DevOps.
