Руководство по DevOps (Ким, Уиллис) - страница 204

Рис. 41. Производительность организаций с рецензированием кода выше, чем у организаций, где требуется разрешение на внесение изменений (источник: отчет DevOps Survey of Practice, 2014 г., компания Puppet Labs)

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

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

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

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

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

Однако даже в слабо связанной архитектуре, когда много команд проводят сотни независимых развертываний в день, есть риск того, что изменения будут мешать друг другу (например, при одновременном A/B-тестировании). Для уменьшения этих рисков можно использовать чаты, чтобы оповещать о планируемых правках и проактивно обнаруживать возможные накладки.

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