Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Sprouter размещался между фронтэнд-приложениями PHP и базой данных Postgres, обеспечивая централизованный доступ к базе данных и скрывая реализацию БД от приложений прикладного уровня. Проблема в том, что внесение любых изменений в бизнес-логику приводило к значительным трениям между разработчиками и администраторами баз данных. Как заметил Снайдер, «почти для любой новой функциональной возможности сайта требовалось, чтобы администраторы баз данных написали для Sprouter новую хранимую процедуру. В результате каждый раз, когда разработчики хотели добавить новые функциональные возможности, им было необходимо содействие администраторов баз данных, а его нередко нельзя получить, минуя множество бюрократических процедур». Другими словами, существует зависимость разработчиков, создающих новые функциональные возможности, от администраторов баз данных. Задачи, порожденные этой зависимостью, должны в списке приоритетных быть скоординированы с разработчиками и осуществляться во взаимодействии с ними. В результате работа ждет своей очереди, время тратится на совещаниях, а итог появляется намного позже, чем мог бы. Это происходит из-за того, что Sprouter создал тесную взаимосвязь между разработчиками и администраторами баз данных, не давая разработчикам возможность самостоятельно разрабатывать, тестировать и развертывать их код в производство.

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

Обе проблемы связаны со Sprouter, и их возможное решение может быть объяснено законом Конвея. В компании Etsy первоначально было две команды, разработчики и администраторы баз данных. Каждая отвечала за два уровня служб: уровень логики приложений и уровень хранимых процедур. Две группы работали над двумя уровнями именно так, как предсказывает закон Конвея. Sprouter был предназначен для облегчения жизни обеим командам, но он работал не так, как ожидалось: стоило бизнес-правилам измениться, как вместо изменений на двух уровнях потребовались изменения в трех (приложение, процедуры, а теперь еще и в Sprouter). В результате сложность координации и определения приоритетности между тремя командами значительно возросла и вызвала проблемы с надежностью.

Весной 2009 г. в ходе того, что Снайдер называл «великим культурным преобразованием в компании Etsy», к компании в качестве технического директора присоединился Чад Дикерсон. Дикерсон привел в движение множество вещей, включая крупные инвестиции в стабильность сайта, дал разработчикам возможность самостоятельно выполнять развертывание кода в производство, а также начал занявшую два года ликвидацию Sprouter.

Для этого команда решила переместить всю обработку бизнес-логики из уровня базы данных на уровень приложений, устраняя необходимость Sprouter. Исполнители создали небольшую группу, написавшую на языке PHP уровень объектно-реляционного сопоставления (ORM — Object Relational Mapping)[47], что позволило разработчикам внешнего интерфейса обращаться непосредственно к базе данных и сократило число команд, задействованных в изменении бизнес-логики, с трех до одной.

Как описывал Снайдер, «мы начали использовать ORM для любых новых областей сайта и постепенно переносили небольшие части нашего сайта из Sprouter в ORM. Нам потребовалось два года для переноса всего сайта и отключения Sprouter. И хотя все это время мы недовольно ворчали на Sprouter, он, несмотря на это, оставался в производственной среде».

За счет устранения Sprouter были также ликвидированы проблемы, связанные с ситуациями, когда несколько команд нуждаются в координации для внесения изменений в бизнес-логику. Сократилось количество случаев передачи заданий от одной команды к другой, значительно увеличились скорость и успешность внедрения в производство, повысилась стабильность сайта. Кроме того, поскольку небольшие команды теперь могут самостоятельно разрабатывать и развертывать код, не привлекая новые команды для внесения изменений в другие области системы, увеличилась производительность труда разработчиков.

Sprouter был удален из производственной среды и репозиториев версионного контроля компании Etsy в 2001 г. Как сказал Снайдер, «класс! Отличные ощущения!»[48].

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

Архетипы организационной структуры