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

Знакомство с DramaFever

Знакомство с DramaFever

Тим Гросс начинал свою карьеру в области архитектуры, позднее занялся разработкой программных инструментов и ИТ-проектами. Затем Тим стал первым «devops-инженером», работавшим на компанию DramaFever. В основном его обязанности заключались в выполнении работ по техобслуживанию, но зачастую ему приходилось заниматься разработкой программ. В марте 2013 года на работу в DramaFever был принят второй инженер по эксплуатации.

В команде отсутствовало преднамеренное или формальное распределение обязанностей и ролей, был лишь постепенный процесс, который привел к созданию эксплуатационной команды. Хотя соответствующая должность в компании называлась «devops-инженер», на самом деле все ограничивается выполнением работ по эксплуатации. Выполняемые обязанности описываются следующей фразой: «управление и автоматизация всех аспектов […] инфраструктуры, включая развертывание сайтов, CDN и управление облачными услугами». К числу специфических обязанностей относятся поддержка высокодоступных AWS-систем и online-дежурства. В данном случае какой-либо специфический devops-проект отсутствовал.

Описание должностных обязанностей devops-инженера в компании DramaFever включает следующую фразу.

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

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

В июле 2014-го в состав devops-команды в DramaFever вошла Бриджит Кромхаут. При описании стека технологий DramaFever Кромхаут отметила, что весь он включен в состав веб-сервисов Amazon (Amazon Web Services; AWS) наравне с веб-приложением Django/Python и постоянно растущим числом микросервисов на Go. Основная сеть доставки контента Akamai (content delivery network; CDN) обеспечивает доставку необходимого контента и быстрое кэширование.

Код пути запроса – это код приложения, который объявляет путь для запроса конечного пользователя в базе кода, а также для всех связанных сервисов, для которых имеют место критические требования к доступности и времени ожидания (помимо требований со стороны других приложений). Этот путь запроса использует неизменную инфраструктуру, которая создается с помощью Chef и Packer. Сам код приложения выполняется в контейнерах Docker начиная с конца 2013 года.

По словам Кромхаут:

Наш код приложения существует в виде экземпляров без состояния, которые автоматически масштабируются в 10–20 раз (в виде нескольких экземпляров) в течение одной недели. Наши слои хранения данных находятся в Elasticache (Memcached, Redis), RDS (MySQL), DynamoDB и Redshift. Мы передаем логи в ELK и записываем их в Graphite с помощью CollectD и StatsD.

Сервисы, которые не указаны в пути запроса, включают асинхронные рабочие задания Celery, задания cron, агрегацию регистрации и серверы метрик, такие как Graphite или Logstash, либо внутренние приложения, такие как приложение отслеживания качества. Кромхаут продолжает:

Хотя все эти сервисы имеют большое значение для бизнеса, они не всегда столь же важны для обычных пользователей. Если, например, не запускается на выполнение задание cron, а инженеру из эксплуатационного отдела потребуется примерно около часа на выяснение причин сбоя, мы можем сэкономить время, а пользователи даже не заметят проблемы. Если доступ к приложению Django заблокирован везде, пользователи не смогут наслаждаться своими любимыми фильмами.

Влияние существующей технологии

Благодаря доступности сервисов AWS (с 2006 года) произошла трансформация индустрии. Современные компании больше не нуждаются в привлечении менеджеров, владеющих навыками управления центрами обработки данных. Ранее приходилось брать на работу сотрудников, владеющих навыками управления средствами общего пользования. Изначально платформа DramaFever поддерживала веб-сервисы AWS. В настоящее время она продолжает использовать эти веб-сервисы для поддержки вычислительных ресурсов. Гросс заявил следующее:

Мы использовали Google App Engine (GAE) для создания и поддержки некоторых одноразовых проектов. По мере роста интенсивности использования GAE возникла необходимость перехода к среде AWS, в которой доступен более высокий уровень контроля.

В качестве примера подобного перехода можно привести наш микросервис обработки изображений, который называется ImageBoss. Этот сервис позволяет по запросу изменять размеры изображений, обрезать их. В результате вашим художникам не придется создавать слишком много вариантов каждого графического объекта. Первоначально этот микросервис был развернут на платформе GAE. При этом одновременно на каждом узле для Go было доступно лишь одно ядро. В результате были очень высоки эксплуатационные расходы. После перемещения этого сервиса на платформу AWS была получена оптимально настроенная среда приложения.

Хотя услуги AWS обходятся дороже услуг других облачных провайдеров, взамен пользователи получат отличный набор инструментальных средств. На вопрос о стоимости выполнения анализа с помощью AWS Гросс сказал следующее:

Если нам нужно будет перейти от AWS к другому провайдеру, нам придется найти замены для управляемых услуг, таких как SQS или DynamoDB. Затраты на выполнение подобных замен наверняка превысят возможную выгоду. К тому же наша рабочая нагрузка идеально вписывается в почасовую модель ценообразования AWS. В этом случае мы будем регулярно масштабировать узлы в течение рабочего дня. Это позволит обоснованно прогнозировать возникающие требования и в случае необходимости выполнять масштабирование при небольших затратах.

К тому же затраты на поддержание платформы AWS намного меньше, чем затраты на поддержку CDN (большие затраты связаны с большим объемом видеоданных, передаваемых каждый месяц) и зарплаты инженеров. Небольшая оптимизация расходов в случае перехода к другому провайдеру нивелируется резким ростом трудозатрат со стороны инженерного персонала.

При рассмотрении существующих технологий, используемых в процессах выбора инструментов, задайте себе следующие вопросы.

• Какие средства абсолютно необходимы, а какие – желательны?

• Какие решения доступны прямо сейчас, а какие могут стать доступными в ближайшее время?

• Каким образом затраты на внедрение необходимых вам средств соотносятся с затратами на внедрение доступных средств?

Непрерывное влияние новых технологий

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

Гросс описал несколько проблем, с которыми столкнулась его команда в октябре 2013 года.

• Как правило, Django применялось для выполнения медленного неатомического развертывания со сложными сбоями. Приложение Django являлось одним из важнейших приложений пути запроса, которое имело серьезные требования к доступности и времени ожидания. Из-за использования клона git замедлялось развертывание, к тому же в процессе развертывания периодически случались сбои.

• Увеличение степени сложности развертывания. Новые приложения Go не могут быть развернуты при использовании существующих процессов. Для двоичных модулей и интерпретированного исходного кода имели место разные требования к поставке.

• Раздельное тестирование качества и процессов развертывания производства без каких-либо возможностей аудита.

• Различные среды разработки и непрерывной интеграции.

Гросс также описал дополнительные цели, которые преследовала его команда:

• переход от монолитного приложения к меньшим по размерам микросервисам;

• изоляция разных версий приложения на одном хосте в средах разработки и контроля качества.

Как говорит Гросс:

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

Большой риск заключался в том, что в те времена Docker был весьма сырым проектом (в октябре 2013 года, версия 0.6). К тому же мы не развертывали в производственной среде проекты, не подготовленные к использованию в производстве. Мы знали, что в случае возникновения каких-либо проблем можем всегда вернуться к более зрелой базовой LXC-системе. Эту ситуацию мы изложили руководству команды разработчиков, чтобы получить «добро» на продолжение работы.

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

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

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

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

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

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

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

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

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

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

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

– @0x74696d at @dramafever

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

– Bridget Kromhout (@bridgetkromhout)

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

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

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

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

Чтобы еще больше облегчить работу удаленных сотрудников, в конференц-залах DramaFever установлены компактные компьютеры Chromebox. На основе такого компьютера реализуется бизнес-система организации видеоконференций. Используется операционная система Chrome OS, камера с высоким разрешением, внешние микрофоны и колонки. По умолчанию совещания проводятся в режиме виртуального присутствия, реализованного с помощью Google Hangouts, благодаря чему не требуется физическое присутствие в офисе.

Обратите внимание на то, каким образом инструменты и методы работы взаимодействуют между собой внутри вашей организации и команд.

• Каковы ценности, исповедуемые в вашей команде или организации?

• Помогают ли инструменты реализовать эти ценности на практике или только мешают этому процессу?

• Насколько прозрачно взаимодействуют между собой ценности и процессы?

Порядок выбора инструментов в DramaFever

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

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

Беседа, проводимая при внедрении новой технологии, посвящена рассмотрению соответствующего определения. На основе этого определения можно судить, будут ли работать существующие решения, почему новая технология может оказаться более подходящей. Также нужно рассчитать дополнительную рабочую нагрузку на имеющийся персонал.

Согласно объяснению, приведенному Кромхаут,

при выборе между своим собственным сервисом и SaaS[49] оцениваются соответствующие расходы и преимущества, включая затраты, связанные с выполнением дополнительных работ (как затраты времени персонала, так и финансовые).

Например, при рассмотрении порядка обработки логов мы подсчитали текущий объем логов, учли желательный объем и сравнили стоимость поддержки логов с помощью ELK со стоимостью передачи логов независимым провайдерам услуг. Мы перечислили действия, выполняемые по отношению к логам. После получения квот и учета количества времени, выделенного на поддержку ELK, мы сделали выбор в пользу ELK.

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

Как отмечает Кромхаут:

Создание рабочей инфраструктуры, определенной кодом, очень важно, поскольку мы стремимся все заменять в оперативном режиме, не отключая сайт на проведение профилактических работ. Рассматриваемый код может обрабатываться с помощью файла JSON, определяющего конфигурацию сервисов AWS, или «поваренных книг» Chef, или же с помощью Python (посредством Boto и Fabric). Мы отправляем запросы на включение подобного кода, который будет просмотрен и протестирован нашими коллегами перед выполнением слияния и развертывания. Критерий успеха в данном случае – создание рабочего кода. Это позволило нам отказаться от GitHub и наладить рабочий поток в стиле Канбан.

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

• Кто несет ответственность за принятие решений по выбору инструмента?

• Какие критерии используются для выбора инструмента, его оценки и опыта использования?

• Что является главным при выборе инструмента с точки зрения разработчика и заказчика?

Многие люди избегают пользоваться технологиями. Особенно это относится к новым технологиям, таким как Docker, которая имела статус новой во времена развертывания производственной инфраструктуры DramaFever. Также существует категория людей, для которых Docker вообще лишен всякого смысла. Цель этого примера заключается не в том, чтобы обсудить технологию Docker, а в том, чтобы выявить причины, в силу которых инженеры выбирают эту программу, изучить соображения, которыми они руководствуются, и компромиссы, а также познакомиться со способами принятия окончательных решений в пользу выбора того или иного инструмента.

Оглавление книги

Оглавление статьи/книги
Похожие страницы

Генерация: 1.155. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз