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

Неотправленное письмо боссу в кровавом Enterprise

Хоть я и интроверт, но с soft skills у меня неплохо. Поэтому я стараюсь придерживаться принципа:

Having a lot to say.

Вариацией пункта 2 являются неотправленные письма менеджерам. Для ускорения процесса они пишутся в голове. Однако иногда хочется поделиться рассуждениями, чтобы не держать все в себе.

Небольшая предыстория

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

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

О прогрессорстве в кровавом Enterprise

На самом деле, американец, я благодарен за ту задачу. Это была «вкусная» задача. Мне было интересно, и я многое узнал. Конечно, обидно, что то что я сделал, почти не использовали. Но теперь я понимаю, что это было неизбежно.

Такого рода системы не живут сами по себе в вакууме. Это не WinZip и не Total Commander. У них есть привязка к Active directory, пермиссии пользователей, каталог серверов и многое другое, за чем кто-то должен следить.

Завод по производству роботов? Да уже через пару дней он остановится. Разве что из силовых балок строения сделают мечи. Технология должна быть адекватна умениям туземцев. иначе она не приживется. Ну или приживется только как карго культ.

Автоматизация никому не нужна

Я ждал первого использования этих jobs, вопросов и возможных проблем. Документация на Confluence ждала своего часа

потому что отлаживать это сложно

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

В другой части фирмы у меня автоматизации работает и используются. Такой уютный пузырь. Конечно, если я уйду из фирмы, или меня уйдут из фирмы, то вскоре все это перестанет работать. Но на функционирование enterprise это никак не повлияет.

Теория гандикапа

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

Зачем павлину хвост? Ведь это же неудобно. Ответ дает теория гандикапа. Самец демонстрирует признак, который показывает, что он не только способен выжить, но и имеет дополнительные ресурсы, а это важно при размножении.

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

У homo sapiens, с его экстремально сильным поведенческим половым диморфизмом, это проявляется во всей красе. Пропустим Бентли у мужчины, который представляет тот самый мешок с углем и перейдем к самкам.

Свойство

Суть гандикапа

Message

Требуют времени для ухода

Цепляются за ветки в первобытном лесу

Надо мыть, а то заведутся вши

Живет в безопасности, по лесу бегать не надо

Не может быстро бегать

«я живу в безопасных условиях»

Не может быстро бегать

«я живу в безопасных условиях»

Не могу работать и защищать себя

Безопасные условия жизни

Заметная одежда с рюшечками

Видима для хищников

Безопасные условия жизни

Чистый дом (для детей)

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

Источник

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

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

Источник

Миграция данных в кровавом энтерпрайзе: что анализировать, чтобы не завалить проект

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

Для начинающих поясню, что миграция идет по такой схеме: источники → преобразование данных (отвечает ETL или шина) → приемник.

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

Работали так:

Советы пригодятся тестировщикам, внедренцам enterprise-продуктов, системным интеграторам-аналитикам. Приемы универсальны для реляционных баз, а во всю мощь раскрываются на объемах от миллиона клиентов.

Но сначала — об одном из главных мифов системной интеграции.

Документация и архитектор помогут (на самом деле нет)

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

Выходит скверно. Только анализ покажет, что́ реально творится в базе. Если не залезть в данные с засученными рукавами и увеличительным стеклом, миграция пойдет наперекосяк.

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

Обычная история: в таблице клиентов есть поле «СНИЛС», на бумаге очень важное. Но когда я смотрю в данные, то вижу — поле пустое. В итоге заказчик соглашается, что целевая база обойдется без поля для СНИЛС, раз данных все равно нет.

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

Бизнес-процессы безупречны лишь на бумаге. Ранним утром в оперофис банка на окраине Выксы заходит невыспавшийся оператор Анатолий. Под окном всю ночь орали, а с утра Анатолий поругался с девушкой. Он ненавидит весь мир.

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

Хаос побеждает бизнес-процессы, очень стройные на бумаге.

Системный архитектор знает не все. Дело снова в почтенном сроке жизни enterprise-систем. За годы, что они работают, архитекторы меняются. Даже если поговорить с действующим, решения предыдущих всплывут сюрпризами во время проекта.

И будьте уверены: даже приятный во всех отношениях архитектор сохранит в тайне свои факапы и костыли системы.

Интеграция «по приборам», без анализа данных — ошибка. Я покажу, как мы в HFLabs изучаем данные при системной интеграции. В последнем проекте я анализировала только выгрузки из ETL. Но когда заказчик выдает доступ к исходным данным, их обязательно проверяю по тем же принципам.

Заполненность полей и null-значения

Самые простые проверки — на заполненность таблиц в целом и на заполненность отдельных полей. С них и начинаю.

Сколько всего заполненных строк в таблице. Самый простой запрос из возможных.

Получаю первый результат.

Здесь смотрю на адекватность данных. Если в выгрузке для крупного банка пришло только два миллиона клиентов, явно что-то не так. Но пока все выглядит ожидаемо, двигаюсь дальше.

Сколько строк заполнены по каждому полю отдельно. Проверяю все столбцы таблицы.

Первым попалось поле с днем рождения, и сразу любопытно: данные почему-то вообще не пришли.

Если в выгрузке все значения в поле — «NULL», первым делом смотрю в исходную систему. Возможно, там данные хранятся исправно, но их потеряли при миграции.

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

Иду дальше, к полю с ИНН.

В базе 100 миллионов человек, а ИНН заполнены только у 65 тысяч — это 0,07%. Такая слабая заполненность — сигнал, что поле в базе-приемнике, быть может, не нужно вовсе.

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

Добралась до флага удаления клиента.

Флаги не заполнены. Это что же, компания не удаляет клиентов? Смотрю в исходную систему, разговариваю с заказчиком. Выходит, что да: флаг формальный, вместо удаления клиентов удаляют их счета. Нет счетов — клиента как бы удалили.

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

Дальше — табличка с адресами. Обычно в таких таблицах что-то не так, потому что адреса — штука сложная, вводят их по-разному.

Проверяю заполненность составляющих адреса.

Адреса заполнены неоднородно, но выводы делать рано: сначала спрошу у заказчика, для чего они нужны. Если для сегментации по странам, все отлично: данных достаточно. Если для почтовых рассылок, тогда проблема: дома́ почти не заполнены, квартир нет.

В итоге заказчик увидел, что ETL брал адреса из старой и неактуальной таблички. Она в базе как памятник. А есть другая таблица, новая и хорошая, данные нужно брать из нее.

Во время анализа на заполненность я особняком ставлю поля, ссылающиеся на справочники. Условие «IS NOT NULL» с ними не работает: вместо «NULL» в ячейке обычно «0». Поэтому поля-справочники проверяю отдельно.

Изменения заполненности полей. Итак, я проверила общую заполненность и заполненность каждого поля. Нашла проблемы, интеграторы исправили ETL-процесс и снова запустили миграцию.

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

Заполненность всех полей.

Между выгрузками исчезли 5 миллионов записей. Иду к интеграторам, задаю типовые вопросы:

А вот дни рождения в новой выгрузке появились, как я и ожидала.

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

Что проверять, в двух словах.

Длина значений в строковых полях

Я следую одному из базовых правил тестирования — проверяю граничные значения.

Какие значения слишком короткие. Среди самых коротких значений полно мусорных, поэтому здесь интересно копнуть.

Таким способом я проверяю ФИО, телефоны, ИНН, ОКВЭД, адреса сайтов. Всплывает бессмыслица вроде «A*1», «0», «11», «-» и «. ».

Все ли в порядке с максимальными значениями. Заполненность поля впритык — маркер того, что при переносе данные не влезли, и их автоматом обрезали. MySQL откалывает такое лихо и без предупреждений. При этом кажется, что миграция прошла гладко.

Таким способом я нашла в поле с типом документа строку «Свидетельство о регистрации ходатайства иммигранта о признании ег». Рассказала интеграторам, длину поля поправили.

Как значения распределяются по длине. В HFLabs таблицу распределения строк по длине мы называем «частотка».

Здесь я выискиваю аномалии в распределении по длине. Например, вот частотка для таблицы с почтовыми адресами.

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

Что проверять, в двух словах.

Популярные значения

Я делю на три категории значения, попадающие в топ популярных:

Популярные значения я ищу в полях трех типов:

Для строковых полей — каковы топ-100 популярных значений. Если хочется, можно взять и побольше, но в первые сто значений обычно помещаются все аномалии.

Я проверяю таким способом поля:

Бывает, что найденная проблема — и не проблема вовсе. Однажды я нашла в базе подозрительно популярный номер телефона. Оказалось, что этот номер клиенты указывали как рабочий, а в базе просто много сотрудников одной организации.

Попутно такой анализ покажет скрытые поля-справочники. Этим полям по логике вроде как не положено быть справочниками, но фактически в базе они таковыми являются. Например, выбираю популярные значения из поля «Должность», а их всего пять.

Возможно, компания обслуживает только пять профессий. Не очень похоже на правду, верно? Скорее, в форме для операторов вместо строки сделали справочник и забыли отсыпать значений. Важный вопрос здесь: разумно ли вообще заполнять должности через справочник. Так через анализ данных я выхожу на возможные проблемы с операторским софтом.

Для полей-справочников и классификаторов проверяю, какова популярность всех значений. Для начала разбираюсь, какие поля — справочники. Скриптами здесь не обойтись, беру документацию и прикидываю. Обычно справочники создают для значений, число которых конечно и относительно невелико:

Обычно в строковых-полях справочниках лежит такое.

Популярные значения в полях-классификаторах я проверяю, чтобы отловить недостаток вариантов. Сталкивалась с такими случаями.

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

Что проверять, в двух словах.

Консистентность и кросс-сверки

От анализа данных внутри таблиц перехожу к анализу связей.

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

Если запрос дал дельту, значит, не повезло — в выгрузке есть несвязанные данные. Так я проверяю таблицы с телефонами, договорами, адресами, счетами и так далее. Однажды во время проекта нашла 23 миллиона номеров, просто висевших в воздухе.

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

Нет ли дублирования первичных ключей в разных таблицах. Иногда одинаковые сущности хранят в разных таблицах. Например, разнополых клиентов. (Никто не знает, зачем, потому что структуру утверждал еще Брежнев.) А в приемнике таблица единая, и при миграции айдишники клиентов будут конфликтовать.

Я включаю голову и смотрю на структуру базы: где возможно дробление схожих сущностей. Это могут быть таблицы клиентов, контактных телефонов, паспортов и так далее.

Если таблиц со схожими сущностями несколько, делаю кросс-сверку: проверяю пересечение идентификаторов. Пересекаются — клеим заплатку. Например, собираем айдишники для единой таблицы по схеме «название исходной таблицы + ID».

Что проверять, в двух словах.

Что еще проверить

Нет ли латинских символов там, где им не место. Например, в фамилиях.

Так я отлавливаю замечательную латинскую букву «C», которая совпадает с кириллической. Ошибка неприятная, потому что по ФИО с латинской «C» оператор никогда не найдет клиента.

Не затесались ли посторонние символы в строковые поля, предназначенные для цифр.

Проблемы всплывают в полях с номером паспорта РФ или ИНН. Телефоны — то же самое, но там я разрешаю плюс, скобки и дефис. Запрос выявит и букву «O», которую поставили вместо нуля.

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

Все, что нужно — SQL и Excel

Чтобы анализировать данные, дорогое ПО не нужно. Хватает старого доброго Excel и знания SQL.

Excel я использую, чтобы собрать длинный запрос. Например проверяю поля на заполненность, а в таблице их 140. Писать руками буду до морковкиного заговения, поэтому собираю запрос формулами в excel-табличке.

_{В столбец «A» вставляю названия полей, беру их в документации или служебных таблицах. В колонке «B» — формула для склеивания запроса}

Вставляю названия полей, пишу первую формулу в колонке «B», тяну за уголок — и готово.

_{Работает и в Excel, и в Google Docs, и в Excel Online (доступен на «Яндекс.Диске»)}

Анализ данных экономит вагон времени и спасает нервы менеджеров. С ним проще уложиться в дедлайн. Если проект крупный, аналитика сохранит миллионы рублей и репутацию.

Не цифры, а выводы

Что я собираю для отчета:

Иногда заказчик, увидев проблему, отвечает: «Не парьтесь, не обращайте внимания. Закупим лишний терабайт памяти, да и все. Так дешевле, чем оптимизировать». Соглашаться на такое нельзя: если забирать все подряд, качества в приемнике не будет. Мигрируют все те же замусоренные избыточные данные.

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

Главное — найти и разрешить все вопросы, пока систему не запустили в прод. На живую менять архитектуру и модель данных — с ума сойдешь.

На этом с базовыми проверками все, изучайте данные!

Источник