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

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

В обзоре 2014 State of DevOps Reports компании Puppet Labs одним из ключевых открытий было то, что высокоэффективные организации больше полагались на рецензии коллег, а не на внешнее одобрение изменений. На рис. 41 показано: чем больше компании зависят от получения разрешений, тем хуже их результаты и в отношении стабильности (среднее время восстановления сервиса и доля неудачных изменений), и в отношении производительности (время на развертывание, частота развертываний).

Производительность в IT

Рецензии коллег vs Получение разрешений

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

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

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

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

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

Обеспечьте условия для координации и планирования изменений

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

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

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

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

Введите практику рецензирования изменений