Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 405
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
250
Часть IV. Инструменты и создавать необходимые инструменты самостоятельно. Подобная разработка может оказаться менее затратной для бюджета, но придется предусмотреть время и ресурсы для поддержки в долгосрочной перспективе.
И наконец, постоянно контролируйте процессы по внедрению инструментов, оценивайте влияние изменений на работоспособность решений. Специфика объ- ектов оценки будет немного изменяться в зависимости от текущих проблем, но без проведения оценки невозможно судить о степени влияния и эффективности изменений.
Практики
Первая практика, рассматриваемая в этой главе, — платформа потокового видео
DramaFever. На этой платформе реализован документальный сайт SundanceNow
Doc Club и сайт ужасов Shudder. Компания DramaFever была основана в 2009 году, а уже к середине 2015 года она насчитывала около 120 сотрудников. Платформы
DramaFever поддерживают международный контент из 15 стран, насчитывающий около 15 000 эпизодов, который предлагается 70 провайдерами контента. Аудито- рия контента насчитывает 20 миллионов зрителей
1
. Чтобы погрузиться в атмосфе- ру оценки и применения инструментов (и технологий), мы поговорили с Тимом
Гроссом и Бриджит Кромхаут. На момент интервью они работали инженерами по эксплуатации в DramaFever.
Вторая практика посвящена Etsy (см. главу 2). Эта глобальная торговая пло- щадка предназначена для продажи винтажных и хендмейд-товаров. Она была основана в 2005 году Робом Калином, Джаредом Тарбеллом, Крисом Магуайром и Хаимом Шоппиком. Во втором квартале 2015 года в компании Etsy работали примерно 785 сотрудников. Помимо соавтора книги Кэтрин Дэниелс, которая поделилась своим опытом работы с Etsy, мы поговорили с инженером по ра- боте с персоналом из компании Etsy Джоном Коуи. Благодаря этой беседе мы получили представление о том, каким образом в Etsy оценивают и используют инструменты и технологии.
Информация, используемая в обеих практиках, была получена на основе опу- бликованных сообщений в блогах, презентаций и архивов компаний. При рас- смотрении этих практик можно найти примеры идентификации скрытых ценно- стей, адаптировать нужные практики, а также оценить и выбрать инструменты, используемые в среде. Но мы хотели бы напомнить читателям, что следует воздерживаться от бездумного использования любого инструмента или техно- логии. Также нужно учитывать причины и области применения инструментов и технологий.
1
Peter Shannon, «Scaling Next-Generation Internet TV on AWS with Docker, Packer, and Chef»,
October 20, 2015, http://bit.ly/shannon-scaling.
Глава 12. Инструменты: акселераторы культуры
251
Знакомство с 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 года.
252
Часть IV. Инструменты
По словам Кромхаут:
Наш код приложения существует в виде экземпляров без состояния, которые автоматически масштабируются в 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 была получена оптимально настроенная среда приложения.
Глава 12. Инструменты: акселераторы культуры
253
Хотя услуги AWS обходятся дороже услуг других облачных провайдеров, взамен пользователи получат отличный набор инструментальных средств. На вопрос о стоимости выполнения анализа с помощью AWS Гросс сказал следующее:
Если нам нужно будет перейти от AWS к другому провайдеру, нам придет- ся найти замены для управляемых услуг, таких как SQS или DynamoDB.
Затраты на выполнение подобных замен наверняка превысят возможную выгоду. К тому же наша рабочая нагрузка идеально вписывается в поча- совую модель ценообразования AWS. В этом случае мы будем регулярно масштабировать узлы в течение рабочего дня. Это позволит обоснованно прогнозировать возникающие требования и в случае необходимости вы- полнять масштабирование при небольших затратах.
К тому же затраты на поддержание платформы AWS намного меньше, чем затраты на поддержку CDN (большие затраты связаны с большим объ- емом видеоданных, передаваемых каждый месяц) и зарплаты инженеров.
Небольшая оптимизация расходов в случае перехода к другому провай- деру нивелируется резким ростом трудозатрат со стороны инженерного персонала.
При рассмотрении существующих технологий, используемых в процессах вы- бора инструментов, задайте себе следующие вопросы.
t
Какие средства абсолютно необходимы, а какие — желательны?
t
Какие решения доступны прямо сейчас, а какие могут стать доступными в ближайшее время?
t
Каким образом затраты на внедрение необходимых вам средств соотно- сятся с затратами на внедрение доступных средств?
Непрерывное влияние новых технологий
По мере развития технологий и появления новых инструментов в экосистеме мо- гут возникать затруднения в процессе принятия решений в пользу того или иного инструмента. В случае небольшой компании, выполняющей большие объемы неза- планированных работ и имеющей постоянные технические долги, важно в первую очередь реализовывать наиболее важные проекты.
Гросс описал несколько проблем, с которыми столкнулась его команда в октябре
2013 года.
Как правило, Django применялось для выполнения медленного неатомиче- ского развертывания со сложными сбоями. Приложение Django являлось одним из важнейших приложений пути запроса, которое имело серьезные требования к доступности и времени ожидания. Из-за использования клона git замедлялось развертывание, к тому же в процессе развертывания пери- одически случались сбои.
254
Часть IV. Инструменты
Увеличение степени сложности развертывания. Новые приложения Go не могут быть развернуты при использовании существующих процессов. Для двоичных модулей и интерпретированного исходного кода имели место разные требования к поставке.
Раздельное тестирование качества и процессов развертывания производ- ства без каких-либо возможностей аудита.
Различные среды разработки и непрерывной интеграции.
Гросс также описал дополнительные цели, которые преследовала его команда:
переход от монолитного приложения к меньшим по размерам микросер- висам;
изоляция разных версий приложения на одном хосте в средах разработки и контроля качества.
Как говорит Гросс:
Эксплуатационная команда (состоящая из двух человек на то время) оценила несколько вариантов, основываясь на разных преимуществах, таких как подгонка процесса решения проблем, наш опыт работы с язы- ком реализации, известные виды отказов и т. п. В результате был вы- бран Docker. Этот выбор был основан на перспективах использования обобщенного интерфейса развертывания, который позволил бы решить все проблемы.
Большой риск заключался в том, что в те времена Docker был весьма сырым проектом (в октябре 2013 года, версия 0.6). К тому же мы не развертывали в производственной среде проекты, не подготовленные к использованию в производстве. Мы знали, что в случае возникновения каких-либо проблем можем всегда вернуться к более зрелой базовой
LXC-системе. Эту ситуацию мы изложили руководству команды разра- ботчиков, чтобы получить «добро» на продолжение работы.
После выполнения испытаний в среде разработки/контроля качества мы развернули Docker для производства основного приложения Django.
Только после завершения тестирования мы можем перейти к контейне- ризации остальных приложений.
Как и в случае с любым другим внедрением технологии, возникают дополнитель- ные проблемы, которые должны быть разрешены. Зачастую интеграция резуль- татов работы в среде непрерывной интеграции (CI) осуществляется с помощью автоматизации. Каждое действие по интеграции верифицируется с помощью автоматизированного процесса, который создает и тестирует обязательный код.
В результате ускоряется обнаружение ошибок. Как правило, это достигается путем развертывания среды и тестирования кода с последующим разрушением среды.
Глава 12. Инструменты: акселераторы культуры
1 ... 19 20 21 22 23 24 25 26 ... 39
255
В среде CI часто возникали проблемы, связанные с дисками. Зачастую причина по- явления этих проблем заключалась в повышенной вибрации. Для устранения этой проблемы был заменен драйвер хранилища Docker (эта задача довольно сложная).
Также возникали проблемы, связанные с масштабированием реестра Docker. Что- бы устранить технологические проблемы, связанные с реестром, выполнялось развертывание локального реестра хоста, при поддержке AWS S3 (вместо исполь- зования центрального сервера).
Третья проблемная область появилась после развертывания Docker в локальной среде разработки. По этому поводу Гросс сказал:
В случае выбора платформы AWS эксплуатация осуществлялась без особых проблем. Но мне не удалось найти хорошее решение, пригодное для выполнения Docker на локальной платформе. К тому же команда разработчиков была очень занята внедрением новых средств и не могла выделить время на изучение новой технологии. Когда мы развернули boot2docker в качестве варианта локальной среды разработки, у нас воз- никла серьезная «дыра» в обучении, которая сохранялась дольше, чем мы бы хотели, и привела к появлению серьезных внутренних трений. Это был хороший урок для нас, суть которого заключалась в том, что новые изменения должны вноситься в инфраструктуру при более непосредст- венном участии со стороны команды разработчиков.
Процесс тщательного отбора и оценки имеет значение как для новой, так и для существующей технологии. В случае новой технологии (новой вообще или новой для вашей организации) задайте себе следующие вопросы:
t
Каковы известные риски новой технологии?
t
С какими неизвестными моментами вы можете столкнуться?
t
Какие проблемы невозможно решить в рамках существующей технологии?
Расширенное внедрение практик
формирования близости
Безупречный постмортем (https://codeascraft.com/2012/05/22/blameless- postmortems/) с целью формирования культуры непрерывного улучше- ния.
— @0x74696d at @dramafever
Мне очень приятно, когда @0x74696d ссылается на @codeascraft в дис- куссии, посвященной трактовке сбоев со стороны @dramafever. Спасибо за помощь в обучении, Etsy!
— Bridget Kromhout (@bridgetkromhout)
256
Часть IV. Инструменты
Эти твиты, написанные в феврале 2015 года, иллюстрируют нарастающую тен- денцию формирования близости между компаниями, достигаемую посредством обмена знаниями. Кромхаут заявила, что DramaFever адаптировала безупречные постмортемы для использования техническими командами.
В DramaFever также поощряется самообучающаяся организация с помощью обзора кода. Помимо проверки кода Кромхаут описала культурные проблемы, вызванные быстрым ростом и необходимостью в коррекции понимания между командами. При этом используется метод «улучшенной координации за счет про- яснения ожиданий о взаимодействии сервисов. Это позволяет небольшим группам разработчиков преследовать свои собственные идеи, сохраняя при этом стандарты организации на высоком уровне».
В DramaFever поощряется прозрачность. Как говорит Кромхаут, «прямо сейчас разработчики получают полный доступ к сервисам AWS в среде разработки.
Мы также активизировали IAM-доступ в режиме чтения». Благодаря подобной прозрачности сотрудники могут учиться и наблюдать непосредственно из среды разработки, которая реплицирует производство и ответы на вопросы об использо- вании производства в реальном мире по мере их возникновения.
Поскольку DramaFever эксклюзивно использует технологию AWS, не требуется центр обработки данных. Также отсутствуют требования к сотрудникам по поводу явного присутствия в специфической среде. Команда DramaFever, насчитывающая примерно 120 человек, в основном находится в Филадельфии и в Нью-Йорке, а некоторые сотрудники трудятся в других местах. В процессе описания среды
Кромхаут сказала следующее: «Наши сотрудники находятся поблизости, в Мэ- риленде, или очень далеко, в Сеуле, и все они должны без помех выполнять одну и ту же работу».
Чтобы еще больше облегчить работу удаленных сотрудников, в конференц-залах
DramaFever установлены компактные компьютеры Chromebox. На основе такого компьютера реализуется бизнес-система организации видеоконференций. Ис- пользуется операционная система Chrome OS, камера с высоким разрешением, внешние микрофоны и колонки. По умолчанию совещания проводятся в режиме виртуального присутствия, реализованного с помощью Google Hangouts, благода- ря чему не требуется физическое присутствие в офисе.
Обратите внимание на то, каким образом инструменты и методы работы взаи- модействуют между собой внутри вашей организации и команд.
t
Каковы ценности, исповедуемые в вашей команде или организации?
t
Помогают ли инструменты реализовать эти ценности на практике или только мешают этому процессу?
t
Насколько прозрачно взаимодействуют между собой ценности и процессы?