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

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

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

Джин Ким (соавтор этой книги) называет осознание того, что контроль над изменениями и тестирование могут иметь совершенно противоположный результат, «одним из важнейших моментов моей профессиональной карьеры. Это озарение было результатом одного разговора в 2013 г. с Джоном Оллспоу и Джезом Хамблом о провале Knight Capital. Я начал сомневаться в некоторых своих основополагающих убеждениях, сформированных за последние десять лет, особенно если учесть мое аудиторское образование».

Ким продолжает: «Как бы печально это ни было, этот момент был для меня ключевым. Они не только убедили меня в том, что они правы, но мы также протестировали эти предположения в обзоре 2014 State of DevOps Reports, что привело ко многим потрясающим открытиям. Построение культуры с высоким уровнем доверия — наверное, самый большой вызов для менеджмента в этом десятилетии».

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

• добавление новых вопросов в форму запроса на внесение изменений;

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

• требование большего количества времени для разрешения на внесение изменений, чтобы правки оценивались и анализировались как должно.

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

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

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

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

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

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

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

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

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

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