Как стать автором
Поиск
Написать публикацию
Обновить

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

Вся боль внедрения Open-source в кровавом Enterprise. Читаю и слёзы наворачиваются, т.к. сам участвовал со стороны интегратора в подобных проектах. Постоянно появляющиеся из неоткуда новые хотелки заказчика, необходимость согласования внедрения со всеми подразделениями заказчика, начиная от целевого подразделения и заканчивая безопасниками, сетевиками, мимо проходившими админами, случайно услышавшими о проекте железячниками и виртуализаторами. И все эти согласования длятся неделями, потому что для заказчика это норма, а у тебя горят сроки проекта, бюджет на инженеров и сам проект не резиновый, кого-то надо взять на проект со стороны с нужными компетенциями, кто-то у заказчика уволился, поэтому процесс остановился, Covid-19 и прочее. Причём если не знать нужных людей в банке, то только сам этап согласований может занять 1 год, пока не будет потрачен весь выделенный на проект бюджет. Про желания новый продукт интегрировать с уже существующими системами даже упоминать не буду, т.к. только на эту тему можно выпустить серию объёмных книг.

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

Как один из авторов статьи, спешу согласиться и не согласиться одновременно. С одной стороны, да, хотелки меняются. С другой стороны, люди в проекте разумные, и не хотят ничего невыполнимого или бессмысленного. А интеграция с существующими системами при наличии у последних какого-никакого API не так уж и сложна. По крайней мере, здесь было не так много боли, как в интеграции с AD. Другое дело, что это уже полноценная разработка, и эксплуатации приходится погружаться в код. Но погружаться в Opensource и вообще не погружаться в код - вот это, на мой взгляд, плохо реализуемо. :)

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

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

Пфф, люди сами выбирают. Не нравится, встал и ушёл на спокойно место да ещё и с прибавкой к зарплате.

Если хочется участвовать в проекте, то как говорится "Добро Пожаловать".

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

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

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

Коробочные решения, с нормальной технической поддержкой, с предсказуемым развитием — это именно то, что нужно для подобных компаний. Open-source, DevOps, Agile — там всегда смотрятся как инородное тело, которое всё равно будет убито корпоративной культурой.

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

Я бы тут немного пофилософствовал. С одной стороны, да, коробка с нормальным вендорским саппортом - это хорошо для неIT-компаний. С другой стороны а) все крупные банки постепенно становятся IT-компаниями, и Росбанк здесь не исключение. И б) мы живём в странное время массового перехода на opensource где надо, и где не надо. Можно долго рассуждать о причинах этого явления, но оно имеет место быть. Поэтому всё это вполне в тренде, хоть и требует слома некоторых стереотипов в некоторых головах. :)

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

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

А что вы имеете ввиду под "стандартизацией процессов под некую усредненную модель"?

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

Собственно, это то, что называют "из коробки".

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

извините, вы это серьёзно? сравнивали manageiq и terraform? о_О

Почему нет? И то, и другое проходит в современном маркетинге под кодовым словом "оркестратор", поэтому их часто приходится сравнивать. Это как лазерный принтер и 3D-принтер: оба принтеры, но есть определённая разница. :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий