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

После выполнения испытаний в среде разработки/контроля качества мы развернули Docker для производства основного приложения Django. Только после завершения тестирования мы можем перейти к контейнеризации остальных приложений.

Как и в случае с любым другим внедрением технологии, возникают дополнительные проблемы, которые должны быть разрешены. Зачастую интеграция результатов работы в среде непрерывной интеграции (CI) осуществляется с помощью автоматизации. Каждое действие по интеграции верифицируется с помощью автоматизированного процесса, который создает и тестирует обязательный код. В результате ускоряется обнаружение ошибок. Как правило, это достигается путем развертывания среды и тестирования кода с последующим разрушением среды.

В среде CI часто возникали проблемы, связанные с дисками. Зачастую причина появления этих проблем заключалась в повышенной вибрации. Для устранения этой проблемы был заменен драйвер хранилища Docker (эта задача довольно сложная). Также возникали проблемы, связанные с масштабированием реестра Docker. Чтобы устранить технологические проблемы, связанные с реестром, выполнялось развертывание локального реестра хоста, при поддержке AWS S3 (вместо использования центрального сервера).

Третья проблемная область появилась после развертывания Docker в локальной среде разработки. По этому поводу Гросс сказал:

В случае выбора платформы AWS эксплуатация осуществлялась без особых проблем. Но мне не удалось найти хорошее решение, пригодное для выполнения Docker на локальной платформе. К тому же команда разработчиков была очень занята внедрением новых средств и не могла выделить время на изучение новой технологии. Когда мы развернули boot2docker в качестве варианта локальной среды разработки, у нас возникла серьезная «дыра» в обучении, которая сохранялась дольше, чем мы бы хотели, и привела к появлению серьезных внутренних трений. Это был хороший урок для нас, суть которого заключалась в том, что новые изменения должны вноситься в инфраструктуру при более непосредственном участии со стороны команды разработчиков.

Процесс тщательного отбора и оценки имеет значение как для новой, так и для существующей технологии. В случае новой технологии (новой вообще или новой для вашей организации) задайте себе следующие вопросы:

• Каковы известные риски новой технологии?

• С какими неизвестными моментами вы можете столкнуться?

• Какие проблемы невозможно решить в рамках существующей технологии?

Расширенное внедрение практик формирования близости

Безупречный постмортем (https://codeascraft.com/2012/05/22/blameless-postmortems/) с целью формирования культуры непрерывного улучшения.

Мне очень приятно, когда @0x74696d ссылается на @codeascraft в дискуссии, посвященной трактовке сбоев со стороны @dramafever. Спасибо за помощь в обучении, Etsy!

Эти твиты, написанные в феврале 2015 года, иллюстрируют нарастающую тенденцию формирования близости между компаниями, достигаемую посредством обмена знаниями. Кромхаут заявила, что DramaFever адаптировала безупречные постмортемы для использования техническими командами.

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

В DramaFever поощряется прозрачность. Как говорит Кромхаут, «прямо сейчас разработчики получают полный доступ к сервисам AWS в среде разработки. Мы также активизировали IAM-доступ в режиме чтения». Благодаря подобной прозрачности сотрудники могут учиться и наблюдать непосредственно из среды разработки, которая реплицирует производство и ответы на вопросы об использовании производства в реальном мире по мере их возникновения.

Поскольку DramaFever эксклюзивно использует технологию AWS, не требуется центр обработки данных. Также отсутствуют требования к сотрудникам по поводу явного присутствия в специфической среде. Команда DramaFever, насчитывающая примерно 120 человек, в основном находится в Филадельфии и в Нью-Йорке, а некоторые сотрудники трудятся в других местах. В процессе описания среды Кромхаут сказала следующее: «Наши сотрудники находятся поблизости, в Мэриленде, или очень далеко, в Сеуле, и все они должны без помех выполнять одну и ту же работу».