Портал №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, а стало быть — о росте требований к скорости выпуска продуктов и/или обновлений, важность автоматизации, скорее всего, возрастёт на всех участках, не только тестировании. Но только автоматизацией вопрос не решить. Потребуется изменение людей и порядка работы.

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

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

 

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

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

  • Андрей

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

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

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

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

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

  • Игорь

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT