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

ИТ-скептик про Devops и Agile

Наш друг Роб Ингланд (IT Skeptic) решил опубликовать заметки к своим выступлениям на конференциях в этом году.

Первый в очереди – мгновенно ставший популярным в социальных сетях критический очерк о концепции Devops.

DevOps (Developers+Operations) – современный свод различных методик, направленных на продуктивную совместную работу разработчиков программного обеспечения и эксплуатационщиков (администраторов) информационных систем.

Идея Devops – прямой наследник Agile. Подход предлагает использовать комплекс мер по "разрушению стены между разработчиками и системными администраторами": единые инструменты повсеместной автоматизации, революция культуры взаимодействия, отказ от бюрократических процедур, мелкие и частые изменения продуктивной среды.

Скептик выразил крайне консервативное отношение к этой новой идее. Противопоставив ее традиционной системе управления ИТ как системой услуг (ITSM), Он считает Devops утопичной идеей, очень далёкой от реализации.

В частности, Роб приводит следующие аргументы:

Утверждение: Используя гибкую разработку ПО (Agile) мы можем контролировать риски.

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

Agile и Devops порождают риски.

У ПО есть малое число рабочих состояний. Практически все состояния ПО являются ошибочными, а иногда – катастрофически ошибочными. При увеличении числа зависимых систем, число ошибочных состояний растёт по экспоненте. Вам придётся очень потрудиться, чтобы убедить меня в том, что сделав изменения систем более частыми и быстрыми и снизив число контролей, вы не увеличите вероятность возникновения ошибочного состояния программы.

Нужно всегда помнить, что на кону деньги, причём не наши и не нашей организации. Если владельцы бизнеса считают, что ИТ должно больше рисковать, тогда вы можете использовать Devops. С вероятностью 90% они так не считают. Разработчики говорят что они не склонны к риску, но хочется взглянуть на результаты соответствующих исследований. Готов биться об заклад, что разработчики более азартны, чем сисадмины и их работодатели.

Сторонники Devops громко жалуются на "нечестные" ограничения, накладываемые теми, кто менее склонен к риску. У всех разные представления о том, что такое "честно": мнение ИТ-специалистов может отличаться от мнения Совета директоров. Однако именно Совет директоров – управляющие – решает, что именно является "честным". Остальные должны подчиняться, хотя бы и против желания.

Я согласен с тем, что "высокопроизводительные сотрудники работают лучше при большей свободе действий". В сфере ИТ есть сотни миллионов и разработчиков и системных администраторов. Они разные: от "высокопроизводительных", до тех, кому вы не доверите приготовить яичницу. Поэтому я считаю, что сторонники Agile наивны и оптимистичны. Ни та, ни другая черта вам не пригодятся, когда нужно защищать стабильность и управлять рисками (первоочередные задачи ИТ-менеджмента). Тем более это актуально, чем больше мы привлекаем к разработке и обслуживанию ИТ внешних партнёров. Не считаю идеи Agile просвещёнными. Считаю их опасными.

Как обычно, интересен не только сам текст Скептика, но и комментарии сторонников Devops в аналогичном провокационном ключе.

Кстати, краткое описание идей и сборник статей про Devops доступны в википедии, пока только на английском. 

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

  • Павел С.

    Я согласен с тем что “высокопроизводительные сотрудники работают лучше при большей свободе действий”. В сфере ИТ есть сотни миллионов и разработчиков и системных администраторов. Они разные: от “высокопроизводительных”, до тех, кому вы не доверите приготовить яичницу. Поэтому я считаю сторонники Agile наивны и оптимистичны. Ни та, ни другая черта вам не пригодятся, когда нужно защищать стабильность и управлять рисками (первоочередные задачи ИТ-менеджмента).

    А что ITSM, или ITIL (чему там противопоставляется Devops) не напирают на свободу действий высокопроизводительных специалистов? Как же “прежде всего люди!”?

  • Мне кажется, что не напирают. Я не видел, как они это делают. “Прежде всего люди” должны принимать контроли, которые привносит в их жизнь процессный подход и приоритеты, которые туда привносит подход сервисный. Свобода при этом если и подразумевается, то лишь как осознанная необходимость.

    • Спорно. Это текст про исполнителей. От менеджеров среднего звена конечно ожидается большее. И даже от исполнителей большего требует, например CSI.

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

    • Grigory Kornilov

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

      Я знаю 3 причины для объединения:
      1. сокращение суммарного downtime бизнес систем
      2. уменьшение восприятия пользователей о том, что IT постоянно что-то улучшает\ломает
      3. сокращение расходов на согласования

      • 4. Повышение пропускной способности QA.

        • Grigory Kornilov

          ‘Пропусканая способность QA’ – не прямое value для бизнеса, имхо.

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

    • Dmitriy Zaitsev

      И рынок ждет этого апдейта месяц? Если для "кровавого энтерпрайза" это еще как-то может считаться нормальным, то для ит-компаний новой волны это неприемлемо. Чаще релизы – быстрее фидбэк от пользователей – быстрее корректировка курса. Badoo, например, релизятся два раза в день.

      Мне кажется, что многие не понимают ключевого отличия между ITSM(ITIL) и DevOps.

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

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

  • Александр Т.

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

    Реальность жизни такова, что во многих организациях в нашем динамически меняющемся мире своевременность внедрения новых решений и продуктов важнее, чем достижение близкого к идеалу качества этих решений. Такие организации ставят time-to-market выше, чем качество или стоимость, и ИТ в них должно действовать соответсвующим образом. И в этом случае Agile-подходы становятся реальной альтернативой классическим waterfall-моделям, и баланс между развитием и поддержкой смещается в другую сторону. Главное – с этим не переборщить.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM