Много лет назад я от усталости облокотился на стену техкоридора и начал по ней медленно сползать. Мы только что сдали проект после пары недель ночных переработок, чтобы уложиться в дедлайн. Мимо шёл мой руководитель, я простонал:
— Рома, я задолбался быть инженером. Всё, ухожу!
Он ласково улыбнулся и сказал:
— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.
Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.
Но! Если понимаете — это будет очень увлекательное приключение.
Как это выглядит?
Вообще, мне казалось, что будет интересно общаться с заказчиками, выявлять самому, что им на самом деле нужно, узнавать, что у них в головах, в инфраструктуре, а потом делать большие проекты — и чтобы всё было красиво.
Разрыв с реальностью в том, что то, что у них в головах, не всегда соотносится с тем, что у них в инфраструктуре.
И сначала ты работаешь психологом, потом доносишь правду, потом на тебя обижаются (иногда), потом ты опять работаешь психологом, потом задаёшь сто вопросов, потом проверяешь факты (и не все они такие, как представлены) — и только после этого складывается мнение, как проектировать систему. Потом ты объясняешь это всем людям, которые в ней заинтересованы: почему так, зачем, сколько будет стоить, как правильно для такой-то ситуации и для такой-то, почему может оказаться, что «чтобы быстрее заработало» и «надо на 10 лет вперёд» может быть на одной и той же технологией, а может и не быть. И как выбрать. А потом, когда твоя печень вырастает большая-пребольшая, остаётся только нарисовать сову — собственно, спроектировать систему в деталях.
Самое большое удовольствие в профессии — это сначала закончить проектирование и понять, что всё именно так, как нужно по задаче. А потом, спустя пару лет, увидеть, как это воплощается командой (или многими командами, до сотен людей), и порадоваться, что ты это увидел и показал, как делать.
В общем, архитектор — это тот, кто принимает главные решения на проекте. Наверное, это больше всего и «подсаживает» на профессию.
Что вообще делает архитектор?
Сейчас я занимаюсь клиентскими проектами и нашим облаком Техносерв Cloud. Развлечение выглядит так: прилетает какой-нибудь крупный проект. Например, спроектировать дата-центр.
Кто-то ЦОД рисует. Кто-то хорошо разбирается в базах данных. Кто-то в сети. И во всём этом нужен такой человек, который понимает верхнеуровневые требования заказчика к проекту в целом. У заказчика нет желания построить ЦОД или внедрить какую-то систему. У него задача — «хочу переместить всю свою нагрузку из одного места в другое» или «организовать отказоустойчивую площадку, которая позволила бы всем моим системам пережить дизастер». Нужен тот, кто поймёт все эти требования. Причём они ещё даже не требования, они просто хотелки. «Мы хотим увеличить продажи в 2 раза и при этом число инцидентов сократить в 3 раза» — надо прийти поговорить с нужными людьми, понять, откуда у них столько инцидентов, что с этим можно сделать.
То есть сначала собираются хотелки. Потом составляется и согласуется ТЗ, потом по нему делается решение, которое включает и физику, и прикладную часть, — для всех этих задач нужен архитектор.
Не обязательно архитектор делает весь проект по всем подсистемам — на крупных вещах система совета или зон ответственности под руководством главного специалиста. Например, сетевой архитектор привлекается тогда, когда необходимо спроектировать и построить ВКС (СКС) для проекта. Архитектор-прикладник же привлекается, когда нужно разработать какие-то информационные системы. И так далее.
Проще всего объяснить на примере облака. Я делаю начальное проектирование всего того, что компания продаёт из облака. Я планирую и проектирую (и ещё потом контролирую) построение собственной инфраструктуры, потом сдаю её команде эксплуатации. Со мной работают три человека на подзадачах: отвечают за OpenStack, за VMware, за сеть хранения.
Где тогда геморрой?
Где-то в 85% случаев бизнес считает, что половина того, что он хочет, и мы ему рассказываем, у него уже есть — и проблем никаких нет. Но штука в том, что когда спускаешься на уровень департамента, отдела и т. д., оказывается, что всё не так прикольно: процессы прорисованы у бизнеса («Мы полностью исполняем ITIL в процессах, заявки проходят согласование чисто только в системах, всё проскакивает моментально»), а у админов СУБД выясняется, что безопасники всё равно просят принести бумажную копию, подписанную у всех руководителей компании. Анализируют эту бумажку много месяцев и только потом дают добро на развёртывание какой-то тестовой среды.
Подстава в том, что если прийти на проекте к бизнесу с формулировкой, что у вас всё работает не так, то молись, чтобы тебя не взяли в этот проект.
Потому что те, кого ты этим «спалил», тебе работать не дадут.
Особенно, знаете, изредка встречаются такие древние особисты, у которых всегда должна быть бумажка, чтобы прикрыться.
И да, мне нравится придумывать, как всё это можно изменить.
Оценить проект можно только вместе с бизнесом, и то через пару лет. Но на самом представлении бывает субъективная составляющая: ну, самолёт должен летать и быть красивым. А ещё такой результат должен стать шаблоном в идеале, чтобы можно было внедрять во всех похожих случаях.
Как выгорают
Рынок маленький, все про всех знают. Бывает, люди просто уходят куда-то с должности из-за накопившейся усталости и ответственности. Бывает, людей терпят. Например, знаю одного очень сильного технического эксперта. Он приходит и всех благим матом кроет.
Говорит: «Как вас земля носит, идиотов таких!» И доказывает, разбирая код. Но его любят за профессионализм. Он никогда не хотел быть архитектором, говорит: «Я не хочу переводить оттенки смыслов и эманации, что они там чувствуют». И остаётся инженером и по сей день. «Есть ТЗ. Я взял, пошёл и сделал. Я не хочу даже знать, нужно ли ему это было или нет».
Ещё один коллега возглавлял техслужбу, потом архитектурное подразделение, а сейчас он занимается удалённым администрированием с какого-то тропического острова, кажется. Счастлив.
Так что, если думаете, что архитектор — это ветка развития разработчика, которая сразу после тимлида, — не уверен. Геморроя, как видите, тут очень много, но и радости от того, что ты разобрался и решил сложную задачу, очень много. Но только проекты все большие, поэтому радость приходит пару раз в год.
«А если я буду делать неправильно»?
ИТ-директор телекома как-то спросил: «Если я буду делать неправильно, вы меня поправите?»
«Да, — говорю, — мы будем разговаривать».
Он: «А как вы будете меня убеждать?»
Я говорю: «Никак. Пистолет у вас. Я могу только сказать, что если вы будете себе стрелять в ногу, вероятно, вам будет больно».
Но я всегда предупрежу, что пистолет направлен в ногу.
Или вот пример. Есть виртуализованные приложения, нагрузка скачет от случая к случаю. Клиент из розницы, и у него перед 8 марта начинается шквал. Бэкэнд успевает, а сайты ложатся на 404. Тут всё просто: надо просто приложение разнести на параллельные процессы, продумать, чтобы узких мест не было. А писалось оно в 90-х и с тех пор обрастало ракушками — надо много чего переворошить. Потом сменились люди в бизнесе, говорят: «Давайте закупим лишних серверов и будем жить от концепции, чтобы мощностей хватало под пик». Докупили пару стоек, вхолостую гоняют их 320 из 365 дней в году. Через два года эти дядьки ушли, пришли новые. Смотрят на стойки, говорят: «Чего воздух греют, давайте продадим». Продают. Весна наступает неожиданно, пик. Снова начинается первая итерация. В итоге они идут в облако, и мои коллеги начинают помогать им правильно делать инсталляцию. Не все даже понимают, что такое балансировщик, но тут лучше в деталях эксплуатация расскажет, у них накипело.
Часто надо быстро запустить проект любой ценой за 2 месяца, а на деле, когда зоопарк разбираешь, понимаешь, что строить должны на 10 лет. Иногда удаётся донести. Иногда нет — заказчик мыслит годовым планом, и это его деньги и его бизнес. Он прав, он знает, что делать стратегически в бизнесе. Моя задача — показать ему варианты и, условно говоря, плюсы-минусы каждого в максимально понятных ему числах или определениях.
А ещё нас иногда дразнят стартапщиками — всё чаще запускаем прототипы, а потом их начинаем переделывать в постоянные штуки.
Кто может «потянуть»?
Не знаю, как становятся архитекторами. Могу сказать, что я 4 года работал инженером, потом в другой компании (уже с опытом) — как проектировщик, а потом как архитектор. В «Техносерве» два с половиной года. Но «на той стороне» я всё равно работал с инженерами «Техносерва», как с людьми подрядчика — делали один большой проект.
Большинство архитекторов, конечно, вырастают из продвинутых разработчиков и инженеров. Но есть единичные исключения, всё зависит от навыков системного , которые в целом приобретаются не обязательно в ИТ-специальностях.
Многие в архитектуру идут за новыми технологиями. Общие подходы к проектированию и построению систем остаются неизменными. Что внедрять и что планировать — вопрос подготовки. За достаточно ограниченное время можно в своё портфолио включить решения какого-нибудь вендора. Например, есть мониторинг БД, приложений, сети, пользовательских транзакций, ЦОДов — в принципе подходы одни и те же. Решает опыт (много опыта) и системное .
Если бы мне пришлось собеседовать нового архитектора в команду, я предпочёл бы проиграть ситуацию с заказчиком и исполнителем: ставлю задачу, а точнее, озвучиваю хотелки, как заказчики часто делают, а потом смотрю, какие вопросы задаёт мне соискатель, как выясняет задачу, какие модели предлагает.
В разработке знания технологий устаревают быстро, а культура и навыки алгоритмизации остаются навсегда. А в архитектуре почти ничего из знаний не устаревает — изучая что-то, можно быть уверенным, что многое пригодится и через год, и через пять, и через десять.
Как понять, что стоит идти в архитекторы?
Не знаю. Наверное, когда вы захотите острых ощущений от общения с людьми и решения сложных задач со множеством факторов. Или когда вы всё равно выступаете архитектором на проектах, просто эта роль входит во что-то, называющееся по-другому.
В общем, приходите. У нас тут, говорят, только свет и чистота.
Это материал нашего архитектора Александра Шубина.
Автор: TS_Cloud
