Кэтрин Дэниелс - Философия DevOps. Искусство управления IT Страница 2

Одна из наиболее приятных особенностей книги заключается в ее доступности для разной аудитории. Часть 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». Пользователи также поддерживают написание терминов «Dev» и «Ops», используемое для обозначения групп в составе организации. На основе этих терминов создаются производные термины, такие как «DevSecOps» и «DevQAOps», тогда как термин «DevOps» подразумевает исключительное использование терминов «Dev» и «Ops».

В итоге мы выбрали написание «devops», поскольку оно соответствует оригинальному хэштегу в Твиттере, используемому для объединения людей, которые хотят изменить слоган «мы против них» на «делаем бизнес» с применением устойчивых рабочих практик, ориентированных на людей.

Успешные проекты требуют вклада, усилий, понимания и сотрудничества со стороны сотрудников организации. Проблемы, возникающие в организации, могут быть присущи не только разработчикам или группам поддержки. Мы сознательно решили использовать запись термина с помощью символов в нижнем регистре «devops» по всей книге. Это отражает нашу точку зрения, которая заключается в том, что devops является инклюзивным движением, а не эксклюзивной единицей.

Эта книга в первую очередь предназначена для менеджеров и рядовых сотрудников, которые исполняют роли лидеров и сталкиваются с проблемами в своих организациях. Благодаря этой книге они смогут предпринять конкретные реальные действия, направленные на реализацию или улучшение devops-культуры в рабочей среде. Рядовые сотрудники, занимающие различные должности, найдут здесь практические предложения, позволяющие ослабить болевые точки благодаря выполнению действенных рекомендаций.