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

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

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

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

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

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

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

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

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

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

Логичный момент, когда нужно проводить анализ, — перед отправкой кода в систему управления кодом, где изменения потенциально могут привести к глобальному сбою. Как минимум рецензирование должен проводить ваш непосредственный коллега, но для областей с более высоким уровнем риска, например для баз данных или критичных для бизнеса компонентов со слабым покрытием автоматизированными тестами, может потребоваться более глубокий анализ эксперта (например, инженера по информационной безопасности или инженера по базам данных) или же несколько разных рецензий от разных специалистов («+2» вместо «+1»).

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