Портал №1 по управлению цифровыми
и информационными технологиями

Гаврила был DеvOps-адептом, DevOps Гаврила полюбил…

Опубликовано 17 ноября 2016
Рубрики: DevOps, Обо всём на свете
Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

 

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 3

  • Андрей

    Умным людям мысли приходят одновременно. О таком шнуре, как одном из интрументов, пишут Ким и Хамбл в DevOps Handbook. Там другие сложности возникают, но для ПО применимость отличная.

  • Андрей другой

    1. Пусть медленно, но до сообщества начинает доходить, что ИТ, по-сути, такая же отрасль как и все остальные и что для неё вполне применимы уже давно разработанные и успешно себя зарекомендовавшие методы управления проектированием и производством.

    2. В аналогии с автопромом конвейер – это ops, это производство услуги/продукции. Что касается Dev, то основная идея – сокращение длительности процесса проектирования и сдвиг его "влево". Сдвиг влево – это начинать тестирование еще на шаге разработки кода. Продолжая аналогию – тестировать подушки безопасности еще до того, как будет спроектирован кузов. Для этого предлагается использовать систему виртуализации сервисов. Она позволяет без особых затрат и усилий создать эмулятор различных подсистем с тем, чтобы разработчик мог оперативно протестирвоать свой код. Причем виртуализировать можно не только существующие сервисы путем записи реального трафика, но и по согласованной спецификации, когда реальных систем еще нет. Но тут есть проблема – разработчики люди  не аккуратные, я достаточно часто сталкивался с тем, что тестирование проводилось в среде разработки, поскольку разработчику было лень выполнять рутинные операции по развертыванию тестовой среды и т.д. Для решения этой проблемы и для сокращения цикла проектирвоания используется система управления версиями(Vertion control) в интеграции с ситемой автоматизации развертывания релиза(Release Automation). В идеале это выглядит так – разработчик написал код и нажиммает кнопку Chekout. В ответ на это система управления версиями сохраняет новую версию кода и автоматически, используя систему RA, запускает процессы автоматического: компилирования, сборки, развертывания  тестовой среды и виртуальных сервисов, установки новой версии продукта, подготовки тестовых данных и запуска самих тестов. Все автоматически с минимальным временем и без ошибок(забыл, заболел, ненашел и т.д.). В результате разработчик автоматически получает отчет о тестировании и может приступать к исправлению ошибок. 

    Про инициативу Била Гейтса – я достаточно давно перешел к конкурентам, последней каплей была Виста. Но единственный реальный вклад этого персонажа в ИТ как раз и состоит в том, что он первый ввел моду выпускать на рынок "сырой" продукт, в котром не только есть ошибки, но и ряд заявленных функций просто не реализован. Главное – первый на рынке. Я просто помню килотонны патчей и апдейтов, которые приходилось качать буквально на следующий день после выхода новых версий. Возможно, получив, наконец, несколько лет назад высшее образование (по специальности МАРКЕТИНГ, отнюдь не ИТ) Билл Гейтс пересмотрел свои взгляды. Будем надеяться.

  • Игорь

    Бил Гейтс – персонаж…  Рука-лицо


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM