Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

340
Часть V. Масштабирование и избегают обсуждений. Подобно Микман, вы также можете найти время для выполнения эффективных преобразований в организации, особенно если со- средоточитесь на желаемых результатах и изменениях, а не на голой термино- логии. Изменения выполняются поэтапно, начиная с агентов индивидуальных изменений, массовых усилий и нисходящей поддержки и завершая успешными стратегиями масштабирования.
Критически важными для адаптации изменений являются сосредоточение на желаемых результатах и осведомленность о чувствительности к языку.
Рассказывайте интересные истории, которые пробуждают интерес и вдох- новляют на изменения, без использования слова devops. Важно осознать текущий ландшафт в Target и понять, как отразились на людях приложенные усилия.
Формирование корпоративной близости
Руководство компании Target поощряет формирование близости на предпри- ятии путем поддержки существующей культуры организационного обучения.
Благодаря «внедрению в массы» идеи организационного обучения и поощрению всех сотрудников к продвижению «на ступеньку выше» обеспечивается масшта- бирование по всей организации. При этом делается упор на следующих четырех элементах:

экспериментирование;

тестирование;

неудача;

достижение цели.
Благодаря большому опыту работы с разными командами Росс Клэнтон осознал и прочувствовал проблемы каждой команды. Также он столкнулся с разными проблемами на уровне организации, такими как смещенные символы, передача работы и подотчетность.
Путешествие Клэнтона в мир devops, внедряемого в компании Target, началось с поиска руководства, которое помогло бы справиться с подобными проблемами.
Многие рекомендуют книгу Phoenix Project: A Novel About IT, DevOps, and Helping
Your Business win, написанную Кевином Берром (Kevin Behr), Джин Ким (Gene
Kim) и Джорджом Спэффордом (George Spafford). После прочтения этой книги
Клэнтон приобрел дополнительные экземпляры и раздал их другим членам своей команды. Он также провел ролевую игру на основе различных сценариев, описан- ных в книге.

Глава 14. Масштабирование: критические точки
341
Важно отметить, что процесс обучения и внедрения изменений внутри органи- зации зачастую вдохновляется внешними факторами. Если вы черпаете идеи и стратегии только внутри организации, то в конечном итоге рискуете остаться со старыми практиками, привычками и паттернами. А если вы попытаетесь внедрить серьезные изменения в организации, то вряд ли старые методы смогут адекватно использоваться.
Не становитесь жертвой менталитета карго-культа, внедряя изменения только по той причине, что это делают другие. Но и не стоит недооценивать опыт и знания других людей.
Он объединился с другими технологическими лидерами в организации, вклю- чая директора Хизер Микман и технического руководителя Джеффа Эйнхорна
(Jeff Einhorn), для поиска партнеров внутри организации, которые помогли бы внедрить необходимые общие изменения. Это имело решающее значение для преодоления разрыва между разными бункерами и сглаживания противоречий между организациями, имеющими разные приоритеты и сталкивающимися с различными вызовами. Вместе они обращались к другим экспертам в этой об- ласти, включая руководство Netflix, Google и Facebook, чтобы разобраться с со- ответствующими паттернами, которые можно адаптировать для использования в своей организации.
На саммите DevOps Enterprise Summit, прошедшем в 2014 году, Росс Клэнтон описал свое devops-путешествие в компании Target как объединение людей, ра- ботающих в разных отделах организации. После достижения успеха в небольших командах активные участники движения devops начали рассылать сообщения более широкой аудитории компании Target различными способами:

В феврале 2014 года была проведена первая внутренняя мини-конференция devops. На этой конференции выступали приглашенные докладчики Роб
Каммингс (Rob Cummings) из компании Nordstrom и Майкл Даки (Michael
Ducy) из компании Chef.

Участники devops-движения регулярно проводят встречи, на которые при- глашают независимых ораторов, в том числе Джеффа Сассну (Jeff Sussna),
Флетчера Никола (Fletcher Nichol), Иэна Мэлпэсса (Ian Malpass), Шона
О’Нэйла (Sean O’Neil) и Джеза Хамбла (Humble). Благодаря этим встречам удалось пополнить ряды сторонников devops-движения. Так, если на пер- вой встрече было 160 посетителей, то на встрече, имевшей место в феврале
2015-го, количество посетителей выросло до 400.

Чтобы предоставить людям больше информации о devops, была запущена еженедельная программа Automation Open Labs, используемая в качестве открытого сеанса вопросов и ответов.

342
Часть V. Масштабирование

Также был запущен ежемесячный демонстрационный сеанс, благодаря которому члены сообщества получили возможность совместно выполнять работу, получать обратную связь, вдохновлять и быть вдохновленными.
Росс и Хизер адаптировали последовательный обмен сообщениями в органи- зации, который реализуется через коучей, выполнив сведение методик гибкой и бережливой разработки программ, а также devops-методики. В результате в организации появились коучи, специализирующиеся в смежных областях.
Также была сформирована практика обеспечения качества, которой способст- вуют высокоиммерсивные сеансы тренинга. Сотрудников компании поощряют делиться опытом с пользователями Интернета на сайте http://target.github.io.
В результате увеличивается степень близости как внутри организации, так и за ее пределами.
Применение инструментов и технологий в компании
Команду под руководством Микман обязали создавать интерфейсы приложений
(application program interfaces; API), которые позволили бы упростить растущую сложность систем и организационных бункеров в компании Target.
Со временем в организации, управляемой с помощью модели водопада, наблюда- ется тенденция к формированию иерархий и процессов, которые минимизируют риск. Роли становятся жестко заданными, а команды специализируются на ока- зании единственной услуги, которая тесно связана с другими услугами, предо- ставляемыми в организации. Это приводит к удлинению циклов выпуска, чтобы распространить сведения о потенциальных изменениях по всей организации.
В результате возрастает риск неудачи при внедрении изменений.
Разработка API рассматривается в качестве способа устранения растущей техни- ческой задолженности организации. Поскольку компания Target специализиру- ется в области розничной торговли, она разрабатывает API, позволяющие выпол- нять операции с товарами, отслеживать местоположение и часы работы магазинов, проводить промоакции и регулировать ценообразование. По мере развития API компания Target получила возможность быстро проверять текущее состояние дел, а также узнавать о том, как оптимизировать работу с клиентами и партнерами, например с Pinterest.
Для получения требуемых результатов руководству компании Target следовало найти подходящие инструменты. Как упоминалось в части IV, среди отдельных людей и организаций существуют различные мнения по поводу важности конкрет- ных инструментов либо способа их применения. В компании Target господствует мнение о важности инструментов самих по себе. Благодаря правильно подобран- ному набору инструментов обеспечивается комплексное владение платформой и API. В случае же отсутствия таких инструментов платформа и API будут раз- рознены и заключены в бункерах.

Глава 14. Масштабирование: критические точки
343
ВАЖНОСТЬ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ В DEVOPS
В декабре 2015-го появились сообщения о том, что у приложения списка жела- ний Target обнаружена утечка персональных данных. Известно, что ключевая функция API заключается в поддержке коммуникационных интерфейсов, обес- печивающих передачу данных между программами. Зачастую при разработке программного обеспечения компании уделяют внимание ожидаемому способу использования программного обеспечения, а не потенциальным возможностям его использования.
При создании программы, обеспечивающей возможность взаимодействия меж- ду другими программами, фактически создается возможность для общения человека с этими программами. Зачастую с помощью барьеров авторизации и аутентификации осуществляется отбор пользователей, которым разрешено
«общаться» с программой и использовать ее. С помощью аутентификации га- рантируется подлинность объекта. Авторизация определяет политики доступа, задающие список разрешенных действий для объекта.
Возвращаясь к случаю с уязвимостью, обнаруженной в приложении Target, заметим, что соответствующий интерфейс API не обладает богатым набором средств авторизации и аутентификации. Процесс встраивания аутентификации в сервис может быть затруднительным, особенно если вы разрешаете пользо- вателям найти список желаний на основе известной информации, не требуя создавать профиль пользователя. Например, если человек, создающий список желаний, хочет поделиться идентифицирующей информацией с организацией, пользователь, просматривающий список желаний, может этого не захотеть. По- этому отсутствие аутентификации при работе со списком желаний — это не так уж и плохо, как может показаться на первый взгляд.
Таким образом, проблема заключается в том, чтобы создать безопасный сервис, который не передает персональную идентифицирующую информацию (personal identification information; PII) неуполномоченным лицам. Также нужно обеспе- чить способ поиска подобной информации, соответствующей спискам поже- ланий пользователей. Основной недостаток API заключается в наличии четко заданного набора политик доступа, связанных с сущностями. Если сущность не прошла процедуры аутентификации и авторизации, она не может получить доступ к PII даже при наличии идентификатора пользователя. В идеале иденти- фикаторы пользователя следует выбирать так, чтобы затруднить их угадывание.
В случае с уязвимостью в приложении компании Target все выглядит так, что при наличии какой-либо информации о человеке она может быть истолкована как разрешение на получение полного набора сведений, относящихся к этому человеку.
В процессе преобразования должны принимать участие все компоненты ор- ганизации. Если в организации накопились культурные и технические задол- женности, их влияние будет ощущаться до тех пор, пока в организации будут существовать бункеры.

344
Часть V. Масштабирование
Чтобы достичь поставленных целей, в компании Target использовался соответ- ствующий набор инструментов. В число этих инструментов входят платформа облачных вычислений OpenStack, средство непрерывной интеграции и доставки
Jenkins, средство автоматизации инфраструктуры либо управления конфигура- цией Chef, средство контроля исходного кода GitHub. Благодаря использованию подобного набора инструментов обеспечивался более прозрачный процесс раз- работки кода. Ранее разработчики имели свои собственные автономные обзоры кода, теперь же они используют запросы на включение кода GitHub. Подобный подход очень нравится сотрудникам из эксплуатационного отдела, поскольку они получают возможность отслеживания изменений и могут легко стать участниками процесса разработки программ.
Для общения внутри организации весьма полезно приложение Hipchat, а при- ложение chatops стало неотъемлемой частью процесса разработки. Благодаря
Hipchat обеспечивается общение не только внутри одной команды, но и между командами. Благодаря использованию chatops для потоковой передачи оповеще- ний и событий в соответствующих каналах можно в режиме реального времени получить представление об экосистеме разработки программ. Это позволяет ре- агировать на инциденты гораздо быстрее, чем при использовании классических подходов.
В компании Target успех инициатив по внедрению новых инструментов частич- но оценивался пропорционально количеству соответствующих API. С октября
2014 года по февраль 2015 года этот показатель вырос от 30 до 45. Важность API обусловлена их использованием для интеграции и совместной работы команд и сервисов. До появления API они находились в бункерах и работали раздельно.
Несмотря на возросшее число внутренних и внешних запросов API, сайт оставал- ся стабильным, а ежемесячное количество инцидентов было весьма небольшим.
Благодаря подбору корректной комбинации инструментов, обеспечивших улуч- шенное сотрудничество, были устранены некоторые болевые точки, что способст- вовало достижению успеха.
Не забудьте сформулировать критерии успешного использования инструмен- та в организации. Сконцентрируйтесь на результатах, которые вы хотите полу- чить, выясните болевые точки, а затем подыщите инструменты для решения идентифицированных проблем.
Обмен знаниями внутри компании
После достижения успеха в ограниченных командах Микман и Клэнтон на- чали формировать послание для более широкой аудитории в Target. Один из механизмов, позволяющих внедрить изменения в организации, — проведение ежеквартальных внутренних конференций devopsdays. На этих конференциях

Глава 14. Масштабирование: критические точки
345
выступали докладчики из других организаций, в частности Роб Каммингс из компании Nordstrom и Майкл Даки из компании Chef. Как уже упоминалось, это способствовало привлечению новых идей и возбуждению интереса к собственным devops-инициативам и прогрессу.
Вторая стратегия, адаптированная в Target, заключалась в обеспечении согласо- ванности при обмене сообщениями в организации. Росс и Хизер имели представ- ление о том, каким образом эксперты в области бережливой разработки программ, гибкой разработки ПО и devops могут помочь тренеру либо наставнику, обучаю- щему отдельных сотрудников либо команды, в обучении и обмене информацией.
Они обнаружили, что сведение этих тем в одну и воспитание тренеров, специали- зирующихся в смежных областях, облегчит формирование более последователь- ной внутренней народной модели. В результате все больше людей будут владеть информацией, относящейся к разным devops-концепциям.
Еще один способ распространения инициатив с уровня отдельных команд на уро- вень всей организации заключается в проведении иммерсивных коучинг-сеансов.
Формирование открытых лабораторий, в работе которых могут принимать участие все сотрудники организации, позволяет расширить масштабы взаимного обучения и обмена информацией. Благодаря «автоматизированным хакатонам» еще боль- шее число людей могут принять участие в этих изменениях. Это также хорошо сказывается на собственной работе этих людей.
Здесь перечислены лишь несколько способов, благодаря которым компания Target смогла не только подобрать наборы инструментов и решения по сотрудничеству, которые успешно использовались в работе, но и поделиться информацией в мас- штабах организации о работоспособных (и не очень) решениях. Сочетание под- держки в направлении сверху вниз и усилий, проявленных на нижних уровнях, обеспечивает внедрение изменений на уровне отдельных людей и команд.
Подход, заключающийся в разрешении отдельным сотрудникам и командам внедрять изменения на основе их собственного глубокого опыта, необходим для уверенности в корректности изменений, осуществляемых в любой орга- низации. Чтобы придать этим изменениям устойчивый характер, необходима административная поддержка.
Выводы
Мы сталкиваемся с проблемами нашей рабочей среды, причинами которых по- служили наши прошлые решения либо текущие задачи. Если подходить к этим проблемам с точки зрения отдельного сотрудника, команды или организации, то можно успешно оценивать, планировать и преодолевать их. На самом деле ключевые проблемы, связанные с адаптацией devops-практик, заключаются в масштабировании. На разных уровнях могут существовать барьеры, которые