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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Павел С.

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

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

    0
    0
  2. Роман Журавлёв

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

    0
    0
  3. Евгений Шилов

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

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

    0
    0
    1. Grigory Kornilov

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

      Ведь придется или разбираться что именно негативно повлияло (и отказывать эту часть) или проводить откат всего релиза.

      Я знаю 3 причины для объединения:

      1. сокращение суммарного downtime бизнес систем

      2. уменьшение восприятия пользователей о том, что IT постоянно что-то улучшает\ломает

      3. сокращение расходов на согласования

      0
      0
        1. Grigory Kornilov

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

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

          0
          0
    2. Dmitriy Zaitsev

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

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

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

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

      0
      0
  4. Александр Т.

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

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)