Песнь льда (кровавый Enterprise) и пламени (DevOps и IaC)

    Тема DevOps и IaC очень популярна и развивается быстро. Однако большинство авторов касаются сугубо технических проблем на этом пути. Я же опишу проблемы, характерные для большой компании. Решения у меня нет — проблемы, в общем, фатальны и лежат в области бюрократии, аудита, и «soft skills».


    Раз название статьи такое, то в качестве котика выступит Дайнерис, перешедшая на сторону Enterprise

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



    Это так называемый Change Request. Вы видите примерно треть полей, которые надо заполнить из разнообразных справочников, остальные поля — в других закладках. Такой документ надо заполнить, чтобы применить скрипт к production серверу, или залить новые файлы и вообще, что-либо поменять.

    Количество полей таково, что я написал свою маленькую автоматизацию по заполнению этих полей. Причем эта страница написана так, что никакие средства автоматизации не видят ее полей, и единственным возможным решением было использовать AutoIt, чтобы тупо бить мышкой по координатам. Оцените степень отчаяния, чтобы решиться на такое:



    Так вот, берете вы jenkins, chef, terraform, nexus и прочее, и радостно деплоите все это на своем dev. Но настает время отправить это на QA, UAT и PROD. Nexus артефакт у вас есть и вы получаете письмо от DBA примерно с таким текстом:

    Уважаемый,

    Во-первых, ваш nexus вы можете себе у меня нет доступа вашему Nexus
    Во-вторых, все изменения должны быть оформлены как Change Request.
    SQL скрипты вам надо вычленить их Nexus, и приаттачить к Change Request.
    Если изменение не Emergency, сделать это следует за 7 дней то релиза (исключительно в Weekend)
    Когда ваш Change Request заапрувит куча народу, то DBA выполнит ваш скрипт и даже пришлет по почте скриншот результата.

    С уважением, ваш DBA который тут работает со времен mainframe.
    Знаете что мне это напоминает? Полуавтоматизацию: робот держит станину, а рабочий лупит по ней кувалдой. Ну действительно, какой толк в этом Nexus, если потом все делается полностью вручную?

    Но не следует в этом винить Enterprise! Он, конечно, кровавый, но вся эта бюрократия с Change Requests вынужденная и идет от аудиторов. Enterprise обязан так работать, и точка. Нельзя ему иначе. А аудит очень консервативная вещь. Сколько, например, говорилось про то, что длинные псевдо-сложные и часто меняемые пароли — плохо, но энтерпрайзы будут последним местом, где это поменяют. Также с деплоями и со всем остальным.

    Кстати, в свое время я пытался создать файл для terraform, но у меня не получилось. Споткнулся на значении тега 'Project Accounting Billing Code', который мне так и не удалось узнать — не хватило soft skills.

    Я даже не беру тему пассивного луддизма — ой, ваша автоматизация угрожает моей job security, учиться ничему новому я не хочу, поэтому буду тихо саботировать.

    Ну и какое может быть в принципе решение? У системы ITSM крайне примитивный API чтобы автоматически генерить документы. Да и вообще, большинство таких систем идет из времен мейнфреймов. Может кто знает действительно современные системы ITSM? Может кто имеет успешный опыт интеграции современных DevOps и бюрократии? Речь, конечно же, идет не про чисто продажные сайты, где реально может быть деплой каждый день, а, например, банковскую сферу, которая под аудиторами и очень сильной изоляцией higher environments.

    Только не забывайте, что все ваши фантазии ограничены аудитом. И это все меняет. Жду вас в комментариях!
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 10

      0
      Соболезную) похожие условия последнее время (последние 4 года в 2 разных компаниях) наблюдаю и к счастью удавлось немного это сдвинуть с мертвой точки. Самое наверное сложное — сдвинуть с мертвой точки восприятие Dev и Оps, которым ваш этот DevOps побоку. Тоесть стоит начать с решения именно проблем людей, который там работают, принести им чтото новое и показать полезность стратегии, тогда собственно нововведения, приятные вам будут проходить легче.
        +2

        Ммм, Remedy. Наблюдал два вида change management process и DevOps:


        1. Не-ИТ компания на другом конце планеты. «Окей, мы вам сделаем этот доступ, уже сделали заявку, но CAB соберётся через какое-то время, надо подождать». Через четыре часа после первого письма доступ появляется.


        2. Не самый маленький оператор всего на этом конце планеты. Вопль самопровозглашенного DevOps-а: «да выключите уже этот @#%! Puppet! Он задолбал перетирать то, что я руками в конфигурации на хостах пишу!»


        • UFO just landed and posted this here
            0
            О, как это знакомо!
            +3

            Это просто ужасно. Я думал, у меня у одного дико бомбит от этого, а остальные просто принимают это как должное. Работа в энтерпрайзе — это обхаживать полных болванов ради малейшего чиха. Я раньше думал, что itsm делает из бардака порядок, но в реальности он делает из бардака формализованный бардак, хранимый идиотами на протяжении десятилетий.
            Девопс в энтерпрайзе это полная жесть, это выступать в роли паровоза, за счёт невероятных усилий которого все остальные едут 1 мм в час.
            Бегите из энтерпрайза, психика целее будет.

              +1

              Не знаю что имел ввиду автор под современными itsm системами, но банальный micro focus service manager ( бывший hpsm) имеет rest api через который можно любой документ заполнить. Ну если это включено конечно.
              В остальных enterprise itsm системах думаю все примерно так же. Я к тому, что дело не в системах обычно, а в нежелании тех кто их поддерживает и администрирует сделать нормальное взаимодействие системы с окружением.

                +4
                Большинство ритуалов релиз менеджмента на местах появились не просто так. Они следствие боли случившейся в прошлом. В легком варианте боль выражалась в переработках и emrgency break-fix, в тяжелых и особо тяжелых это лишений премий, увольнения, штрафы от регуляторов. Ни один PM(и выше) в здравом уме не примет все эти риски ради того чтобы линейному заменяемому разработчику стало «хорошо».
                Если хочется что-то менять, то:
                1. Разработку изменения начинать с вопроса: «Какую конкрентную боль/риск это изменение снижает или решает в масштабе существующего процесса?»
                2. PoC должен показывать реальные измеримые изменения на -N ошибок развертывания/+N сохраненных денег или часов
                3. Изменение не должно создавать новых проблем на организационном уровне.
                4. Забыть о быстрых результатах. От успешного PoC до успешного внедрения в энтерпрайзе пройдет год и более.
                5. Энтерпрайзу в целом существующее положение дел норм. Если нет, то трасформации начинаются далеко за пределами ответственности отдела разработки.
                  0

                  Это так, но как вы думаете, на каком рубеже остановится проникновение девопс в энтерпрайз?

                    0
                    Ну вот пусть PM и выше сами устраивают у себя девопс, раз не считают, что «линейным разработчикам» должно быть комфортно работать.
                    0
                    Дима, ты читал The Phoenix Project и DevOps Handbook? Там немного описывается, как подружить эти вещи. Вкратце — автоматизация трекинга изменений. В идеале — отсутствие апрувов. Да, может повышаться риск, но это компенсируется легкостью процесса деплоя, а значит, легкостью накатывания фиксов. Список изменений используется просто как история, чтобы понять, что кто и что сломал. Правда, там не про регулированный энтерпрайз.
                    P.S. The Phoenix Project — художка, стоит почитать хотя бы ради лулзов. Смех будет перемежаться со слезами.

                    Only users with full accounts can post comments. Log in, please.