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

Другие технологии, укрепляющие общие цели, — чаты, например IRC, HipChat, Campfire, Slack, Flowdock и OpenFire. Чат позволяет быстро обмениваться информацией (в отличие от заполнения форм, обрабатывающихся с помощью предварительно определенных рабочих процессов), дает возможность пригласить других специалистов по мере необходимости и вести журналы истории, заполняющиеся автоматически. Они могут быть проанализированы при разборе событий.

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

Однако среда быстрых коммуникаций, предоставляемая чатом, может иметь и обратную сторону. Как отмечает Райан Мартенс, основатель и технический директор компании Rally Software, «в чате, если кто-либо не получает ответа через пару минут, считается нормой, что можно отправить вопрос снова и делать это, пока вы не получите необходимый ответ».

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

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

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

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

В этой главе мы начнем разбираться, как лучше организовать себя для достижения целей потока создания ценностей. В конце концов то, как мы организуем команду, повлияет на то, как мы будем работать. В 1968 году доктор Мелвин Конвей провел известный эксперимент в контрактной исследовательской организации. Восьми сотрудникам было поручено написать компиляторы языков COBOL и ALGOL. Он отметил: «После некоторых первоначальных оценок сложности и необходимого времени пять человек были назначены на написание компилятора COBOL, и три — компилятора ALGOL. В результате компилятор COBOL выполнял компиляцию в пять проходов, компилятор ALGOL — в три».

Эти наблюдения послужили основой того, что сейчас называют законом Конвея, гласящего: «Организации, проектирующие системы… производят их, копируя структуры коммуникаций, сложившиеся в этих организациях… Чем крупнее организация, тем менее она гибкая и тем сильнее выражен характер этого явления». Эрик Реймонд, автор книги The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, придумал упрощенный (и сейчас более известный) вариант закона Конвея, изложенный в словаре Jargon File [46]: «Организация программного обеспечения и организация команды разработчиков программного обеспечения будут совпадать»; обычно упрощается до «если над компилятором работают четыре группы, то получите четырехпроходный компилятор».

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