Привет, Хабр! Меня зовут Сергей Терехин, и я — системный архитектор. Даже искушенные в ИТ люди не всегда знают специфику моей работы. Расскажу, как меня угораздило стать системным архитектором, чем занимаюсь, а также про прелести, боли и перспективы этой профессии.
Системный архитектор — это скорее роль, чем конкретная должность. Этой профессии не учит ни один вуз. А парадокс в том, что эти самые мифические системные архитекторы крайне востребованы и без их участия нормально не смог бы функционировать ни один крупный бизнес, базирующийся на ИТ.
Если вы считаете, что мир кровавого Enterprise загибается и однажды все корпоративное ИТ будет из облака, в вас поднимается волна возмущения и руки тянутся к помидорам, чтобы запустить в автора… Подождите. В реальности монстры российского бизнеса пока предпочитают строить свои ИТ иначе. И роль системного архитектора при таком подходе к инфраструктуре очень велика. Эти люди анализируют задачи, которые бизнес ставит перед ИТ, что именно нужно сделать и как лучше достичь поставленных целей. Они выбирают инструменты, оптимально подходящие в той или иной ситуации, придумывают архитектуру будущего вычислительного комплекса в целом, а иногда и каждого отдельного модуля в нем. И самое главное — системные архитекторы видят общую стратегию внедрения инфраструктуры и следят, чтобы все части выбранного решения укладывались в эту общую канву.
Так чем же они, то есть мы, по факту занимаемся?
Три вида архитекторов
Проще всего это понять, разобравшись, какие бывают архитекторы в ИТ.
Есть наиболее распространённое и понятное определение «архитектора решений» или «solution-архитектора» — это специалист, который понимает, как устроена и должна работать определенная прикладная система (веб-сервис, социальная сеть, ERP-система и пр). Он держит команды разработки в рамках техзадания и помогает создавать решения, фокусируясь на бизнес-задаче, а не просто на функциональных требованиях к исполняемому коду. Любое приложение должно на чем-то работать, а данные, которым оно оперирует, храниться долго и без потерь. Solution-архитектор может только сформулировать, какие ресурсы требуются и как быстро должен подниматься упавший сервис. Кто же сделает это реальностью?
Именно здесь подключается «системный архитектор». Он как раз гуру в создании ИТ-инфраструктуры, включая ЦОДы, железо, сети, различных системы хранения и серверные платформы. Его основная задача — подготовить инфраструктуру к тем требованиям, которые диктуют ей приложения. В сферу ответственности системного архитектора может входить множество систем, которые так или иначе относятся к инфраструктурному уровню, обеспечивая необходимую производительность, надежность и доступность. Но сути это не меняет — системный архитектор придумывает, как будет выглядеть ИТ-инфраструктура в целом и что она должна «уметь».
В идеале синергия системного и solution-архитекторов должна давать компании тот самый импульс для развития. В действительности между ними — бездна. Архитекторы решений не знают, как функционирует инфраструктура, а системные архитекторы часто не заинтересованы вникать в работу ПО. Именно поэтому над ними появляется «enterprise-архитектор» — супермен, способный соединить два сегмента архитектуры. Это не какой-нибудь отдельный «биологический» вид, а скорее новая эволюционная форма развития системного и solution-архитектора. Обычно он соединяет два берега над той самой бездной.
Мой личный опыт
Лично я начинал с простого инженера. Еще будучи студентом, работал эникейщиком, потом руководил маленьким отделом из трех человек в компании в Приморье. После перебрался в Питер и там впервые столкнулся с полноценной ИТ-инфраструктурой, став руководителем группы эксплуатации серверов и систем хранения. Через какое-то время меня притянула Москва. За несколько лет я стал руководителем дирекции ИТ-инфраструктуры, где кроме должности и нового масштаба задач мне вручили набор административных и, как я потом уже понял, архитекторских задач. Разбираться с этим приходилось на ходу, а многое просто брать и делать своими руками. Часто впервые.
По факту я уже тогда был системным архитектором, но без титула; выполнял определенные функции не для заказчиков, а для работодателя, конструируя системы виртуализации, проектируя доменные леса с нуля, перестраивая сети хранения в новую топологию. Оказавшись в компании «Инфосистемы Джет», я наконец-то официально стал носить гордое звание системного архитектора.
Футболисты и шахматисты
Наша компания ведет много крупных и сложных проектов, и поэтому у нас в штате я далеко не единственный системный архитектор. Оказывается, достичь этой позиции можно разными путями. Например, я — «футболист». Всю свою карьеру я «играл на поле»: бегал по ЦОДам, физически имел дело с оборудованием, знал его особенности, решал проблемы в реальном окружении. Но бывают прекрасные архитекторы «шахматисты». Они развиваются из глубоких теоретиков, которые изначально занимались только проектированием и не имеют богатого «полевого» опыта.
У каждого карьерного пути свои плюсы и минусы. Однажды я участвовал во встрече, где мои коллеги архитекторы готовили таблицу сравнения по двум системам резервного копирования. Мне это было странно, потому что, как практик, я прекрасно знал, насколько одно решение лучше другого. Да что там — на голову выше! Практика дает хорошую опору в принятии решений. В то же время, теоретики более беспристрастно оценивают все возможные опции, особенно когда все запутано и откровенно плохо. Так что разница между практиками и теоретиками не сказывается на качестве принятых решений.
В конечном счете сегодня я, как системный архитектор, отношусь как раз к теоретикам. После «полевой» работы ИТ-инфраструктуре средних размеров, я перешел в высшую лигу, но не «футбольную», а «шахматную». Какое-то время к этому пришлось привыкать: менять характер своего мышления и много работать с людьми.
Какие навыки нужны ИТ-архитектору?
Умение абстрагироваться
ИТ-архитекторы разрабатывают сложные решения под уникальные задачи бизнеса. На рынке нет типовых кейсов, которые можно использовать всегда и везде. Как в шахматах всего из 32 фигур может получиться 10120 шахматных партий, так и одинаковый набор решений и продуктов можно объединить в различные ИТ-системы, иметь разную структуру и в итоге получить уникальный функционал. ИТ-архитектору важно развивать гибкость мышления, чтобы взглянуть на проект под другим углом, суметь разбить его на логические части и найти наиболее подходящее решение.
Менеджмент и любовь к людям <3
Архитектор не просто разбирается в ИТ и способен с завязанными глазами спроектировать и построить многокомпонентную инфраструктуру. Это еще и отличный менеджер, который взаимодействует с людьми. Интровертам на этой позиции бывает сложно, потому что она подразумевает непрерывный контакт со своей проектной командой и заказчиком. При этом, кроме технический требований, почти каждая задача приходит с увесистым багажом «политических» условий.
Как-то на проекте мы уперлись в «человеческий фактор». Специалист, отвечавший за работу СУБД, был крутым DBA. А еще у него был прямолинейный и упрямый характер. Миграция приложений происходила долго и мучительно, и ему надоели миллионы вопросов по поводу каждой системы. Однажды он перестал выдавать нужную информацию по БД. Миграция застопорилась.
Тогда я остановил все миграции и стал разбираться, что же происходит. Столько возмущения и несогласия со стороны коллег мне еще не приходилось выносить! Но зачем страдать и поддерживать процесс, который идет хуже некуда? Пока инженеры фокусировались на других задачах, мы нарисовали общий сайзинг для всех серверов и кластеров СУБД, составили таблицу, и я лично пошел к тому специалисту, которого тогда уже все боялись. Посидели, поговорили, нашлись общие темы. Обсудили «портянку» на 100 серверов БД. Так наконец появилась карта миграции для всех баз данных до конца проекта. Больше не нужно было ходить к DBA с каждой мелочью, и процесс миграции встал на рельсы.
Высокая обучаемость
ИТ, как отрасль, включают в себя столько направлений, что быть экспертом в каждом из них нереально. Системный архитектор смотрит скорее вширь, чем в глубь. Но он должен быть способен разобраться в любой тематике, опираясь на свои базовые знания, даже если эта область для него совершенно новая.
Желание быть «на гребне волны»
Системный архитектор обязан следить за зарубежными тенденциями развития ИТ-инфраструктуры и работы с ней. Такому специалисту лучше владеть как минимум одним иностранным языком, регулярно ездить на профессиональные конференции и повышать свою квалификацию. Желательно, за счет работодателя.
Владение языком бизнеса
От архитектора ждут не только экспертных знаний, но и умения представить проект заказчику, включая топ-менеджмент. При этом нужно оперировать ценностями и аргументами из мира бизнеса. Руководителям не интересна метла Nimbus-2000 потому, что это самая актуальная и быстрая модель. Но она будет привлекательна, если грамотно доказать, как ее покупка поможет максимально эффективно решить бизнес-задачи.
Наличие опыта
Мы шутим с коллегами, что основная задача ИТ-архитектора — борьба с неопределенностью. Приходится действовать в условиях, когда вопросов больше, чем ответов. Как это делать, не допуская ошибок? Ответа нет. Принимая решение, ИТ-архитектор с этой же секунды начинает отвечать за него. И устранять последствия своих промахов, если они возникли. Исключить ошибки невозможно, но можно свести их к минимуму. «Противоядие» только одно — накопленный опыт. Когда уже за плечами поле с граблями, чаще всего наперед знаешь, где скрываются подводные камни и как их обойти.
Необъективное мнение
Мир ИТ сегодня разделен на два лагеря. В первом те, кто верит в облака, во втором — те, кто сталкивается с реальностью «большого ИТ» и понимает, что к эпохе digital еще долгий путь. Первые считают вторых динозаврами, дни которых сочтены. Но по факту on-premise пока не уступает место облакам, как предрекали аналитики и эксперты. Оба направления развиваются параллельно. И системные архитекторы крайне востребованы. Причем все больше с учетом роста роли ИТ в последние годы в разных сферах бизнеса.
Многие забывают, что под самыми навороченными и дружелюбными системами, в том числе и теми, который позволяют в облаках налету получать ИТ-сервисы, лежит старое доброе железо. И чтобы каждый из нас мог сполна насладиться использованием любого приложения без тормозов, зависаний и «черных экранов», какой-то системный архитектор, должен вдумчиво выполнить свою работу и подложить под него правильно проработанную ИТ-инфраструктуру.
Автор: Сергей Терехин, руководитель отдела комплексных проектов «Инфосистемы Джет»