Комментарии 77
на рынке твои навыки с каждым годом теряют в цене, потому, что другим компаниям не нужен архитектор, который ничего не знает кроме ИТ ландшафта зеленого банка.
Что характерно для зеленых, если заменить должность корпоративного архитектора да хоть на разраба 6 грейда, то заключительная часть статьи особо не изменится.
FYI, разраб 6 грейда — это примерно как дворник/студент, который вообще еще ничего не умеет, и может только приобрести квалификацию — терять ему еще нечего. Нормальные уровни начинаются примерно от 10.
Как после каждой крупной компании, квалификация временами вполне востребованная (хотя возможно разработчики редких специализаций, Hadoop, скажем, нужны далеко не каждой мелкой компании), а временами конечно, ориентирована на специфику компании. Вообще говоря, это каждый сам для себя решает, у меня был случай, когда я отказался от предложения пойти работать в Терадату, где зарплаты были ну очень хороши (+50%), а вот работа была такой, что я пришел к выводу как у автора, что с такими знаниями я буду никому не нужен уже очень скоро.
И потом, допускаю что архитектор и может ничего не знать «кроме», а разработчик будет писать обычные приложения на Spring Boot, или что у него там в стеке. А все у него там в стеке в общем-то обычное, более или менее типовое.
BTW, я знаю лично и архитекторов, которые уходили и возвращались в Сбер обратно через всего пару лет. Так что никому не нужен — ну это 100% преувеличение.
Ну или скажем вот, у автора:
>Нужно отдать должное бывшим коллегам, обучение у них выстроено грамотно.
Как по мне, как раз обучение выстроено примитивно (почти везде — я не видел чтобы было лучше). То есть, есть у компании курсы, рассчитанные на типовые профили сотрудника. И там к примеру прописано, что Data Science это такой человек, который пишет на питоне и использует юпитер и пандас — и проводящие обучение люди уперлись в это, и требуют проходить этот курс. При этом наш случай — это скала, спарк, и скажем Hue, и мы готовы всему этому учить сами — но нет, нельзя. А курс под наш профиль может даже и есть — но неофициальный. И в итоге обучение выливается в то, что надо максимально быстро сдать эти ненужные темы, и приступить наконец к реальной работе — к другой. То есть, если вы попали в мейнстрим — все нормально, если же ваша работа отличается от типовой — вы возможно будете учиться тому, что вам не пригодится вообще.
Или еще более глупый пример — нужно всем пройти курсы по Jira. Которые начинаются с того, что описывается вход в систему. То есть, будет вот такой экран, сюды логин, сюды пароль — вуаля, в таком вот аксепте. И эти курсы заставляют пройти всех, включая людей, имеющих опыт работы с Jira где-то с 2004 года, примерно. Ну ок, про мой старый опыт никто не знает, но если я в компании уже скажем лет 5, я все это время работаю с Jira, уже, потому что это целевой инструмент. Нафига мне сегодня этот вводный курс?
Ну или вот еще, что зацепило, из той же в общем оперы:
>Получается, стандарты, хоть и написаны верно, не работают.
Архитекторы спокойно могут написать, что любое взаимодействие между двумя системами должно происходить по одному стандарту, и выбрать в качестве стандарта, условно, REST. По разным причинам, например потому, что архитектор сам имеет опыт таких проектов, или потому, что таких взаимодействий реально большинство (я верю). А потом они приходят с таким стандартом к разработчикам конкретной системы, а те им отвечают — а что, наши текущие 10 терабайт в сутки вы предлагаете просунуть через REST? Разумеется пример условный, но вполне реально описывает, откуда берутся «исключения», смущающие автора. Нет одинаковых требований, нет одинаковых систем. Всякий стандарт ограничивает гибкость решения.
В общем, этот текст — обычный, имеющий право на жизнь, субъективный взгляд автора. С чем-то хочется согласиться, а что-то наоборот с моей точки зрения выглядит странным.
Не понимаю, что вас побудило разродится таким пассажем. Я в общем-то и не изрекаю несокрушимые истины. Но у меня 3 года собственного опыта в сбере + опыт собеседований 20-30 человек, уходивших из сбера. И я делаю вывод, что после сбера можешь смело понижать свой грейд на пару позиций и отметать 50% опыта как даром никому не нужного. Я просто не вижу другой такой компании, где потраченное время конвертируется в ценный опыт по настолько плохому "курсу".
Я вам в общем-то особо не возражаю — да, у любой большой компании есть много такого, изучение чего вам потом не то что не пригодится, а даже помешает. Я и про Дойче скажем могу такое сказать, да и про других тоже (и мой опыт тут порядка 15 лет работы на разные крупные компании, в основном банковской сферы). Если вы сами не развиваетесь, и не думаете об этом — вы будете деградировать. Ну разве что про разработчика, мне кажется, вы преувеличиваете. Условный миддл, которого я вижу, ничего не знает об ИТ ландшафте Сбера или любой большой компании, что я видел. Это в лучшем случае с тимлида начинается.
Я вот не вижу, чтобы моя стоимость уменьшалась на внешнем рынке после текущей работы. Что я делаю не так? Изучаю технологии, которые будут полезны при смене работы в том числе? Стараюсь держаться подальше от тех, что считаю неперспективными (в том числе и для себя)? Разумеется, любой работодатель, включая Сбер, будет рад, если вы влезете по уши в изучение его ИТ ландшафта, и станете в этом специалистом. А повышать вашу стоимость на внешнем рынке работодателю вообще не интересно.
По этому я прекрасно понимаю, что все что я знаю о конкретном бизнесе (и за что мне в общем-то платят дополнительные деньги) на следующей работе, как правило, обесценится. Но я хочу сказать, что вот это все — моя область ответственности, а не работодателя.
Получается, идеология правильная, но реализация подкачала.
А бывает и так:
Задача поставлена в одном ключе,
Воспринята в другом,
А реализована в третьем.
Какая грустная история. Сотни "затырканных" людей, мечутся по встречам и ничего не успевают...
Welcome to real Corporate World!
А есть примеры других? К примеру я работаю в РЖД - такая же картина со скоростью решения проблем и регламентами + отсебятина от сотрудников на местах.
Но ничего страшного - как то живем, внедряем что-то новое.
Мне кажется все-таки чем больше корпорация, тем больше подобных проблем - просто автор себе не представлял масштабы проблемы.
Попробуйте перестать есть советское и начать есть зарубежное.
Всегда хотел понять: почему до сих пор коды станций и грузов несут в себе информацию (и, соответственно, меняются каждый раз, когда, скажем, на станции что-то переделывают). Я понимаю, когда каждый бит был на учете, но сейчас-то зачем?
Курс по проектированию приложений от Amazon https://aws.amazon.com/ru/training/learn-about/architect/ - вы о нём?
Спасибо за статью. У меня и коллег разработчиков было всё так же, один в один. Кто-то ушел через 7 месяцев sbergile, у кого-то хватило нервов на 1,5 года. Но уволились все.
Сложилось ощущение, что архитектор в этой зелёной компании по большей части языком чешет вместо того, чтобы изучать, проектировать и документировать. Если никто вокруг не заинтересован в работе, то это прямой путь к выгоранию.
Ну так этот подход Кулик и в ВТБ принес
Простите пожалуйста, нельзя ли в статье заменить фразы "зелёный банк" на слово Sber? К чему эта ложная стеснительность? Какой-то атавизм с пикабу, ей-богу.
По поводу регламентирующих всё и вся, но несоблюдающихся стандартов, подозреваю беда в том что в стандарт не заложено требование каждый спринт выделять время для подтягивания проекта команды к стандартам, по сути - на технический долг. Кроме того, по всей видимости нет никакого штрафа за несоблюдение этих самых стандартов, а он должен быть и должен применятся к тимлиду команды, обязательно копеечный штраф, мелкий, но неприятный, как комар, зудящий над ухом.
Командам действительно записывается техдолг по несоответствию стардартам и они его копят. К сожалению, я не знаю как устроена мотивация лидеров команд, но, судя по тому, что устранять техдолг команды не стремятся, так работать выгоднее.
Совершенно не очевидно. А почему не к автору стандарта? И почему штраф, а не бонус за выполнение?
«Чисто условный» пример, взятый из совершенно реальной практики — приходит к нам команда по эксплуатации нашего софта, и говорит: «мы тут написали эксплуатационные требования». Казалось бы, нужно начать завтра же (в крайнем случае — с понедельника ;) строго соблюдать требования, и карать за невыполнение? Ан нет, не так все просто. Все требования вроде «за все хорошее против всего плохого», вполне логичные, только вот там не написано, как измерять выполнение. А раз нет ни методики, ни критериев приемки, выполнить требования в таком виде невозможно. Тем более — выполнить прямо сейчас.
И чем это отличается от стандарта? Как по мне — почти ничем.
Совершенно не очевидно. А почему не к автору стандарта?
Тимлид детектед :) А если серьёзно, применять штраф за невыполнение исполнителями требований стандарта к автору стандарта всё равно что посадить в тюрьму авторов УК за преступления злоумышленников.
На самом деле в конечном итоге решение о применении той или иной технологии/версии принимается после отмашки тимлида, посему логично что ответственность за это должен нести он.
И почему штраф, а не бонус за выполнение?
Соглашусь по размышлении с вами, система мотивации исключительно на штрафах идея так себе. Правильнее наверное будет следование более гибкой шкале - при проценте соответствия стандартам менее, допустим 80% идёт штраф, чем большее несоответствие тем штраф больше, соответственно и наоборот, если соответствие стандартам более 90% то следовательно выплачивается премия, все это в разумных пределах конечно, прошу помнить идею что штраф должен быть небольшим, но назойливым. Конечно, можно настраивать эту шкалу более тонко с течением времени или в зависимости от направления разработки.
требования вроде «за все хорошее против всего плохого», вполне логичные, только вот там не написано, как измерять выполнение
Спасибо за пример, не знаю как устроены стандарты в сбербанке, но в тексте статьи приведен случай, когда команды добиваются неприменения каких-то пунктов стандарта по отношению к своим проектам, т.е. подразумевается что стандарт достаточно, кхм, стандартизирован и точен.
Ну, «если бы мне платили доллар» за каждую штуку, внедренную на уровне корпорации, не спросив меня, я бы был миллионером как минимум. То есть к сожалению, не всегда команды спрашивают, и еще чаще — не обращают внимание на обратную связь — и это особенность больших бюрократических компаний, в том числе.
Насчет бонус vs штраф — ну да, я просто уточнил, что мотивировать можно по-разному. И в принципе я совсем не против стандартов, разумеется — надо лишь понимать, что они тоже всегда ограничены.
>подразумевается что стандарт достаточно, кхм, стандартизирован и точен.
Я не уверен, про что конкретно автор говорит, но вот например, есть у нас такой свод стандартных архитектурных стеков. И в нем к примеру, в наличии примерно два стека на базе Java, это Spring Boot, и JavaEE. И все. То есть, считается неявно, что все приложения — это что-то типа веб сервиса, и других видов не бывает. И даже ничего похожего например на ESB, типа Jboss Fuse, просто как пример. Или вообще пишем на скале?
И что прикажете делать, если мы пишем не веб приложение? Если у нас уже в наличии результат многолетней разработки приложений на условном Spark, которые в эти стеки вообще не ложатся ни в какие? Стандарты должны быть живые, и в подобных случаях исключений — дописываться. Но я подозреваю, что на это просто не хватает ресурсов.
Вот знаете, авторов некоторых законопроектов явно не помешало бы в тюрьму вместо тех «злостных преступников», которые их «нарушают» ._.
Добавлю, что есть еще направления в которых действует конкурентная система для команд вынужденных кооперировать и "соревноваться". Даже описать словами сложно что происходит, когда цель "получить баллы" и "забраться повыше" практически полностью вытесняет цель "принести прибыль". В ход идут все возможные средства...
Есть сильное подозрение, что это специфика не конкретного банка, а любой крупной организации. С ростом количества человек число связей растёт квадратично, коммуникационные "факапы" начинают превалировать над всем. Чего уж там банк - вы в чатик любого детсада\школы\соседей по району зайдите, посмотрите, как плёвые вопросы разрастаются в многочасовые ночные срачики. И это между людьми, которые друг другу ничего не должны. А когда надо сделать архитектуру, удовлетворяющую все стороны, да ещё в приемлемый бюджет, да ещё чтобы её поняли все одинаково - тут обиды, игнорирование стандартов и постоянные исключения неминуемы. И не важно, какая квалификация у участников, как они замотивированы. В этом отношении архитектору сильно сложнее, чем разработчику - деньги примерно те же, а общения (обычно неприятного) на порядок больше. Всё-таки ругаться с самим собой и своим кодом попроще, чем с парой сотен коллег :)
"Есть сильное подозрение, что это специфика не конкретного банка, а любой крупной организации."
Мне за эти же слова (в другом виде) минус поставили.
Корп. мир он такой. Всё донельзя излишне зарегулировано. На первых порах путь кажется лёгким так как идёшь по накатанной дороге, но чем дальше влез в этот мир, тем больше ограничений. Причём многие самим же собой и накладываются.
Может быть вы помните, как года три-четыре назад была очень похожая статья, только человек работал кажется админом?
Так вот, просто для примера — меня там зацепила претензия, что он потратил кучу времени на заполнение плана отпусков. То есть на бюрократию. А теперь рассказываю, как реально выглядит эта «бюрократия» — вам приходит письмо: «Заполните план отпусков, или система сделает это за вас». Вы хотите заранее забронировать за собой отпуск на Мальдивах с 10 июня? Заполняете. Вы не знаете, что будете делать через месяц? Не заполняете. Через пару недель вам приходит второе письмо: «Мы заполнили за вас план отпусков как в прошлом году».
При этом реально уход в отпуск выглядит так — вы можете уйти в любое время. Если вы свалите тогда, когда вся команда в запарке и полно работы — ну на вас возможно посмотрят косо и обидятся, но к годовому графику отпусков это не имеет никакого отношения.
Можно увидеть тут бюрократию? Наверное да. Но как по мне, претензия к этому процессу — не более чем пустая придирка.
>многие самим же собой и накладываются.
Именно так. Многие ограничения — от людей. Никто не может вас заставить посещать кучу встреч, на которых вы не нужны. Никто не может вас заставить посещать встречи без четкой повестки, которые обычно не приносят результата. Откажитесь, попросите сформулировать повестку.
Во время написания статьи у меня родилась мысль о том, что на текущем месте работы я, по сути, собираюсь сделать то же самое, просто масштаб пока не такой. Разрабатываю стандарты, внедряю архитектурный комитет, регламентирую требования к системам. Я начал понимать, что, если буду действовать так дальше, то неизбежно приду к такому же результату. Сейчас, на текущем месте работы, у меня есть возможность построить работу подразделения архитектуры так, как я вижу правильным, но, оказывается, я не знаю другого пути. Мне кажется, это хорошая тема для развития, буду искать другие пути реализации архитектурных процессов.
Смотрите, сама по себе работа на процессах - не страшна. При одном важном условии: если стек процессов прозрачен и за техническими явно видны бизнесовые. Да, будет специфика конкретной компании, всегда. Сами процессы могут быть неоптимальными, более того, в них легко будут углы, которые все срезают. Но каждый участник сможет понять, почему вот это делается так, а не иначе. И в итоге сможет свой опыт вложить в совершенствование системы и наоборот, сможет опытом работы в компании обогатить свои навыки.
Жёппа начинается, когда бизнесовые и технические процессы стыкуются через интерфейс "поговорить с N". Вот тогда да, приходится именно что зазубривать как что работает: когда писать заявку, когда позвонить, что нужно кому предлагать при торговле. И человек действительно потихоньку (а иногда и очень быстро) превращается в специалиста по работе в таком-то отделе компании. Опыт абсолютно непереносим, в запущенных случаях - непригоден даже для другого департамента той же компании.
В целом верно, но конкретно бесконечные совещания – это необязательная опция, мало зависящая от размеров фирмы и уровня бюрократии, а больше от любви устроителей бизнеса к говорильне.
Видел фирму из четырёх человек, где они непрерывно сидят и трындят между собой, и фирму из двух тысяч в центральном офисе, где совещания – редкость.
Идти за творчеством в бюрократические системы, такие как сбер, росатом и т.д.? Ну такое себе решение.
Это не какая-то ноунеймовская фирма, где можно сказать: Я думал там будет творчество и разгул фантазии, где я смогу себя реализовать, а там оказалась бюрократия - не знал, будет мне опыт.
Сбер/Росатом и похожие фирмы давно "на слуху" и все прекрасно понимают какие там идут бюрократические проволочки.
Пример из жизни.
Человек работал в ростсельмаше в РО, такая же гигантская контора с такими же методами управления: бюрократия, согласования, перекладывание ответственности и т.д. Делал какой-то проект, ставились сроки, акценты что вещь нужная и т.д., делал полгода, потом случилось так что уезжал в другой город, уволился. Через 2 года вернулся в город, приняли снова в ростсельмаш. Когда вернулся, ему выдали тот же самый проект над которым он работал, в тот же самом месте где он закончил его и сдал. По факту на срочный и важный проект забили на 3 года.
Архитектура этого банка - это самое страшное и подлое, что я видел в жизни.
Несколько лет назад, в самом начале ковида мне пришло время оформлять пенсию. И величайшим удивлением обнаружил, что в пенсионном фонде можно указать только два банка - Сбер и Почта. Но что самое подлое и гнусное - в отделении Сбера ( когда уже всё оформил) мне вдруг заявили, что пенсия начисляется на карточку(!) и без карточки я пенсию получить не смогу. После 1 часа мата, вызовов охраны, бросания скомканных листов в лицо нач отделения и прочих уговоров, до сотрудников Сбера дошло, что мой банковский стаж больше, чем у них и инструкцию ЦБ я всё таки читал. Но поступили опять подло - "мы счет открыли, реквизиты вот они, но карточку всё равно выпустили, но запишем, что вы от неё отказались и пенсию не сможете получить" После звонков в службу поддержки и безопасности банка кто-то всё таки вставил им в голову инструкцию ЦБ и через час я заменил в личном кабинете ПенсФонда счет в Сбере на другой банк. Это мерзко, так обманывать самую незащищенную часть, пенсионеров.
Тут еще веселее. Карточка Сбера понадобилась (так нужно стало получателю) и пошел в Банк заказывать. Взял новый номер мобильного специально для Сбера, т.к. старого уже нет. В банке написал на бумажке номер, предъявил паспорт, попросил пенсионерский тариф. Мальчик банковский (строго по архитектуре наверно) ответил, три дня и карта готова, телефон дадите, когда карту забирать, мы её привяжем.
И что вы думаете по этому поводу? А случилось опять всё ровно по сберовски, по архитектуре - прихожу в банк через три дня, даю паспорт - мол, принесите карточку. Мальчик банковский мне и отвечает - сообщите код из СМС. Я ему - вот телефон, мой друг, и никаких СМС он не получал. Мальчик впал в ступор - "мы не можем выдать Вам карту!"
И далее после полчаса обсуждений, закончившихся моим предложением засунуть в ж.. ГО все его новые технологии и сделать по инструкции ЦБ, как делают все приличные банки! мне карточку выдали и привязали новый номер телефона. В прошлый раз в этом отделении я при третьей попытке закрыть уже "закрытые" счета также кричал и бросал скомканные бумаги в лицо зав отделение и тот терпел, т.к. на них была его подпись, что этот счет уже закрыт. Наверно они помнили и до бросания бумаг в этот раз не довели. ( для гос службы это подлость величайшая, если не указать в декларации счет в банке, то можно пойти на выход быстро. Даже если есть на руках бумаги, что счет закрыт)
Я понимаю, что хабр не жалобная книга и не собираюсь жаловаться и уж тем более не жду никакой реакции от Сбера. Но в этом банке нет никакой нормальной архитектуры ни в каком подразделении ни в каком деле с которыми я пересекался.
Я, судя по статье, не будет.
Мне жаль.
Спасибо за статью.
Сейчас прощаюсь с подразделением тех.блока банка - не подходит политика компании и подход руководства.
Для меня основной причиной ухода стало выражение руководства "Ты создашь плохой прецедент, сейчас все захотят работать из дома..." в период начала частичной мобилизации(не смотря на то, что на собеседовании договаривались на гибрид после испытательного срока, чего так не получил). По моему мнению это был не обоснованный риск в тот момент времени из-за общей неразберихи.
Из головы не выходил вопрос - почему я должен после звонка руководителя вечером дополнительно задерживаться и идти на уступки (переработок официальных нет в будни у тех.блока банка), а для меня как что-то потребовалось - сначала отказ, а потом отфутболивание.
Я понял, что мой случай - частный(но не редкий), но все равно не приятно.
На встречах с руководством СБТ тоже замечал много вопросов по поводу удаленки, кого-то брали в период пандемии просто на удаленку, потом был приказ выгнать 80% стаффа в офис (формулировка еще была интересная: "Греф на встрече сказал, что Эппл вывел свой стафф в офис, и мы должны", я еще подумал "ну вы станьте хотя бы как половина Эппл по показателям"). Но очевидно, что для большинства тех, кто в офисе, удаленщики так скажем раздражающий фактор, своеобразная сегрегация. Но не знаю я в офис гоняю(хотя он не очень хороший по расположению, 15+ минут пешком от метро), когда надо беру удаленку.
разве не 70%? Стикерпак ходит именно с 70% в офисе, хотя он про Сбер, а не СБТ.
Может путаю и 70%, но на последней встрече с гендиром он сказал, что можно фулл удаленку взять. Плюс вот намедни у нас PO собирал списки тех кто в офис ходит и кому надо место постоянное, вроде как мест уже стало не хватать. Лучше бы отменили проценты от московских окладов в Мск (100%), Питере(90%) и регионах (80%). С Москвы бы многие уехали куда-то в регионы, где по 2 часа в день не надо тратить на поездку до офиса.
Всю сберинфру выгнали в офис как только кончился официальный ковид. Насколько я понимаю, решение такое принимается на уровне менеджмента департамента. И менеджеров там странных полно.
Ничего нового. Всё как и во множестве других банков с другими логотипами.
Ещё один весёлый момент в том, что такие обучающие материалы есть вообще для всех должностей, включая менеджерские. Поэтому свеженанятый владелец продукта пройдёт такое же вдохновляющее обучение, где ему авторитетно поведают о том, что применение канбанка позволило достигнуть немыслимых для других банков показателя TTM меньшего трёх месяцев. Новичок с горящими глазами прибегает к архитектору, описывает свою гениальную идею и спрашивает о времени её реализации, получает ответ "Тут две интеграции, значит на одни согласования понадобится минимум полгода." и записывает архитектора в число некомпетентных и ленивых. Впрочем, наблюдаю и бывалых менеджеров, продолжающих верить в маленький TTM в банках.
Прошло уже лет 10 после моего сокращение, а вижу ничего не поменялось)
мне кажется, что людям из айти-отрасли стоит посмотреть, как работают инженеры в других отраслях (спойлер: именно вот так и работают. В обстоятельствах зарегулированности стандартами, которые все стремятся нарушить, и при этом тратя кучу времени на переписки, согласования и сборы подписей). А посмотрев - вздохнуть, и начинать привыкать, что и в нашей отрасли тоже теперь это обыденность.
После чего, правда, стоит осмотреться по сторонам, вспомнить, как окружающая действительность поменялась за 20 лет, что вот - новые дома, вот - новые фабрики, вот - новые поезда и дороги, вот приложение сбера в карманном компьютере (который мы почему-то называем телефоном), и в этом приложении в два тапа можно сделать то, для чего 20 лет назад надо было переться чёрт знает куда, стоять в очередях, и потом ждать результата действия до нескольких суток... Т.е. инженеры всё-таки продолжают менять мир, а не тонут в бумажках и совещаниях.
Ну, и может быть, вся эта бюрократия не так уж и плоха? Как говорил мне один пожилой инженер-строитель лет 15 назад: "Если бы не вся эта бюрократия, карьера каждого, без исключения, инженера заканчивалась бы не пенсией, а тюрьмой"
Сильный довод, трудно спорить. Но я попробую.
>>в этом приложении в два тапа
Это прекрасно, но без бюрократии (именно бюрократии а не стандартизации, не путать) - это случилось бы не сейчас, а 10 лет назад. И банковское приложение не "весило" бы 300 МБ. И показывало плачевное состояние моего счёта с последними операциями а не "сторис" и прочую маркетинговую шелуху...
И сразу отвечу комментатору из РЖД.
Перед праздниками за сутки (а не за 30-60 дней) можно было свободно бы купить билет в соседний город. Потому что подключали б дополнительные вагоны. Потому что пассажирские ЖД перевозки были б не убыточными...
Как лихо вы работу Европы-США-Китая выдали за Российскую. У них действительно есть новые фабрики, поезда, а в РФ новых поездов нет. В Москве может есть, раз у них купили, а в РФ нет.
Владышев, Сысоев, Зайцев прекрасные инженеры, но чтобы сделать zabbix, nginx, mariadb им пришлось убежать из РФ.
Я не буду описывать все круги ада, скажу коротко: я бежал из СБЕР, так что пятки сверкали после нескольких месяцев работы - с позиции ведущего эксперта управления облачных решений ( OpenStack ).
Интересно как вообще стать архитектором. Какой опыт должен быть релевантным для работодателя? Что спрашивают на собеседовании? Может автор поделится?
Начать стоит с того, чтобы выбрать направление архитектуры, наиболее близкое к вашему текущему бекграунду.
Классический Togaf выделяет следующие слои архитектуры:
На каждую позицию необходим свой бекграунд компетенций. В интернете полно статей об этом.
Нужно учитывать также, что не все организации живут по классическому Togaf и выделяют такие роли как Solution архитектор (архитектор конкретного решения, тут будет нужен бекграунд разработчика или лида разработки, а также аналитика, чтобы перерабатывать потребности заказчика в конкретные программные решения), архитектор сервиса (функционал похож на Solution, но могут быть нюансы). Некоторые компании декомпозируют роли на более мелкие, например в Ростелекоме в отделе технической архитектуры работают технические и сетевые архитекторы, а вот роль архитектора предприятия, архитектора данных и бизнес архитектора схлопнута в позицию под названием корпоративный архитектор.
В любом случае, необходимы прокачанные коммуникативные навыки, так как постановка задачи и требования это половина успеха проектирования. Придется много общаться с заказчиками, продуктовыми и техническими командами. Предполагается, что архитектор лидирует встречи, задает правильные вопросы и прорабатывает с коллегами сценарии. Зачастую, заказчик либо вообще не знает чего хочет, либо приходит с готовым решением, которое, по его мнению, удовлетворит его потребности, но ошибается.
Третье, необходимо в любом случае уметь визуализировать и структурировать информацию и работать с диаграммами и документацией. Неплохо было бы посмотреть в сторону актуальных нотаций описания процессов, сценариев, систем и их компонентов. Тут нужно гуглить BPMN, IDEF0, UML, C4.
По тексту вакансий вообще не понятно. Складывается ощущение, что это такой продвинутый в тех. плане менеджер проектов
редко когда попадалась действительно амбициозная задача, выходящая за рамки текущей работы, да и те, обычно, не проходили дальше этапа оценки бюджета. Как известно, любые не типовые решения стоят кратно дороже типовых...
Покуда есть деньги, всё решается типовым образом. Амбициозные и нетиповые задачи возникают, когда работать надо, а денег нет и не будет.
Например, вот закончилось место на файловом сервере или сгорела материнская плата на файловом сервере. Типовое решение — купить носители, чтобы добавить их или заменить, либо купить другую материнскую плату. Но для этого нужно потратить деньги, которые вообще неоткуда взять.
И тут начинаются амбициозные задачи.
Можно прозвонить материнскую плату, найти там испорченные элементы, выпаять их, найти аналоги на других испорченных материнских платах, проверить степень аналогии, припаять. Но что если аналогичной материнской платы нету? Задача внезапно выходит за рамки текущей работы.
Можно пересмотреть политику хранения файлов на файловом сервере, создать распределённое хранилище на основе старых смартфонов, подключить арвид, собрать дисковую полку из нескольких DVD-RW дисководов. Но что если старых смартфонов найти не удалось, а арвида никогда не покупали? Что если на всём предприятии нету даже десятка DVD-приводов? Задача снова выходит за рамки текущей работы.
Да, здесь нужна оптимизация процессов. Можно отказаться от локальной записи файлов, перенести файловое хранилище в бесплатные облака вроде яндекс-диска, распределить его по бесплатным почтовым ящикам вроде мейл-ру. Или, может быть, сделать трансформацию процедур, то есть перейти от хранения файлов на жёстких дисках к хранению файлов в каком-то другом виде? Например, в мессенджере?
:-) Вот это я понимаю реальный ответ человека который предлагает потенциально возможные решения проблемы... Только к этому остается еще добавить все + и - предложенных решений, и одно/два из этих решений рекомендуемых (на основе собственного опыта и оценки других показателей/факторов)... :-)
Это по-разному работает на разном масштабе.
Вы все правильно пишите про материнскую плату на сервере, но когда у вас несколько десятков ЦОДи тысячи ИС - стандартизация, унификация и типовые решения начинают работать наоборот, на сокращение расходов.
Компания заключает рамочные договоры и не тратит время и другие ресурсы на торги каждый раз, плюс получает скидку за объем у одного вендора. Эксплуатацию не нужно учить работать с зоопарком оборудования и систем, достаточно научить работать с парой используемых вендоров, а дальше старшие инженеры бесплатно обучают младших, вместо постоянных вендорских платных обучений с полным отрывом сотрудников от работы.
Если есть стандарты для внедряемых систем, вы точно знаете каким требованиям они будут удовлетворять и вам не придется делать нетиповые интегарции, нетиповые авторизациии прочие доработки, которые стоят времени и денег, а также увеличивают гетерогенность вашего ИТ ландшафта.
Вы разработали типовое решение для разворачивания ЦОД в поле, написали требования по каналам связи, питанию, охлаждению, инженерной подготовке здания, запасли на складе типовых компонентов ЗИП, а все ваши системы своими нефункциональными требованиями вписываются в ваш типовой ЦОД. Больше эту работу по проектированию не нужно делать и оплачивать, строй по типовому проекту, это дешево.
Как я в зеленом банке архитектором работал