Джин Ким - Руководство по DevOps

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

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

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

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

• замедляют или мешают рабочему процессу;

• являются причиной большого количества незапланированной работы;

• являются причиной большого количества запросов на поддержку;

• плохо соответствуют целям в плане характеристик архитектуры (например, производительность, стабильность, безопасность, надежность, бесперебойность работы).

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

Как пишет Том Лимончелли, «когда я работал в Google, у нас был один официальный компилируемый язык, один официальный язык сценариев и один официальный язык пользовательского интерфейса. Да, другие языки тоже так или иначе поддерживались, но, если вы работали с “большой тройкой”, вам было гораздо проще найти нужные библиотеки, инструменты и желающих работать с вами коллег» [156]. Эти стандарты укреплялись правилами рецензирования кода, а также тем, какие языки поддерживались внутренними платформами.

Ральф Лура, директор по информационным технологиям компании Hewlett-Packard, в презентации на конференции 2015 DevOps Enterprise Summer, подготовленной совместно с Оливье Жаком и Рафаэлем Гарсиа, отмечал:

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

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

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

Их целью было стандартизировать и сознательно уменьшить инфраструктуру и число конфигураций. Одним из первых было принято решение перевести всю среду Etsy на PHP и MySQL. Это было скорее философское решение, чем технологическое — в компании хотели, чтобы и в разработке, и в эксплуатации разбирались во всем стеке технологий, чтобы все могли работать в одной среде, а также читать, переписывать и исправлять чужой код. За несколько лет, как вспоминает Майкл Рембетси, тогдашний директор по эксплуатации, «мы отправили на пенсию несколько отличных технологий, полностью выведя их из эксплуатации», в том числе lighttp, Postgres, MongoDB, Scala, CoffeeScript, Python и многие другие.

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

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

Одна из методик, входящих в производственную систему Toyota, носит название блиц-обучения (или иногда kaizen blitz ): это короткий промежуток времени, полностью посвященный решению одной конкретной проблемы, иногда длиной в несколько дней. Спир объясняет: «…блицы часто проходят так: собирается группа из нескольких человек, и они концентрируются на каком-нибудь проблемном процессе… Штурм длится несколько дней, его цель — улучшение процесса, средство для достижения цели — помощь коллег вне процесса коллегам внутри него».

Спир отмечает: часто результат блиц-обучения — возникновение нового подхода к решению проблемы. Например, появляется новая схема размещения оборудования, новый способ передачи информации, лучше организованное рабочее пространство или стандартизация деятельности. Также итогом иногда бывает список возможных изменений: их стоит ввести в обозримом будущем.