Философия DevOps. Искусство управления IT Дэвис Дженнифер
Как только завершается сбор данных по проекту и требований к проекту, производится оценка потенциальных решений, реализованных в форме открытого и коммерческого кода. Затем создается прототип, который совместно используется командами, такими как разработчики, эксплуатационники и сервисные менеджеры. Благодаря этому возможно получение обратной связи от максимального числа заинтересованных сторон прежде, чем полностью утвердить выбранное решение. Также минимизируются впустую потраченные усилия, если выясняется изменение направления разработки, и обеспечивается максимальное удовлетворение потребностей каждого заказчика, которому предлагаются потенциальные решения.
При планировании проектов или других работ в организации, особенно работающей в условиях масштабирования, обращайте внимание на следующие моменты.
• Работают ли в этой области другие команды или группы?
• Каким образом могут координироваться или объединяться усилия с другими командами?
• Какие заинтересованные стороны и лица, принимающие решения, должны быть привлечены?
• Каким образом вы определяете успех для этого проекта?
Вызовы
Один из вызовов, который часто возникает в правительственных агентствах, – дублирование усилий разными группами (рис. 14.3). В каждой группе должны поддерживаться основные элементы инфраструктуры. Эти элементы применяются дополнительно к работе, которая находится в центре внимания или в области компетенции определенной группы. Поскольку эти основные услуги не централизованы, каждой команде или группе придется потратить время, чтобы нанять специалистов, обладающих необходимыми навыками.
Предоставление услуг на основе платформы многоарендной архитектуры в правительственном секторе позволило бы сэкономить время эксплуатационных команд. Экономия достигается за счет того, что вводится централизованная служба поддержки, которая удовлетворяет всем требованиям безопасности и конфиденциальности. Централизованное предоставление услуг позволило бы сервисным командам сосредоточиться на областях, навыках и требованиях, которые являются для них уникальными. Ключевые требования для мультиарендной платформы, используемой в правительственных учреждениях, приведены в следующем списке:
• она должна быть самообслуживаемой;
• должны использоваться несколько провайдеров услуг;
• должна быть изоляция кода, данных и логов.
Рис. 14.3. Дублирование услуг, предоставляемых правительственными организациями
Благодаря самообслуживанию пользователи получают полный контроль над нужными аспектами приложения. Это позволяет командам сосредоточиваться на разработке усовершенствований платформы, а не на создании услуг. В результате поощряется специализация, приводящая к формированию платформенных и сервисных команд.
Второе требование, заключающееся в использовании нескольких провайдеров услуг, предотвращает привязку к одному поставщику, стимулирует конкурентное ценообразование и способствует устранению единственных точек отказа. В процессе обдумывания требований проекта лучше использовать несколько облачных хранилищ, чем одно. Заблаговременное соблюдение этого требования позволит отказаться от использования специфичных для поставщика средств, привязка к которым затруднит переход к другому провайдеру либо включение дополнительных провайдеров в дальнейшем. Позднее в агентстве GPS решили отказаться от этого требования, поскольку решения с открытым исходным кодом также будут обеспечивать необходимую степень гибкости.
Третье, и наиболее существенное, требование для многоабонентской платформы заключается в полной изоляции кода, данных и логов между агентствами. Это необходимо, чтобы убедиться в том, что каждая группа или агентство в состоянии соблюдать собственные ограничения безопасности и конфиденциальности. Даже если одно из ограничений не удовлетворяется, платформа не может использоваться и, соответственно, не может рассматриваться как успешная. И хотя детали этого вызова являются уникальными для каждой правительственной организации, во многих организациях также должны удовлетворяться разные юридические требования (например, соблюдение совместимости с PCI, SOX либо HIPAA). Все эти моменты должны учитываться в процессе планирования, чтобы избежать потенциальных напрасных затрат усилий.
Формирование близости
Один из способов формирования близости, применяемых в GDS, заключается в участии в турнирах Global GovJams. Турнир GovJam (http://www.govjam.org/) подобен хакатону в том, что участники имеют ограниченное количество времени (всего лишь 48 часов), чтобы завершить выбранные ими проекты. Вдохновленные идеями Global Service Jams и Sustainability Jams, организаторы турниров GovJam предлагают участникам свободно выбирать темы, голосовать за идеи и создавать команды.
Как только команды будут сформированы, они начнут общаться с клиентами, чтобы выяснить их нужды. В отличие от традиционного хакатона, в GovJam во главу угла ставится налаживание взаимодействия между людьми, заинтересованными во внедрении улучшений и инноваций. В сети Global GovJam объединяются и соединяются люди со всего мира на основе общей темы и общей централизованной платформы, используемой для размещения прототипов. Также участники могут сотрудничать и обмениваться информацией с помощью Twitter, используя хэштег #ggovjam.
Затем в течение 48 часов команды создают прототипы. При этом используется все, что доступно, и все, что может применяться в работе, а также коллективный опыт и экспертные знания. Они регулярно просматривают демоверсии и видят, как другие пользователи испытывают и используют продукт, улучшая его на основе полученных знаний. Благодаря распространению идей и помощи между командами больше выигрывают клиенты, а не сами участники команд. Благодаря концентрации на сотрудничестве обеспечивается отличный способ внедрения совместного мышления в GDS.
Второй способ, используемый GDS для формирования близости, заключается в регулярном ведении блогов для обмена информацией об организации, ее целях и текущих проектах. Несмотря на необходимость соблюдения различных инструкций по безопасности и конфиденциальности, сотрудникам GDS рекомендуется публиковать посты в публичном блоге группы. Эти посты посвящены самым разным темам, начиная от новых продуктов и услуг, которые доступны клиентам, и завершая способами усовершенствования культуры и процессов. В результате формируется узнаваемый образ группы и приобретаются привычки по получению знаний и обмену информацией.
И наконец, в GDS формируется близость на основе участия в сообществе разработчиков ПО с открытым исходным кодом. Портал GOV.UK основан на использовании программного обеспечения с открытым исходным кодом. Благодаря использованию открытого исходного кода облегчается сосредоточение на нуждах пользователей. Этот код доступен на сайтах по адресам https://github.com/gds-operations и https://github.com/alphagov.
Джеймс Стюарт (James Stewart), директор по технической архитектуре в агентстве GDS, продемонстрировал общий подход к выбору инструмента, показанного на рис. 14.4, процитировав мирового судью Рангасвами.
Для устранения общих проблем используйте инструменты с открытым исходным кодом.
Для устранения редких проблем используйте платные решения.
Для устранения уникальных проблем создавайте свой код.
Рис. 14.4. Пирамида создания, покупки и использования открытого кода
По сути, эта цитата говорит нам, что все участники команды должны решать повседневные проблемы с помощью открытого исходного кода, внося свой вклад в сообщество. Вклад в сообщество подразумевает нечто большее, чем обычное подтверждение кода и включение таких элементов, как документация, отчеты об ошибках и иллюстрации. В случае возникновения редких проблем приобретите продукты, которые способствуют устранению этих проблем. И наконец, для устранения уникальных проблем, специфичных для вашей команды или организации, создайте свое собственное решение.
В общем случае правительственное агентство по оказанию цифровых услуг работает над созданием и поддержкой явно определенной культуры, которая нацелена на пользователей и на решение связанных с пользователями проблем. К ценностям также относятся опыт проектирования и общий опыт, сосредоточение на использовании agile-практик для уменьшения количества затрат, ускоренного выполнения итераций, а также упрощения оказания цифровых и технологических услуг для других правительственных организаций. Акцент на сотрудничестве и близости, а также собственных ценностях и запретах появился в результате длинного пути к созданию культуры правительственных организаций, необходимой для успешности в будущем.
За последние десять лет произошли серьезные изменения в том, как, где и когда люди совершают покупки. Клиенты компании Target должны легко получать доступ к услугам в любом месте и в любое время. Технология, заложенная в основе компании, критически важна для способности быстро модифицировать стратегии в соответствии с изменяющейся средой для цепочки поставок и в соответствии с требованиями клиента.
Поскольку размеры компании Target довольно большие, принятие devops-культуры не было односторонним, спущенным сверху вниз решением. Некоторые команды начали свое devops-путешествие отдельно, а после того, как полученные результаты доказали успешность выбранных стратегий, объединились. Информация для этого примера была подобрана на основе сообщений в блоге, общедоступных презентаций, опубликованных сотрудниками Target, и регистрационных документов компании.
Компания Target Corporation – это розничная торговая компания со штаб-квартирой в Миннеаполисе, штат Миннесота. Основанная в 1902 году Джорджем Дейтоном (George Dayton) как Dayton Dry Goods, в середине 2015 года Target насчитывала примерно 347 тысяч сотрудников. По состоянию на 2015 год эта компания являлась вторым по величине импортером в США. Компания Target имеет сеть обычных магазинов, а также работает в банковском, фармацевтическом секторах и в сфере охраны здоровья.
Как любая современная компания, работающая в сфере розничных продаж, Target имеет большой послужной список технических инноваций. В 1988 году компания установила сканеры UPC во всех магазинах и центрах дистрибуции Target. Также был изменен дизайн магазинов, в частности появились более удобные товарные полки. Также в течение нескольких лет в магазинах появился ряд новых инноваций, от пунктов проверки цен, контрольно-кассовых аппаратов, карманных устройств проверки запасов товара на складах, пунктов формирования списков подарков до приложений, гарантирующих поставку товаров из центров дистрибуции в нужное время и место, а также другие инновации.
Начнем с желаемых результатов
В крупной организации с длинной историей путешествие в направлении изменений часто напоминает перемещение в запутанном лабиринте, состоящем из большого числа изгибов и поворотов. Хорошее прохождение лабиринта включает лучшие практики, которые минимизируют риск. Организация отражает сложность, создаваемую со временем. Если посмотреть на Target «с высоты птичьего полета», вряд ли вы определите начало devops-путешествия компании Target.
В действительности не было никакой единственной начальной точки. Многие команды начинали с разных начальных точек. Хизер Микман (Heather Mickman) возглавила команду под названием «API and Integration Development», а Росс Клэнтон (Ross Clanton) – команду «Ops Infrastructure Services». Именно эти две команды работали над внедрением devops в организации. Избранные командами способы не относятся к категории простых, причем некоторые сотрудники даже не знали о наличии термина devops. Вместо этого они описывали желаемые результаты на обычном языке, например «более скудно, более быстро, предоставление более качественных услуг». Эти слова выражают суть философии devops. Как объясняет Хизер Микман:
Я должна была прекратить использовать термин devops, поскольку он перегружен смыслом, несет большое количество дезинформации и недоразумений. Я беседовала с коллегами и руководителями организации и видела, как они умолкали, когда я произносила слово «devops».
Решение Микман в пользу отказа от использования термина devops в силу его перегруженности смыслом демонстрирует силу народных моделей, рассмотренных в главе 2. Вы могли бы столкнуться с подобными реакциями в своих собственных организациях, когда предвзято настроенные люди проявляют недовольство и избегают обсуждений. Подобно Микман, вы также можете найти время для выполнения эффективных преобразований в организации, особенно если сосредоточитесь на желаемых результатах и изменениях, а не на голой терминологии. Изменения выполняются поэтапно, начиная с агентов индивидуальных изменений, массовых усилий и нисходящей поддержки и завершая успешными стратегиями масштабирования.
Критически важными для адаптации изменений являются сосредоточение на желаемых результатах и осведомленность о чувствительности к языку. Рассказывайте интересные истории, которые пробуждают интерес и вдохновляют на изменения, без использования слова devops. Важно осознать текущий ландшафт в Target и понять, как отразились на людях приложенные усилия.
Формирование корпоративной близости
Руководство компании Target поощряет формирование близости на предприятии путем поддержки существующей культуры организационного обучения. Благодаря «внедрению в массы» идеи организационного обучения и поощрению всех сотрудников к продвижению «на ступеньку выше» обеспечивается масштабирование по всей организации. При этом делается упор на следующих четырех элементах:
• экспериментирование;
• тестирование;
• неудача;
• достижение цели.
Благодаря большому опыту работы с разными командами Росс Клэнтон осознал и прочувствовал проблемы каждой команды. Также он столкнулся с разными проблемами на уровне организации, такими как смещенные символы, передача работы и подотчетность.
Путешествие Клэнтона в мир devops, внедряемого в компании Target, началось с поиска руководства, которое помогло бы справиться с подобными проблемами. Многие рекомендуют книгу Phoenix Project: A Novel About IT, DevOps, and Helping Your Business win, написанную Кевином Берром (Kevin Behr), Джин Ким (Gene Kim) и Джорджом Спэффордом (George Spafford). После прочтения этой книги Клэнтон приобрел дополнительные экземпляры и раздал их другим членам своей команды. Он также провел ролевую игру на основе различных сценариев, описанных в книге.
Важно отметить, что процесс обучения и внедрения изменений внутри организации зачастую вдохновляется внешними факторами. Если вы черпаете идеи и стратегии только внутри организации, то в конечном итоге рискуете остаться со старыми практиками, привычками и паттернами. А если вы попытаетесь внедрить серьезные изменения в организации, то вряд ли старые методы смогут адекватно использоваться.
Не становитесь жертвой менталитета карго-культа, внедряя изменения только по той причине, что это делают другие. Но и не стоит недооценивать опыт и знания других людей.
Он объединился с другими технологическими лидерами в организации, включая директора Хизер Микман и технического руководителя Джеффа Эйнхорна (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, используемая в качестве открытого сеанса вопросов и ответов.
• Также был запущен ежемесячный демонстрационный сеанс, благодаря которому члены сообщества получили возможность совместно выполнять работу, получать обратную связь, вдохновлять и быть вдохновленными.
Росс и Хизер адаптировали последовательный обмен сообщениями в организации, который реализуется через коучей, выполнив сведение методик гибкой и бережливой разработки программ, а также devops-методики. В результате в организации появились коучи, специализирующиеся в смежных областях. Также была сформирована практика обеспечения качества, которой способствуют высокоиммерсивные сеансы тренинга. Сотрудников компании поощряют делиться опытом с пользователями Интернета на сайте http://target.github.io. В результате увеличивается степень близости как внутри организации, так и за ее пределами.
Применение инструментов и технологий в компании
Команду под руководством Микман обязали создавать интерфейсы приложений (application program interfaces; API), которые позволили бы упростить растущую сложность систем и организационных бункеров в компании Target.
Со временем в организации, управляемой с помощью модели водопада, наблюдается тенденция к формированию иерархий и процессов, которые минимизируют риск. Роли становятся жестко заданными, а команды специализируются на оказании единственной услуги, которая тесно связана с другими услугами, предоставляемыми в организации. Это приводит к удлинению циклов выпуска, чтобы распространить сведения о потенциальных изменениях по всей организации. В результате возрастает риск неудачи при внедрении изменений.
Разработка API рассматривается в качестве способа устранения растущей технической задолженности организации. Поскольку компания Target специализируется в области розничной торговли, она разрабатывает API, позволяющие выполнять операции с товарами, отслеживать местоположение и часы работы магазинов, проводить промоакции и регулировать ценообразование. По мере развития API компания Target получила возможность быстро проверять текущее состояние дел, а также узнавать о том, как оптимизировать работу с клиентами и партнерами, например с Pinterest.
Для получения требуемых результатов руководству компании Target следовало найти подходящие инструменты. Как упоминалось в части IV, среди отдельных людей и организаций существуют различные мнения по поводу важности конкретных инструментов либо способа их применения. В компании Target господствует мнение о важности инструментов самих по себе. Благодаря правильно подобранному набору инструментов обеспечивается комплексное владение платформой и API. В случае же отсутствия таких инструментов платформа и API будут разрознены и заключены в бункерах.
ВАЖНОСТЬ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ В DEVOPS
В декабре 2015-го появились сообщения о том, что у приложения списка желаний Target обнаружена утечка персональных данных. Известно, что ключевая функция API заключается в поддержке коммуникационных интерфейсов, обеспечивающих передачу данных между программами. Зачастую при разработке программного обеспечения компании уделяют внимание ожидаемому способу использования программного обеспечения, а не потенциальным возможностям его использования.
При создании программы, обеспечивающей возможность взаимодействия между другими программами, фактически создается возможность для общения человека с этими программами. Зачастую с помощью барьеров авторизации и аутентификации осуществляется отбор пользователей, которым разрешено «общаться» с программой и использовать ее. С помощью аутентификации гарантируется подлинность объекта. Авторизация определяет политики доступа, задающие список разрешенных действий для объекта.
Возвращаясь к случаю с уязвимостью, обнаруженной в приложении Target, заметим, что соответствующий интерфейс API не обладает богатым набором средств авторизации и аутентификации. Процесс встраивания аутентификации в сервис может быть затруднительным, особенно если вы разрешаете пользователям найти список желаний на основе известной информации, не требуя создавать профиль пользователя. Например, если человек, создающий список желаний, хочет поделиться идентифицирующей информацией с организацией, пользователь, просматривающий список желаний, может этого не захотеть. Поэтому отсутствие аутентификации при работе со списком желаний – это не так уж и плохо, как может показаться на первый взгляд.
Таким образом, проблема заключается в том, чтобы создать безопасный сервис, который не передает персональную идентифицирующую информацию (personal identification information; PII) неуполномоченным лицам. Также нужно обеспечить способ поиска подобной информации, соответствующей спискам пожеланий пользователей. Основной недостаток API заключается в наличии четко заданного набора политик доступа, связанных с сущностями. Если сущность не прошла процедуры аутентификации и авторизации, она не может получить доступ к PII даже при наличии идентификатора пользователя. В идеале идентификаторы пользователя следует выбирать так, чтобы затруднить их угадывание. В случае с уязвимостью в приложении компании Target все выглядит так, что при наличии какой-либо информации о человеке она может быть истолкована как разрешение на получение полного набора сведений, относящихся к этому человеку.
В процессе преобразования должны принимать участие все компоненты организации. Если в организации накопились культурные и технические задолженности, их влияние будет ощущаться до тех пор, пока в организации будут существовать бункеры.
Чтобы достичь поставленных целей, в компании Target использовался соответствующий набор инструментов. В число этих инструментов входят платформа облачных вычислений OpenStack, средство непрерывной интеграции и доставки Jenkins, средство автоматизации инфраструктуры либо управления конфигурацией Chef, средство контроля исходного кода GitHub. Благодаря использованию подобного набора инструментов обеспечивался более прозрачный процесс разработки кода. Ранее разработчики имели свои собственные автономные обзоры кода, теперь же они используют запросы на включение кода GitHub. Подобный подход очень нравится сотрудникам из эксплуатационного отдела, поскольку они получают возможность отслеживания изменений и могут легко стать участниками процесса разработки программ.
Для общения внутри организации весьма полезно приложение Hipchat, а приложение chatops стало неотъемлемой частью процесса разработки. Благодаря Hipchat обеспечивается общение не только внутри одной команды, но и между командами. Благодаря использованию chatops для потоковой передачи оповещений и событий в соответствующих каналах можно в режиме реального времени получить представление об экосистеме разработки программ. Это позволяет реагировать на инциденты гораздо быстрее, чем при использовании классических подходов.
В компании Target успех инициатив по внедрению новых инструментов частично оценивался пропорционально количеству соответствующих API. С октября 2014 года по февраль 2015 года этот показатель вырос от 30 до 45. Важность API обусловлена их использованием для интеграции и совместной работы команд и сервисов. До появления API они находились в бункерах и работали раздельно. Несмотря на возросшее число внутренних и внешних запросов API, сайт оставался стабильным, а ежемесячное количество инцидентов было весьма небольшим. Благодаря подбору корректной комбинации инструментов, обеспечивших улучшенное сотрудничество, были устранены некоторые болевые точки, что способствовало достижению успеха.
Не забудьте сформулировать критерии успешного использования инструмента в организации. Сконцентрируйтесь на результатах, которые вы хотите получить, выясните болевые точки, а затем подыщите инструменты для решения идентифицированных проблем.
Обмен знаниями внутри компании
После достижения успеха в ограниченных командах Микман и Клэнтон начали формировать послание для более широкой аудитории в Target. Один из механизмов, позволяющих внедрить изменения в организации, – проведение ежеквартальных внутренних конференций devopsdays. На этих конференциях выступали докладчики из других организаций, в частности Роб Каммингс из компании Nordstrom и Майкл Даки из компании Chef. Как уже упоминалось, это способствовало привлечению новых идей и возбуждению интереса к собственным devops-инициативам и прогрессу.
Вторая стратегия, адаптированная в Target, заключалась в обеспечении согласованности при обмене сообщениями в организации. Росс и Хизер имели представление о том, каким образом эксперты в области бережливой разработки программ, гибкой разработки ПО и devops могут помочь тренеру либо наставнику, обучающему отдельных сотрудников либо команды, в обучении и обмене информацией. Они обнаружили, что сведение этих тем в одну и воспитание тренеров, специализирующихся в смежных областях, облегчит формирование более последовательной внутренней народной модели. В результате все больше людей будут владеть информацией, относящейся к разным devops-концепциям.
Еще один способ распространения инициатив с уровня отдельных команд на уровень всей организации заключается в проведении иммерсивных коучинг-сеансов. Формирование открытых лабораторий, в работе которых могут принимать участие все сотрудники организации, позволяет расширить масштабы взаимного обучения и обмена информацией. Благодаря «автоматизированным хакатонам» еще большее число людей могут принять участие в этих изменениях. Это также хорошо сказывается на собственной работе этих людей.
Здесь перечислены лишь несколько способов, благодаря которым компания Target смогла не только подобрать наборы инструментов и решения по сотрудничеству, которые успешно использовались в работе, но и поделиться информацией в масштабах организации о работоспособных (и не очень) решениях. Сочетание поддержки в направлении сверху вниз и усилий, проявленных на нижних уровнях, обеспечивает внедрение изменений на уровне отдельных людей и команд.
Подход, заключающийся в разрешении отдельным сотрудникам и командам внедрять изменения на основе их собственного глубокого опыта, необходим для уверенности в корректности изменений, осуществляемых в любой организации. Чтобы придать этим изменениям устойчивый характер, необходима административная поддержка.
Мы сталкиваемся с проблемами нашей рабочей среды, причинами которых послужили наши прошлые решения либо текущие задачи. Если подходить к этим проблемам с точки зрения отдельного сотрудника, команды или организации, то можно успешно оценивать, планировать и преодолевать их. На самом деле ключевые проблемы, связанные с адаптацией devops-практик, заключаются в масштабировании. На разных уровнях могут существовать барьеры, которые растут с течением времени. Эти барьеры влияют на подход к различным критическим точкам, которые могут возникать на протяжении жизненного цикла организации.
Иногда нужно пересматривать текущие процессы и возвращаться обратно. Порой нужно быть медлительными и осторожными, а бывает, что нужно быть быстрыми и динамичными. Успех приходит в результате непрерывной практики и обучения на ошибках.
Успешное масштабирование – это искусство и наука принятия решения о том, когда и как нужно изменить направление (в случае необходимости), чтобы успешно перемещаться в постоянно изменяющейся среде. Как и в случае с открытым восхождением, отсутствуют размеченные красочные маршруты, которые будут направлять вас в конкретной ситуации. Нужно начать с повышения необходимых навыков на уровне отдельных людей, команд и организации в целом, а затем применить базовые принципы эффективных devops-методик независимо от сложности и размеров организации.
Глава 15. Масштабирование: заблуждения и устранение проблем
В этой главе будут рассмотрены некоторые наиболее часто встречающиеся проблемы масштабирования и способы их устранения. Также будут рассмотрены вопросы, относящиеся как к обычным сотрудникам, так и к менеджерам. Советы, представленные в данной главе, помогут в разрешении проблем работникам, выполняющим разные роли на предприятии.
Как упоминалось в предыдущей главе, организации более заинтересованы в масштабировании, чем просто в сохранении статуса большой компании или во внедрении некоторых devops-практик уровня предприятия.
Некоторые команды никогда не смогут работать вместе
Очень часто движение devops возникает как результат конфликта между командами разработчиков и эксплуатации из-за отсутствия взаимопонимания. Обычно команды попадают в состояние конфликта из-за повышенной напряженности и накопившихся недоразумений. Как упоминалось в части II, не следует рассматривать конфликты как негативные явления. Конфликт – это хороший признак здоровой организации, поэтому не стоит его бояться или избегать. Важно не допускать взаимных конфликтов между командами. Если межличностное урегулирование подразумевает примирение по принципу «один на одни», то групповое урегулирование конфликта – более сложный процесс. Следует научиться корректировать внутригрупповые связи и процессы, приведшие к сбоям.
На первых этапах бывает очень трудно урегулировать конфликты, поскольку команды заново учатся взаимодействовать друг с другом. Для восстановления доверительных отношений требуется много времени и усилий. Одно неловкое действие может свести на нет все предыдущие попытки.
Ниже приведены основные модели поведения, которые нужно отслеживать.
Критика
Переход на личности, диктуемый особенностями характера.
Проявление неуважения
Заявления или поведение, обусловленные позицией превосходства.
Защитное поведение
Заявления или поведение, продиктованные соображениями самозащиты.
Замалчивание проблемы
Эмоциональное отчуждение, мешающее общаться с людьми.
Огульные обвинения
Заявления, содержащие упреки типа «они всегда», «они никогда» или «мы всегда/никогда».
В командах, постоянно противопоставляющих себя другим, зачастую возникают проблемы самоопределения. Команды должны иметь одно общее видение и определение успеха. Если одна группа почувствует, что ее цели недостижимы из-за дефицита информации и прозрачности, относящейся к другим группам, в этом случае вторая группа может оказывать эмоциональное давление. Это в свою очередь способствует усугублению и так напряженных отношений между командами.
В случае распределенных команд проблемы будут усугубляться. Если в противоречие вступают различные приоритеты и цели, связанные с достижением успеха, конфликт между распределенными группами будет усугубляться и для его разрешения потребуется больше усилий. Процесс принятия решений в таких группах должен быть прозрачен и понятен для всех членов команды.
Как показывают исследования, если сотрудники различных подразделений регулярно наносят визиты друг другу, между ними налаживаются дружеские связи, укрепляются договорные отношения и вырабатываются способы взаимодействия и сотрудничества[64]. Менеджеры по возможности должны содействовать проведению таких встреч, чтобы на основе прозрачности обеспечить совместную работу команд. Людям не нравится, когда их ставят перед фактом принятия решений, которые оказывают на них непосредственное влияние, даже если они удовлетворены результатами принятия таких решений.
Серьезный конфликт, отражающийся на результатах работы, обычно является следствием слияния двух компаний. Чтобы искоренить принцип противопоставления команд, в процесс продвижения к цели должны быть вовлечены влиятельные лица из обеих компаний.
Подобная ментальность присуща людям, использующим свою независимость и знания в целях засекречивания своей работы. Им нравится быть в роли единственной критической точки или уязвимого места в процессе передачи знаний. Эти люди считают себя настолько ценными, что компания, по их мнению, никогда от них не откажется. Такой подход может негативно отразиться на отношениях с аналогичными компаниями. В этих случаях рекомендуется принимать меры, направленные на передачу информации и корректировку взаимоотношений, включая устранение недоверия между отдельными сотрудниками и компанией.
Внедрение изменений невозможно без одобрения начальства
Менеджер всегда оказывает достаточно большое влияние на своих непосредственных подчиненных и на эффективность их работы. Если со стороны высшего руководства отмечается сильное давление на сотрудников, менеджер выступает в роли «зонтика»,[65] то есть защищает своих подчиненных от грязи, которая выливается на них в процессе работы.
Если руководство ставит слишком высокие требования, менеджер может либо защитить свою команду от возможных неприятностей, либо просто слить на них все непомерные запросы начальства (то есть выступить в роли «сливной воронки для нечистот»).
Менеджер должен делать все от него зависящее, чтобы вдохновить свою команду, предоставив ей максимальную свободу действий по экспериментам с инструментами, рабочими потоками и практиками, применяемыми в команде. В зависимости от культуры организации менеджеру легче убедить своих подчиненных в том, что текущие результаты могут достигаться за счет использования новых, более эффективных инструментов или рабочих потоков. Менеджер обязан делать все возможное для защиты своей команды от скептиков и поиска оптимальных способов работы с ними.
Наш бюджет не предусматривает набор новых специалистов, в связи с чем внедрение devops-методик на данном этапе невозможно
Процесс переориентирования культуры небольших или быстро развивающихся организаций в сторону использования devops-практик происходит проще в случае подбора персонала с соответствующим опытом и мировоззрением. Тем не менее не каждая компания решится на прием большого количества новых сотрудников, если вообще пойдет на такой шаг. К счастью, внедрение devops-методик возможно и без привлечения новых сотрудников, являющихся «10x devops-инженерами».
Выработайте единое понимание целей
Чтобы каждый сотрудник компании проникся идеей devops, следует убедиться в том, что у всех работников сформировано одинаковое представление об этой методике. Менеджер должен уметь не только донести до коллектива предмет изменений, но и объяснить причину, вызвавшую необходимость этих изменений. Это особенно касается больших компаний, имеющих тенденцию к реорганизации. В таких компаниях люди зачастую с подозрением относятся к изменениям, для них это звучит как что-то несущественное или как пустые декларации. Менеджер должен убедить свою команду в том, что речь идет о конкретных изменениях, направленных на получение практических результатов.
Создайте условия и возможности для обучения
Как уже упоминалось в главе 8, старого системного администратора можно обучить новым трюкам. Трансформация devops подразумевает освоение новых программных и технических навыков, таких как составление безупречного постмортема и работа с Docker. Убедитесь в том, что сотрудники организации могут получить все необходимые навыки. Также обеспечьте создание обучающей среды и личностный рост каждого сотрудника организации.
Сформируйте среду для успешного внедрения devops-принципов
Для внедрения изменений следует создать условия, при которых людям будет интересно выполнять эту работу. Чтобы сотрудники больше общались между собой или занимались наставничеством, менеджер должен закрепить эти навыки в матрице навыков или внести в план служебного роста. В целях пресечения грубого поведения следует поощрять сотрудников, которые сообщают о таких поступках. Агрессивное и оскорбительное поведение недопустимо и должно наказываться менеджером. Невозможно создать такую среду, в которой совмещались бы хорошие и плохие работники. Если менеджер не борется с негодяями, то, скорее всего, он активно сопротивляется внедрению devops-среды, основанной на сотрудничестве.
Если нужно изменить существующую среду, привычки и поведение людей, следует действовать постепенно. Нужно быть уверенным в наличии четких целей, возможностей для обучения и атмосферы доверия, эмпатии и сотрудничества.
Универсального решения по устранению проблем, возникших при выполнении масштабирования, не существует. В данном разделе представлены общие сценарии развития событий в организациях в процессе их роста и развития на протяжении жизненного цикла.
Менеджмент рекомендует придерживаться X, не видя пользы от devops
При рассмотрении компании Target в предыдущей главе говорилось о том, что на определенном этапе развития компании менеджмент дает добро на внедрение изменений, которые имели бы более продолжительный эффект в рамках всей организации. Тем не менее не стоит ожидать одобрения этих действий с самого начала. Рекомендуется начать с одной команды, дать ей время на эксперименты и посмотреть, как будет продвигаться дело. Положительные результаты внедрения изменений будут служить ценным примером для других команд.
Если проблема связана с топ-менеджментом, попросите вашего непосредственного менеджера помочь в вопросе внедрения изменений. Эта помощь может заключаться в следующем:
• разобраться с ограничениями непосредственно на рабочем месте;
• вести переговоры с другими менеджерами от вашего имени;
• позволить вам проводить эксперименты в команде;
• защищать вас от любых негативных последствий.
Если ваш непосредственный менеджер не видит пользы от внедрения devops, вам будет сложнее влиять на ход изменений. В этом случае можно найти союзников в своей команде. Если менеджер настаивает на использовании инструмента Х, сможете ли вы применять его наравне с новым инструментом или методикой Y, чтобы через некоторое время сравнить результаты? Сможете ли вы влиять на вашего менеджера и обсуждать с ним темы эффективности изменений и их преимуществ?
Недостаточные ресурсы команд
Если команды систематически не выполняют задания или не соблюдают нормативные сроки при достаточно реальных планах и требованиях, возможно, над поставленными задачами или проектами работает мало людей. В этом случае следует произвести переоценку рабочей загрузки и сроков выполнения работ. Вариантом выхода из создавшейся ситуации может быть перераспределение сотрудников между проектами или пересмотр календарного планирования, что реально позволит данной команде завершить работу в установленные сроки.
Возможно, придется нанять в команду больше людей, особенно на стадии роста. При этом следует учитывать, что на стадии спада, сопровождающейся сокращением количества штатных сотрудников, не всегда уменьшается объем работ или рабочая нагрузка. С целью сокращения расходов прежний объем работ выполняется меньшим количеством людей, что на определенном этапе может негативно отразиться на качестве работ и привести к выгоранию персонала. Поэтому нужно соизмерять свои ожидания с реальностью.
Чтобы при том же количестве сотрудников достигались более эффективные результаты труда, люди должны работать не интенсивнее, а интеллектуальнее. Вместо того чтобы тратить больше времени на выполнение большего объема работ, можно усовершенствовать оборудование и технологии. Следует обсудить с членами команды производственный процесс и инструменты, используемые в работе, продумать способы повышения их эффективности с целью экономии времени и усилий. Поиск оптимальных решений можно вести за пределами компании, учитывая вместе с тем мнения и предложения членов команды. Опрос сотрудников обычно занимает много времени и усилий, особенно если люди не привыкли высказывать свои идеи и мнения. Как бы там ни было, но благодаря таким исследованиям можно получить очень полезную информацию.
Принятие необоснованных решений
Болевой точкой в процессе роста и развития организаций является осознание того, что процессы принятия решений отнимают много времени и усилий, а результаты не всегда соответствуют ожиданиям (руководство решило попробовать Х, но стало не лучше, а еще хуже). В небольшой организации, когда весь инженерный отдел помещался в одной комнате, решения принимались быстро и легко. Когда компания расширяется до нескольких подразделений, разбросанных по всему миру, процесс принятия решений превращается в затяжную рутину. Ниже описаны способы решения этой проблемы.
Исследование процессов
По мере роста организации усиливается путаница в вопросах ответственности за те или иные проблемы. Если над проектом работает несколько команд, проблемы зачастую остаются незамеченными и никто не несет за них ответственности. Иногда оспаривание командами своей вины в появлении проблемы может привести к конфликтам. Последняя ситуация особенно отрицательно сказывается на эффективности процесса принятия решений. Многочисленные споры всегда затрудняют возможность что-либо решить. С другой точки зрения, любые спускаемые сверху решения, которые принимаются без особого оспаривания, как правило, не всегда устраивают сотрудников.
Идентификация проблем, связанных с прозрачностью
Если менеджер недостаточно четко осознает необходимость принятия тех или иных решений, а также их возможные последствия, он склонен к аналитическому параличу.
Контроль оценки процесса
Люди избегают принимать решения в том случае, если процедура их принятия сама по себе превращается в процесс достижения результатов в оптимальные сроки.
Соизмерение продуктивности с рисками
Избегание принятия решений сказывается на производительности труда. Следует четко осознавать риски, связанные с принятием неправильных решений. Если такие действия приводят к незначительным последствиям, то постоянное игнорирование принятия решений оборачивается потерями времени, что может уменьшить полезность этих решений.
Внедрение постепенных изменений
Осознание того, что многие решения не являются необратимыми, способствует переосмыслению рамок понимания. Если мы понимаем, что можем передумать после принятого решения, то уменьшаем аналитический паралич, возникающий из-за большого количества альтернатив.
Сохранение безопасного пространства для экспериментов
На ошибках учатся анализировать риски и принимать правильные решения. Это еще одна сфера, в которой проявляются преимущества безупречной культуры. При такой модели сотрудники в основном сосредоточены на достижении наилучших результатов, а не просто заботятся о спасении своей шкуры.
Отслеживайте принимаемые решения. Последовательное выполнение одних и тех же действий с ожиданием других результатов – это зря потраченные усилия и проявление безрассудства. Отслеживая решения и результаты, можно скорректировать свой курс и достичь большей уверенности в принимаемых решениях.
Мы не можем привлечь талантливых сотрудников
Знакомьте свой персонал с основными требованиями к работе, посещайте собрания отдельных групп, пересмотрите требования к работе и поддерживайте обратную связь с коллективом. Если история организации диктует требования к количеству и качеству кандидатов, претендующих на вакантные места, можно воспользоваться некоторыми рекомендациями, которые будут полезными.
Поинтересуйтесь историей и проблемами, характерными для этой среды. Будьте готовы ответить на возможные вопросы после изложения сути основных проблем. Если потенциальный кандидат ознакомился с деятельностью вашей компании, изучил отзывы в Glassdoor и пришел на собеседование, это хороший знак. Попросите нынешних сотрудников рассказать о работе в форме презентации или участия в конференциях. Процесс просмотра презентаций и участия в конференциях должен быть четким и доступным.
Выясните, в чем состоит проблема, – в процессе найма или в проведении собеседований с кандидатами. Разработайте программу по обучению сотрудников интервьюированию и разбейте их на пары, чтобы в организации было как можно больше людей, готовых проводить собеседования. Выявите методики, которые, по вашему мнению, могут отпугивать потенциальных кандидатов. Собеседования, затягивающиеся на целый день или даже на несколько дней, а также враждебно настроенные интервьюеры зачастую отпугивают кандидатов, тем самым пороча идею многообразия внутри организации.
Бывают случаи проблемного поведения отдельных сотрудников на рабочем месте. Если эти вопросы довольно долго игнорируются, люди поймут, что такого рода поведение допустимо. Как результат, сотрудники перестанут сообщать о подобных случаях и устранять проблемы, возникающие в связи с неподобающим поведением. Проблемных сотрудников следует обязательно увольнять из компании, тем самым давая возможность привлекать новых людей. Особенно жестко следует реагировать на проявления расизма, сексизма или дискриминации по другим признакам.
Благодаря таким действиям вы сможете выявить потенциальных кандидатов на вакантные места. Если большая организация медленно реагирует на изменения в отрасли, ей, скорее всего, не придется переманивать сотрудников стартапов. Обращайте особое внимание на организационные проблемы и ограничения, учитывая которые можно отнести поиски кандидатов с целевой аудиторией и не заработать плохую репутацию из-за несоблюдения методик подбора персонала.
Ослабление морального духа коллектива после реорганизации или сокращения
Фаза сокращения в жизненном цикле организации – это естественный процесс, в ходе которого руководство сокращает линейки продуктов или штат сотрудников. Изменение культурных норм способствует повышению уровня прозрачности, когда работники могут публиковать отзывы о своей работе, информацию о зарплате и собеседовании. Существует сайт Glassdoor, представляющий собой площадку, на которой сотрудники могут размещать сведения на условиях анонимности. Потенциальные работники могут познакомиться с подобной информацией и оценить свои силы и возможности.
Процессы, происходящие после вхождения компании в эту фазу, отражают ее культуру. Стиль и методика изложения руководством информации о грядущих изменениях иногда вызывают когнитивный диссонанс у сотрудников (внутренний конфликт). Это имеет место в том случае, когда внутреннее восприятие культуры и возможных последствий такого сообщения не синхронизированы.
Непонимание разных способов оценивания людей может негативно отразиться на моральном состоянии коллектива. Если компания сокращает отстающих сотрудников и среди них оказывается ценный работник, оставшиеся члены команды должны восполнить недостающее звено для восстановления после когнитивного диссонанса.
Неумело проводимые и управляемые процессы изменений деморализуют оставшихся сотрудников компании. Это приводит к ухудшению сотрудничества и командной работы между отдельными сотрудниками и командами, а также способствует росту количества аварийных ситуаций и прогулов, вызванных стрессами или болезнями. В зависимости от причин реорганизации или сокращения все это может привести к обратному нежелательному эффекту.
Если предстоит сокращение персонала, не стоит это скрывать. Чем больше организация, тем больше вероятность утечки информации. В порыве чувств и эмоций некоторые люди могут просто «слить» служебную информацию. Если новости о реорганизации становятся известными прежде, чем руководство информирует об этом сотрудников, людей охватывает паника по поводу возможного сокращения или увольнения ценных сотрудников.
Если команда недостаточно корректно справилась с такими событиями в силу постоянно растущего уровня прозрачности, связанной с событиями, важно, чтобы сотрудники могли решать остальные внутренние вопросы при таких же условиях.
Пересмотрите и откорректируйте методики приема на работу. Убедитесь в том, что они позитивно оценены сообществом. Проявляйте индивидуальный подход в процессе найма персонала.
Старайтесь искать кандидатов младшего звена, имеющих небольшой опыт работы. Проводите обучение и наставническую работу. Несмотря на то что в скором времени им придется платить больше, их помощь еще долго будет представлять ценность для организации. Обладая большим потенциалом, они могут оживить процесс найма персонала.
И наконец, увольте всех нерадивых сотрудников. Изучите влияние отдельных работников на команду. Не прощайте плохое поведение даже ценным членам коллектива. Их поведение плохо влияет на остальных сотрудников, а также может негативно отразиться на кандидатах, проходящих собеседование.
Если проект или роль не предусматривают необходимости приема на работу более одного человека, можно воспользоваться готовым рецептом от выгорания в виде команды одного сотрудника. Существует такое понятие, как автобусный фактор, – предельное количество людей, которое может потерять команда или проект, чтобы утратить свои институционные знания или возможности роста. Иными словами – это количество людей, которое может сбить автобус, прежде чем проект/команду нельзя будет спасти. Чем меньше этот показатель, тем хуже для команды, поскольку сужаются границы для возможных ошибок или смягчающих обстоятельств.
Автобусный фактор для команды, состоящей из одного сотрудника, по определению равен единице. Что будет делать руководство, если этого сотрудника вдруг собьет автобус или, что менее драматично, он заболеет, захочет взять отпуск или уволиться? Постарайтесь найти способы передачи информации и опыта другим сотрудникам (даже не прибегая к большой рабочей загрузке) для создания полноценной команды. Начните с составления рабочих пар и старайтесь регулярно обновлять документацию.
Еще одной серьезной проблемой для команды, состоящей из одного сотрудника, является такое понятие, как выгорание. Если определенный вид работ выполняет единственный сотрудник, существует вероятность оказания на него внутреннего или внешнего давления (например, невозможность уйти в отпуск или взять больничный). Без должной подзарядки будет постоянно накапливаться стресс, и это, скорее всего, подтолкнет работника к решению уйти из компании. Такие люди предусмотрительно ищут новую работу, на которой не будут считаться «козлами отпущения» и, соответственно, будут работать без стресса и выгорания. Было бы неплохо, если бы несколько людей, несущих одинаковую ответственность и имеющих одинаковый опыт, работали бы по сменам. С точки зрения отдельного работника и организации в целом это было бы лучше и продуктивнее, чем работа одного человека на полной ставке.
Часть VI. Объединение культур devops
Глава 16. Наведение мостов между культурами с помощью четырех столпов devops
Гибкость – это один из ключевых факторов, поддерживающих жизнеспособность и далеко идущее влияние devops-культуры. Как уже неоднократно упоминалось на страницах этой книги, внедрение devops не сводится к какому-либо одному способу, не требует определенного программного обеспечения или процесса и не ограничивается веб-стартапами.
Определенные истории (например, Netfix и Etsy) часто пересказывают в качестве успешных примеров внедрения devops. Но они не описывают все способы применения четырех принципов devops с целью повышения производительности. Такие организации, как Etsy, которые славятся своими культурными и техническими традициями, определенно могут поделиться историями роста производительности и эффективности работы. Но в этой книге собраны не только те истории, которые традиционно излагаются в devops-окружении. Разнообразие изложенных историй никоим образом не отрицает роль devops, а, наоборот, дает ключ к пониманию его важности в функционировании отдельной компании и отрасли в целом.
В историях, посвященных devops, зачастую прослеживается тема разобщенности. Команды разработчиков и эксплуатации настолько далеки друг от друга, что практически не общаются между собой, не говоря уже об эффективном сотрудничестве. Логичным выводом кажется желание начать с разрушения этих барьеров. Мы же предпочитаем представлять devops, используя не деструктивные, а конструктивные метафоры.
Представим различные команды в качестве отдельных островов. Для поддержания здоровой и жизнеспособной экосистемы обитатели островов должны обмениваться ресурсами, передавать друг другу информацию и даже переезжать с острова на остров. Поэтому необходимо построить мосты между островами. И чем больше мостов будет построено, тем эффективнее будет сеть между островами. Истории о применении четырех столпов эффективных devops-практик посвящены принципам возведения мостов между отдельными островами, на которых находятся сотрудники, команды и организации.
На страницах этой книги подчеркивается важность историй. После знакомства с четырьмя столпами devops можно увидеть, как они работают в комплексе и как влияют на прошлые и настоящие истории.
Истории, рассказываемые людьми, – оболочка, содержащая их мир и придающая смысл их жизням.
– Эндрю Реймер
В некотором смысле devops подразумевает понимание и потенциальное изменение основных убеждений, относящихся к нашей личности. Наше восприятие личности, основанное на исполняемых ролях, и отторжение людей из-за несоответствия нашим взглядам влияют на нашу оценку инженеров, на выбор подходящих кандидатов на вакантные места, на способ проведения собеседований. Devops-практики подразумевают, что вместо фразы «Я сотрудник отдела эксплуатации, потому что я изначально занимаюсь этим» следует говорить «Я сотрудник отдела эксплуатации, потому что я занимаюсь этим сейчас». Эта фраза дает установку на образ мышления роста, который мы поощряем, вместо закостенелого образа мышления. Дело не в том, выполняется ли формально devops, а в том, как выявляются и решаются проблемы.
Чтобы понять причины большой популярности devops-практик в производственных компаниях, рассмотрим их важность с разных точек зрения. В понимании команд и организаций devops-практики влияют на жизни и рабочие структуры как отдельных сотрудников, так и отрасли в целом. Изучение различных культур компаний открывает перед нами возможности для взаимодействия с непохожими друг на друга людьми. Также мы получаем возможность увидеть взаимосвязь devops-практик и новых философских концепций, которым только предстоит появиться на свет.
Рассказывая и слушая истории из личного опыта, люди укрепляют чувство своей принадлежности к сообществу, ощущают себя более комфортно благодаря общим ценностям группы, а также обретают дополнительное понимание происходящих событий. Будучи членами группы, мы совершенствуем навыки общения благодаря общей системе обозначения, уменьшаем количество конфликтных ситуаций благодаря наличию общего понимания, а также усиливаем сплоченность благодаря общим ценностям и пониманию реальности.
Явные и неявные истории
Люди всегда любили использовать истории в качестве средства общения, но это не единственный способ рассказать о нашей жизни и культуре.
Явные истории излагают события в непосредственной повествовательной форме. Это самые распространенные виды историй, постоянно используемые в качестве примеров. Они рассказываются осознанно и преднамеренно.
Неявные истории предоставляют информацию о культуре, историях и деятельности. Они не рассказываются непосредственно.
Говоря о своем опыте работы с devops, мы зачастую даже не подозреваем, что рассказываем неявные истории. Рассмотрим следующие примеры.
Предложение кандидату присоединиться к команде
На собеседовании интервьюер часто неосознанно делится информацией о ценностях компании. Упоминание о необходимости работать в выходные дни служит сигналом, который говорит кандидату о том, что в этой компании нарушен баланс работы и личной жизни. Кроме того, этот факт может свидетельствовать об энтузиазме сотрудников, работающих над общим продуктом.
Публикации в блоге
Исходя из характера информации, содержащейся в публикациях, и уровня их написания потенциальный сотрудник может узнать о ценностях компании и об ожидаемом уровне знаний.
Презентации на отраслевых конференциях
Уровень и роль сотрудников, представляющих компанию на отраслевых конференциях, говорят о степени доверии и прозрачности внутри организации. Тот факт, что компанию представляют линейные сотрудники, может свидетельствовать о недостаточном уровне престижности конференции.
ЭЛИС ГОЛДФАС, ИНЖЕНЕР ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ САЙТОВ, КОМПАНИЯ NEW RELIC
Для меня devops-практики заключались в интеграции и взаимодействии разработчиков и инженеров эксплуатации для создания надежного программного обеспечения и платформ. DevOps подразумевает автоматизацию, тестирование и грамотное управление инцидентами.
Тем не менее devops может быть чем-то большим, целой культурой. Команды должны научиться понимать друг друга, и только после этого приступать к совместному решению задач. По сути, devops-культура функционирует настолько очевидно, что сначала я даже и не осознавала, что являюсь практикующим специалистом в этой области. Разумеется, нужно общаться с другими командами. Разумеется, инциденты не должны сопровождаться огульными обвинениями. Разумеется, нужны разносторонние таланты. И еще очень много ситуаций, когда слово «разумеется» вполне уместно.
Мне повезло работать в компании, которая с энтузиазмом внедряет ценности devops в повседневные рабочие процессы, не прибегая к громким словам и презентациям. Мы практикуем разбор инцидентов без поиска виноватых, назначаем инженеров по надежности в команды разработки и по возможности обеспечиваем прозрачность. Например, наша инженерная организация управляется с помощью централизованной базы данных процессов, вклад в которую может сделать любой инженер. Все изменения в процессах отображаются в ежемесячных рассылках.
Я знаю, что могу обсудить свой текущий проект с любым инженером из моей организации и найду людей, которые мне сочувствуют и готовы помочь при выполнении проекта. Поскольку каждая команда разработчиков участвует в дежурствах, мы все говорим практически на одном языке и поддерживаем успехи и неудачи друг друга. По сути, мы стремимся к приобретению универсальных навыков, когда разработчики могут устранять неполадки в Linux, а инженеры по надежности – создавать системные инструменты и веб-приложения.
Конечно, это не идеальное решение. Когда кто-то звонит вам в 3 часа ночи из-за ошибки в чужом коде, вам хочется послать его куда подальше. Но наличие официальных процессов гарантирует, что никто не будет обижен в порыве чувств. При наличии культуры, в которой интерес поддерживается дисциплиной, люди остаются в команде надолго. Ценность сбалансированных команд состоит в создании возможностей для выявления и реализации молодых талантов.
Если все вышесказанное и есть суть devops, то все сотрудники должны действовать в подобном ключе.
Одно дело – обсуждать, как что-то работает в теории, и совсем другое – реализовать это на практике. Любой сотрудник, внесший изменение в программный продукт, в определенный момент говорит себе (или коллегам): «В теории оно должно работать». При этом он будет не уверен, как внесенное изменение проявит себя в производственной среде.
У всех нас есть свое видение мира и представление о том, как все должно работать. Независимо от того, осознаем мы это или нет (а чаще всего не осознаем), эти модели управляют нашими мыслями и поведением в повседневной жизни. Все это называется используемой теорией, или, другими словами, все это способы проявления на практике теорий или моделей мышления. Тем не менее на вопросы о нашем видении мира или о предположительном поведении в той или иной ситуации мы зачастую даем другие ответы. Наше предположительное или желаемое поведение, так называемые проповедуемые теории, не всегда совпадает с нашими фактическими действиями.
Как правило, люди не ставят целью обмануть себя, когда проповедуемые теории отличаются от используемых теорий. Человеку свойственно верить в то, что его действия лучше и более позитивны. Но когда он сталкивается с чем-то, что происходит на самом деле, результаты его действий будут гораздо хуже, чем в теории. И если в теории менеджер позволяет своим подчиненным самостоятельно выбирать способы разрешения конфликтной ситуации, на практике он контролирует каждый их шаг на бессознательном уровне.
Практика на основе примеров из реальной жизни
На страницах этой книги приводятся примеры из реальной жизни, демонстрирующие практическое применение разнообразных теорий в процессе внедрения devops. Одно дело рассказывать о безупречной среде и совсем другое – создать эту среду в реальности.
Посещая конференции или знакомясь с публикациями в блогах, обращайте внимание на то, как другие организации внедряют devops, и сравнивайте со своей компанией. В процессе сравнения может оказаться, что культуры других организаций ушли далеко вперед. Тем не менее не стоит из-за этого расстраиваться, ведь проповедуемые ими теории могут существенно отличаться от используемых теорий.
Многих раздражает, когда одни и те же люди или представители организаций рассказывают о том, что они делают, или когда другие говорят о них как об «авторитетах отрасли». В этой ситуации остается только порадоваться за них, но реалии таковы, что многое из этого просто не будет работать в вашей организации. Процесс внедрения изменений может протекать сложнее в организациях со специфическими проблемами.
В культуру организации можно внести гораздо больше изменений, чем могут представить себе сотрудники этой организации. Разные компании и отрасли выдвигают различные требования и ограничения, поэтому не каждое желаемое изменение возможно внедрить. Если, например, необходимо поддержать совместимость со стандартом безопасности PCI, есть определенные изменения процесса, касающиеся таких аспектов, как серверы, обрабатывающие данные банковских карт, которые невозможно применить. Также есть ограничения, которым нужно следовать для поддержания совместимости. Тем не менее для большинства организаций это не исключает возможности получения значимых результатов в других областях деятельности.
Учимся на историях
Читать бесплатно другие книги:
