Вступительное слово Николь Форсгрен
21
ее производительности в целом. Лучшим ИТ-организациям присуща удвоенная производительность, большая рентабельность и доля рынка по сравнению с кон- курентами. И вовсе не случайно книга начинается дискуссией, посвященной аспектам культуры, общения и доверия. Значительная часть книги посвящена обоснованию важности вклада этих факторов в процесс трансформации в сто- рону DevOps. Нам, как технарям, нравится начинать с использования инстру- ментов и, возможно, даже процессов. Но время от времени практика показывает, что культура, наравне с упомянутыми ранее ИТ и производительностью органи- зации, имеет большое значение для успешного применения инструментов и тех- нологий. Обязательно прочитайте части II–III, посвященные сотрудничеству и близости соответственно, независимо от того, начинаете ли вы трансформацию
DevOps и хотите знать, что нужно реализовывать и что требуется отслеживать, или же вы поднимаете существующую практику DevOps на новый уровень и ищете способы оптимизации и устранения проблем.
Работая консультантом в наиболее инновационных компаниях, я пришла к выво- ду о том, что наиболее трудная часть реализации и составления предварительно- го плана технологической трансформации DevOps заключается в невозможности дать однозначный ответ, который подходил бы для всех ситуаций. Все зависит от того, что именно считается корректным для вашей команды и вашей органи- зации. Поэтому мне нравится, что именно эта мысль постоянно подчеркивается в книге. Не существует единственного простого решения всех проблем. Чтобы внедрить собственное решение DevOps и добиться успеха, нужно использовать подходящие инструменты и компоненты. Помимо частей II–III обязательно обратитесь к части IV, в которой описаны инструменты, необходимые для вы- полнения произвольной трансформации DevOps. Особенно мне нравится, что при описании инструментов идет речь не только о технологических аспектах, но и о ключевых компонентах культуры, в рамках которой эти инструменты используются.
Одна из наиболее приятных особенностей книги заключается в ее доступности для разной аудитории. Часть V, посвященная масштабируемости, особенно полезна для рядовых участников и руководителей команд. Я использую материал, изло- женный в этой части, в качестве справочника для себя и своих клиентов. Главы 4 и 11, включающие описание терминологии и обзор экосистемы, соответственно будут полезными как для технарей (в качестве терминологической базы), так и для руководителей, нуждающихся в актуальном справочном пособии. Эта книга является позитивным и полезным введением в DevOps, включающим сведения, которые отсутствуют в университетских учебниках. Я была бы просто счастлива, если бы в свое время могла использовать подобное пособие в своей преподаватель- ской деятельности.
Мы живем и работаем в поистине удивительные времена, когда интеграция техно- логий в бизнес привела к превращению каждой фирмы в софтверную компанию.
22
Вступительное слово Николь Форсгрен
Благодаря современным технологиям потребители могут использовать новые способы получения доступа к требуемым средствам, причем этот доступ осуществ- ляется с невиданной ранее скоростью. Компаниям приходится прилагать макси- мум усилий, чтобы не отставать от конкурентов. На основе своего опыта работы с компаниями, внедрявшими DevOps, я пришла к выводу, что прежние методы
(итеративная и каскадная модели) не позволяют поддерживать необходимую скорость обмена данными в организации. Авторы книги рассматривают проблемы технологической трансформации, выполняемой с помощью устаревших способов, и захватывающие возможности, открывающиеся в результате внедрения DevOps.
Читайте книгу и выбирайте собственный путь! Повторяйте, учитесь, растите и вы- бирайте свой путь перехода к DevOps!
Николь Форсгрен, доктор философии,
директор компании Chef Software,
Сиэтл, Вашингтон
Предисловие
Представьте себе такой сценарий. Небольшая веб-компания начала сталкиваться со следующими проблемами. Веб-сайт этой компании «тормозит» и периодически
«ложится» в случае непредвиденного роста числа пользователей. Сотрудники все чаще выражают недовольство по причине увеличения трудозатрат, требуемых для предоставления услуг, а также в силу необходимости разработки и выкатки нового функционала. Между глобально распределенными командами разработ- чиков появляются барьеры, вызванные использованием разных языков и часовых поясов. Растет количество взаимных обвинений, вызванных стрессом из-за роста
«падений» сайта. Это приводит к росту подозрительности и снижению степени прозрачности при взаимодействии между группами сотрудников.
Столкнувшись с подобными проблемами, менеджмент организации принимает решение о devops-трансформации. Для реализации этого решения нанимается несколько сотрудников, формирующих новую devops-группу. Члены этой группы исполняют обязанности по вызову, то есть к ним обращаются члены эксплуата- ционной группы в случае возникновения неразрешимых проблем. Члены devops- группы являются экспертами в своей предметной области и лучше подготовлены к решению проблем. Но если у членов эксплуатационной группы нет ни времени, ни возможностей для получения новых навыков, одни и те же проблемы будут возникать снова и снова.
Рано или поздно членам devops-группы надоест исполнять роль посредников меж- ду группой разработчиков и эксплуатационной группой. Вместо того чтобы убрать напряжение, подобное «решение» менеджмента приведет к росту недопонимания, поскольку ни одна из групп не причастна к процессам планирования, обмена сооб- щениями и отслеживания ошибок, реализуемых членами другой группы.
В результате менеджмент заявляет о провале идеи с формированием devops- группы и перестает выделять время, деньги и усилия в развитие devops-группы и эксплуатационной группы. К членам этих групп начинают относиться как к не- компетентным бездельникам, которые способствуют «падениям сайта» и только
«мешают» разработчикам, выполняющим «реальную» работу. Вполне естественно,
24
Предисловие что члены этих групп, не выдержав груза обвинений в некомпетентности, начина- ют увольняться из организации, еще более затрудняя исполнение обязанностей оставшимися сотрудниками.
Первое знакомство с devops
В чем причина появления проблем в описанной ситуации? Вроде бы внедрение
«devops» являлось хорошей идеей, но создание devops-группы привело к нега- тивным последствиям. Что нужно изменить, чтобы добиться значительного улуч- шения ситуации и реального устранения проблем? На протяжении всей книги вы увидите, как можно выполнить эффективные преобразования на основании devops-мышления.
Не рассматривайте эту книгу в качестве сборника бесспорных рекомендаций по внедрению devops-подхода. Мы не предлагаем вам devops «из коробки», devops в качестве услуги и не говорим вам, что вы некорректно внедряете devops-реше- ния. В этой книге вы найдете коллекцию идей и подходов по улучшению сотрудни- чества между отдельными сотрудниками, по достижению однородности на уровне отдельной группы и организации в целом и по использованию инструментов на уровне компании или организации. Вы также увидите, каким образом эти концеп- ции способствуют изменению и адаптации организаций в случае возникновения необходимости в этом. Поскольку каждая организация является уникальной, не существует единого универсального подхода по внедрению devops. Существу- ющие общие подходы должны применяться в каждой организации различным образом. В результате улучшается качество создаваемого в этой организации про- граммного обеспечения, а также улучшается эффективность работы и повышается благосостояние сотрудников.
Результативность является следствием того, что «делаются нужные, правильные вещи». А эффективность является следствием того, что «пра- вильно создаются эти самые вещи».
— Питер Ф. Друкер
Эффективность определяется как способность делать правильные вещи и дости- гать желаемых результатов. Чтобы делать правильные вещи, нужно осознать по- ставленные задачи и выявить связь между конкретными краткосрочными целями и поставленными задачами.
Мы выражаем надежду, что сможем помочь вам идентифицировать правильные вещи в вашей среде на основе вашей культуры, включая применяемые процессы
Предисловие
25
и инструменты. Идеи и принципы, излагаемые на протяжении всей книги, приме- нимы к организации в целом, а не только на уровне групп разработчиков и техни- ческой поддержки. В процессе написания книги мы даже сами использовали эти идеи и принципы.
В то время как наша цель при написании книги заключалась в том, чтобы по- делиться универсальными историями, советами и практиками с менеджментом организаций, который сможет адаптировать и использовать их в качестве своих рабочих методологий, каждой из нас присущи свои уникальные знания и опыт.
Разнообразные идеи, использованные при написании книги, были порождены коллективным опытом. Этот опыт получен на основе анализа работы частного и общественного сектора, маленьких стартапов и огромных корпоративных сред, а также отделов, распределенных по должностям, от разработки ПО до его под- держки, контроля качества, консалтинга и многого другого.
КАК ПРАВИЛЬНО ПИСАТЬ СЛОВО «DEVOPS»?
У нас были жаркие споры по поводу использования заглавных букв при напи- сании термина «devops». В результате проведения простого интерактивного опроса выяснилось, что подавляющее большинство пользователей выбрали написание «DevOps». Пользователи также поддерживают написание терминов
«Dev» и «Ops», используемое для обозначения групп в составе организации. На основе этих терминов создаются производные термины, такие как «DevSecOps» и «DevQAOps», тогда как термин «DevOps» подразумевает исключительное использование терминов «Dev» и «Ops».
В итоге мы выбрали написание «devops», поскольку оно соответствует ориги- нальному хэштегу в Твиттере, используемому для объединения людей, которые хотят изменить слоган «мы против них» на «делаем бизнес» с применением устойчивых рабочих практик, ориентированных на людей.
Успешные проекты требуют вклада, усилий, понимания и сотрудничества со стороны сотрудников организации. Проблемы, возникающие в организации, могут быть присущи не только разработчикам или группам поддержки. Мы сознательно решили использовать запись термина с помощью символов в ниж- нем регистре «devops» по всей книге. Это отражает нашу точку зрения, которая заключается в том, что devops является инклюзивным движением, а не эксклю- зивной единицей.
Для кого предназначена книга
Эта книга в первую очередь предназначена для менеджеров и рядовых сотруд- ников, которые исполняют роли лидеров и сталкиваются с проблемами в своих организациях. Благодаря этой книге они смогут предпринять конкретные реаль- ные действия, направленные на реализацию или улучшение devops-культуры
26
Предисловие в рабочей среде. Рядовые сотрудники, занимающие различные должности, найдут здесь практические предложения, позволяющие ослабить болевые точки благода- ря выполнению действенных рекомендаций.
Читатели этой книги исполняют разные профессиональные роли, поскольку devops является профессиональным и культурным движением, ориентированным на поддержку повторяющихся усилий, направленных на открытие доступа к орга- низационной информации, отслеживание отношений и устранение недопонима- ния, возникающего между группами в организации.
В книге рассматривается широкий набор навыков и теоретических положений devops, включая основы фундаментальных идей и концепций. Предполагается, что вы уже знакомы с термином «devops» и, возможно, даже имеете базовые познания об инструментах и процессах, используемых в этой области.
Мы рекомендуем вам отказаться от жестко заданных и быстро сформулированных определений и настроиться на восприятие принципов devops, которые, по нашему мнению, являются наиболее эффективными.
После прочтения книги у вас сформируется четкое представление о том, что означает на практике devops-культура для вашей организации. Вы узнаете о том, как стимули- ровать эффективное сотрудничество таким образом, чтобы отдельные сотрудники, относящиеся к разным слоям и группам, имеющие разные цели и владеющие различ- ными рабочими стилями, могли продуктивно работать вместе. Вы получите сведения о том, как наладить совместную работу групп таким образом, чтобы максимизировать производимую стоимость при одновременном повышении степени удовлетворенно- сти сотрудников. Вы научитесь балансировать между конфликтующими организаци- онными целями и выбирать инструменты и организационные потоки, наращивающие потенциал вашей организации.
Структура книги
Мы приложили немало усилий для упорядочения и организации глав книги.
Подобно тому как не существует единственно верного способа внедрения devops, отсутствует и единственно правильный способ упорядочения действий, требуемых для внедрения devops. Каждый читатель книги будет использовать уникальную последовательность этапов внедрения devops, решать собственные проблемы и устранять возникающие при этом конфликты.
Эта книга состоит из нескольких частей. В части I рассматривается общая карти- на, которая детализируется до уровня идей, определений и принципов, имеющих отношение к devops. В частях II–V рассматриваются четыре фундаментальные концепции, лежащие в основе эффективного внедрения devops. В части VI завер- шается дискуссия, посвященная построению связей между отдельными людьми, группами и организациями.
Предисловие
27
Часть I. «Основы devops».
Часть II. «Сотрудничество».
Часть III. «Близость».
Часть IV. «Инструменты».
Часть V. «Масштабирование».
Часть VI. «Объединение культур devops».
Части II–V завершаются главой, в которой обсуждаются различные заблу- ждения, относящиеся к той или иной концепции, лежащей в основе внедрения devops. В этой главе также рассматриваются некоторые универсальные сценарии по устранению неполадок, относящиеся к данной теме. Читатели, занимающиеся внедрением devops в своих организациях, в главе «Заблуждения и устранение проблем» найдут также ряд практических советов, которые будут полезными в работе.
Читатели, предпочитающие общество компьютера, а не живого человека, могут испытать соблазн пропустить материал, описывающий межличностное взаимо- действие и культуру общения. Это нецелесообразно, поскольку данный материал дает представление о принципах совместной работы, включая межкультурное и технологическое взаимодействие, благодаря которому увеличивается степень эффективности devops.
Читайте главы книги в наиболее удобном для себя порядке, действуйте в стиле
«выбор своего собственного приключения». Концепции, заложенные в основу devops, переплетаются и тесно связаны между собой, поэтому при чтении книги вы будете неоднократно возвращаться к ранее прочитанному материалу, чтобы освежить в памяти ту или иную концепцию.
Методология практик
На протяжении всей книги вы будете знакомиться с рассказами сотрудников раз- ных компаний. Эта информация была получена в процессе проведения интервью с людьми, находящимися на разных уровнях организаций, на основании сообще- ний, опубликованных в блогах, из презентаций и заявок на регистрацию компаний.
В то время как тема для каждой главы информирует о направлении практик, при- рода devops приводит к тому, что каждое тематическое исследование затрагивает несколько, если не все четыре концепции, лежащие в основе devops.
Также вниманию читателей представляется комбинация более формальных прак- тик, неформальных историй и нашего личного опыта. Все это делается в целях демонстрации разнообразия способов, посредством которых devops может оказать влияние на принятие решений и нарративы.
28
Предисловие
Прочитайте истории, представленные в следующих главах. Распознайте истории, имеющие отношение к вашей организации. Ответьте на вопрос о том, что влияет на ваши группы и информирует их. Поделитесь вашими историями на корпора- тивных или общих встречах. Прислушивайтесь к историям о внедрении devops от других людей.
Соглашения, используемые в книге
В книге приняты следующие типографские соглашения:
Курсив
Используется для обозначения новых терминов, адресов URL, адресов электрон- ной почты, имен файлов и расширений.
Моноширинный шрифт
Применяется для оформления листингов программ и программных элементов внутри обычного текста, таких как имена переменных или функций, базы данных, типы данных, переменные среды, инструкции и ключевые слова.
Моноширинный полужирный шрифт
Обозначает команды или другой текст, который должен вводиться пользователем.
Моноширинный наклонный шрифт
Обозначает текст, который должен замещаться фактическими значениями, вводи- мыми пользователем или определяемыми из контекста.
Общее примечание, совет или предположение.
Предостережение или предупреждение.
Действенное предположение, основанное на четырех концепциях эффектив- ного внедрения devops.