Идентифицируйте конкретную проблему, которую вы решаете в данный момент. Прежде чем приступать к выполнению изменений, оглянитесь вокруг и проверьте, что должно быть сделано. Установите, кто заинтересован в проекте, у кого есть время, и оцените общую стоимость проекта. Отобразите различные параметры и идентифицируйте возможные проекты. Расставьте приоритеты для проектов и убедитесь в том, что вы работаете над устранением актуальных проблем.
Разбейте конкретный проект на меньшие фрагменты, которые могут выполняться и отслеживаться по отдельности. Эти фрагменты обычно проще планировать, а следовательно, легче обсуждать. Соответственно проще убедиться в том, что они являются достижимыми, реалистичными и направлены на решение нужных задач. Чтобы выполнять планирование этих проектов на высоком уровне, нужно идентифицировать людей, заинтересованных в устранении проблем. Каковы их потребности и мотивация? Как часто они собираются использовать это решение? Опишите решение в терминах конечной цели. Пообщайтесь с заинтересованными лицами и получите одобрение начальства. Все это требует затрат времени и усилий.
После идентификации проблемы и лиц, заинтересованных в ее устранении, можно приступать к подбору необходимых инструментов. Прежде чем выбрать определенное решение, рассмотрите сильные и слабые стороны различных предлагаемых решений. Также привлекайте к этому процессу заинтересованных лиц, которые помогут вам оценить потенциальные решения. Порой вы будете приходить к выводам об отсутствии подходящего решения. В этом случае вам придется изобретать и создавать необходимые инструменты самостоятельно. Подобная разработка может оказаться менее затратной для бюджета, но придется предусмотреть время и ресурсы для поддержки в долгосрочной перспективе.
И наконец, постоянно контролируйте процессы по внедрению инструментов, оценивайте влияние изменений на работоспособность решений. Специфика объектов оценки будет немного изменяться в зависимости от текущих проблем, но без проведения оценки невозможно судить о степени влияния и эффективности изменений.
ПрактикиПервая практика, рассматриваемая в этой главе, – платформа потокового видео DramaFever. На этой платформе реализован документальный сайт SundanceNow Doc Club и сайт ужасов Shudder. Компания DramaFever была основана в 2009 году, а уже к середине 2015 года она насчитывала около 120 сотрудников. Платформы DramaFever поддерживают международный контент из 15 стран, насчитывающий около 15 000 эпизодов, который предлагается 70 провайдерами контента. Аудитория контента насчитывает 20 миллионов зрителей[48]. Чтобы погрузиться в атмосферу оценки и применения инструментов (и технологий), мы поговорили с Тимом Гроссом и Бриджит Кромхаут. На момент интервью они работали инженерами по эксплуатации в DramaFever.
Вторая практика посвящена Etsy (см. главу 2). Эта глобальная торговая площадка предназначена для продажи винтажных и хендмейд-товаров. Она была основана в 2005 году Робом Калином, Джаредом Тарбеллом, Крисом Магуайром и Хаимом Шоппиком. Во втором квартале 2015 года в компании Etsy работали примерно 785 сотрудников. Помимо соавтора книги Кэтрин Дэниелс, которая поделилась своим опытом работы с Etsy, мы поговорили с инженером по работе с персоналом из компании Etsy Джоном Коуи. Благодаря этой беседе мы получили представление о том, каким образом в Etsy оценивают и используют инструменты и технологии.
Информация, используемая в обеих практиках, была получена на основе опубликованных сообщений в блогах, презентаций и архивов компаний. При рассмотрении этих практик можно найти примеры идентификации скрытых ценностей, адаптировать нужные практики, а также оценить и выбрать инструменты, используемые в среде. Но мы хотели бы напомнить читателям, что следует воздерживаться от бездумного использования любого инструмента или технологии. Также нужно учитывать причины и области применения инструментов и технологий.
Знакомство с 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 года) произошла трансформация
