Кровавый энтерпрайз что значит

Песнь льда (кровавый 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.

Только не забывайте, что все ваши фантазии ограничены аудитом. И это все меняет. Жду вас в комментариях!

Модное и современное, но в кровавом энтерпрайзе

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

При этом невооружённым глазом заметно, что есть минимум два мира ИТ: тот, где всё модное и современное так или иначе становится или уже считается нормой, и тот, где всё то же самое либо не очень приживается, либо требует больших изменений, ресурсов, воли, при этом до конца непонятно, стоит ли так надрываться. Первый мир — это «единороги», «стартапы» и прочие цифровые компании. Второй — наш любимый Enterprise. Рассмотрим его немного подробнее.

Под Enterprise будем понимать бизнес, который не сводится на 100% к информационным технологиям, но очень от них зависит, потому имеет собственный ИТ-департамент. Успех бизнеса возможен только если эти технологии иметь, грамотно использовать, а ещё и развивать. Размер ИТ-департамента — сотни сотрудников, может быть даже тысячи.

Предположим, что вопросы необходимости и целесообразности как-то решены: да, мы хотим, как и все вокруг, сокращать Time to Market, непрерывно давать бизнесу новое и полезное, чтобы при этом не страдали доступность и надёжность наших решений.

Сфокусируемся на ограничениях. Что мешает обычному Enterprise успешно применять все эти модные штуки, чтобы решать новые задачи и отвечать требованиям времени?

Мы бы тоже могли как они, но есть нюансы

Известны две крайности:

Ничего не мешает. Имеющий желание — найдёт возможность. Бери и трансформируйся.
«Послушайте, мы — большая корпорация. Этого всего у нас нет и быть не может».

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

Один из вариантов: от сотрудников тех самых корпораций. Например, на нашем учебном курсе «Основы DevOps» есть финальное упражнение. Группе предлагается ответить на вопрос «Почему всей этой красоты конкретно в вашей компании никогда не будет», ответы аргументировать. Обобщение часто встречающихся ответов может выглядеть вот так:

Идеологические. Мы привыкли работать (очень грубо говоря) «по водопаду», а тут этот Agile, который требует свой «mindset» (простите за набор слов в этой фразе, пытаюсь передать смысл). Само слово mindset непонятно, тем более непонятно, что именно нужно изменить в своём mind. Отдельные граждане на специально выделенном им этаже уже все стены обклеили стикерами, но остальные, нормальные, лишь тихонько над ними посмеиваются: известно же, что Scrum — это лучший способ угробить команду, остановить работу и демотивировать сотрудников.
Структурные. Как ни крути, а Enterprise — это иерархия, в ней сила, смысл и масштаб, в ней устойчивость и понятные связи, в ней целеполагание, делегирование и отчётность. Какие ещё продуктовые команды? Кому подчиняются люди в команде, ну не владельцу же продукта? Ещё трайбы нарисуйте, ага. У каждого должен быть начальник, который знает, чем именно сейчас занят его сотрудник!
Организационные. Есть отдел, у него есть зона ответственности. Есть сотрудник, у него есть функция. Для повышения эффективности работы и ускорения решения задач в Enterprise принято организовывать сквозные процессы, налаживать горизонтальные связи. Это понятно. Но поток создания ценности? Каденции, объединяющие сотрудников разных отделов, у каждого из которых свой руководитель? Это какая-то ерунда. «Управляйте задачами, не управляйте людьми» — вы как эту сказку себе представляете в ИТ-департаменте на 1000—3000 человек? У нас задач на два порядка больше, чем людей.
Финансовые. Предприятия десятилетиями выстраивали наиболее экономически эффективную схему использования ценного человеческого ресурса, основа которой — группировка этого ресурса по специализации, а выделение на задачи/работы/проекты — по запросу, по плану, на долю времени, на ограниченный срок. А тут предлагается серьёзно задуматься про запрет на совмещение и выделение 100% времени сотрудника на один продукт. ИТ-бюджет такого, очевидно, не выдержит.
Технологические. Конвейер развёртывания для 1С? Автоматические тесты для COTS — системы сторонней разработки, нами кастомизируемой? Виртуализация нашей основной ИТ-системы, разработанной 20 лет назад, без потери производительности? Не всё так просто, коллеги, давайте будем реалистами.
Связанные с компетенциями. Два наших товарища, Даннинг с Крюгером, шепчут на ушко: «Да не парься, мы всё делаем правильно, мы лучшие, все так делают!». А если у кого-то закрадывается сомнение, то оно быстро разрушается о простые прикладные вопросы, ответы на которые нам неизвестны.

И что теперь делать?

Мне кажется, что хотя эти виды ограничений выглядят весьма категорично, ни одно из них не является стоп-фактором. Да, их устранение требует интеллекта и усилий. Да, решение не всегда очевидно. Да, универсальных рецептов пока очень мало. Но воспринимать ограничения Enterprise как данность означает, что про описанные выше задачи в существенной степени придётся забыть.

Мне представляется намного более интересным следующий вопрос: что из новых модных направлений, идей, инструментов и методов придётся адаптировать, и как, чтобы они давали значимый эффект в обычных корпорациях? Отдельные моменты достаточно очевидны — например, не стоит устраивать CustDev для бухгалтерии. Другие — менее понятны, например как изменяется роль владельца продукта? Третьи приводят к потрясающим открытиям — например, в корпорации вполне допустимо и разумно под продуктом понимать внутреннюю ИТ-систему (или несколько ИТ-систем), не стремясь включать внутрь продуктового контура наш собственный бизнес. И это мы ещё не затронули вопросы метрик, KPI и SLA, где, очевидно, тоже есть особенности.

Обращение к читателю: если у вас есть минута, можете ответить на следующие простые вопросы?

В чём отличие Кровавого Энтерпрайза от остального?

«Периодически меня разные люди спрашивают, так в чём же отличие enterprise (как правило спрашивают про ПО) от всего остального. Я для себя это сформулировал следующим образом.

Как ни странно, не цена и не vendor lock. Enterprise продукт может выглядеть как собачье говно, местами смердеть индусским кодом, что-то делать неэффективно, что-то очень неэффективно, но он всегда идёт от запросов бизнеса и решает какую-то бизнес-задачу.

Не enterprise — нет никаких гарантий, что люди шли от задачи а не хрен пойми от чего. Если это opensource — то обязательно будет желание показать "какие мы охрененные и впереди планеты всей".»

enternet

Господа, откуда есть пошел ~~русский~~ айтишный мем «кровавый энтерпрайз»?

Залез на лукоморье – нету. Погуглил – всякий шлак лезет. Ну чего в нем кровавого, кроме глаз? Да и то раз в год. Плаваю в нем много лет.

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

Ну и на работу нужно ходить к 9:00, а то заказчики могут очень удивиться. Это типа как политику нельзя публично в носу поковырять – профессиональные издержки.

Так что кому мир кровавого энтерпрайза, а кому и вполне себе мир розовых пони.

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

Ну хотя бы откровенную чернуху там не творят? «Нахер нам багтрекер, можно в почте всё решать», «Какое-такое проектирование — измерение нагрузок? Архитектуру нарисовали, вот по картинке и масштабируем», «Разработчики долго копаются по заявке? Ну так давайте исходник выпросим и сами пофиксим!»

Edited at 2015-04-29 11:47 am (UTC)

Термин возник у меня в журнале 2007-08-15

После этой даты термин встречается 2й раз, ссылка еще осталась:

Edited at 2015-04-29 12:02 pm (UTC)

Пруфы потер, дааа?

Кровавость ынтыпрайза подверждается! )

Радоваться надо. У меня все заказчики начинали с 9 и реально в это время почти ежедневно звонили, так что такую вольность я стал себе позволять позже ) Когда процесс взаимодействия стал отлажен, а служебные обязанности стали подразумевать регулярные разъезды и визиты в разные кабинеты.

Теоретически да. Но я не знаю таких мест, где бы без эпизодического привлечения разработчиков обходилось бы. Например, мы сейчас кое-что автоматизируем у некоторых российских монополистов, так и то, мне, как ведущему разработчику, иногда нужно съездить посидеть на совещаниях. Есть даже внутренняя шутка про «пора уже в Кремль на совещания ездить» ) Партнеры делают ровно так же, всегда присутствует технический специалист. Это на самом деле удобно и создает определенный фон доверия. Психологически комфортно. А когда всё сводится только к скайпу, письмам и баг-трекеру, то этот фон разрушается и начинается напряг. Ну и про прямое общение айти-структур без менеджмента тоже забывать не нужно, это просто удобно потому что разговор идет на одном языке.

Т.е. периодическое чередование вертикального и горизонтального взаимодействия — это и есть основа сотрудничества. А остальное — это просто инструменты. Они полезны, но только к ним всё не сводится.

При горизонтальном общении люди общаются преимущественно с равными по уровню ответственности. Поэтому начальник департамента у заказчика не будет звонить в саппорт, он или своим подчиненным скажет «звоните» или сам позвонит, но руководителю отдела у подрядчика. Кроме того есть определенный этикет. Например звонки через голову — от заказчика субподрядчику на практике у менеджмента почти невозможны, а у айти — ещё как возможны, но только в определенных случаях ))) Ну тут такая тема начинается, сам не всё постиг.

Короче, я бы не назвал это «доставать». Подавальщиков ключей никто доставать не будет, но с ростом ответственности в проекте будет и общение. Нормальный процесс для небольшой компании.