Сетевая библиотекаСетевая библиотека

Философия DevOps. Искусство управления IT

Философия DevOps. Искусство управления IT
Философия DevOps. Искусство управления IT Кэтрин Дэниелс Дженнифер Дэвис Бестселлеры O’Reilly (Питер) IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps. DevOps – это не просто набор техник, это философия. Разработчики, зацикленные на пользователях, должны уделять внимание поддержке и ее запросам. Сисадмины должны сообщать о проблемах продукта и вносить свой вклад в улучшение процесса работы. Но налаживание связей внутри компании – это лишь первый шаг. Чтобы продукт стал простым и удобным, придется вложить время и ресурсы в его доработку. Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах – вот лишь часть задач, которые придется решать на этом пути. Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения. Дженнифер Дэвис, Кэтрин Дэниелс Философия DevOps. Искусство управления IT Jennifer Davis Katherine Daniels Effective DevOps. Building a Culture of Collaboration, Affinity, and Tooling at Scale © 2016 Jennifer Davis, Katherine Daniels © Перевод на русский язык ООО Издательство «Питер», 2017 © Издание на русском языке, оформление ООО Издательство «Питер», 2017 © Серия «Бестселлеры O’Reilly», 2017 * * * Вступительное слово Иван Евтухович В мире, где такие фразы, как «дигитализация», «цифровая трансформация» и «технологические компании», давно набили оскомину, не вызывает сомнения, что эффективное управление ИТ-процессами является фактором выживания современной компании в любой сфере, будь то онлайн-продажи авиабилетов, интернет-торговля или дистанционное банковское обслуживание. Уже сейчас для многих компаний команды разработки и эксплуатации являются главным активом. Александр Титов Методология DevOps возникла как ответ на постоянный вызов делать программное обеспечение быстрее, качественнее и надежнее. Авторы книги рассказывают о том, что же такое DevOps, какие инструменты и технологии он в себя включает и как внедрять его внутри компании. Никита Борзых Особый акцент в книге сделан на корпоративную культуру доверия, сосредоточенную на коммуникации, сотрудничестве и интеграции между ИТ-подразделениями. Подход DevOps давно снискал большую популярность на Западе среди таких гигантов, как Amazon и Facebook, а теперь он все шире проникает в нашу страну. В книге приведены типичные антипаттерны внедрения DevOps, а также множество историй из жизни реальных компаний, которые внедряли у себя этот подход. Наша компания с первых дней своего существования является проводником методологии DevOps. И конечно, мы очень рады, что книга «Философия DevOps» теперь доступна и на русском языке. Ищите новые подходы, становитесь более гибкими, быстрыми и эффективными! Делитесь своими открытиями, используйте мировой опыт и участвуйте в развитии профессионального DevOps-сообщества России – DevOpsRU.com. Иван Евтухович Александр Титов Никита Борзых Управляющие партнеры «Express 42» http://express42.com/ +7 495 088 42 84 Вступительное слово Джона Оллспоу В настоящее время мы являемся свидетелями качественных изменений в подходах к разработке программного обеспечения. Эти фундаментальные изменения затрагивают все, что связано с проектированием, разработкой и использованием программ. Практически все успешные компании осознали, что программное обеспечение – это не просто код, который можно разрабатывать и запускать на выполнение. На самом деле любая программа – это некий объект, с которым осуществляется взаимодействие. Новый подход к разработке программного обеспечения является более универсальным, целостным и лучше отражает действительность, с которой ежедневно сталкиваются команды разработчиков ПО. Давно ушли в прошлое те времена, когда для описания разработки и поддержки программ применялись производственные метафоры. Когда-то считалось, что программы, как и любые другие товары, проектировались, планировались и, наконец, запускались в производство. Теперь же слово «наконец» к описанию процесса разработки ПО не применяется. Этот процесс представляет собой бесконечный цикл адаптации, изменения и обучения. В этой книге изложены тысячи примеров преодоления затруднений, с которыми сталкиваются разработчики программ в попытках упростить свою работу. Авторы книги не предлагают универсальное решение, которое подошло бы всем. Вместо этого они предлагают обзор тематических областей, практик и наблюдений за командами разработчиков и организациями, которые осознали, что для создания хороших продуктов, выработки пользовательских практик и разработки ПО требуются совместная работа, вдумчивая критика, эффективное сотрудничество и обратная связь. В 2009 году на конференции Velocity 09, проводимой издательством О'Reilly, я и мой друг Пол Хэммонд представили презентацию «10+ Deploys a Day: Dev and Ops Cooperation at Flickr». Несмотря на то что часть материала презентации была посвящена вопросам непрерывного развертывания, многие зрители обращали больше внимания на часть «10+ развертывание», а не на часть «Сотрудничество». Я считаю, что было бы ошибкой полагать, что технологии или «железо» нужно рассматривать отдельно от социального или культурного «софта». Эти компоненты неразрывно связаны и в одинаковой степени важны для достижения успеха. Другими словами, люди, процессы и программное обеспечение связаны между собой гораздо сильнее, чем принято думать. Я настоятельно советую читателям не совершать ошибку, полагая, что технологии существуют отдельно от людей и процессов. Ваши конкуренты тут же воспользуются вашей ошибкой и съедят вас живьем. Вряд ли вы найдете рассматриваемые в этой книге темы в типовых учебных программах по информатике либо в курсах профессионального лидерства или в курсах, предназначенных для разработчиков программ. Эти темы появились на этапе прагматической зрелости, которая, в свою очередь, появляется лишь в результате напряженной работы. В этой книге вы найдете исчерпывающий набор указаний. И я призываю вас, дорогие читатели, использовать эти указания применительно к вашему контенту и к вашей среде. Джон Оллспоу, технический директор, Etsy, Бруклин, Нью-Йорк Вступительное слово Николь Форсгрен В 2003 году Николас Карр в своей работе «IT Doesn’t Matter» заявил о том, что информационные технологии не являются стратегически важными для бизнеса. И поскольку эта статья была опубликована в журнале Harvard Business Review, она получила признание в корпоративной среде. Но с тех пор много воды утекло. Начиная с 2009 года наиболее инновационные команды и компании продемонстрировали, что технологии могут играть ключевую роль в создании реальной стоимости и обеспечении конкурентного преимущества. Эта технологическая революция получила название DevOps. После прочтения книги вы узнаете о том, как влиться в ряды инновационных компаний и начать создавать стоимость с помощью технологий. Авторы книги являются известными экспертами в сообществе пользователей DevOps и имеют большой опыт работы в инновационных компаниях. Они знают, что именно нужно предпринять, чтобы сделать подход DevOps (или, как его называют авторы, «devops») действительно эффективным. Авторы книги делятся с читателями уникальными знаниями и опытом. И поскольку эти знания и опыт получены при работе с разными компаниями и отраслями, они будут полезны любому читателю. И независимо от занимаемой вами должности или величины вашей компании эта книга поможет вам добиться успеха. Советы и рекомендации, изложенные в книге, коррелируют с моим опытом работы, полученным за последние десять лет. Как известный специалист в этой области и как ведущий исследователь State of DevOps Reports, я знаю, что ключевым компонентом любой трансформации в направлении DevOps является сильная организационная культура. Она служит фактором, задающим переход от традиционной ИТ-структуры к DevOps, а также ставит во главу угла информационный поток. На основе данных, предоставленных более чем 20 тысячами профессионалов в области DevOps, можно прийти к выводу о том, что сильная организационная культура способствует продвижению ИТ-организации и росту ее производительности в целом. Лучшим ИТ-организациям присуща удвоенная производительность, большая рентабельность и доля рынка по сравнению с конкурентами. И вовсе не случайно книга начинается дискуссией, посвященной аспектам культуры, общения и доверия. Значительная часть книги посвящена обоснованию важности вклада этих факторов в процесс трансформации в сторону DevOps. Нам, как технарям, нравится начинать с использования инструментов и, возможно, даже процессов. Но время от времени практика показывает, что культура, наравне с упомянутыми ранее ИТ и производительностью организации, имеет большое значение для успешного применения инструментов и технологий. Обязательно прочитайте части II–III, посвященные сотрудничеству и близости соответственно, независимо от того, начинаете ли вы трансформацию DevOps и хотите знать, что нужно реализовывать и что требуется отслеживать, или же вы поднимаете существующую практику DevOps на новый уровень и ищете способы оптимизации и устранения проблем. Работая консультантом в наиболее инновационных компаниях, я пришла к выводу о том, что наиболее трудная часть реализации и составления предварительного плана технологической трансформации DevOps заключается в невозможности дать однозначный ответ, который подходил бы для всех ситуаций. Все зависит от того, что именно считается корректным для вашей команды и вашей организации. Поэтому мне нравится, что именно эта мысль постоянно подчеркивается в книге. Не существует единственного простого решения всех проблем. Чтобы внедрить собственное решение DevOps и добиться успеха, нужно использовать подходящие инструменты и компоненты. Помимо частей II–III обязательно обратитесь к части IV, в которой описаны инструменты, необходимые для выполнения произвольной трансформации DevOps. Особенно мне нравится, что при описании инструментов идет речь не только о технологических аспектах, но и о ключевых компонентах культуры, в рамках которой эти инструменты используются. Одна из наиболее приятных особенностей книги заключается в ее доступности для разной аудитории. Часть V, посвященная масштабируемости, особенно полезна для рядовых участников и руководителей команд. Я использую материал, изложенный в этой части, в качестве справочника для себя и своих клиентов. Главы 4 и 11, включающие описание терминологии и обзор экосистемы, соответственно будут полезными как для технарей (в качестве терминологической базы), так и для руководителей, нуждающихся в актуальном справочном пособии. Эта книга является позитивным и полезным введением в DevOps, включающим сведения, которые отсутствуют в университетских учебниках. Я была бы просто счастлива, если бы в свое время могла использовать подобное пособие в своей преподавательской деятельности. Мы живем и работаем в поистине удивительные времена, когда интеграция технологий в бизнес привела к превращению каждой фирмы в софтверную компанию. Благодаря современным технологиям потребители могут использовать новые способы получения доступа к требуемым средствам, причем этот доступ осуществляется с невиданной ранее скоростью. Компаниям приходится прилагать максимум усилий, чтобы не отставать от конкурентов. На основе своего опыта работы с компаниями, внедрявшими DevOps, я пришла к выводу, что прежние методы (итеративная и каскадная модели) не позволяют поддерживать необходимую скорость обмена данными в организации. Авторы книги рассматривают проблемы технологической трансформации, выполняемой с помощью устаревших способов, и захватывающие возможности, открывающиеся в результате внедрения DevOps. Читайте книгу и выбирайте собственный путь! Повторяйте, учитесь, растите и выбирайте свой путь перехода к DevOps! Николь Форсгрен, доктор философии, директор компании Chef Software, Сиэтл, Вашингтон Предисловие Представьте себе такой сценарий. Небольшая веб-компания начала сталкиваться со следующими проблемами. Веб-сайт этой компании «тормозит» и периодически «ложится» в случае непредвиденного роста числа пользователей. Сотрудники все чаще выражают недовольство по причине увеличения трудозатрат, требуемых для предоставления услуг, а также в силу необходимости разработки и выкатки нового функционала. Между глобально распределенными командами разработчиков появляются барьеры, вызванные использованием разных языков и часовых поясов. Растет количество взаимных обвинений, вызванных стрессом из-за роста «падений» сайта. Это приводит к росту подозрительности и снижению степени прозрачности при взаимодействии между группами сотрудников. Столкнувшись с подобными проблемами, менеджмент организации принимает решение о devops-трансформации. Для реализации этого решения нанимается несколько сотрудников, формирующих новую devops-группу. Члены этой группы исполняют обязанности по вызову, то есть к ним обращаются члены эксплуатационной группы в случае возникновения неразрешимых проблем. Члены devops-группы являются экспертами в своей предметной области и лучше подготовлены к решению проблем. Но если у членов эксплуатационной группы нет ни времени, ни возможностей для получения новых навыков, одни и те же проблемы будут возникать снова и снова. Рано или поздно членам devops-группы надоест исполнять роль посредников между группой разработчиков и эксплуатационной группой. Вместо того чтобы убрать напряжение, подобное «решение» менеджмента приведет к росту недопонимания, поскольку ни одна из групп не причастна к процессам планирования, обмена сообщениями и отслеживания ошибок, реализуемых членами другой группы. В результате менеджмент заявляет о провале идеи с формированием devops-группы и перестает выделять время, деньги и усилия в развитие devops-группы и эксплуатационной группы. К членам этих групп начинают относиться как к некомпетентным бездельникам, которые способствуют «падениям сайта» и только «мешают» разработчикам, выполняющим «реальную» работу. Вполне естественно, что члены этих групп, не выдержав груза обвинений в некомпетентности, начинают увольняться из организации, еще более затрудняя исполнение обязанностей оставшимися сотрудниками. Первое знакомство с devops В чем причина появления проблем в описанной ситуации? Вроде бы внедрение «devops» являлось хорошей идеей, но создание devops-группы привело к негативным последствиям. Что нужно изменить, чтобы добиться значительного улучшения ситуации и реального устранения проблем? На протяжении всей книги вы увидите, как можно выполнить эффективные преобразования на основании devops-мышления. Не рассматривайте эту книгу в качестве сборника бесспорных рекомендаций по внедрению devops-подхода. Мы не предлагаем вам devops «из коробки», devops в качестве услуги и не говорим вам, что вы некорректно внедряете devops-решения. В этой книге вы найдете коллекцию идей и подходов по улучшению сотрудничества между отдельными сотрудниками, по достижению однородности на уровне отдельной группы и организации в целом и по использованию инструментов на уровне компании или организации. Вы также увидите, каким образом эти концепции способствуют изменению и адаптации организаций в случае возникновения необходимости в этом. Поскольку каждая организация является уникальной, не существует единого универсального подхода по внедрению devops. Существующие общие подходы должны применяться в каждой организации различным образом. В результате улучшается качество создаваемого в этой организации программного обеспечения, а также улучшается эффективность работы и повышается благосостояние сотрудников. Результативность является следствием того, что «делаются нужные, правильные вещи». А эффективность является следствием того, что «правильно создаются эти самые вещи».     – Питер Ф. Друкер Эффективность определяется как способность делать правильные вещи и достигать желаемых результатов. Чтобы делать правильные вещи, нужно осознать поставленные задачи и выявить связь между конкретными краткосрочными целями и поставленными задачами. Мы выражаем надежду, что сможем помочь вам идентифицировать правильные вещи в вашей среде на основе вашей культуры, включая применяемые процессы и инструменты. Идеи и принципы, излагаемые на протяжении всей книги, применимы к организации в целом, а не только на уровне групп разработчиков и технической поддержки. В процессе написания книги мы даже сами использовали эти идеи и принципы. В то время как наша цель при написании книги заключалась в том, чтобы поделиться универсальными историями, советами и практиками с менеджментом организаций, который сможет адаптировать и использовать их в качестве своих рабочих методологий, каждой из нас присущи свои уникальные знания и опыт. Разнообразные идеи, использованные при написании книги, были порождены коллективным опытом. Этот опыт получен на основе анализа работы частного и общественного сектора, маленьких стартапов и огромных корпоративных сред, а также отделов, распределенных по должностям, от разработки ПО до его поддержки, контроля качества, консалтинга и многого другого. КАК ПРАВИЛЬНО ПИСАТЬ СЛОВО «DEVOPS»? У нас были жаркие споры по поводу использования заглавных букв при написании термина «devops». В результате проведения простого интерактивного опроса выяснилось, что подавляющее большинство пользователей выбрали написание «DevOps». Пользователи также поддерживают написание терминов «Dev» и «Ops», используемое для обозначения групп в составе организации. На основе этих терминов создаются производные термины, такие как «DevSecOps» и «DevQAOps», тогда как термин «DevOps» подразумевает исключительное использование терминов «Dev» и «Ops». В итоге мы выбрали написание «devops», поскольку оно соответствует оригинальному хэштегу в Твиттере, используемому для объединения людей, которые хотят изменить слоган «мы против них» на «делаем бизнес» с применением устойчивых рабочих практик, ориентированных на людей. Успешные проекты требуют вклада, усилий, понимания и сотрудничества со стороны сотрудников организации. Проблемы, возникающие в организации, могут быть присущи не только разработчикам или группам поддержки. Мы сознательно решили использовать запись термина с помощью символов в нижнем регистре «devops» по всей книге. Это отражает нашу точку зрения, которая заключается в том, что devops является инклюзивным движением, а не эксклюзивной единицей. Для кого предназначена книга Эта книга в первую очередь предназначена для менеджеров и рядовых сотрудников, которые исполняют роли лидеров и сталкиваются с проблемами в своих организациях. Благодаря этой книге они смогут предпринять конкретные реальные действия, направленные на реализацию или улучшение devops-культуры в рабочей среде. Рядовые сотрудники, занимающие различные должности, найдут здесь практические предложения, позволяющие ослабить болевые точки благодаря выполнению действенных рекомендаций. Читатели этой книги исполняют разные профессиональные роли, поскольку devops является профессиональным и культурным движением, ориентированным на поддержку повторяющихся усилий, направленных на открытие доступа к организационной информации, отслеживание отношений и устранение недопонимания, возникающего между группами в организации. В книге рассматривается широкий набор навыков и теоретических положений devops, включая основы фундаментальных идей и концепций. Предполагается, что вы уже знакомы с термином «devops» и, возможно, даже имеете базовые познания об инструментах и процессах, используемых в этой области. Мы рекомендуем вам отказаться от жестко заданных и быстро сформулированных определений и настроиться на восприятие принципов devops, которые, по нашему мнению, являются наиболее эффективными. После прочтения книги у вас сформируется четкое представление о том, что означает на практике devops-культура для вашей организации. Вы узнаете о том, как стимулировать эффективное сотрудничество таким образом, чтобы отдельные сотрудники, относящиеся к разным слоям и группам, имеющие разные цели и владеющие различными рабочими стилями, могли продуктивно работать вместе. Вы получите сведения о том, как наладить совместную работу групп таким образом, чтобы максимизировать производимую стоимость при одновременном повышении степени удовлетворенности сотрудников. Вы научитесь балансировать между конфликтующими организационными целями и выбирать инструменты и организационные потоки, наращивающие потенциал вашей организации. Структура книги Мы приложили немало усилий для упорядочения и организации глав книги. Подобно тому как не существует единственно верного способа внедрения devops, отсутствует и единственно правильный способ упорядочения действий, требуемых для внедрения devops. Каждый читатель книги будет использовать уникальную последовательность этапов внедрения devops, решать собственные проблемы и устранять возникающие при этом конфликты. Эта книга состоит из нескольких частей. В части I рассматривается общая картина, которая детализируется до уровня идей, определений и принципов, имеющих отношение к devops. В частях II–V рассматриваются четыре фундаментальные концепции, лежащие в основе эффективного внедрения devops. В части VI завершается дискуссия, посвященная построению связей между отдельными людьми, группами и организациями. • Часть I. «Основы devops». • Часть II. «Сотрудничество». • Часть III. «Близость». • Часть IV. «Инструменты». • Часть V. «Масштабирование». • Часть VI. «Объединение культур devops». Части II–V завершаются главой, в которой обсуждаются различные заблуждения, относящиеся к той или иной концепции, лежащей в основе внедрения devops. В этой главе также рассматриваются некоторые универсальные сценарии по устранению неполадок, относящиеся к данной теме. Читатели, занимающиеся внедрением devops в своих организациях, в главе «Заблуждения и устранение проблем» найдут также ряд практических советов, которые будут полезными в работе. Читатели, предпочитающие общество компьютера, а не живого человека, могут испытать соблазн пропустить материал, описывающий межличностное взаимодействие и культуру общения. Это нецелесообразно, поскольку данный материал дает представление о принципах совместной работы, включая межкультурное и технологическое взаимодействие, благодаря которому увеличивается степень эффективности devops. Читайте главы книги в наиболее удобном для себя порядке, действуйте в стиле «выбор своего собственного приключения». Концепции, заложенные в основу devops, переплетаются и тесно связаны между собой, поэтому при чтении книги вы будете неоднократно возвращаться к ранее прочитанному материалу, чтобы освежить в памяти ту или иную концепцию. Методология практик На протяжении всей книги вы будете знакомиться с рассказами сотрудников разных компаний. Эта информация была получена в процессе проведения интервью с людьми, находящимися на разных уровнях организаций, на основании сообщений, опубликованных в блогах, из презентаций и заявок на регистрацию компаний. В то время как тема для каждой главы информирует о направлении практик, природа devops приводит к тому, что каждое тематическое исследование затрагивает несколько, если не все четыре концепции, лежащие в основе devops. Также вниманию читателей представляется комбинация более формальных практик, неформальных историй и нашего личного опыта. Все это делается в целях демонстрации разнообразия способов, посредством которых devops может оказать влияние на принятие решений и нарративы. Прочитайте истории, представленные в следующих главах. Распознайте истории, имеющие отношение к вашей организации. Ответьте на вопрос о том, что влияет на ваши группы и информирует их. Поделитесь вашими историями на корпоративных или общих встречах. Прислушивайтесь к историям о внедрении devops от других людей. Соглашения, используемые в книге В книге приняты следующие типографские соглашения: Курсив Используется для обозначения новых терминов, адресов URL, адресов электронной почты, имен файлов и расширений. Моноширинный шрифт Применяется для оформления листингов программ и программных элементов внутри обычного текста, таких как имена переменных или функций, базы данных, типы данных, переменные среды, инструкции и ключевые слова. Моноширинный полужирный шрифт Обозначает команды или другой текст, который должен вводиться пользователем. Моноширинный наклонный шрифт Обозначает текст, который должен замещаться фактическими значениями, вводимыми пользователем или определяемыми из контекста. Использование примеров кода У книги есть сайт, где можно найти список опечаток, дополнительные истории и другой сопутствующий материал. Все это доступно по следующему адресу: http://effectivedevops.net. Эта книга призвана помочь вам в решении задач. По большей части вы можете использовать код из книги в своих программах и документации. Вам не нужно связываться с нами по поводу получения разрешения на это, если только вы не начнете копировать достаточно существенные фрагменты кода. Например, написание программы, в которой используется несколько фрагментов кода из этой книги, не требует разрешения. А вот продажа или распространение компакт-дисков с примерами из книг издательства O’Reilly требует разрешения. Ответы на вопросы с использованием цитат из этой книги и приведением примеров не требуют получения разрешения. А вставка существенных объемов кода примеров из этой книги в документацию потребует разрешения. Мы приветствуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание названия, автора, издательства и ISBN. Например: «Философия DevOps. Искусство управления ИТ», Дженнифер Дэвис и Кэтрин Дэниелс (O’Reilly), 978–1-491–92630-7». За получением разрешения на использование значительных объемов программного кода примеров из этой книги обращайтесь по адресу permissions@oreilly.com. Safari® Books Online Safari Books Online – это виртуальная библиотека, содержащая авторитетную информацию в виде книг и видеоматериалов, созданных ведущими специалистами в области технологий и бизнеса. Профессионалы в области технологий, разработчики программного обеспечения, веб-дизайнеры, а также бизнесмены и творческие работники используют Safari Books Online как основной источник информации для проведения исследований, решения проблем, обучения и подготовки к сертификационным испытаниям. Библиотека Safari Books Online предлагает широкий выбор продуктов и тарифов для организаций, правительственных и учебных учреждений, а также физических лиц. Подписчики имеют доступ к поисковой базе данных, содержащей информацию о тысячах книг, видеоматериалов и рукописей от таких издателей, как O’Reilly Media, Prentice Hall Professional, Addison-Wesly Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, и сотен других. За подробной информацией о Safari Books Online обращайтесь по адресу: http://www.safaribooksonline.com/. Благодарности Написание книги Философия DevOps. Искусство управления ИТ было бы невозможным без помощи и содействия со стороны многих друзей, коллег и членов семьи. Мы хотели бы выразить благодарность всей команде издательства О’Reilly, особенно Кортни Нэшу (Courtney Nash), который всячески стимулировал нас на написание книги. Мы благодарны нашему редактору, Брайану Андерсону (Brian Anderson), оказавшему нам безусловную поддержку. Мы также благодарны сотрудникам издательства, которые помогли выбрать тотемных животных для книги и которые благословили нас на использование изображения волосатого яка в качестве символа книги. Мы также благодарны всем тем, кто помог нам написать эту книгу. Мы также признательны Джону Оллспоу (John Allspaw), Ларе Хоган (Lara Hogan) и Джону Кови (Jon Cowie) из Etsy; Николь Форсгрен (Nicole Forsgren) и Ивонн Лам (Yvonne Lam) из Chef; Бриджит Кромхаут (Bridget Kromhout) из Pivotal; Тому Лимончелли (Tom Limoncelli) из Stack Exchange за помощь, поддержку и вдохновение. Спасибо участникам наших тематических исследований: Алексу Ноберту (Alex Nobert), Бриджит Кромхаут (Bridget Kromhout), Тиму Гроссу (Tim Gross,) Тине Донбек (Tina Donbeck) и Федре Маршалл (Phaedra Marshall). Спасибо всем, кто поделился своими историями, в том числе Давиде Марион (Davida Marion), Линде Лаубенхаймер (Linda Laubenheimer), Холли Кей (Hollie Kay), Николь Джонсон (Nicole Johnson) и Элис Голдфасс (Alice Goldfuss). Спасибо нашим техническим рецензентам, которые помогли довести текст книги до совершенства: Элис Голдфасс (Alice Goldfuss), Дастину Коллинзу (Dustin Collins), Эрнсту Мюллеру (Ernest Mueller), Мэтью Скэлтону (Matthew Skelton), Оливье Жаку (Olivier Jacques), Бриджит Кромхаут (Bridget Kromhout), Ивонн Лам (Yvonne Lam) и Питеру Нилону (Peter Nealon). Спасибо Энди Парофф за Эда, нашего великолепного яка, изображение которого красуется на сайте и на обложке. Благодарности от Кэтрин Спасибо руководству Etsy за предоставленную мне возможность работать над книгой, выступать на множестве конференций и за великолепное место для работы. Дополнительные благодарности хочу выразить команде веб-поддержки за помощь и проявленное во время осуществления проекта терпение. Благодаря работе с вами я никогда не забывала о том, за что я люблю эту работу. Я хочу выразить особую благодарность Майку Римбетси (Mike Rembetsy), который ни разу мне не сказал «нет» в ответ на мои вопросы, Джону Оллспоу (John Allspaw) за вдохновение и веру в мои силы, а также Лори Диннесс (Laurie Denness) и Джону Кови (Jon Cowie) за предоставленную поддержку и информацию, которые помогли мне повысить квалификацию как инженеру службы поддержки. Спасибо Лоре Хоган (Lara Hogan), Бриджит Кромхаут (Bridget Kromhout), Хэйт Хьюстон (Cate Huston) и Меллисе Сантос (Melissa Santos) за то, что они отличные друзья, великолепные ролевые модели и просто веселые девушки. Благодаря знакомству и беседам с вами я черпала силы даже в безнадежных ситуациях. Ваша поддержка просто бесценна. Спасибо Джеймсу Тернбуллу (James Turnbull) за общение в Твиттере все эти годы, благодаря которому я попала в сообщество профессионалов в области технической поддержки. Я ценю знакомство с вами, вашу поддержку, мудрость и вдохновение на писательский труд. Спасибо Джейсону Диксону (Jason Dixon) за высланное мне первое приглашение на конференцию. Он был убежден, что мне есть что сказать на конференции, хотя я тогда совсем не была уверена в этом. Спасибо сообществу профессионалов в области техподдержки и devops-сообществу в целом, и особенно сообществу профессионалов в области техподдержки из Нью-Йорка за предоставленную помощь, новые возможности и друзей, вместе с которыми можно наслаждаться великолепным пивом Sysdrink. Спасибо Дженнифер Дэвис, моему лучшему другу, напарнику на конференциях и соавтору. Мозговой штурм, написание книги, общение, обучение и редактирование вместе с тобой стало удивительным приключением для меня. Я очень рада, что довелось поработать с тобой. И наконец, спасибо моей маме за поддержку, поощрение и веру в мои силы. Написание этой книги было бы невозможным без преданной любви и поддержки моих кошек, которые мурлыкали и грели меня в процессе написания книги. Благодарности от Дженнифер Спасибо Chef за предоставленные возможности многому научиться у различных организаций, а также за поддержку совместного обучения в форме бесед и тренингов. Спасибо всем женщинам, работающим в данной области, которые изменяют способы работы путем внедрения новых подходов, а также приемлемых форм и норм поведения. Ваш голос непременно будет услышан. Продолжайте обмениваться опытом и обращаться за необходимой поддержкой. Спасибо devops-сообществу в целом, которое вновь пробудило во мне желание стать его частью. Члены этого сообщества разработали систему поддержки и поощряют устойчивые практики на рабочих местах. Спасибо всем людям, которые поделились своими личными историями и опытом. Спасибо Ивонн Лам (Yvonne Lam), Бриджит Кромхаут (Bridget Kromhout), Доминике Де Грандис (Dominica DeGrandis), Мэри Грейс Ченгволл (Mary Grace Thengvall), Эми Скаварда (Amye Scavarda), Николь Форсгрен (Nicole Forsgren) и Шери Элджин (Sheri Elgin) за проявление поистине бесценных дружеских чувств. Ваше мнение и поддержка помогли мне многое понять и выработать свою собственную точку зрения на разные вещи. Благодаря вашей помощи я стала активнее и сильнее. Спасибо Кэтрин Дэниелс (Katherine Daniels), моей подруге и соавтору, за вдумчивые и вдохновляющие часы, проведенные в размышлениях. Она постоянно вдохновляла меня на писательский труд и редактирование ранее написанного текста. Мы прошли вместе все этапы этого проекта, иллюстрируя на практике мысли по поводу devops. Для меня было большой честью работать с тобой над книгой, посвященной devops. Спасибо моей бабушке, учителю начальной школы Frances Wadsworth Hayes, которая вдохновляла меня делиться своими историями и учиться на протяжении всей жизни. Эта книга никогда бы не появилась на свет, если бы не любовь и поддержка моей семьи, Брайана Бреннана и Джорджа. От издательства Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение! Подробную информацию о наших книгах вы найдете на веб-сайте издательства: http://www.piter.com. Часть I. Основы devops Глава 1. Первое знакомство По сути devops – это способ мышления и работы. Это своего рода каркас, служащий для того, чтобы делиться историями и развивать эмпатию. Благодаря devops отдельные люди и группы могут эффективно и непрерывно развивать свои навыки. Это часть культурной «ткани», которая формирует способы выполнения работы, а также создает мотивацию для этой работы. Многие представляют devops как некий набор специфических инструментов, таких как Chef или Docker, но на самом деле devops не ограничивается ими. Инструменты превращаются в «devops» благодаря способу их применения, а не в силу характеристик самих инструментов. Помимо используемых на практике инструментов, не менее важную часть культуры devops составляют ценности, нормы и знания. Благодаря исследованию рабочего процесса, технологий, применяемых в работе, и влияния этих технологий на работу в целом облегчается принятие специальных решений, относящихся как к ландшафту наших организаций, так и к ландшафту сектора экономики в целом. Обратите внимание, что devops – это не просто еще одна методология разработки ПО. Несмотря на то что devops связан и даже в какой-то мере зависит от таких методик разработки ПО, как Agile или XP, а devops-практики могут включать способы разработки или такие средства, как автоматизация инфраструктуры или непрерывная доставка, на самом деле devops – это нечто большее, чем просто сумма составных компонентов. Хотя вышеупомянутые концепции связаны и часто реализуются в devops-средах, сосредоточение исключительно на них приведет к тому, что вы пропустите самое главное – культурные и межличностные аспекты, которые придают devops его мощь. Культура развертывания ПО Что же нужно для формирования успешной культуры развертывания ПО? Чтобы продемонстрировать факторы, влияющие на успех культуры, рассмотрим совокупность людей, процессов и инструментов, сформированную в Etsy. Эта компания представляет интерактивный глобальный рынок товаров ручной работы, а также винтажных товаров. Мы выбрали в качестве примера Etsy не только потому, что этот бренд хорошо известен в отрасли своими техническими и культурными практиками. Основная причина выбора этой компании заключается в том, что Кэтрин – опытный сотрудник компании Etsy, который может компетентно судить о сформированной в этой компании культуре. Инженер, принятый на работу в Etsy, начинает свой первый рабочий день за ноутбуком, на котором установлена подготовленная виртуальная машина для ведения разработки. Для него уже созданы соответствующие учетные записи, позволяющие подключиться к этой машине и пройти авторизацию. Склонированы наиболее популярные репозитории GitHub, предварительно созданы системные ссылки и указатели для соответствующих инструментов. Также на рабочем столе новоиспеченного инженера имеется руководство, включающее ссылки на другие корпоративные ресурсы. Благодаря стандартизации инструментов и применяемых практик для различных групп облегчается подключение к процессу новых людей, независимо от того, в состав какой группы они входят. Каждая команда также может настроить применяемые инструменты и практики на свое усмотрение. К новому сотруднику прикрепляется опытный специалист, который знакомит новичка с процессами разработки и тестирования ПО, ежедневно применяемыми в организации. Новый сотрудник начинает создавать код на локальной виртуальной машине, предназначенной для разработки программ. С помощью модуля управления конфигурацией среда виртуальной машины настраивается таким образом, что становится практически идентичной реальной производственной среде. В результате можно выполнять и тестировать код локально. Это дает возможность быстро выполнять работу и вносить необходимые изменения, не привлекая опытных специалистов из группы разработчиков в качестве консультантов. Путем запуска набора локальных модулей и функциональных тестов инженеры Etsy могут с большой долей вероятности гарантировать работоспособность внесенных в ПО изменений на локальном уровне. Также они могут протестировать изменения на отладочном сервере. При этом используется Jenkins-кластер, который практически идентичен производственному кластеру непрерывной интеграции (CI). К тому же Jenkins-кластер обладает дополнительным преимуществом: для перехода к мастер-ветви не нужен дополнительный код. После успешного прогона тестов инженеры получают дополнительные гарантии того, что изменения не приводят к нарушению работоспособности тестов. В зависимости от масштаба и сложности изменений новый инженер может отправить запрос на принятие изменений кода или попросить кого-либо из коллег просмотреть код. Эта процедура не является обязательной для каждого изменения и зачастую осуществляется на усмотрение сотрудника. В среде Etsy, которой присуща высокая степень доверия и где отсутствует практика напрасных обвинений, сотрудникам предоставляется право принимать решение о необходимости просмотра кода. Новым или менее опытным сотрудникам предлагаются рекомендации, помогающие идентифицировать изменения, заслуживающие просмотра кода, а также определить, кто именно должен заниматься этой работой. Поскольку в то время Кэтрин только что приняли на работу в Etsy, более опытный коллега просматривал внесенные ею изменения перед выполнением развертывания этих изменений. После прохождения внутренних и пробных тестов разработчик присоединяется к очереди магазинного типа Etsy, чтобы выполнить развертывание изменений в производственной среде. Если несколько разработчиков готовы развернуть изменения одновременно, для координирования развертывания изменений в системе управления очередью используется Internet Relay Chat (IRC) и IRC-бот. Как только подходит очередь Кэтрин, она подтверждает изменения в мастер-ветви репозитория, в которой она работает. Для развертывания изменений на сервере QA в Etsy используется среда Deployinator. Благодаря применению этой среды выполняется автоматическое создание QA-сервера и выполняется полный набор тестов CI. После успешного завершения создания QA-сервера и прогона тестов Кэтрин выполняет быструю ручную проверку QA-версии сайта и журналов, чтобы идентифицировать проблемы, которые не были обнаружены в результате выполнения автоматизированных тестов. На этом этапе Кэтрин также использует среду Deployinator, чтобы развернуть код на производственной платформе и убедиться в отсутствии проблем с тестами и журналами. Если же в результате выполнения тестов проблемы не идентифицированы, выполняется дополнительная проверка с помощью одной из многочисленных графических панелей либо программы мониторинга Nagios. В случае обнаружения проблем с помощью этих средств пользователи получат соответствующее уведомление. Помимо этого, во многих группах выполняются собственные проверки, реализуемые в запланированном режиме с помощью Nagios. В результате обеспечивается слаженная работа всех членов группы. Если даже возникают какие-то проблемы, коллеги работают совместно над их устранением, учатся на своих ошибках, не обвиняя других постфактум в возникших проблемах. Процесс развертывания кода настолько хорошо оптимизирован, что на его выполнение тратится около 10 минут в среднем (от начала до завершения), и инженерный персонал Etsy проделывает эту операцию до 60 раз в день. Благодаря наличию документации и наставничеству опытных сотрудников, объясняющих подробности процесса, начинающий инженер запускает код в производство за один день. Даже сотрудники, не относящиеся к инженерному персоналу, поощряются к участию в процессе в рамках программы First Push Program. Под руководством инженеров они развертывают небольшие изменения, такие как публикация фотографий на странице персонала веб-сайта. Помимо использования для регулярного развертывания ПО, процессы тестирования и Deployinator могут применяться для развертывания чего угодно – от инструментов, применяемых разработчиками для построения виртуальных машин, до панелей Kibana, применяемых для поиска журналов, от проверок программы мониторинга Nagios до самого процесса Deployinator. Эволюция культуры развертывания ПО История с компанией Etsy резко контрастирует с практикой, которая имела место еще несколько лет назад. В те времена применялся менее прозрачный и более подверженный ошибкам процесс развертывания, который занимал до четырех часов. Разработчики вместо виртуальных машин использовали физические блейд-серверы. Но эти серверы были недостаточно мощными для выполнения полного набора автоматизированных тестов. Для полного прогона тестов, выполняемого в рабочей среде, требовалась пара часов, и даже это не гарантировало хорошего результата. Группы, сформированные в инженерной организации, были разрознены. Многие разработчики имели склонность «перебрасывать» код через «метафорические стены» эксплуатационной группе, которая несла исключительную ответственность за мониторинг и поддержку этого кода. В результате появлялась склонность к слишком частому изменению кода. Разработчики создавали код, вызывали на выполнение вручную написанные сценарии, чтобы создать новую SVN-ветвь. При этом развертывание выполнялось с помощью средства svn merge. Этот довольно сложный в применении инструмент применялся для слияния всех изменений, выполненных разработчиками, в одной ветви развертывания. Затем разработчики сообщали об используемой ветви инженеру из службы эксплуатации, наделенному полномочиями по выполнению развертывания ПО. Как видите, процесс развертывания был весьма кропотливым и занимал много часов (рис. 1.1). По причине сложности этот процесс выполнялся раз в две-три недели. Как и следовало ожидать, сложный и длительный процесс развертывания ПО в конце концов надоел исполнителям. Они поняли, что нужно что-то менять. Ситуация с развертыванием ПО настолько ухудшилась, что дальше уже просто некуда. Тем более что в организации работало много умных, талантливых и мотивированных людей, которые начинали разочаровываться в возможности решения проблем. Они обратились за разрешением к исполнительному и техническому директорам, которые имели ключ к ресурсам, требуемым для выполнения необходимых изменений. Образно говоря, инженер из эксплуатационной службы передал «ключи от царства развертывания» двум разработчикам, которым было предоставлено время и ресурсы на внесение нужных изменений в процесс развертывания. Как говорится, если есть молоток, то все, что нас окружает, может исполнять роль гвоздей, ну а если в вашей организации работает разработчик веб-приложений, возникает острая необходимость в создании таких приложений. Именно таким образом и появилось первое приложение Deployinator (рис. 1.2). Изначально это приложение представляло собой веб-оболочку, в которую заключался сценарий оболочки. Со временем благодаря усилиям многих пользователей это приложение было серьезно улучшено. Причем интерфейс остался практически без изменений, значительным изменениям подверглись внутренние механизмы. Рис. 1.1. До появления среды Deployinator процесс развертывания был сложным и полным ошибок Рис. 1.2. После появления среды Deployinator пользователи получили доступ к простому веб-интерфейсу, доступному каждому Очевидно, что наделение персонала полномочиями по созданию инструментов, упрощающих развертывание, значительно упрощает всю дальнейшую работу. Процесс развертывания стал «прозрачным» и значительно упростился. Тесты прошли путь от хаотичных и требующих много времени инструментов до средств, помогающих выявлять ошибки. Благодаря появлению журналов, графиков и предупреждений даже неквалифицированные пользователи получили возможность видеть результаты выполненных изменений. Ключевой вывод, который можно сделать на основании историй со всеми перечисленными инструментами, заключается не столько в специфике этих инструментов, сколько в том, чтобы кто-то понял, что эти инструменты должны быть созданы и что на это потребуются время и ресурсы. Чтобы создать необходимые инструменты и сформировать культуру их применения, общего доступа и сотрудничества, требуется вовлеченность со стороны менеджмента, свобода экспериментов, работа с кодом, невидимым для заказчиков, и доверие между разными группами разработчиков. Благодаря этим факторам компания Etsy превратилась в так называемого единорога devops (хотя они предпочитают называть себя «лошадью в блестках»). И эта компания старается поддерживать соответствующую культуру на всех внутренних уровнях. Пример с этой компанией олицетворяет наше определение эффективных devops-практик, реализованных в организации. В результате применения этих практик вносятся изменения в культуру, которые влияют на то, как отдельные сотрудники думают о работе. Также оцениваются разные роли, присущие сотрудникам, ускоряется рост ценности бизнеса и измеряется эффект, вызванный изменениями. Именно devops-практики помогли Etsy перейти из состояния фрустрации и изоляции в состояние успешного производства, построенного на основе сотрудничества, и воспитать разработчиков инструментов. Примеры использования подобных руководящих принципов мы уже видели в историях успеха компаний, работающих в этой отрасли. Подобные истории могут использоваться в качестве руководства к действию компаниями, которые хотят реализовать у себя подобные трансформации. Истории пути к успеху Все мы думаем на языке наших собственных мыслей. А делимся концепциями.     – Стивен Тулмин. Человеческое понимание Эта книга включает тематические исследования и истории, рассказанные группами и отдельными людьми. Если же обратиться к существующим книгам, посвященным devops, то вы обнаружите, что в них описываются инструменты и абстрактные культурные практики, а историям из реальной жизни уделяется не столь много внимания. Одно дело говорить о том, как что-то должно работать, в теории, и совсем другое – реализовать это на практике. Мы хотим поделиться с вами историями применения теоретических знаний на практике, рассказать о том, что было сделано, а что не сделано, поделиться идеями, лежащими в основе принятия решений. Это позволит вам получить максимум информации, применяемой в процессе внедрения практик devops. История Кэтрин Моя история, связанная с devops, началась во времена зарождения движения devops. Я совершила резкий поворот в своей карьере в сторону эксплуатации сразу же после формализации идеи devops и проведения первых конференций devopsdays. Я выступала в роли эксплуатационной группы, состоящей из единственной женщины, которая работала в маленьком стартапе, развернутом в пространстве электронной коммерции. И я для себя открыла, что мне нравится эксплуатационная работа. И даже несмотря на то что я на протяжении столь длительного времени работала в одиночестве, идеи devops не лишены для меня смысла. Эти идеи основаны на здравом рассуждении, поскольку обеспечивают более эффективную работу с другими частями организации, не относящимися к вашей группе. В те времена я была рядовым системным администратором, проводившим свои дни в дебрях центра обработки данных. Я была единственным сотрудником по вызову и была столь занята борьбой с унаследованными «пожарами», что практически не представляла, чем занимаются разработчики (либо кто-либо другой, если это имеет значение). Поэтому идеи разделения обязанностей и информации, а также разрушения барьеров между командами действительно имеют для меня значение. Некоторые организации более восприимчивы к изменениям и новым идеям, чем другие. Но помимо того, что мой стартап совершенно не подвергался изменениям, руководство не желало прислушиваться к высказываниям юного системного администратора. Чтобы не прислушиваться к моим идеям, мне просто говорили следующее: «Ты не настоящий системный администратор». И у них даже не было денег, чтобы купить мне пару книг. Мне пришлось самой купить книги Тома Лимончелли Practice of System and Network Administration и Time Management for System Administrators. Я уже молчу о том, что мне не светило попасть на конференции LISA, Velocity и на devopsdays (Нью-Йорк) в ближайшие несколько лет. К счастью, я начала искать devops-сообщества в Интернете и оказалась в состоянии общаться и учиться у людей, которые разделяли мою увлеченность вопросами эксплуатации. Благодаря совместной учебе и работе я просто воспряла духом. Джеймс Тернбулл, который в настоящее время является техническим директором компании Kickstarter, в то время работал в компании Puppet. Он нашел меня в Твиттере, завязал со мной разговор и отправил мне копию своей великолепной книги Pro Puppet. Это случилось в тот момент, когда я сражалась с 200 унаследованными серверами от компании Snowflake, не располагая даже простейшим bash-сценарием для управления этими серверами. Благодаря этой книге я познакомилась с растущим и процветающим сообществом людей, которые подарили мне надежду на то, что в один прекрасный день я смогу стать членом этого сообщества. Как отмечает в своей истории Дженнифер, трудно добиться изменений, если вы уже «выгорели». Если уже прошел год в бесплодных попытках изменить и улучшить родную компанию, но меня никто не слушает в силу отсутствия опыта, хотя он растет каждый день. И я сделала выбор и пошла дальше. Я продолжала учиться и совершенствовать свои навыки, но все еще не чувствовала себя полностью сроднившейся с рабочим местом. Мне все казалось, что я сражаюсь со своими коллегами и организациями, вместо того чтобы работать с ними. В январе 2013 года я попала на свою первую конференцию devopsdays (Нью-Йорк). Я впитывала как губка все разговоры и пыталась слушать как можно больше, даже если понимала, что вряд ли смогу что-либо добавить к сказанному. Я жила под воздействием хэштега #VelocityConf в Твиттере. В октябре того же года у меня было короткое выступление на второй конференции devopsdays (Нью-Йорк), на которой я встретилась с Майком Римбетси, одним из организаторов конференции. Он пригласил меня работать в Etsy, но я подумала, что он шутит, поскольку не считала себя профессионалом в этой области. Я следовала кодексу Code as Craft и придерживалась практики эксплуатационной группы Etsy в Интернете с тех пор, как открыла для себя devops-сообщества, но я не считала себя столь профессиональной, чтобы присоединиться к ним. Когда я поняла, что ошибалась, меня просто переполнило счастье. Моя карьера в области эксплуатации началась как путешествие через несколько разных организационных структур и способов разработки, эксплуатации, а иногда даже через группы «devops», с которыми я работала. Располагая опытом работы с такими компаниями, как стартап, состоящий из 25 человек, и огромная корпорация, существующая десятки лет на рынке, с сотней тысяч сотрудников, я видела множество в разной степени эффективных способов разработки и поставки программных продуктов и систем. Имея опыт работы специалиста по вызову, доступного 24 часа в сутки и 7 дней в неделю большую часть года, и будучи знакомой с иными сценариями работы, далекими от идеального, я хочу поделиться с читателями книги приемами и методами, которые успешно применяются мной и членами моих групп. С помощью этих методик удалось снизить количество сотрудников, считающих себя «слабым звеном» в своей организации. В большой степени мотивация к написанию этой книги представляла собой возможность поделиться историями с читателями, историями, которые имели ко мне отношение или были рассказаны другими людьми. Это дает возможность делиться знаниями с другими пользователями, учиться и расти как сообщество. Именно devops-сообщество помогло мне занять мое нынешнее место, и эта книга представляет собой лишь один из способов возврата долга с моей стороны. История Дженнифер В 2007 году я связалась с руководством Yahoo по поводу позиции, которая относилась «немного к разработке» и «немного к эксплуатации». Речь шла о вакансии старшего сервисного инженера, ответственного за создание и обслуживание мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных типа «ключ/значение» под названием Sherpa. В качестве сервисного инженера в Yahoo я совершенствовала свои навыки в программировании, поддержке и в управлении проектами. Я работала вместе с группами по разработке и обеспечению качества Sherpa, координировала усилия с командами центров обработки данных, группами по поддержке сетей и хранилищ данных, а также группами обеспечения безопасности. В 2009 году, когда слухи о devops проникли в Yahoo, я знала реальную цену этой методики, поскольку фактически ею овладела! Летом 2011 года Джефф Парк принял на себя бразды правления моей группой. Он помог взрастить группу профессионалов, благодаря чему у нас появилось несколько сервисных инженеров в США и в Индии. Этого было недостаточно, и Джефф беспокоился о том, что мне приходилось работать в непрерывном режиме, практически в одиночестве оказывая сервисные услуги. Он также проявлял беспокойство по поводу бизнеса и хотел добавить больше отказоустойчивости в модель эксплуатации путем найма избыточного персонала. В декабре этого же года он посоветовал мне взять настоящий отпуск, не читать электронную почту и отключить мобильный телефон. В ответ я заявила ему, что чувствую, как будто бы что-то происходит неправильно, что-то работает не так, как ожидалось. Он сказал, что просто уволит меня, если я не уйду в отпуск. При этом он заверил меня, что все будет хорошо. И вечером накануне отпуска я настроила простую визуализацию соответствующих метрик с помощью сценария JavaScript и Perl, управляемого с помощью cron. Я посчитала, что этого будет достаточно, поскольку в случае возникновения каких-либо проблем отображались соответствующие уведомления. После возвращения из отпуска я столкнулась с полной деградацией сервиса. Множество мелких проблем, с которыми я встречалась ранее, вылились в неприятный результат. Причем отладка была в значительной степени затруднена именно по причине большого количества этих проблем. Я столкнулась с полным провалом, несмотря на то что наспех состряпанная визуализация позволяла выявлять и отслеживать возникающие проблемы. Джефф отвел меня в сторонку и заявил о том, что знал о существовании высокого риска возникновения сбоев во время моего отпуска. Также имели место дополнительные риски, связанные с тем, что моя группа полностью полагалась на меня. Мой героизм на работе помогал маскировать сбои, присущие системе. Он сказал, что иногда неудачи, имеющие место в краткосрочной перспективе, превращаются в достоинства (в долгосрочной перспективе), если делать верные выводы. Если что-то выходит из строя, это поможет установить приоритет критичности для процессов общего доступа, документирования и распространения знаний и опыта в бизнесе. В конечном счете это приведет к достижению большей стабильности и улучшению показателей как для организации в целом, так и для отдельных сотрудников. Это событие сплотило эксплуатационную группу Sherpa, поскольку мы попытались скорректировать сервис и понять, что же произошло. Мы разделились на кросс-функциональные группы в целях устранения разных компонентов проблемы: обработчики сбоев, коммуникационная группа, инструментальная группа и группы по мониторингу и очистке. Также всегда были доступны ключевые менеджеры, готовые к принятию жестких решений. Эти решения помогут сократить время простоя. Сбои – это ужасно, но они чему-то учат.     – Боб Саттон, инструктор из Stanford Management Основной урок, вынесенный мной из этого события, заключался в признании ценности сбоя. Не нужно бояться потерпеть неудачу, просто следует извлекать уроки из провалов. Мы собирались на регулярные совещания для оперативного решения вопросов, вызванных неприятными событиями. Мы продолжали устранять проблемы как межотраслевая группа, а не как группа сервисного инжиниринга. Мы способствовали возникновению дискуссий между потребителями и поставщиками услуг, которые помогли бы в выявлении слабых мест в системе. Потратив более десяти лет на создание рабочих практик, основанных на примитивной культуре эксплуатации, заключающейся в долгих часах ожидания, изоляции проблем и избегании сбоев системы, я так и не смогла добиться нужных изменений. Я была готова к внедрению devops. Для меня ценность devops заключалась не в мантре «разрабатываем X и поддерживаем Y, либо разработка и поддержка», а в том, чтобы делиться историями, решать проблемы, возникающие в производстве, на основе принципов сотрудничества и укреплять ряды сообщества. Открытая среда для совместной работы превратилась в новую систему поддержки, которая укрепила основы устойчивых рабочих практик и способствовала развитию взаимоотношений между людьми. Сотрудничество с Кэтрин при написании этой книги способствовало углублению моего понимания devops. Возможность делиться рабочими стратегиями и методиками со всего мира, которые полезны для создания и улучшения рабочих практик, превращается в захватывающее путешествие. И это путешествие не завершается после того, как прочитана последняя страница книги. Мы все получаем опыт каждый день, поскольку имеем разные точки зрения на все, что происходит вокруг нас. Независимо от того, находитесь вы в начале карьеры, когда культурная трансформация только начинается, либо задумываетесь об изменении ролей и обязанностей, ваш опыт позволит делиться информацией и обучать других. И я с нетерпением ожидаю ваши истории, в которых я расставлю правильные акценты. Эта даст нам возможность расти как сообществу и вместе извлекать уроки из наших успехов и неудач. Истории, иллюстрирующие devops-практики Мы выбрали различные тематические исследования, чтобы проиллюстрировать разные способы проявления культуры эффективных devops-практик. Цель этих историй заключается не в предоставлении шаблонов, которым нужно точно следовать, слепо копируя структуру, используемую в другой организации, либо задействуя индивидуальные практики для всех обстоятельств и выбранных вариантов. Рассматривайте эти истории как иллюстрации или руководства к действию. Мы надеемся, что в процессе чтения этих историй вы увидите отражение нашего опыта – возможно, нынешнего, а возможно, опыта, который будет иметь место в будущем. Мы включили истории из разных источников, как формальные тематические исследования, так и неформальные личные рассказы. Здесь вы найдете истории, относящиеся к хорошо известным организациям. Но вместе с тем мы намеренно включили истории из менее известных источников, чтобы продемонстрировать все разнообразие существующих devops-практик. В процессе знакомства с результатами этих исследований не только учитывайте выбранные варианты и результаты этих выборов, но и принимайте во внимание возникшие обстоятельства и ситуации. Каково сходство между возникшими обстоятельствами и каковы ключевые отличия? Если вы сделали аналогичный выбор в вашей организации, какие факторы, уникальные для вашего рабочего места, могут повлиять на результат? Мы надеемся, что путем чтения и понимания этих историй вы сможете распознать лежащие в их основе темы и начать их применять в собственных devops-практиках. Обучение не должно ограничиваться рассказанными историями. Экспериментируйте с новыми процессами, инструментами, методиками и идеями. Оцените ваш прогресс и, самое главное, поймите причины происходящего. Как только вы начнете понимать, что получается, а что нет, вы сможете перейти к более сложным экспериментам. Глава 2. Определение devops Devops – это культурное движение, изменяющее отношение людей к работе и к ее результатам. Благодаря внедрению devops в организации формируются интенциональные процессы, ускоряющие эффективность бизнеса. Это способствует скорейшему появлению результата от социальных и технических нововведений. Благодаря новым способам мышления и работы отдельные сотрудники и организации могут развивать и поддерживать устойчивые рабочие практики. Devops представляет собой культурный субстрат, ускоряющий формирование эмпатии между коллегами и облегчающий обмен опытом. В результате закладывается прочный фундамент, обеспечивающий эффективное приложение усилий в процессе работы со стороны отдельных сотрудников и команд. Рецепт формирования культуры Devops является необходимым условием для формирования культуры, но не достаточным. Ни одно культурное движение в мире не существует само по себе, поскольку культура неразрывно связана с социальной структурой. На культуру оказывают влияние много факторов. Это иерархические структуры, сформированные внутри организаций, связи между организациями и эффекты, вызванные глобализацией. Также на формирование культуры воздействуют ценности, нормы, убеждения и артефакты, связанные с упомянутыми выше факторами. Например, программное обеспечение варьируется в зависимости от того, кто его разрабатывает и использует. Благодаря devops появились способы адаптации и совершенствования социальной структуры, культуры и технологии, что, в свою очередь, способствует более эффективной работе. Уравнение devops Существует опасность, что движение, которое расценивает себя как новое, будет пытаться охватывать все, что не является старым.     – Ли Рой Бич и др., Naturalistic Decision Making and Related Research Lines Не относитесь к этой книге как к сборнику рецептов, позволяющих реализовать единственно верный путь применения devops. Несмотря на то что мы будем упоминать часто используемые неверные представления и «антишаблоны», мы больше заинтересованы в описании внешних признаков и принципов внедрения успешной devops-культуры, а также способов применения этих принципов в разных организациях и средах. Хотя термин devops образован на основе слов «development» (разработка) и «operations» (эксплуатация), принципы devops могут и должны применяться на всех стадиях рабочего процесса, реализуемого в организации. Устойчивый и успешный бизнес представляет собой нечто большее, чем совокупность, состоящую из команд разработчиков и эксплуатации. Если же вы будете ограничиваться исключительно этими командами, вы окажете бизнесу, налаженному в вашей организации, «медвежью услугу». Использование «devops» в качестве народной модели В наши дни термин «devops» стал общеупотребительным и приобрел статус народной модели. Это обстоятельство может привести к определенному недопониманию и вызвать недоразумения. В когнитивистике под народной моделью понимают некую абстракцию, на основе которой формируются более конкретные идеи. В силу своей простоты народная модель используется в качестве замены обсуждаемых концепций. В качестве примера подобной модели может служить ситуационная осведомленность, которая заменяет более конкретные понятия, такие как восприятие и кратковременная память. Но не используйте народную модель в качестве неадекватной замены исходного понятия. Как правило, эти модели становятся непригодными в тех случаях, когда применяются не по назначению. Люди зачастую тратят много времени на споры о природе «devops». Они также обсуждают народные модели вместо того, чтобы сосредоточиться на идеях, представляющих собой реальную ценность[1 - Sidney Dekker and Erik Hollnagel, “Human Factors and Folk Models.” Cognition, Technology & Work 6, no. 2 (2004): 79–86.]. Порой для обхода проблем, вызываемых попытками точного определения devops, и стимулирования обсуждения соответствующих концепций и принципов преувеличивается значимость «плохого» поведения. Это делается для того, чтобы сконцентрироваться на «хорошем» поведении, которое подается в качестве «devops». Чтобы перейти к обсуждению эффективного сотрудничества в команде, можно воспользоваться примером фиктивной компании, в которой создана devops-команда. Эта команда выступает исключительно в качестве посредника между командами разработчиков и техподдержки (см. предисловие). Этот пример является в какой-то мере искусственным, но зато иллюстрирует более серьезные и практические концепции, чем обычные определения. Прежний и новый взгляд Если в компании складывается практика взаимных обвинений и преследований за совершенные ошибки, формируется атмосфера страха. В результате между сотрудниками компании появятся «стены», препятствующие общению. А теперь представьте себе идеальную среду, в которой все проблемы решаются сообща и расцениваются в качестве возможности для обучения как отдельных людей, так и организации в целом. Профессор Сидни Деккер в своей книге Field Guide to Understanding Human Error[2 - Sidney Dekker, Field Guide to Understanding Human Error (Farnham, UK: Ashgate Publishing Ltd, 2014).] характеризует эти ситуации как «прежний взгляд» и «новый взгляд» на человеческие ошибки. В первом случае «человеческие ошибки являются причиной появления проблем». «Прежний взгляд» описывается как способ мышления, в котором основной акцент делается на устранение человеческих ошибок. Ошибки вызываются «гнилыми яблоками», которые нужно выкинуть. Этот взгляд доминирует в культурах, основанных на взаимных обвинениях, поскольку предполагается, что ошибки часто порождаются злым умыслом или некомпетентностью. Люди, ответственные за ошибки, должны быть обвинены и пристыжены (либо просто уволены). Во второй среде «человеческие ошибки рассматриваются в качестве симптома более глубоких системных проблем». Этот «новый взгляд» соответствует образу мышления, в котором человеческие ошибки рассматриваются как следствие проблем, имеющих структурный, а не личный характер. Люди делают выбор и выполняют действия на основе собственного понимания ситуации. Они не совершают ошибки в силу злых намерений или некомпетентности. Чтобы минимизировать последствия ошибок или ответить на возникшие вопросы, нужно применять системный подход на уровне организации. «Новый взгляд» является ключом к пониманию движения devops. Этот взгляд поощряет нас делиться опытом, который представляет собой прекрасную возможность для обучения сотрудников. Если вы поделитесь опытом применения devops, то это: • приведет к увеличению степени прозрачности и доверия в группе; • поможет вашим коллегам понять, как избежать ошибок, чреватых серьезными потерями; • предоставит больше времени на решение новых задач, благодаря чему появятся дополнительные инновации. Как только истории об опыте применения devops станут всеобщим достоянием, они окажут влияние на отрасль в целом. В результате появятся новые возможности и знания, а также станет возможным обмен знаниями. Devops-пакт Подлинный devops-пакт имеет место только тогда, когда люди не просто работают вместе в одной группе, а формируют единую команду. Если участники команды постоянно сообщают друг другу о своих намерениях и возникающих проблемах и постоянно подстраиваются с учетом общих целей организации, формируется так называемый devops-пакт. Пример пакта Чтобы представить себе критически важный пакт, рассмотрим общение между двумя скалолазами, которое заключается в обмене информацией, уточнении спорных моментов и формировании взаимного доверия. Суть скалолазания заключается в перемещении по скалам и искусственным сооружениям в разных направлениях. Скалолазу нужно достичь верхней или конечной точки маршрута и не сорваться при этом. Для достижения этой цели понадобится как физическая выносливость, требуемая для решения возникающих проблем, так и умственная активность, необходимая для понимания сути проблемы и подготовки к выполнению следующих действий. Обычно в процессе скалолазания скалолаз, выполняющий восхождение (восходитель), использует трос и карабин для страховки от возможного падения. Напарник восходителя контролирует степень натяжения троса. Он должен натягивать его достаточно сильно во избежание падения, но в то же время давать слабину, необходимую для обеспечения свободы маневра. Обеспечение правильной и безопасной страховки требует от страхующего напарника как понимания используемых инструментов и процессов, так и обеспечения постоянной связи со скалолазом, выполняющим восхождение. Восходитель должен надежно прикрепить страховочный трос к карабину. Страхующему напарнику нужно убедиться в том, что страховочное устройство надежно закреплено с помощью карабина. Между скалолазами устанавливаются доверительные отношения, но прежде чем приступать к восхождению, нужно еще раз все проверить. При восхождении используется набор словесных ключей, позволяющих проверить готовность к процессу восхождения. Сначала восходитель спрашивает у напарника: «На страховке?» Напарник отвечает: «На страховке». Затем восходитель говорит: «Подъем!», сигнализируя о готовности к началу восхождения. И наконец, напарник подтверждает осведомленность о готовности восходителя, произнося слово «подъем». Для обеспечения работоспособности этого пакта применяются следующие принципы: • общие четко сформулированные цели; • непрерывное общение; • динамическая настройка и коррекция понимания. Как будет показано в следующих разделах, соблюдение этих принципов необходимо как для внедрения devops на рабочем месте, так и для успешного восхождения на горную вершину. Пример devops-пакта Представьте себе, что два сотрудника компании Sparkle Corp работают в разных командах. Сотрудник по имени Дженераль является старшим разработчиком, обладает множеством рабочих навыков и работает в компании Sparkle Corp уже два года. Джордж работает в отделе техподдержки, обладает некоторыми рабочими навыками и является новичком в компании Sparkle Corp. Команды, в которых работают эти два сотрудника, поддерживают глобальное сообщество людей, использующих сайт компании Sparkle Corp для реализации своих творческих начинаний. Общая цель, стоящая перед этими командами, заключается во внедрении нового средства, которое увеличивает ценность сайта компании для конечных пользователей, не оказывая на него негативного влияния. Обладая большим опытом работы в компании, Дженераль дает четкие указания Джорджу об ожиданиях, ценностях и процессах, имеющих место в компании Sparkle Corp. В свою очередь Джордж может в любой момент обратиться к Дженераль с просьбой о помощи или в случае непонимания какого-либо производственного нюанса. Прежде чем перейти к следующему этапу производственного процесса, Дженераль и Джордж контролируют результаты работы друг друга. Подобная проверка является примером модели «доверяй, но проверяй», используемой при описании процесса скалолазания. Как Дженераль, так и Джорджу присуще понимание общих целей: • внедрение нового инструмента, увеличивающего ценность для заказчиков компании Sparkle Corp; • поддержка безопасности и доверия при осуществлении взаимного обмена информацией. В изолированной среде, не использующей принципы devops, понимание общих целей отсутствует. Это может привести к тому, что, например, Дженераль попытается приступить к кодированию, не убедившись в том, что Джордж понял суть требований. В этом случае совместная работа возможна, но без обмена информацией о намерениях шансы на успех уменьшаются. Безусловно, в любой организации могут возникать неожиданные проблемы или препятствия, но при наличии общего понимания целей каждый сотрудник является частью пакта, а предпринимаемые действия направлены на выполнение текущего «ремонта». Мы «ремонтируем» наше недопонимание, связанное с выбором исполнителей работ по разработке конкретного инструмента или сроков выполнения работы. Мы устраняем ошибки, влияющие на наше понимание предполагаемого поведения программного обеспечения. Мы «ремонтируем» процессы и сопровождающую документацию, если дела в производственной сфере идут не так, как ожидалось. На протяжении всей книги мы будем использовать идею о devops-пакте. Мы также продемонстрируем, каким образом технологические и культурные аспекты devops становятся способами развития и поддержки общего взаимопонимания. Глава 3. История devops Чтобы лучше понять причины, которые привели к зарождению и развитию движения devops, нужно рассмотреть историю разработки ПО, а также повторяющиеся паттерны и идеи, применяемые в этой области. Вооруженные этими знаниями, мы можем представить, где находимся в данный момент. Мы осознаем, каким образом с помощью эффективных devops-способов можно разорвать порочный круг расширения специализации, приводящий к созданию изолированных сред и девальвации конкретных ролей. Разработчик в качестве оператора Изначально разработчик программ являлся оператором. На исходе Второй мировой войны правительство США обратилось к ведущим математикам с призывом создать «компьютеры». Эти устройства должны были применяться для расчета баллистических таблиц, используемых при стрельбе. На этот призыв откликнулись женщины-математики, и среди них была Джин Бартик. Она пренебрегла возражениями своего преподавателя колледжа, который считал, что решение повторяющихся задач не столь важно, как продолжить семейную традицию и получить классическое образование. Иногда полезно выслушать совет и сделать по-своему. Джин Бартик оказалась на нужном месте в нужное время и стала одним из первых программистов компьютера ENIAC. Используя анализ аппаратных и логических схем, Бартик и пять ее коллег-программистов смогли научиться программировать на компьютере ENIAC, и это при полном отсутствии сопровождающей документации. Программирование на этом компьютере, работающем на 18 тысячах радиолампах, осуществлялось путем вращения дисков и изменения кабельных подключений с помощью 40 управляющих панелей. В те времена для обеспечения работы компьютеров вместо программирования использовалась аппаратная инженерия. В случае возникновения проблем инженеры заявляли о том, что причина появления проблем заключается не в машине, а в операторе. Программисты несли на себе бремя ответственности за управление и эксплуатацию компьютеров. Им приходилось заменять предохранители и кабели, а также устранять синтаксические ошибки в программах. Появление программной инженерии В 1961 году президент США Джон Кеннеди провозгласил амбициозную лунную программу. В рамках этой программы в течение ближайших десяти лет должен был состояться полет человека на Луну с последующим благополучным возвращением на Землю. Учитывая сжатые сроки и отсутствие специалистов, которые могли бы создать необходимое программное обеспечение, NASA объявило о наборе профессиональных программистов. Проект NASA по разработке ПО возглавила математик из Массачусетского технологического института Маргарет Гамильтон[3 - Robert McMillan, «Her Code Got Humans on the Moon – And Invented Software Itself», WIRED, October 13, 2016.]. Как вспоминает Гамильтон: Процесс генерирования новых идей превратился в настоящее приключение. Везде царили самоотверженный труд и ответственность. Атмосфера взаимного уважения способствовала комфортной работе. Поскольку процесс разработки ПО носит мистический характер, являясь чем-то вроде «черного ящика», топ-менеджмент предоставил нам полную свободу и оказал абсолютное доверие. Мы должны были найти эффективный способ создания программ, и мы сделали это. Оглядываясь назад, я хочу сказать, что мы были счастливейшими людьми в мире. У нас не было другого выбора, кроме как стать первыми в мире, и не было времени на то, чтобы пребывать в состоянии «чайников»[4 - A. S.J. Rayl, «NASA Engineers and Scientists – Transforming Dreams Into Reality», 2008, http://www.nasa.gov/50th/50th_magazine/scientists.html.]. Поскольку Гамильтон была известна стремлением к созданию сложного программного обеспечения, ей приписывают создание термина программная инженерия. Она также разработала приоритетные дисплеи, программное обеспечение, предупреждающее астронавтов о наличии информации, которая требует реагирования в режиме реального времени. Маргарет разработала набор правил по сбору требований, один из пунктов которого заключался в обеспечении качества как одного из методов программного инжиниринга. Список методов программной инженерии включал следующие позиции: • отладка всех отдельных компонентов; • тестирование отдельных компонентов до этапа сборки; • интеграционное тестирование. В 1969 году во время осуществления миссии «Аполлон-11» произошел сбой бортового компьютера из-за большого объема выполняемых вычислений. Команда разработчиков предусмотрела возможность вмешательства астронавтов в процесс управления модулем в обход бортового компьютера. Это позволило Нейлу Армстронгу в критической ситуации взять управление лунным модулем на себя. Благодаря свободе и доверию, предоставленным менеджерами группе инженеров-разработчиков ПО, а также взаимному уважению, царившему в группе разработчиков, стало возможным создание программного обеспечения, способствующего достижению величайших технологических успехов, таких как высадка Нейла Армстронга на Луну. Если бы в среде разработки ПО отсутствовало взаимное доверие, вряд ли была бы реализована критически важная функция ручного управления лунным модулем. Если бы не эта функция, вряд ли лунная эпопея завершилась бы благополучно. ПРОБЛЕМЫ, СВЯЗАННЫЕ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ В 60-е годы XX века космические полеты были не единственной областью, в которой применялось программное обеспечение. По мере того как оборудование стало более доступным, начало вызывать тревогу постоянно усложняющееся программное обеспечение. Эта сложность не соответствовала стандартам, принятым в других инженерных дисциплинах. Быстрый рост сложности систем и возрастающая зависимость от них начали беспокоить пользователей. В 1967 году Научный комитет НАТО, в состав которого входили ученые из разных стран и отраслей промышленности, организовал проведение дискуссий, посвященных состоянию программной инженерии. Осенью 1967 года была сформирована исследовательская группа по компьютерным наукам. Цель этой группы заключалась в привлечении внимания к проблемам, связанным с программным обеспечением. Были приглашены 50 экспертов в разных областях, которые в составе трех рабочих групп сосредоточили внимание на разработке, производстве и поддержке программного обеспечения. При этом предпринимались попытки определить, описать и приступить к решению проблем в области программной инженерии. В 1968 году на конференции НАТО, посвященной программной инженерии, были сформулированы ключевые проблемы программной инженерии, перечисленные в следующем перечне: • определение и оценка степени успеха; • создание сложных систем, требующих больших инвестиций, с непредсказуемым внедрением; • разработка систем в соответствии с графиком и спецификацией; • оказание экономического давления на производителей, создающих определенные продукты. Благодаря идентификации этих проблем облегчается определение и формирование областей деятельности для отрасли на ближайшие годы. Появление закрытого программного обеспечения и стандартизация До 1964 года существовала практика создания компьютеров, которые были весьма специфичными и соответствовали требованиям конкретного заказчика. Оборудование и программное обеспечение были не стандартизованы и не взаимозаменяемы. В 1964 году компания IBM анонсировала семейство компьютеров System/360. Компьютеры, входящие в это семейство, имели разные размеры и предназначались для использования в коммерческих и научных целях. Благодаря созданию этого семейства компьютеров снизилась стоимость разработки, производства и обслуживания, в то же время клиентам стало проще обновлять оборудование по мере необходимости. Семейство мэйнфреймов System/360 заняло господствующее положение, обеспечивая своим пользователям возможность начать с использования небольших вычислительных ресурсов, а потом наращивать их по мере необходимости. Эти компьютеры также обеспечивали гибкость в работе, позволяя отдельным сотрудникам изучать возможности оборудования и программного обеспечения. При этом они получали необходимые рабочие навыки, которые могли успешно использовать в другом месте. Вплоть до конца 1960-х годов компьютеры использовались на условиях аренды. Это было связано с высокой ценой оборудования, программного обеспечения и сопутствующих услуг. Обычно предоставлялся исходный код для программного обеспечения, установленного на компьютере. После того как в 1969 году против американской компании IBM был подан антимонопольный иск, произошло разделение аппаратного и программного обеспечения и конкретных моделей компьютеров. В результате стала возможной раздельная покупка оборудования (мэйнфреймов) и программного обеспечения. Это привело к изменению подхода к программному обеспечению, которое приобрело денежную стоимость, что, в свою очередь, привело к прекращению распространения открытого программного кода. Сетевая эра В 1979 году появилась всемирная система групп новостей Usenet, которую создали студенты из Университета Дьюка Том Трескотт и Джим Эллис. Изначально Usenet представляла собой простой сценарий оболочки, который автоматически вызывал разные компьютеры, искал изменения в файлах, находящихся на этих компьютерах, а потом копировал изменения с одного компьютера на другой с помощью набора программ UUCP. Этот набор обеспечивал передачу файлов и выполнение команд на удаленных компьютерах. Эллис выступил с докладом Invitation to a General Access UNIX Network[5 - Ronda Hauben and Michael Hauben, Netizens: On the History and Impact of Usenet and the internet (Los Alamitos, CA: IEEE, 1997).] в группе пользователей Unix, известной как USENIX. Это был один из первых и быстро развивающихся способов коммуникации и обмена знаниями между организациями, имеющими компьютеры. Хотя этот инструмент способствовал обмену знаниями между университетами и корпорациями, в те времена многие детали, связанные с деятельностью компаний, были засекречены. Было не принято обсуждать проблемы за стенами офиса компании, поскольку подобная информация рассматривалась как конкурентное преимущество. На основе подобных сведений конкуренты могли делать выводы о неэффективности компании. Это привело к появлению барьеров на пути к сотрудничеству и к ограничению эффективности доступных коммуникационных каналов. Подобная культурная изоляция приводила к появлению сложностей на пути к росту компаний. Появление все более сложных систем, в свою очередь, привело к неизбежности специализации навыков и к распределению ролей. Подобные роли включали системных администраторов, специализирующихся в области управления системами и минимизирующих затраты на поддержку систем, а также инженеров-программистов, которые специализировались на создании новых продуктов и возможностей для удовлетворения вновь возникающих потребностей. Также завершилась изоляция других, более специализированных групп, таких как сетевой операционный центр, отдел обеспечения качества, отдел безопасности, отдел поддержки баз данных и хранилищ данных. Подобная ситуация привела к формированию институционной Вавилонской башни, население которой в силу разных причин говорило на разных языках. К еще большему разделению привели специфические проблемы, касающиеся оборудования и программного обеспечения. Теперь уже разработчикам не приходится отслеживать «синие экраны смерти», сопровождающие «падение» системы, или подвергаться гневу неудовлетворенных пользователей. Крен в сторону языков высокого уровня, наметившийся в программировании, означал, что процесс разработки ПО стал более абстрактным, все сильнее отдаляясь от оборудования и системных инженеров прошлого. В своем стремлении выполнять упреждающие действия и предотвращать сбои в обслуживании системные администраторы начали документировать наборы действий, необходимых для ручного выполнения рутинных операций. Системные администраторы позаимствовали идею «анализа первопричин» из методики всеобщего управления качеством. Частично это способствовало привлечению дополнительного внимания и усилий, что позволило минимизировать риск неудачи. Недостаточная степень прозрачности и плохо реализованное управление изменениями ведут к росту энтропии, с которой все чаще и чаще приходится иметь дело инженерам. Истоки глобального сообщества В то время как взаимосвязанные сети позволили программистам и ИТ-практикам обмениваться идеями в Интернете, обычные люди также стали искать способы обмена идеями. Начали появляться новые и все более популярные пользовательские группы, предназначенные для обсуждения разных вопросов практиками и пользователями различных технологий. В те времена одной из самых больших пользовательских групп была DECUS (Digital Equipment Computer Users’ Society, Сообщество пользователей цифрового компьютерного оборудования), основанная в 1961 году. В основной состав этой группы входили программисты, создающие или поддерживающие код для компьютеров DEC. Американское отделение DECUS проводило различные технические конференции и организовывало локальные пользовательские группы в США, тогда как отделения, действующие в других странах, проводили соответствующие мероприятия у себя. Результаты этих конференций и событий начали публиковаться в форме сборников трудов DECUS. Эти сборники были доступны для членов сообщества в качестве средства обмена информацией. Они стимулировали рост общего объема знаний сообщества и усиливали степень сплоченности членов этого сообщества. КОММЕРЧЕСКИЕ СЕКРЕТЫ И КОНФИДЕНЦИАЛЬНАЯ ИНФОРМАЦИЯ Информация, которая неизвестна широкой публике, является засекреченной. Это делается для обеспечения экономических или бизнес-преимуществ. Подобные закрытые сведения расцениваются как коммерческий секрет. Информация, которая является собственностью компании, либо информация, на использование которой компания имеет эксклюзивные права, считается конфиденциальной. Примеры конфиденциальной информации компании – программное обеспечение, процессы, методы, структура зарплаты, организационная структура и списки заказчиков. Например, исходный код собственного программного обеспечения обычно недоступен для конечных пользователей. Все коммерческие секреты являются конфиденциальными, но далеко не вся конфиденциальная информация является секретной. В дополнение к изменениям в культуре, в промышленности на засекреченность информации оказывают влияние коммерциализация и затраты на приобретение знаний и технологий. Аналогичное сообщество, объединившее в своих рядах системных администраторов, было создано в USENIX. Это сообщество представляло собой группу пользователей со специальными интересами и получило название System Administrators Group (группа системных администраторов). Позднее эта группа называлась SAGE, сейчас же она известна как группа пользователей со специальными интересами LISA (Large Installation System Administration, Администрирование установки больших систем). Эта группа проводит ежегодные конференции под названием «Large Installation System Administration»[6 - Согласно анонсу от USENIX, группа LISA будет расформирована в конце 2016 года. Более подробные сведения по этой теме можно найти на сайте https://www.usenix.org/blog/refocusing-lisa-community.]. Кроме того, встречи NSFNET «Regional-Tech» эволюционировали в группу North American Network Operators’ Group (NANOG). Это сообщество специально предназначено для организации сотрудничества между сетевыми администраторами, стремящимися внести свой вклад в улучшение Интернета. Наряду с обменом знаниями, который имел место в локальных и глобальных пользовательских группах, существовала и засекреченность разных аспектов деятельности технологических компаний. Организации в своем стремлении к финансовому и материальному успеху хранят подробности производственных процессов в строжайшем секрете. И если конкурирующие компании используют неэффективные методики, то соблюдение режима секретности позволяет добиться относительного успеха компании. Чтобы поддержать это конкурентное преимущество, сотрудникам в явной или неявной форме запрещалось делиться информацией на отраслевых конференциях. Эта ситуация резко контрастирует с современными средами разработки, в которых сообщества и конференции основаны на обмене информацией и сотрудничестве между компаниями. Эра приложений и Интернета Один из первых примеров успешной кооперации в рамках одной организации – суперпопулярный HTTP-сервер Apache (https://httpd.apache.org/ABOUT_APACHE.html), появившийся в 1995 году. Этот сервер был основан на бесплатном http-сервере NCSA HTTPd и разработан студентом Иллинойского университета (Урбана-Шампейн) Робертом Маккулом. Благодаря использованию модульного программного обеспечения Apache любой пользователь может быстро развертывать веб-сервер, выполнив лишь минимальную конфигурацию. Это ознаменовало начало эпохи использования решений с открытым программным кодом. Программы с открытым исходным кодом предоставляют пользователям лицензии на чтение, изменение и распространение исходного кода. Эти программы начинают конкурировать с собственными программными решениями, имеющими закрытый программный код. Учитывая доступность различных дистрибутивов операционной системы Linux и рост популярности языков написания сценариев, таких как PHP и Perl, возрастающая популярность программ с исходным открытым кодом привела к распространению стека LAMP (Linux, Apache, MySQL и PHP) в качестве средства создания веб-приложений. Система управления реляционными базами данных MySQL, появившаяся в 1995 году, наравне с инструментами написания серверных сценариев PHP позволила разработчикам создавать динамические веб-сайты и приложения. Эти сайты и приложения быстро обновлялись и динамически генерировали контент. Учитывая ту простоту, с которой могли создаваться новые веб-приложения, в конце 1990-х годов отдельным программистам и коллективам приходилось работать быстрее и проявлять большую гибкость, чтобы быть конкурентоспособными. Это было время тоски и разочарования для программистов и системных администраторов. Некоторые из системных администраторов являлись представителями традиционной культуры, суть которой заключалась в ключевых фразах «нет» и «очень важно для сохранения стабильности». В 1992 году Симон Траваглия начал публиковать в Usenet серию статей под общим названием «Чертов ублюдок оператор». Эти статьи были посвящены мошеннику сисадмину, который вымещал свое разочарование и гнев на пользователях. И нашлись сисадмины, недовольные своей работой, которые начали подражать герою этих публикаций, часто в ущерб другим пользователям. В процессе разработки программного обеспечения господствовали две точки зрения, выраженные следующими фразами: «критически важно выполнить эти изменения» и «я не хочу знать, как это делать, поскольку у меня ничего не получается». В некоторых средах разработки это побуждало разработчиков рисковать стабильностью системы в процессе поиска незадокументированных способов обхода установившихся процессов для достижения собственных целей. Это, в свою очередь, вело к дополнительным массовым чисткам и к росту убежденности в том, что изменения являются крайне рискованным делом. Те же единицы, которые пытались внести изменения в общие процессы, часто «застревали в трясине» авторитетных мнений экспертов в предметной области и блокировались на этапе технической поддержки. Развитие методологий разработки программного обеспечения В 2001 году в сообществе активных и деятельных приверженцев экстремального программирования и в других подобных сообществах было разослано приглашение принять участие в дискуссии, посвященной разработке программного обеспечения. Экстремальное программирование – это одна из форм гибкой разработки программ, которая более чутко реагировала на изменяющиеся требования, чем предыдущие методологии разработки программного обеспечения, такие как короткие циклы выпуска, интенсивное тестирование и парное программирование. В ответ на это предложение 17 инженеров-программистов собрались в Сноуберде (штат Юта). Они обсудили свои общие ценности, позволяющие включить адаптивность и реагирование на изменения в процесс разработки программного обеспечения с явным выделением человеческого фактора. Эти ценности были изложены в манифесте гибкого программирования, который положил начало движению сторонников гибкого программирования. В 2004 году программист Алистер Кокберн, являющийся одним из соавторов манифеста гибкого программирования (Agile Manifesto), описал методологию разработки ПО Crystal Clear[7 - Alistair Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams (Boston: Addison Wesley, 2004).]. Эта методология основана на десятилетнем опыте изучения успешных команд и предназначена для небольших групп разработчиков. Алистер описал три основных метода, используемых в Crystal Clear: • Быстрая доставка полезного кода, переход от больших и редких развертываний кода к меньшим и более частым развертываниям. • Отражающее усовершенствование, или получение сведений о том, что работало хорошо и плохо в предыдущей версии программы. Это позволяло улучшить следующую версию программы. • Осмотическая коммуникация, осуществляемая между разработчиками. Если разработчики находятся в одной комнате, информация воспринимается ими неформально, как фоновый шум. Этот процесс напоминает явление осмоса. Эта методология развивалась несколько лет, приобретая все большее влияние. В этот период времени системный администратор Марсель Вегерманн написал эссе, посвященное использованию принципов разработки программного обеспечения Crystal Clear, Scrum и Agile в области системного администрирования. В дополнение к блиц-докладу по теме, в котором были предложены такие идеи, как контроль версий для каталога /etc операционной системы Linux, парное администрирование системы и операционные ретроспективы, в 2008 году Марсель также создал список рассылки Agile System Administration. Приложения с открытым исходным кодом и собственные услуги По мере того как получили распространение приложения с открытым исходным кодом, а приложения стали более модульными и начали предоставлять больше возможностей для взаимодействия, инженеры получили больше вариантов выбора. Вместо того чтобы ограничиваться единственным поставщиком оборудования и какой-либо операционной системой и собственным программным обеспечением, используемым совместно с этим оборудованием, разработчики получили возможность выбирать используемые инструменты и технологии. По мере того как программное обеспечение, особенно веб-приложения, стало в большей степени коммерческим, оно приобрело большую ценность в прямом смысле этого слова, а в переносном смысле его стоимость снизилась. Приложения стали менее эксклюзивными и более распространенными, а программисты стали более высокооплачиваемыми и широко востребованными. В 2006 году компания электронной коммерции Amazon.com, Inc., которая ранее была известна своим сайтом по продаже книг и других товаров, предназначенных для широкого круга потребителей, запустила два сервиса: Amazon Elastic Compute Cloud (EC2) и Amazon Simple Storage Service (S3). Эти сервисы представляли собой первую попытку реализации виртуальных компьютерных экземпляров и виртуального хранилища с помощью собственной службы. В результате пользователи получили доступ к вычислительным ресурсам без предварительных инвестиций в оборудование. Также можно было запрашивать дополнительные ресурсы по мере необходимости. Как и в случае появления компьютеров из семейства System/360, этот сервис был быстро принят пользователями, став стандартом «де факто» благодаря простоте использования, невысоким начальным затратам и гибкости. По мере роста и развития веб-технологий появлялись новые способы коммуникации и сотрудничества в Интернете. В 2006 году появился онлайновый сетевой сервис Твиттер. Изначально этот сервис применялся пользователями, которые хотели делиться информацией, представленной в сокращенном формате. Эта информация использовалась в качестве средства привлечения внимания как простыми пользователями, так и знаменитостями. Но в 2007-м популярность Твиттера буквально взлетела до небес благодаря конференции South by Southwest Interactive (SXSW). Эта конференция транслировалась в режиме реального времени с помощью твитов на экранах, установленных в холлах. Твиттер быстро превратился в инструмент, предназначенный для быстрого формирования случайных сообществ пользователей в любой точке земного шара. При проведении конференций Твиттер предоставлял дополнительное средство информирования участников и объединял людей, близких по стилю мышления. Благодаря Твиттеру беседы между участниками конференций распространились на просторы Интернета, где каждый мог принять в них участие. Конец ознакомительного фрагмента. Текст предоставлен ООО «ЛитРес». Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/dzhennifer-devis/filosofiya-devops-iskusstvo-upravleniya-it/?lfrom=390579938) на ЛитРес. Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом. notes Примечания 1 Sidney Dekker and Erik Hollnagel, “Human Factors and Folk Models.” Cognition, Technology & Work 6, no. 2 (2004): 79–86. 2 Sidney Dekker, Field Guide to Understanding Human Error (Farnham, UK: Ashgate Publishing Ltd, 2014). 3 Robert McMillan, «Her Code Got Humans on the Moon – And Invented Software Itself», WIRED, October 13, 2016. 4 A. S.J. Rayl, «NASA Engineers and Scientists – Transforming Dreams Into Reality», 2008, http://www.nasa.gov/50th/50th_magazine/scientists.html. 5 Ronda Hauben and Michael Hauben, Netizens: On the History and Impact of Usenet and the internet (Los Alamitos, CA: IEEE, 1997). 6 Согласно анонсу от USENIX, группа LISA будет расформирована в конце 2016 года. Более подробные сведения по этой теме можно найти на сайте https://www.usenix.org/blog/refocusing-lisa-community. 7 Alistair Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams (Boston: Addison Wesley, 2004).