В то время как некоторые пользователи представляют облачные вычисления как синоним devops, это не всегда так. Ключевая часть devops – возможность оценивать и анализировать разные инструменты и процессы в целях идентификации средств, которые будут наиболее эффективны для вашей среды. Это вполне возможно сделать даже без перехода к облачной инфраструктуре.
Автоматизация инфраструктуры
Автоматизация инфраструктуры – это способ создания систем, позволяющий уменьшить нагрузку на персонал, связанную с управлением системами и относящимися к ним службами. Благодаря автоматизации повышается качество, точность и корректность сервиса, предоставляемого заказчикам. Автоматизация в целом представляет собой способ уменьшения количества повторяющихся операций, что позволяет свести к минимуму ошибки и сэкономить время и энергию операторов-людей.
Например, вместо того чтобы выполнять одни и те же командные оболочки вручную на каждом сервере, входящем в инфраструктуру организации, можно включить эти команды в сценарий оболочки. Этот сценарий можно выполнить отдельно, за один шаг, вместо выполнения множества мелких шагов.
Управление артефактами
Артефакты создаются в результате выполнения любого этапа в процессе разработки программного обеспечения. В зависимости от используемого языка под артефактами могут подразумеваться разные объекты, включая файлы JAR (архивные файлы Java), WAR (архивные файлы веб-приложений), библиотеки, ресурсы и приложения. Управление артефактами может быть столь же простым, как управление веб-сервером с контролем доступа, обеспечивающим управление файлами вручную. Управление файлами также может быть сложным и предусматривать использование разных расширенных средств. Как и в случае с рассмотренным раньше контролем версий для исходного кода, управление артефактами может выполняться разными способами, с учетом возможностей вашего бюджета.
В общем случае хранилище артефактов может выступать в качестве:
• центрального пункта управления бинарными файлами и зависимостями;
• настраиваемого прокси-сервера, установленного между организацией и общественными хранилищами;
• интегрированного хранилища, предназначенного для продвижения разработанного в организации программного обеспечения.
Контейнеры
Одна из самых серьезных болевых точек, которые традиционно возникают при взаимодействии команд разработчиков и поддержки, способ максимально быстрого выполнения изменений, требуемых для эффективной разработки, не рискуя при этом стабильностью производственной среды и инфраструктуры. Относительно новая технология, которая позволит в какой-то степени избавиться от этой болевой точки, заключается в использовании программных контейнеров. Это изолированные структуры, которые могут разрабатываться и развертываться относительно независимо от основной операционной системы или оборудования.
Подобно виртуальным машинам, контейнеры обеспечивают помещение кода в «песочницу», который будет выполняться здесь, но, в отличие от виртуальных машин, при этом уменьшаются накладные расходы и меньше степень зависимости от операционной системы и оборудования. В результате облегчается разработка приложений в контейнерах (в локальной среде) с дальнейшим развертыванием этого контейнера в производстве. При этом минимизируется риск и накладные расходы при разработке, а также уменьшаются усилия при развертывании, требуемые от инженеров из отдела эксплуатации.
Культурные концепцииФинальные концепции, которые будут определены в этой главе, относятся к культуре. В то время как некоторые методологии разработки программного обеспечения, например гибкая разработка, определяют основные способы взаимодействия разработчиков ПО, требуются дополнительные способы взаимодействия между людьми и связанные с ними культурные концепции, которые будут рассмотрены как в этой главе, так и в следующих главах книги.
Ретроспектива
Ретроспектива – это обсуждение проекта, которое имеет место после его завершения. В частности, анализируется, что было сделано хорошо, а что можно улучшить в будущем при выполнении следующих проектов. Ретроспективы обычно происходят на регулярной основе (возможно, и не слишком часто), например ежеквартально либо после завершения проектов. Основная цель ретроспективы заключается в локальном обучении. Обсуждается опыт успехов и неудач проекта, который может применяться в будущих проектах. Стили ретроспективы могут изменяться, но обычно обсуждаются следующие вопросы:
Что произошло?
Каковы были цели проекта и что мы получили после его завершения.
Что было сделано хорошо?
Что было успешного в этом проекте, что в проекте особенно нравится команде разработчиков и что можно использовать в будущих проектах.
Что пошло не так?
Что было сделано неправильно, с какими ошибками пришлось столкнуться, насколько были сорваны сроки и чего нужно избегать в будущих проектах.
Постмортем
В отличие от планового регулярного характера ретроспективы постмортем имеет место после какого-то незапланированного инцидента либо сбоя. Обычно это происходит тогда, когда последствия происшедшего события были неожиданными для участников проекта, а также обнаруживается как минимум один выход из строя системы или сбой в работе организации. В то время как ретроспективы имеют место по завершении проектов и планируются заранее, постмортем произносится неожиданно в силу непредсказуемости соответствующего события. Цель постмортема заключается в проведении обучения на уровне организации. При этом можно воспользоваться преимуществами, связанными с системным и последовательным подходом к постмортему. Не забудьте упомянуть следующие темы:
Что случилось?
Хронология инцидента от начала до конца, часто вместе с журналами общения или системных ошибок.
Опрос
Каждый человек, имеющий отношение к инциденту, высказывает свою точку зрения о происшедших событиях, в том числе о своих мыслях во время событий.
Что нужно исправить?
Что нужно исправить, чтобы улучшить безопасность системы и избежать повторения в будущем подобных инцидентов.
В сообществе devops большое внимание удаляется тому, чтобы во время проведения ретроспективы или произнесения постмортема не высказывались упреки. Конечно, в постмортеме могут содержаться упреки, адресованные виновникам инцидента, но эта политика противоречит акценту на обучение, занимающему центральное место в движении devops.
Безупречность
Концепция безупречности является противоположной культуре, основанной на обвинениях. Несмотря на то что эта концепция обсуждалась уже несколько лет, в основном Сидни Деккером и его сторонниками, настоящую известность она получила после появления поста Джона Оллспоу, посвященного постмортемам, не содержащим упреков (https://codeascraft.com/2012/05/22/blameless-postmortems/). Суть этого поста заключается в том, что ретроспектива инцидента будет более эффективной в случае акцента на обучении, а не на наказании.
Культура безупречности направлена не на то, чтобы дать людям возможность уйти от ответственности, а на то, чтобы люди чувствовали себя комфортно при обсуждении подробностей происшедшего инцидента, даже если они являются виновниками этого происшествия. Обучение будет успешным только после осознания всех деталей происшедшего события.
Организационное обучение
Самообучающейся называется организация, которая непрерывно обучается и трансформируется… Обучение – это непрерывный и направленный на достижение стратегических целей процесс, который интегрирован и выполняется одновременно с рабочим процессом.
– Karen E. Watkins and Victoria J. Marsick, Partners for LearningОрганизационное обучение представляет собой процесс сбора, роста и совместного использования знаний организации. В самообучающейся организации процесс обучения является более продуманным, поскольку оно представляет собой конкретную цель. Также предпринимаются действенные меры, чтобы со временем увеличить интенсивность коллективного обучения.
Организационное обучение, выбранное в качестве цели, является частью того, что отделяет культуру, основанную на упреках, от безупречной культуры. Тогда как культуры, основанные на упреках, зачастую в большей степени ориентированы на наказание, а не на обучение, безупречные или самообучающиеся организации понимают ценность опыта, извлекают уроки из происшедших событий и накапливают опыт, даже если этот опыт является негативным. Обучение может происходить на разных уровнях – на индивидуальном, групповом и на уровне организации. Организационное обучение оказывает
