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

В защиту Роба нашего Ингланда

Опубликовано 26 июня 2017
Рубрики: DevOps, Аналитика: точка зрения, Обо всём на свете, Общие вопросы менеджмента, Управление изменениями
Комментарии

Провокационный пост от Роба Ингланда (IT Skeptic), посвящённый CAB, заметка о котором недавно была опубликована на нашем портале, и не менее эмоциональный (но весьма рациональный) комментарий моего коллеги по этому поводу побудили меня высказаться немного более развёрнуто, чем предполагает формат комментариев на форуме.

Действительно в обсуждении практик DevOps у апологетов, по моему мнению, в некоторых случая наблюдаются проявления, обусловленные слишком упрощённым взглядом на вещи. Вряд ли имеет смысл без оглядки применять рецепт по отказу от CAB в абсолютно любых компаниях. Собственно, примеров классических «enterprise’ов» (крупных, распределённых компаний, с «гетерогенной, территориально распределенной» инфраструктурой, как писал Андрей Труфанов, которые бы поменяли свой процесс управления столь радикально, они не приводят.

Понятно, что любые практики (включая DevOps) имеют свою область применения. Понятно также, что в понимании границ применимости и есть основное расхождение. Это относится к любым сводам знаний и подходам: Agile, DevOps, ITSM/ITIL… Поэтому так распространены статья типа «Мифы ХХХ», в которых увлечённые адепты объясняют, почему расхожее мнение о невозможности реализации рекомендации из свода знаний/подхода ХХХ неверно. В каких-то случаях эти объяснения весьма убедительны. В каких-то… В последнем отчёте DevOps State 2017 от компании Puppet, например, авторы упоминают «миф» о неприменимости DevOps в среде, где используются унаследованные системы или коммерческие («коробочные») решения. Нет, – говорят они, – это не так. «Непрерывная поставка (Continuous delivery) может быть применима к любой системе, если она имеет правильную архитектуру» smiley [раздел отчёта «DevOps and COTS» («DevOps и коробочные решения»)]. Но, справедливости ради следует заметить, что далее в этом разделе звучит важная мысль о том, что мы должны разделять подходы к управлению нашими системами в зависимости от того, для чего они используются. Совсем кратко – если поддерживаемый ИТ-решением бизнес-процесс не является фактором дифференциации (конкурентным преимуществом нашей компании), то, может быть, проще адаптировать бизнес-процесс, а не решение? То есть, прежде чем применять те или иные инструменты, методики и подходы, необходимо оценить целесообразность их применения с точки зрения конечной задачи. 

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

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


Это означает, что мы считаем, что несмотря на рост сложности объекта управления (нашей инфраструктуры, нашей компании), мы за счёт приложения бОльших усилий по планированию, контролю и оценке, сможем сделать достижение цели изменения более предсказуемым.

Но что будет происходить с ростом сложности? По идее, начиная с какого-то уровня сложности, мы перестаём находиться в области, в которой можно гарантированно (с рациональными затратами) точно предсказывать результат. Это то, что в модели Cinefyn (ниже картинка из Wikipedia) определяет переход из области «Запутанно»(Complicated), где причинно-следственные связи между событиями, хоть и сложные, но определяемые при привлечении экспертизы должного уровня, к области «Сложно» (Complex), где связи, возможно, и есть, но во многих случаях могут быть установлены лишь пост-фактум.
Возможно, что, с учётом соображений рациональности, нам в некоторых случаях имеет смысл отказаться от веры в то, что мы можем всё оценить и спрогнозировать – дешевле (во всех смыслах, в т.ч. с учётом последствий) взять и попробовать. Мы же часто продолжаем использовать инструменты (тот же CAB в традиционном Change Management), несмотря на то, что стоимость их применения уже давно не соотносится с результатом.
Думаю, именно это имел в виду Роб Ингланд.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление изменениями и конфигурациями в ИТ
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Также по теме:

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

  • Роман Журавлёв

    Думаю, вы льстите Робу 🙂 

    Но в целом – конечно, каждому овощу свой фрукт. Помните эту распространенную метафору: единороги – лошади с рогами – просто лошади (я бы добавил ещё мертвых лошадей)?

    CAB, как и многие контроли в системах управления, это костыль, помогающий снижать риски. То же верно про, например, SLA, хотя жрецы DevOps пока и не предлагают их отменить. 

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

    Но только частью и не главной. 

    А Роб, как обычно, провокатор.

    • Nargiza Suleymanova

      Замечательно, что Роб провоцирует нас в итоге рассуждать и аргументированно спорить 🙂

    • Игорь Гутник

      Согласен, Скептик – провокатор. Спасибо ему за это!
      В данном случае провокация, как мне кажется, направлена против перекоса, обусловленного тем, что в некоторых случаях, когда мы думаем, что контроли, спроектированные для снижения рисков в детерминированной среде, будут столь же эффективными (в соотношении с ценой) в среде не детерминированной. По-моему, для людей с техническим складом ума это весьма не лишнее напоминание.
      А «жрецы DevOps» (а также Agile)  что-то совсем игнорируют Ops. Все в основном про Dev рассказывают. И описание задач эксплуатации пока во вех прокламациях сводится к автоматизации конвейера поставки (Deployment Pipeline) в инфраструктурной части (как с в старом неполиткорректном анекдоте «покорми собак и ничего не трогай»). Может быть, действительно это наше будущее? С учётом того, что я вижу вокруг, оно наступит не завтра.

  • Андрей Труфанов

    О! Класс!

    Если руководство ИТ в результате своей осмысленной деятельности переводит ключевую инфраструктуру (нам же интересна именно она, мы говорили о CAB) из состояния “Complicated” в “Complex”, то на то должны быть ОЧЕНЬ внушительные основания. Т.е. я могу себе представить, когда такое происходит в среде стартапов или на развивающихся рынках, фактически за счет того, что среда меняется очень быстро, скачкообразно, но если мы представим, например Аэрофлот и начнем говорим о системах обеспечивающих обслуживание и ремонт судов, безопасность летной эксплуатации – это за гранью моего понимания. Подход просто “взять и попробовать” будет оплачен человеческими жизнями.

    • Игорь Гутник

      Андрей, а если развернуть наоборот? Руководство продолжает управлять так, как будто находится в области Complicated, тогда как мы давно уже в зоне Complex. Это ведь странно.
      И попали мы туда не потому, что очень хотели. А в силу сложной природы экосистемы ИТ (включая сюда и ИТ-инфраструктуру, и ИТ-организацию и взаимодействие с бизнесом). Т.е. мы, возможно, в некоторых случаях уже там (в Complex), того не осознавая.
      Ещё раз речь не только о ситуациях, когда мы не можем осознать сложность Системы. Но и о ситуациях, когда контроль над Системой становится неоправданно дорогим (во всех смыслах слова). Ведь это, как раз одна из причин, по которой большинство компаний не пытается строить идеальную всеобъемлющую cmdb (или CMS), а ограничиваются инструментом достаточным для работы (включая, возможно, дополнительные контроли в CHG/REL). Точно также и с процессом CHG. В его адаптации под специфику конкретной организации возможны различные варианты. Одним из которых может быть упрощение CAB вплоть до полного отказа от него. Это, как написал выше Роман, конечно же, не может быть самоцелью. Лишь инструментом для повышения эффективности потока создания ценности реализации изменений. И принимать решение мы будет, сравнивая стоимость CAB с его отдачей (ровно об этом пишет Роб, предлагая применить подходы CAB к оценке изменений к оценке его, CAB-а,  собственной работы).
      В примере с условным Аэрофлотом на одной чаше весов человеческие жизни. И это сильно влияет на уравнение. В данном случае компания будет мириться с дорогими процедурами, обеспечивающими необходимую безопасность. При этом мы ведь, к сожалению, знаем, что 100%-гарантии это не даёт. Более того, в крупных компаниях типа упомянутой тяжеловесный CHG приводит к тому, что многие вещи не столь критичные, но важные для бизнеса улучшаются слишком медленно.

      • Андрей Труфанов

        Если мы заявляем о том, что мы таки управляем нашей инфраструктурой, то, во первых, она не должна меняться без нашего участия/информирования :), а во вторых, естественное желание менеджмента – двигаться в сторону порядка, это уменьшает и риски и стоимость.

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

        Не хочу больше это обсуждать, здесь нет предмета для дискуссии.

        • Игорь Гутник

          Андрей, продолжать обсуждение или нет, каждый участник, конечно же, решает сам.
          Хочу только заметить, что, как мне кажется, неверно было бы сводить всё к обсуждению CAB’а. На мой взгляд, ключевая тема в обсуждении – подход к управлению. И, прошу прощения за пафос, сдвиг парадигмы, предлагаемый DevOps и лежащими в его основании подходами действительно может показаться неочевидным (неестественным). Именно поэтому стоит про него добавить пару слов.
          Это вовсе не про исключения. И точно не только про стартапы.
          Возьмём для примера реальное производство. И для пущей наглядности дискретное производство. Большое количество работников различной специализации и квалификации что-то точат, пилят, собирают… В общем настоящее производство, где конечный продукт является, как сказал классик, весомо, грубо, зримо. Не какие-то там сложные и непонятные информационные системы 😉 Казалось бы, куда более детерминированный процесс. Движение деталей, материалов и людей описывается вовсе не уравнением Шредингера – всё, вроде бы, вполне определённо и понятно. Для повышения эффективности нужно только правильно всё распланировать и обеспечить выполнение плана (заниматься координацией).
          Почему так не получается на практике, хорошо описано у Э. Голдратта («Цель»). И одним из решений является переход от внешних по отношению к самой производственной деятельности контроля и координации к встраиванию в деятельность механизмов обеспечения качества и плавности потока. Разумеется, это невозможно без культурной трансформации . И, опять, это не про стартапы. Успех Lean в том числе на крупных производствах показывает, что отказ от внешнего управляющего контура возможен. И может вести в кратному повышению эффективности.

          • Андрей Труфанов

            Не могу отказать людям в праве и в удовольствии плясать на собственных граблях.

            Хочется пожелать удачи, здоровья и “держаться там” всем тем, кто собирается отказываться “внешнего управляющего контура” (не могу удержаться, приходится цитатно выделять) при наличии нескольких единиц, а лучше десятков самодостаточных (зачеркнуто: молодых и дерзких) продуктовых команд. Как бы он не назывался, CAB или “бригада машинистов поезда релизов” из SAFe.

            • Александр Тараторин

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

              Может быть, некоторым нашим компаниям тоже пора начать думать чуточку шире и гибче? Тем более что примеры есть и у нас…

              • Андрей Труфанов

                Амазон это не стартап, если мы говорим о сложившихся бизнесах магазина и облачных услуг. Эти два бизнес направления приносят Безосу почти 98% прибыли. Но у Амазона есть масштабнейшее R&D, куда они вкладывают для поиска новых путей и рынков, и там их смело можно называть стартапами. Я совсем не выступаю против гибких методологий, я только за. Это в настоящий момент наиболее эффективный способ организации труда с точки зрения растущего бизнеса, даже с учетом ограничений наследуемой инфраструктуры и квадратных бизнес-процессов.

                Точка вокруг которой закрутился спор: “ах этот ваш CAB, (читай: формальный management и governance) – одни потери и простои”. С этим я не согласен. В качестве примера могу сказать, что я в своей жизни видел, что такое лоскутная-автоматизация крупных компании и это просто не может быть эффективно. Результата (удовлетворенности бизнеса) достичь можно, но это будет дорого, долго и больно. Кто-то должен сказать продуктовой команде внедряющей CRM систему, что в компании уже есть актуальный централизованный справочник контрагентов, сотрудников и площадок, как и люди отвечающие за контент и защиту этих справочников. Кто-то должен приоритезировать, выстраивать таймлайн происходящих внедрений, чтобы они поддерживали друг друга, и уж точно не накладывались, создавая хаос и панику в рядах пользователей.

                Думать нужно всегда. И примеры есть, да.

                 

      • Олег Скрынник

        В примере с условным Аэрофлотом на одной чаше весов человеческие жизни. И это сильно влияет на уравнение. 

        Не факт. Насколько я знаю, в таких случаях вообще, и в Аэрофлоте в частности, "зона влияния" традиционного ИТ сильно сужена, а то и вырождена. Ключевые системы обслуживаются отдельным подразделением, работающим по своим правилам. Не ITSM и тем более не Agile.

        Включая разделение в орг.структуре, ответственности, функциях, инфраструктуре и, конечно, весе в компании, со всеми вытекающими.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.