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

Советы и рекомендации, изложенные в книге, коррелируют с моим опытом работы, полученным за последние десять лет. Как известный специалист в этой области и как ведущий исследователь 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-группы и эксплуатационной группы. К членам этих групп начинают относиться как к некомпетентным бездельникам, которые способствуют «падениям сайта» и только «мешают» разработчикам, выполняющим «реальную» работу. Вполне естественно, что члены этих групп, не выдержав груза обвинений в некомпетентности, начинают увольняться из организации, еще более затрудняя исполнение обязанностей оставшимися сотрудниками.