DevOps, похоже, достигает пика цикла зрелости технологии (hype cycle) от Gartner. Это слово стало настолько модным, что употребляется во всевозможных сочетаниях и смыслах. А количество статей и заметок с заголовком «DevOps и… <подставить любое слово>» или «DevOps невозможен без … <подставить любое слово>» уже не поддаётся счёту.

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

Рассуждая на прошлой неделе в статье «У вас не DevOps, если вы не готовы дёргать за верёвку» («You’re Not Doing DevOps if You Can’t Pull the Cord») о применимости подходов бережливого производства (Lean) к разработке программного обеспечения, Питер Вотерхауз фокусирует внимание на концепции шнура-андон.

Специальный шнур, появившийся изначально на производстве TOYOTA, позволял сигнализировать о любых проблемах, возникающих на любом из участков конвейера. Любой сбой, ошибка в выполнении операции и так далее – любой сотрудник, обнаруживший проблему дёргает андон. Ранее это приводило к включению звуковой сигнализации и зажиганию сигнальной лампы на соответствующем участке. Сейчас нередко – это ещё и вывод на центральный монитор номера проблемного участка. И, если после включения сигнала устранить проблему (в том числе с помощью прибежавшего мастера) не удаётся до момента, когда изделие должно переместиться на следующий участок, конвейер останавливается.

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

При чём тут разработка ПО?
Питер в своей статье обращает внимание на то, что андон-шнур фактически является механизмом эскалации. И возможность для всех сотрудников использовать механизм эскалации, причём механизм довольно серьёзный, вплоть до остановки конвейера – это мощный инструмент в борьбе за качество.
Сравнивая полный цикл разработки программного продукта с производственным конвейером, автор говорит о том, что андон-подход применим и в ИТ-сфере.

Признавая, что характер и количество возможных ошибок в разработке ПО, могут существенно отличаться, и, более того, часть ошибок будет обнаружена только в эксплуатации (уже пользователями), автор считает, что можно и нужно очертить круг областей, проблемы в которых должны быть выявлены на этапе производства. «Никто ведь не предлагает тестировать автомобильные подушки безопасности на пользователях», – пишет Питер, – «то же относится и к вопросам безопасности разрабатываемого ПО (особенно если речь идёт о критичных системах)».

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

Это требует мужества (остановить конвейер, когда «у нас тут план горит!»), это требует определённой культуры в компании. Это требует поддержки со стороны руководства. Здесь можно вспомнить инициативу Билла Гейтса Trustworthy Computing, запущенную в Microsoft в 2002 году. Объявление вопросов безопасности и надёжности приоритетными, не осталось просто декларацией, а привело к существенным усилиям, направленным в этом направлении. В том числе – в ущерб скорости выпуска продуктов.

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

Разумеется, поскольку автор рассуждает о DevOps, а стало быть – о росте требований к скорости выпуска продуктов и/или обновлений, важность автоматизации, скорее всего, возрастёт на всех участках, не только тестировании. Но только автоматизацией вопрос не решить. Потребуется изменение людей и порядка работы.

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

Таким образом, из статьи можно сделать следующий вывод.
Внедрение в компании-разработчике ПО механизмов и культуры андон, несмотря на то, что, на первый взгляд, ничего, кроме торможения этот подход не даёт, позволит не только повысить качество выходного продукта, но «встроить» качество во все процессы производства и взаимодействия с потребителями. А при разумной организации и автоматизации обеспечит и требуемую скорость вывода готового продукта.

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы