Книга: Руководство по DevOps

Используйте технологии, работающие на достижение целей компании

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

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

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

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

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

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

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

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

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

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

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

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

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