Джин Ким - Руководство по 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 ): это короткий промежуток времени, полностью посвященный решению одной конкретной проблемы, иногда длиной в несколько дней. Спир объясняет: «…блицы часто проходят так: собирается группа из нескольких человек, и они концентрируются на каком-нибудь проблемном процессе… Штурм длится несколько дней, его цель — улучшение процесса, средство для достижения цели — помощь коллег вне процесса коллегам внутри него».