Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 374
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Глава 4. Основные термины и концепции
79
Организационное обучение
Самообучающейся называется организация, которая непрерывно обуча- ется и трансформируется… Обучение — это непрерывный и направлен- ный на достижение стратегических целей процесс, который интегрирован и выполняется одновременно с рабочим процессом.
— Karen E. Watkins and Victoria J. Marsick, Partners for Learning
Организационное обучение представляет собой процесс сбора, роста и совместно- го использования знаний организации. В самообучающейся организации процесс обучения является более продуманным, поскольку оно представляет собой кон- кретную цель. Также предпринимаются действенные меры, чтобы со временем увеличить интенсивность коллективного обучения.
Организационное обучение, выбранное в качестве цели, является частью того, что отделяет культуру, основанную на упреках, от безупречной культуры. Тогда как культуры, основанные на упреках, зачастую в большей степени ориентированы на наказание, а не на обучение, безупречные или самообучающиеся организации по- нимают ценность опыта, извлекают уроки из происшедших событий и накаплива- ют опыт, даже если этот опыт является негативным. Обучение может происходить на разных уровнях — на индивидуальном, групповом и на уровне организации.
Организационное обучение оказывает большее влияние на саму организацию.
К тому же компании, практикующие организационное обучение, являются более успешными.
Выводы
В этой главе были рассмотрены разные методики, связанные с разработкой, раз- вертыванием и поддержкой программного обеспечения и лежащей в его основе инфраструктуры. Также были рассмотрены культурные концепции, связанные с реагированием на инциденты и сбои отдельных лиц и организаций, а также с процессом обучения.
Конечно, мы рассмотрели далеко не исчерпывающий список методик, к тому же в будущем неизбежно появятся новые методологии и технологии. Тем не менее фундаментальные темы, связанные с разработкой, развертыванием, обслужива- нием и обучением, будут по-прежнему являться основными для разработчиков
ПО еще долгие годы.
1 2 3 4 5 6 7 8 9 ... 39
ГЛАВА 5
Заблуждения и антишаблоны,
относящиеся к devops
Когда идет речь о devops, будет не лишним обсудить, что не относится к этой концепции. В результате этого обсуждения выявятся некоторые очевидные заблу- ждения или идеи, не имеющие отношения к devops. В этой главе рассматривается дополнительный контент, касающийся devops, а также некоторые общие анти- шаблоны.
Общие заблуждения, связанные с devops
В индустрии разработки ПО часто встречаются неверные представления о devops.
Поэтому группы сотрудников, сформированные в вашей организации, могут и должны бороться за выработку ясных и точных убеждений и ценностей, име- ющих отношение к devops. В этом разделе мы рассмотрим некоторые проблемы, с которыми обычно сталкиваются при попытке внедрения devops в организации.
Devops — это лишь разработчики
и системные администраторы
Несмотря на то что название «devops» произошло от слов development (разработ- ка) и operations (эксплуатация), оно скорее является напоминанием об источниках происхождения движения devops, чем строгим определением. И хотя на конфе- ренциях devopsdays звучит слоган «Конференция, которая объединяет разработку и эксплуатацию», на самом деле концепции и идеи devops охватывают все роли в организации. Не существует единого исчерпывающего списка, регламентиру- ющего, как и какие люди и команды должны быть вовлечены в движение devops.
Также отсутствует единый универсальный подход к внедрению devops.
Идеи, которые помогают группам разработчиков и специалистам эксплуатации лучше общаться и более эффективно работать вместе, могут применяться на
Глава 5. Заблуждения и антишаблоны, относящиеся к devops
81
уровне компании в целом. Можно повысить эффективность любой группы в со- ставе организации, будь то служба безопасности, отдел контроля качества, отдел эксплуатации или юридический отдел. Например, эффективные devops-процессы, внедренные на уровне юридического и коммерческого отделов, позволят реализо- вать автоматическое формирование контрактов на основе постоянного обновляе- мого каталога товаров.
Обратите внимание, что благодаря использованию принципов devops вы- игрывают любые две или большее число команд, поэтому не ограничивайте потенциальную аудиторию пользователей devops и не изолируйте группы сотрудников. В части III будут изложены соображения по эффективному при- влечению групп сотрудников к использованию devops.
Devops — это команда
В общем случае создание специальной «devops-команды» вряд ли можно считать удачным решением. Обратите внимание, что ни создание команды под названием
«devops», ни присвоение имени «devops» существующей команде не является ни необходимым, ни достаточным условием для формирования devops-культуры.
Если ваша организация пребывает в таком состоянии, что члены команд разработ- чиков и эксплуатации не могут общаться друг с другом, создание дополнительной команды, ответственной за налаживание общения, приведет лишь к появлению дополнительных проблем. Чтобы внедрить значительные и долговременные из- менения, сначала нужно решить фундаментальные проблемы.
Формирование отдельной команды в среде, в которой запускаются новые процес- сы и коммуникационные стратегии, может быть эффективным в тех случаях, когда проект стартует «с нуля». В больших компаниях формирование отдельной devops- команды обычно осуществляется на короткий срок. Основная задача подобной команды заключается во внедрении значительных изменений. Со временем, вы- полнив задачи по инициированию изменений, члены вновь созданной команды возвращаются обратно в свои группы.
Наличие в стартап-среде единственной команды, выполняющей обе упомянутые выше функции, является целесообразным в том случае, если она берет на себя ответственность за разработку ПО и выполняет миссию по его эксплуатации. При этом в команде должно быть налажено сотрудничество между участниками, позво- ляющее быстро решать возникающие проблемы, не прибегая к экстренному вызову отдельных профессионалов. В этом случае все равно потребуется менеджмент, позволяющий облегчить четкое распределение ролей и обязанностей. Это позволит выполнять масштабирование группы по мере роста компании в целом.
В этой книге рассматриваются различные возможности, используемые при органи- зации команд, и стратегии, обеспечивающие коммуникации и координирование де- ятельности отдельных групп. В конечном счете следует помнить, что не существует
82
Часть I. Основы devops единственного верного или неправильного способа внедрения devops. И если в ва- шей организации уже сформирована команда, в названии которой присутствует слово «devops», и эта команда действительно работает, нет смысла менять ее на дру- гую команду. Имейте в виду, что слово «devops» подразумевает культуру, процесс, название и структуру команд, сформированных в вашей организации.
Devops как профессия
Толкование профессии «devops-инженер» является неоднозначным. Некоторые из толкований приведены в следующем списке:
системный администратор, который знает, как писать программный код;
разработчик ПО, владеющий навыками системного администрирования;
мифический десятикратный инженер (производительность этого сотруд- ника в 10 раз выше производительности других сотрудников, хотя это скорее образное выражение), который может за одну зарплату выполнять обязанности системного администратора и разработчика ПО с наивысшим качеством работы.
Описанная концепция devops-инженера не только нереалистична, она еще и плохо масштабируется. В новых организациях разработчики нередко развертывают код и поддерживают сопутствующую инфраструктуру, но если компания является зрелой и имеет большие размеры, целесообразно привлекать специалистов к вы- полнению отдельных работ.
Вряд ли имеет смысл назначать devops-директора либо любого другого человека, ответственного за внедрение devops-практик в организации. По своей сути devops является культурным движением, поэтому идеи и принципы этого движения должны внедряться на всех уровнях организации. Лишь в этом случае devops будет эффективным.
Несмотря на все, что сказано выше, должность «devops-инженер» действительно существует. В соответствии с данными, опубликованными в отчете 2015 DevOps
Salary Report от Puppet (https://puppet.com/resources/white-paper/2015-devops-
salary-report), у инженеров, в названии должности которых присутствует слово
«devops», зарплата выше, чем у обычных системных администраторов. Конечно, эти оценки весьма приблизительны, поскольку в разных организациях devops-ин- женеры исполняют самые разные роли. Скажите на милость, кто бы отказался от звания devops-инженера за прибавку в 10 тыс. долларов к зарплате?
В отчете 2015 DevOps Salary Report отмечается, что «большинство devops-инже- неров работают более 50 часов в неделю, системные инженеры работают от 41 до 50 часов в неделю, а системные администраторы работают менее 40 часов в неделю». Как видите, никто даром деньги не платит. Если вы получаете высокую зарплату, будьте готовы пожертвовать своим личным временем и здоровьем.
Глава 5. Заблуждения и антишаблоны, относящиеся к devops
83
Методология devops связана только с веб-стартапами
Основной продукт интернет-компаний — веб-приложения, с которыми имеют дело пользователи при просмотре веб-сайта компании. Эти сайты часто могут быть реализованы без использования информации, которая хранится где-либо между сеансами взаимодействия пользователей с сайтом (то есть сеансы без от- слеживания состояния). Обновление сайта можно выполнить либо поэтапно, либо путем переноса «живого» трафика на новую версию сайта. При этом облегчается процесс непрерывного развертывания.
Несложно понять, почему devops-методики имеют такое значение для интернет- компаний. Это движение помогает разрушить барьеры, которые стоят на пути раз- работки и развертывания программного обеспечения. Если процессы, реализован- ные в интернет-компании, настолько медленны, что требуется несколько недель на устранение мелкой ошибки, скорее всего, эта компания не сможет конкурировать с организациями, в которых используются новые гибкие подходы к разработке и развертыванию приложений.
Преимущества, обеспечиваемые улучшенным сотрудничеством, близостью и ин- струментами, проявляются не только в веб-стартапах. Просто повторяющиеся действия (или итерации) с групповыми структурами и процессами проще выпол- нять в рамках небольших стартапов. Крупные компании сопротивляются быстрым изменениям, а правительственные учреждения активно препятствуют изменениям и ограничивают их с помощью специальных законов. Тем не менее изменения возможны даже в таких учреждениях и организациях. В следующих главах книги будут рассмотрены примеры использования методик devops в крупных корпора- циях и правительственных учреждениях.
Devops нужно сертифицировать
Поскольку devops-методики в большой степени связаны с культурой, сертификация в этом случае вряд ли применима. Невозможно провести 60-минутный экзамен и по его результатам сертифицировать эффективность общения с другими людьми, оценить степень налаженности командной работы в вашей организации и сделать выводы о порядке обучения в организации. Сертификацию имеет смысл применять по отношению к высоким технологиям, использование которых потребует серьез- ного уровня знаний о таких вещах, как специфическое программное обеспечение или оборудование. Благодаря подобной сертификации компании могут получить представление о знаниях отдельных сотрудников в данной области.
При использовании devops-методов не требуется технологическая база либо универсальные решения. На сертификационных экзаменах обычно проверяют уровень знаний, задавая вопросы, на которые существуют четко определенные ответы. Как правило, в devops таких ответов не существует. То, что хорошо работает в одной компании, вовсе не обязательно окажется оптимальным для другой компании. Не существует простого способа разработать набор вопросов,
84
Часть I. Основы devops имеющих отношение к devops, которые имели бы однозначные ответы. Сертифи- кация в devops может либо использоваться в качестве средства заработка, либо быть связанной определенным решением поставщика, но называть ее devops- сертификацией некорректно.
Благодаря devops можно сократить персонал
Некоторые полагают, что благодаря devops можно получить разработчика ПО и инженера из службы эксплуатации в одном лице, но не платить ему двойной оклад. Мало того что это мнение ошибочно, оно еще и очень вредно. Многие стар- тапы предлагают сотрудникам бонусы, такие как трехразовое питание и прачечная на рабочем месте, в надежде стимулировать сотрудников подольше задерживаться на работе, но это приводит к негативным эффектам. Многие инженеры проводят на работе по 60–80 часов в неделю, люди перестают соблюдать баланс между ра- ботой и отдыхом, что ведет к переработке и переутомлению.
На самых ранних стадиях проекта стартап может только выиграть, если разработ- чики настолько хорошо разбираются в эксплуатации, что могут выполнять развер- тывание ПО, особенно при обращении к провайдерам облачных услуг и другим компаниям, могущим взять на себя выполнение большого объема оперативной работы. Но как только компания переходит в стадию зрелости и сотрудники начи- нают выполнять двойную работу, это может вылиться в выгорание.
Методология devops не поможет вам сэкономить деньги за счет сокращения вдвое количества инженеров, работающих в компании. Скорее она позволяет организациям улучшить качество и эффективность работы, сократить коли- чество и длительность простоев, уменьшить время разработки и улучшить эффективность отдельных сотрудников и команд в целом.
Не существует единственно верного пути
внедрения devops
Практики и специалисты по внедрению devops, работавшие во времена появления этой методологии, особенно хорошо известные в этой области, например Netflix и Etsy, часто назывались «единорогами»
1
. Они монополизировали рынок «пра- вильных» способов внедрения devops. Другие компании, стремящиеся ощутить преимущества devops-культуры, иногда стремятся подражать этой практике.
Тот факт, что компания представляет собственную успешную devops-стратегию, вовсе не означает, что те же самые процессы позволят корректно внедрить практики devops
1
В терминологии devops единорог — это интернет-компания, которая исполняла функции практика, специалиста по внедрению инноваций и реализации devops в первые годы появления этой методологии. Не путайте с определением единорога в сфере финансов, там это стартап стоимостью более 1 млрд долларов.