×

Как я работаю: Антон Бойко, Senior Solution Architect в Ciklum и основатель Azure-сообщества

[В рубрике «Как я работаю» мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]

Антон Бойко — Senior Solution Architect в Ciklum, а также основатель сообщества Microsoft Azure Ukraine User Group. Работает в IT более 10 лет, с 2011 года разрабатывает программы на базе Microsoft Azure.

Антон — обладатель почетного звания Microsoft Azure Most Valuable Professional (MVP) с 2014 года. Вместе с коллегами по сообществу он организовывает две популярные конференции по Microsoft Azure — AzureDay и Global Azure Bootcamp.

О себе

В детстве я часто болел и много времени проводил дома — так и проснулся интерес к компьютерам. Вместе с друзьями мы активно играли в компьютерные игры и мечтали сами написать игру. В 90-х родители отправили меня, школьника, на курсы по «железу» при КПИ. После этого я стал сам апгрейдить домашний компьютер, устанавливал всем родственникам софт и помогал в покупке оборудования.

После школы поступил на факультет прикладной математики в НТУУ «КПИ». Моя кафедра называлась «Специализированные компьютерные системы»: там больше упор на инженерию, чем на математику. Каждый предмет мне был интересен по-своему, и я не до конца понимал, чем именно хочу заниматься в будущем. Еще во время студенчества стал преподавать на компьютерных курсах: учил людей пользоваться ПК, офисными пакетами — в начале 2000-х на это был спрос. Вел и другие предметы — например, «Основы Photoshop для графического дизайна».

Интересно, что о вакансии преподавателя на курсах я узнал из газеты с объявлениями. А позже издатель этой газеты сам стал первым работодателем, куда я устроился как программист. Компания называлась Rabota+. Там я разрабатывал систему документооборота, отдаленно напоминающую современные CRM. Работал с Object Pascal на Borland Delphi 7, часть ресурсов была написана на PHP 5.

После Rabota+ я решил попробовать себя в системном администрировании. В начале-середине нулевых это направление выглядело очень перспективным. У сисадминов зарплата была выше, чем у программистов, вакансий было больше. И казалось, что они занимаются по-настоящему крутой работой — держат целые системы на куче серверов! Тогда на внутреннем рынке спрос на разработчиков был не очень большим, а эра тотального аутсорсинга в Украине еще не наступила.

Переключившись на системное администрирование, я пришел работать в компанию «Информационные программные системы». Только сейчас понимаю, насколько крутыми вещами мы там занимались. На базе продуктов Microsoft мы построили решение, которое очень напоминало теперешний Microsoft Office 365. Мы начали продавать его по модели SaaS украинским клиентам — на 5-6 лет раньше, чем это начал делать сам Microsoft.

Затем я понял, что все-таки разработка мне интереснее, чем администрирование серверов. На тот момент я по году-полтора поработал в нескольких компаниях и получил опыт в разных направлениях, но у меня не было глубокой экспертизы по какой-то конкретной технологии. А в страну пришел глобальный финансовый кризис, доллар впервые поднялся с 5 до 8 грн. В компаниях проходили массовые сокращения, молодых специалистов перестали нанимать — потому найти работу было нелегко.

О «гаражной» веб-студии и майндсете клиентов

Тогда я решил попробовать себя во фрилансе. Мы с женой основали собственную «гаражную» веб-студию и стали делать сайты на заказ. Сначала думали взять за основу PHP. Но я уже имел опыт работы с решениями Microsoft и решил попробовать C#/.NET. К тому же нам удалось получить от Microsoft бесплатные лицензии на Visual Studio и Windows Server по программе поддержки подобных «гаражных» проектов.

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

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





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

Наша «гаражная студия» работала до 2011 года. После этого я ушел в аутсорсинг и перестал заниматься фрилансом фултайм, но все же в свободное время беру проекты. Об этом — немного ниже.

Об аутсорсинге и работе в Microsoft Украина

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

Потом было еще несколько компаний, среди которых Matrix42 и Livatek. В каждой из них я проработал год-полтора. Стек технологий варьировался вокруг Microsoft Azure. Но в какой-то момент заканчивались сложные задачи, и я двигался дальше.

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

В 2016 году меня пригласили поработать внештатным консультантом (вендором) в украинском офисе Microsoft. Разработкой украинский офис не занимается — в основном тут работают евангелисты, продавцы и маркетологи. Но я работал в экспериментальном проекте по поддержке инструментов Microsoft для европейских компаний, которые аутсорсят разработку в Украину. Я напрямую подключался к украинским командам и помогал им освоить и внедрить новые технологии, а также спроектировать архитектуру на их базе. Иногда такие пилотные проекты занимали до 3 месяцев, при этом я мог проводить все это время в офисе партнера. Кстати, одним из таких партнеров и оказался Ciklum, мой следующий работодатель.

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

В Ciklum я пришел как Solution Architect. На тот момент в команде архитекторов работало всего лишь 3 человека, включая нашего руководителя департамента. За следующие полгода-год я помог выиграть несколько крупных тендеров и получил повышение до уровня Senior Solution Architect.





О сообществе Microsoft Azure

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

В рамках сообщества мы проводим конференцию AzureDay. В 2018 году мероприятие собрало около 250 участников. Я стараюсь приглашать на Azure Day лучших украинских и заграничных экспертов, чтобы повестка дня состояла из максимально сложных и глубоких докладов. Мечтаю, что мероприятие будет привлекать не только местное сообщество, а и разработчиков из других стран Европы. Кстати, сама конференция уже выросла за пределы Украины: ее проводили в Беларуси, Польше, Болгарии и России.

Также мы поддерживаем в Украине Global Azure Bootcamp — это всемирная конференция, которая проходит в один и тот же день в разных городах мира. В прошлом году в ней участвовали суммарно 15 тыс. человек. Я координирую Global Azure Bootcamp в Киеве, мои коллеги — в Харькове, Львове и Одессе. В рамках конференции проходит благотворительная лабораторная работа: мы поддерживаем исследования для неприбыльной организации, которую выбирают организаторы.

Например, в 2016 году помогали в исследовании проблем рака груди. Все желающие могли запустить у себя в облаке виртуальные машины, на которые загружали специальный образ с необходимыми для проекта научными алгоритмами. Приятно знать, что по результатам уже пяти конференций Global Azure Bootcamp Украина всегда входит в топ-10 стран, которые отдают свои ресурсы на благотворительность.

Помимо организаторской деятельности, я сам часто выступаю с докладами на украинских и зарубежных конференциях. Например, только в прошлом году у меня было около 40 выступлений. Жить в таком графике было нелегко, но выступления на конференциях помогают совершенствовать собственные навыки коммуникации, постоянно учиться новому, развивать сообщество, знакомиться с новыми людьми. Это полезно и для прямых должностных обязанностей. Я постоянно общаюсь напрямую с клиентами, принимаю участие в процессе заведения проекта в компанию. А для этого нужно уметь держаться непринужденно и «продать» себя и свою компанию.

Типичный рабочий день в Ciklum

Рабочие дни проходят очень по-разному в зависимости от того, какие активности я запланировал. Утром из дома я проверяю рабочие чаты и почту. На основе этой информации планирую день. К примеру, могу приехать в офис и к 7-ми утра, если надо, или к 10-ти, как большинство коллег. Такой изменчивый график работы связан с тем, что моя основная роль в Ciklum — специалист по решению проблем. Почти как Мистер Вульф из «Криминального чтива» :)

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

На работу над проектами трачу около 4 часов в день. Примерно 2 часа — на самообразование и еще 2 часа — на менторство.




Что касается менторства, моя позиция — никогда не бегать за учениками. Это ученики должны бегать за ментором :) Люди должны быть заинтересованы в собственном развитии. Заставлять их что-то делать через силу нет смысла. Если у человека есть мотивация и он тянется к новым знаниям, я помогаю ему развиваться дальше. По такому принципу я обучал уже примерно 10 человек, и все они смогли добиться успеха в своих начинаниях. Если же у человека нет глубокого интереса, то я отказываю: вряд ли из этого что-то получится. Кстати, поэтому мне не очень интересно развиваться по линии people-менеджмента — мне кажется, что эта роль подразумевает бегать за людьми.

В офисе я провожу около 8 часов в день. На личном опыте убедился, что переработки до добра не доводят. Если «тушу пожар» и приходится засидеться, на следующий день прихожу позже или же ухожу раньше. Постоянных овертаймов стараюсь не допускать. К примеру, sales-менеджеры одного из проектов из США любили назначать митинги на поздний вечер, при этом команда начинала работать рано утром. Но я объяснил, что от меня будет намного больше пользы, если я не буду перерабатывать и хорошо отдохну.

На развитие Ukrainian Microsoft Azure Community трачу около 4 часов в неделю. Примерно столько же — на общение с коллегами по сообществу Microsoft Azure MVP. Мы даем компании обратную связь по продуктам и за это получаем бесплатные лицензии на продукты и сервисы, возможность протестировать обновления одним из первых (порой до того, как начнется private preview), а также доступ к сообществу экспертов и единомышленников по всему миру.

Инструменты и продуктивность

Я не пользуюсь какими-то специфическими практиками по тайм-менеджменту, а просто заношу все дела и встречи в календарь. Например, если я знаю, что к такому-то времени надо подготовить презентацию для клиента, то ставлю в календаре блокер под эту активность, чтобы никакие другие задачи не пересекались по времени с этой. Рабочий календарь синхронизирую с личным: например, в последнем планирую подготовку докладов для Microsoft Azure сообщества или созвоны с Microsoft Azure MVP.

В плане офисных инструментов активно пользуюсь пакетом Microsoft Office 365. Стоит он относительно недорого и дает мне почту на личном домене, календари, хранилище файлов и лицензию на пакет Microsoft Office.

Основной инструмент коммуникаций — почта. Уведомления просматриваю всегда, но отвечаю на письма по мере свободного времени. Дополнительно использую мессенджеры. Для общения по работе — Microsoft Teams и Slack, для общения с друзьями — Skype и Facebook Messenger, порой Telegram. Но иногда часть рабочей коммуникации проходит и через Skype. Это мне не очень нравится, так как я стараюсь разделять личную и рабочую жизнь, но иногда бывают исключения.

Помимо инструментов для общения, я использую массу других приложений, которые нужны для работы. Чаще всего это Sourcetree и GitHub Desktop — для работы с исходным кодом. Rider, WebStorm, VisualStudio, VisualStudio Code — для написания кода, Postman — для тестирования API. Архитектурные диаграммы делаю в Visio и Draw.IO Desktop, документацию — в Camtasia Snagit. Для презентаций удобен PowerPoint, для заметок — OneNote.




Книжки и самообразование

Главный источник моего самообразования — это та самая «гаражная» студия. Хоть я и переключился на работу в аутсорсинге, ко мне продолжали обращаться клиенты. И я опробовал модель работы, которая показалась мне интересной и выгодной. Я стал предлагать заказчикам невысокую стоимость, но с условием, что я сам выбираю стек технологий и принимаю все технические решения. Дело в том, что в аутсорсинге разработчики не всегда имеют такую возможность, а работа с legacy code мало кому приносит удовольствие.

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

На такой фриланс я трачу до 20 часов в месяц.

Что касается чтения, в основном это не книги, а статьи. Например, блоги крупных компаний и людей, которые в этих компаниях работают: Microsoft Azure Blog, AWS News Blog, Google Cloud Blog, Martin Fowler (ThoughtWorks), Donovan Brown (Microsoft), Troy Hunt (Microsoft). Слушаю HanselMinutes Podcast. Мне интересно, в какую сторону движется тот или иной вендор в плане развития своих технологий. Если какая-та тема цепляет, изучаю ее глубже. Пробую технологию руками и оцениваю, насколько ее маркетинговые описания совпадают с реальностью.

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

Также могу рекомендовать к прочтению: «The Phoenix Project» Джин Ким, Джорджа Спаффорда и Кевина Бера, «Surrounded by Idiots» Томаса Эриксона, «Games People Play» Эрика Берна, «The World According to Clarkson» Джереми Кларксона и «Сказка о Тройке» Стругацких. Каждая из этих книг помогла мне стать тем человеком, кем я есть сейчас.

Ретроспектива и планы на будущее

Как и любой человек, я делал много ошибок, но именно они помогли мне стать профессионалом. Тут можно провести аналогию с культурой DevOps: совершать ошибки — это нормально, но только при условии, что одну и ту же ошибку мы допускаем только один раз. Другими словами, нужно выносить урок и не наступать повторно на одни и те же грабли.

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному3
LinkedIn

Схожі статті




60 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Ви так все описали, що аж хочеться з вами працювати :)
Ви, часом, не шукаєте людей? )) Про себе — 12 років в IT, з них останні 8 це «all-in-one» на фрілансі, частково в невеликій команді, частково сам. Тому більшість описаного вами мені близько.

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

Що можете порадити для росту «technical and soft skills» для людей що вже є або хочуть бути на позиції Solution Architect?

Для прикладу, я з своєї сторони дивлюсь дуже позитивно на:
— книгу: Software Architecture in Practice, 3rd Edition.
— курс: www.sei.cmu.edu/...​course.cfm?courseCode=V07
— книга + сертифікація: iasaglobal.org/certifications
— курс + сертифікація: www.coursera.org/...​tware-design-architecture
— курс + сертифікація: hbx.hbs.edu/courses/negotiation
— ще маю список з хороших курсів з coursera, можу поділитись якщо будуть бажаючі

Все что вы перечислили заслуживает внимания. Лично я бы сосредоточился на первых двух пунктах. Книгу читал и она хороша, хоть и заходит немного вяло. Курс и сертификация от SEI как раз в моем списке todo на ближайшее время.

Ещё я рекомендовал некоторые материалы в другом комментарии, вот ссылка dou.ua/...​how-i-work-boyko/#1481524

Относительно прокачки не технических навыков я ещё раз порекомендую выступать на митапах, конференциях и т.д. Грамотно рассказать и убедить в чём-то вашего коллегу по цеху это тот навык без которого архитектору будет трудно работать в команде. Также это неплохой способ получить обратную связь и мониторить прогресс развития навыков общения. И не вздумайте ограничивать себя митапами исключительно локального формата. Есть очень много технических сообществ в Европе и Штатах, большинство из них будет радо послушать нового докладчика. Вам также будет интересен опыт взаимодействия с разными категориями людей и разными культурами. Поверьте, разговаривать с разработчиком из Украины, Испании, Дании, Британии это как говорить с абсолютно разными людьми. К каждому нужны свои подходы, у каждого свои ценности и у каждого разные ожидания от вашей беседы.

ще раз дякую, вже собі добавив в заклади ресурси якими ви поділились.

Насамперед дякую за хорошу статтю та коментарі. А тепер до питаннь:
Чи є у Вас діти?
Який баланс між роботою та особистим, сімейним життям?
Як Вам вдається балансувати між вище та нижче згаданими активностями?

Детей нет.

Относительно баланса между работой и личной жизнью, то тут все довольно тяжело. Работа занимает 8 часов в день, работа с сообществом тяжей время, фриланс, менторство и так далее. Я не смогу сказать что «у меня была какая-то тактика и я её придерживался», но хочу обратить внимание на следующие вещи:

— Если я дома, то я дома. Если я на работе, то я на работе. Суть в том, чтобы как можно меньше переключатся между контекстами. Договориться с семьей было относительно просто — если есть что-то не срочное, то мне пишут в мессенджер, по срочным вопросам можно звонить в телефон. Как я уже говорил в интервью — я использую (по крайней мере стараюсь) для работы и для личного общения разные месенджеры. Это позволяет обращать внимание только на то, что тебе важно сейчас и фокусироваться больше на выполнении текущего задания. Договориться с коллегами было сложнее, но все равно получилось. Тут также работает взаимоуважение и принятие единого стандарта для всех. Если кто-то в отпуску, то я не буду звонить или писать этому человеку, я приложу все силы чтобы решить задачу без его участия. Аналогично работает и с вашим руководителем. Главное понять что вы ему не раб и ваш успех это его успех. Порой меня просят что-то сделать в ущерб личному времени, но я соглашаюсь на такое в очень редких случаях. На самом деле хороший руководитель увидит сам что вы перегружены и предложит совместно найти способы снять с вас часть работы. Возвращаясь опять к интервью — отдохнув можно потом поработать намного лучше и ошибок наделать меньше. У меня есть четкий рабочий график и если кто-то пишет мне за пределами моего рабочего времени, то он должен быть готов к тому, что отвечу я как только рабочее время наступит.

— Работа не по 8 часов, а головой. Каждый человек в результате своего труда создаёт добавочную стоимость для товаров или услуг. Многие компании продают человеко-часы без какой-либо привязки к результатам работы. Я больше люблю подход fixed price, хоть работать с ним и сложнее. Идея в том, что клиенту на самом деле не интересно сколько часов вы поработали, ему важно чтобы задача была сделана в срок. В результате я оцениваю качество своей работы не по количеству часов проведённых в офисе, а по вкладу для каждого конкретного проекта. Тут можно подумать что я пытаюсь таким образом работать меньше, а списывать времени больше, но это не так. Все что я пытаюсь сказать, так это то, что многие команды работают по scrum и бегут спринт за спринтом, в то время как в больших проектах нужно бежать марафон. Нужно равномерно распределять свои усилия и не допускать собственного выгорания.

— Поддержка со стороны семьи. Это хоть и последний в списке, но очень важный пункт. Семья должна понимать что вы делаете и зачем. У меня есть друзья, которые часто ругаются на тему того, что кто-то поздно приходит с работы и мало времени проводит с семьёй. С одной стороны я их понимаю — смысл создавать семью если муж/жена будет все время пропадать на работе? Но нужно относится к такого рода ситуациям как зрелые люди. Если я провожу все время на работе, то почему так? У меня злой босс и он заставляет меня работать больше чем нужно? У меня горит проект? Я не могу отказаться когда меня просят? Проблемы бывают разные и способы их решения тоже должны быть разными. Но, что должно быть едино для всех таких ситуаций — никогда не кричите на мужа/жену если они поздно пришли с работы. Человеку важно ощущать что его дома ждут, тогда он будет стремиться туда вернуться. Если он будет знать, что дома ждёт промывка мозгов, то наоборот будет задерживаться дольше на работе.

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

В завершение добавлю что много проблем возникает из ситуаций когда люди становятся сами заложниками своего успеха. Если кто-то долго и упорно работал, то он добился успеха. Теперь все знают что этому человеку можно поручить любую задачу и он её выполнит. Следовательно, когда приходит время поработать сверхурочно, то именно этот человек будет первым кандидатом. И вновь важным становится умение сказать «нет». В конце концов у вас есть контракт в котором указано, что вы должны работать 8 часов в день и за это вам платят N денег. Если вам нужно работать больше, то это в контракте не указано и вы смело можете отказать. Если ваш руководитель пытается угрожать вам чём-нибудь и давить на овертаймы, то это первый звоночек чтобы начать обновлять статус на LinkedIn.

Дякую за деталі, хорошу та щиру відповідь.

Один мой друг (без учетки на DOU) спросил — «а чем ты занимаешься в свободное время?» и потом добавил «видать его не так уж и много». Я пообещал ему что перепосчу его вопрос тут и сразу дам ответ.

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

Начнём с простого — «выдохнуть». Этот тип рекреационных активностей я использую когда вечером прихожу домой с головой размером с телевизор. Поскольку клин принято вышибать клином, то за телевизор я и сажусь, точнее не совсем за телевизор, а за комплект Apple TV + большой монитор. Кстати, хозяйке на заметку, монитор диагональю до 40″ можно купить намного дешевле чем телевизор аналогичного размера, а в моем сценарии разницы нет ибо каналы с нашего эфира я не смотрю.

Усевшись напротив телевизора я смотрю либо Netflix, либо Amazon Prime. Смотрю контент исключительно на английском, это помогает держать себя в тонусе в плане английского. Смотрю в основном что-то простое и легкое, чтобы не напрягать мозги. Из понравившегося могу назвать следующее: Brooklyn 99, Gravity Falls, Top Gear, Grand Tour, Community, Two and a half man.

Второй вид рекреационных активностей назовём «вдохнуть». Так скажем «вдохнуть» жизнь полной грудью. Тут у меня было много хобби, каждое из которых отнимало кучу времени и денег. Я играл в Collective Card Games (Magic the Gathering, Warhammer 40k), Miniature Wargames (Warhammer FB, Warhammer 40k, Infinity), Pen and Paper RPG (DnD, GURPS, SPECIAL). Это отличное хобби, но оно требовало слишком много внимания. Самое смешное, что когда я был ещё студентом, то времени было полно, но эти игры также требуют денег, которых у студента обычно нет. Когда деньги появились, то времени на прошлые увлечения уже не осталось и нужно было искать замену.

На текущий момент мое основное хобби это настольные игры, правда я перешёл больше на настолки «в коробках». Я уже не собираю миниатюры, я покупаю коробку в которой есть все необходимое для игры. Сейчас у меня довольно много настолок и мы собираемся как с друзьями по выходным, так и с коллегами по работе по вечерам чтобы в них поиграть. Не буду перечислять все из них, но вот самые интересные (на мой взгляд) игры из моей коллекции: Ticket to ride Europe, Takenoko, 7 wonders, Lords of Waterdeep, Mansion of madness.

В случае если друзей рядом нет, то я могу поиграть в что-то хорошо знакомое с детства. Все свои игры я покупаю на GOG. Из последнего что мне понравилось могу порекомендовать следующее: Master of Orion (2016), Heroes of Might and Magic III, Shenzhen.IO, Shadowrun Hong Kong.

Heroes of Might and Magic III

forever :) респект еще раз, и с Новым Годом :)

Хороший тамада архітектор і конкурси відповіді цікаві!

Редакція, везіть ще людей, які будуть так змістовно на коменти відповідати!

Плюсую, прямо супер-комменты и ответы. Нет ли у Антона колонки или блога на почитать?)) Если нет, обязательно нужно завести :)

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

Попробуй может канал в телеграме завести вместо блога? Как мне кажеться это немного проще формат чем блог. Или страничку фб используй не только для репоста шутеечок))

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

Я обычно смотрю на reference architecture от больших компаний. Вот есть несколько примеров:
— docs.microsoft.com/...​/reference-architectures
— aws.amazon.com/architecture

Также есть хорошие материалы от Microsoft и Amazon относительно шаблонов проектирования архитектуры. Детальнее можно посмотреть тут:
— docs.microsoft.com/...​re/architecture/patterns
— aws.amazon.com/...​tecture/well-architected

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

Спасибо за ресурсы, актуально очень

Чи вам доводилося брати людей на позицію архітектора?

Це були вже готові архітекти чи росли свої?

Як часто бувают трєнія з архітекторами від замовника?

За прошлый год я провел около 40 собеседований на роль архитектора. Взять был готов не больше 10 кандидатов, которые через меня прошли. Я, в основном, проводил техническое собеседование. Сперва я прошу человека рассказать про свой опыт в рамках последних двух или трех лет, прошу его сразу акцентировать внимание на самой интересной и значимой части его работы. Исходя из рассказа задаю несколько уточняющих вопросов с целью лучше понять с чем человек работал. Потом мы переходим к доске и начинаем рисовать. Я даю человеку задание, в котором явно не указаны все требования, например — «хочу архитектуру системы для анализа финансовых данных и чтобы она работала быстро». С такого рода заданием работать невозможно и кандидат начинает задавать вопросы. По ходу выяснения требований он рисует части архитектуры на доске, параллельно я смотрю как он умеет выяснять требования. Как только архитектура приобрела свои очертания я начинаю насыпать новые бизнес требования с целью проверить как архитектура готова их адресовать. Например — «финансовые отчеты раньше строились только по одному отделению банка, а теперь я хочу строить их в разрезе страны» или «система продавала билеты на концерт в фан зону (без закрепления места), а теперь мы хотим ее переиспользовать для продажи билетов в кино или театр (с закреплением места)». Если кандидат чего-то не знает, то это еще не конец разговора. Если у человека основной опыт, например, в сфере финансов, то не факт что он сможет предугадывать и быстро реагировать на изменения в требованиях для здравоохранения. Мой основной критерий к каждому кандидату — адекватность и наличие здравого смысла.

Относительно воспитания архитекторов внутри компании, то был как положительный так и отрицательный опыт. Были случаи, когда человек приходил и спрашивал меня явно — «что нужно сделать чтобы стать архитектором?» и просил меня помочь развить нужные навыки. Бывали случаи когда люди из команды были готовы к повышению и мы предлагали им роль архитекторов, но они отказывались и оставались на текущих местах. Мотивация была разная — человек не чувствовал себя достаточно уверенно и боялся не оправдать доверие, человек чувствовал себя хорошо в своей текущей зоне комфорта и не видел смысла что-то менять, человек хотел развиваться больше в менеджерскую должность.

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

Приведу пример трений и способа их решения. Был проект у нас в котором клиент принес нам свои инструменты. Нам сказали — тут был тендер и мы приняли решение и уже купили вот эти продукты, теперь стройте нам решение на их базе. Проблема была в том, что для автоматизации бизнес процессов они купили довольно популярную утилиту, которая умеет выстраивать процесс парсинга текстовых файлов с последующей загрузкой данных в разные хранилища. Часть архитектуры уже была нарисована их архитектором и продукты там уже были прибиты гвоздями. С нашей стороны давить их на то, что они плохо провели тендер это все равно что сказать их архитектору, что он не умеет делать свою работу. Оставить данную тулу в проекте означало обречь команду на вечные муки. Решение было найдено следующее — мы оставили эту тулу в проекте, но поручили ей исключительно задачи по парсингу файлов. В текущую архитектуры мы добавили два дополнительных компонента — шина интеграции и шина оркестрации. Мы показали, что мы поддерживаем выбор изначальной тулы и она умеет парсить файлы как никто другой. В дополнение к ней мы предложили улучшить систему и ввели свои два компонента. Таким образом мы не бодались с их архитектором, а в конце он еще и получил ачивку за выбор отличного технологического партнера в нашем лице.

Чи були конфлікти з дофіга розумними сеньорами-помідорами?

Чи було таке що команда не хотіла реалізовувати ваше рішення?

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

Чаще всего конфликты случались у меня из-за фраз вида «это не моя работа и я не буду ее делать». Эта формулировка выбешивает меня в кратчайшие сроки. Пример — у меня нет времени сделать прототип и посмотреть на две разные библиотеки с целью выбрать ту что лучше. Я прошу об этом кого-то из команды, а человек мне заявляет что это не его работа и выбор технологий должен делать архитектор. В чем-то он безусловно прав, но я бы посмотрел на это иначе. Архитектор не должен делать выбор технологий, но он должен нести за них ответственность. Какую-бы я не выбрал библиотеку, писать код все равно будут разработчики. Такого рода конфликт обычно решался путем нахождения другого человека в команде, который соглашался брать на себя эту задачу.

Часто бывают конфликты связанные с тем, что человек не хочет взглянуть за пределы своей зоны ответственности. В итоге имеем ситуацию «с моей стороны патроны ушли, а это на вашей стороне проблема с мишенью». Разработчики порой не думают кто и как будет поддерживать их продукт. В целом это не то чтобы смертельный грех, но был у меня один случай давным-давно, который я помню до сих пор. Кому-то из команды пришла в голову идея, что было-бы круто использовать elasticsearch как первичный источник данных. На локальной машине все работало хорошо, интеграционные тесты тоже проходили. Проблемы начались тогда, когда на проде решили пересоздать кластер. В результате отсутствие налаженной коммуникации в команде привело не просто к трениям, а к реальным проблемам.

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

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

Привет Антон! Хорошее интервью =) Рад за тебя что у тебя все получается!

Привет Антон!
Спасибо. Есть шанс что весной буду в твоих краях, так что буду рад пересечься.

Дякую за змістовні відповіді! Неочікувано :)

Скажіть ще таку штуку, з того що у вас тайтл Solution Architect і ви MVP, виходить те, що основною вашою роботою є зрозуміти потреби клієнта і придумати та продати йому рішення на базі технологій MS?

Чи були випадки, коли рішення MS/Azure не підходили?

Были ситуации, когда заказчик приносил с собой ограничения вида «хочу только PHP» или «хочу только Google Cloud». Это бывало по разным причинам, но это не должно сильно мешать работе архитектора. В моем случае я подключал соответствующих ребят, которые помогали мне делать архитектуру в условиях ограничений «хочу только PHP» или «хочу только Google Cloud».

И снова пример — был у меня клиент из сферы рекламного бизнеса. Ребята делали рекламу для крупнейших брендов по всему миру. Для обеспечения работы у них были куплены и развернуты около 10 систем для работы с брифами, макетами, логами времени и т.д. Проблема была в том, что эти системы ничего не знали друг о друге, что приводило к дублированию данных между ними. Нашей задачей было разработать интеграционные компоненты и новый UI чтобы решить поставленные задачи. Обязательным ограничением было использование PHP Laravel. Я занимался ревью разработанной архитектуры, которую делал другой архитектор с опытом меньше чем у меня. Также ему помогали ребята с глубокой экспертизой в PHP для правильного выбора библиотек для решения того или иного вида стандартных задач. Общими усилиями все сделали хорошо, архитектура была разработана под AWS и разработка велась на PHP.

В целом мне тяжело найти сценарий когда та или иная технология могла не подойти под проект. Тут все опять идет от людей. Если у человека руки растут из плеч, то он сможет написать отличный API на .NET / Java / PHP и выбор технологии не так сильно повлияет на успех проекта как умение ей пользоваться. Если у человека руки растут из карманов, то он напишет полную ерунду на любом языке программирования.

Аналогично и с облаками. У меня самая глубокая экспертиза именно в Azure, но я все равно могу помочь с разработкой концепции «cloud native» системы в любом облаке. Принципы построения облака едины для всех провайдеров, облака призваны решать одинаковые задачи, но делают они это по разному. То что я часто вижу, так это муки людей относительно выбора того или иного вендора, того или иного сервиса и т.д. Тут моя рекомендация будет следующего рода — лучшее враг хорошего. Вы всегда можете искать и найти еще более оптимальный путь решения задачи, но не факт что вам стоит это делать. Если вам уже хорошо сейчас, то примите это как факт и двигайтесь дальше. Менять что-то нужно только если вас что-то явно не устраивает.

Антон, расскажите, пожалуйста, про сертификацию на Azure Solutions Architect. Как готовиться? Где сдавать?

Я так понимаю что вопрос касается именно вот этой сертификации www.microsoft.com/...​-solutions-architect.aspx

В целом общий ответ таков — лучше всего готовить к такому используя MOC (Microsoft Official Course). Но сейчас проблема в том, что на экзамены AZ-* еще может не быть MOC`ов. В таком случае я бы рекомендовал курсы от Scott Duffy, найти их можно на платформе Udemy по ссылке www.udemy.com/user/scottduffy2

Привет, Антон.
Можете предложить технологию в Azure. Требования —
желательно Managed(SaaS какой-то или тому подобное) кеш для веб сервисов(0,3-0,5 TB) и батч процессинга(не более 50-100 RPS, latency — <0,7-1 sec), должна покрывать потребности несложного range querying по набору атрибутов сущности(даты, время, целочисленные, строчные значения), желательно distributed(будет здорово, если есть multi-master writes), удобный strongly-typed клиентский api для разработки на трендовых языках.

Вы уверены что вам именно кеш сервис нужен, а не просто базу. Так в целом чтобы удовлетворить все ваши требования я бы порекомендовал посмотреть в сторону CosmosDB

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

Еще одна история с реального проекта — система для просчета налогов. Был у меня один раз проект, где мы строили систему, которая считала сколько налогов должен заплатить человек при условии что он получает деньги в нескольких разных компаниях в разных странах. Первоначально задача была поставлена как и у вас — нужно построить распределенное хранилище на N Tb данных. На вопрос почему ответом был — у нас пользователи могут быть со всего мира. Ок, пока принято. Начинаем совместно с аналитиком копать в сторону того какие сценарии работы с этим хранилищем данных у нас будут использоваться чаще всего. Результатом нашей работы стало то, что больше 90% работ будет проходить в рамках одного налогоплательщика. Остальное это в большей части загрузка данных разного рода (через ftp, почту, форму на сайте и т.д.). Было принято решение сделать упор на оптимизацию работы именно 90% системы, принеся в жертву оставшиеся 10%. В результате мы разбили одно большое хранилище на несколько хранилищ меньшего размера. Каждого налогоплательщика мы поместили в одну из баз, но теперь размер базы уже измерялся в N Gb и работать с ней было намного проще.

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

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

Ваш момент по поводу пересмотра дизайна и применения ABC анализа мне понятен, спасибо. У меня есть конкретные нефункциональные требования и мне интересно мнение эксперта в области услышать, может с этой задачей справиться Azure эффективно, какие есть решения, какие есть проблемы, конкурентоспособен ли azure SaaS в этом смысле.

В целом я соглашусь с советом Ильи относительно того, что нужно посмотреть на CosmosDB в Azure.

Какие-то моменты, которых стоит остерегаться сразу с этой технологией в контексте моей специфики или я просто его как mongo могу взять на виртуалках и ожидать, что оно работать будет хотя бы не хуже, с точки зрения бюджета и ожидаемых показателей?

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

Относительно проблем которых стоит остерегаться при использовании CosmosDB то тут всего одна деталь — при неправильном использовании Cosmos это не набор фич, а стоимость хостинга. Другими словами вам потребуется создать протопит, на базе которого желательно ответить на следующие вопросы:
— Сложно ли разработчику это писать?
— Сложно ли DevOps это поддерживать?
— Адекватна ли стоимость хостинга данного решения?

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

Чуть не забыл, обязательно изучите в деталях что такое request units в контексте CosmosDB (docs.microsoft.com/...​e/cosmos-db/request-units). И желательно поиграться немного с нагрузочным тестированием на стадии прототипа, это даст лучшее понимание подходит вам CosmosDB или нет.

Чи ви ще активно кодите?

Скільки часу приділяєте кодінгу?

Що є основним вихлопом вашої роботи, діаграми, документи, продажі?

Чи почали ви перетворюватися в архітектора-астронавта? Як боротеся з цим?

— Тяжело сказать что именно означает «активный кодинг». По работе мне приходится писать код для прототипов, которые потом разработчики берут и доводят до уровня production кода. Для целей самообразования порой пишу код чтобы потрогать руками новые технологии. Иногда бывает пишу код для своей «гаражной» студии. Но, я уже точно пишу кода меньше, чем когда занимал должность разработчика.

— По времени получается уделять кодингу (именно написанию кода) где-то от 5 до 15 часов в неделю. Это при том что я могу работать над своими проектами на выходных. Порой это бывает не столько код на C#, сколько скрипты для автоматизации чего-то, но я все равно причислю это к кодингу.

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

— Я не совсем понял вопрос про «архитектора-астронавта» и тут мне нужно больше деталей чтобы что-то ответить.

Я не совсем понял вопрос про «архитектора-астронавта»

www.joelonsoftware.com/...​ure-astronauts-scare-you

и тут мне нужно больше деталей чтобы что-то ответить

Я маю наувазі, наскільки ваші діаграми та документи потім реально втілюються в життя. Бо я часто бачив приклади коли команда приходила на проект, викидувала все що понапридумували астронавти і починала робити рішення виходячи з реальної ситуації та реальних вимог, а не з того, що напродавали.

Хорошая архитектура решения является лишь отправной точкой для разработки приложения. Чтобы продукт получился качественным вам нельзя полагаться на хорошую архитектуру и разработчиков средней руки, как и наоборот. Архитектор работает вместе с командой, он задает ей вектор для движения. Архитектор в вакууме (без команды) практически никогда не принесет пользы бизнесу. Команда без архитектора имеет шанс бежать хорошо, но не в ту сторону.

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

1. Приходит существующий клиент и дает нам задачу — разработайте нам архитектуру хранилища данных так, чтобы оно выдерживало нагрузку в два раза больше текущей. И вроде все понятно, но не совсем. В жизни всегда приходится работать в условиях каких-то ограничений. В нашем случае был строгий лимит по времени — не больше двух месяцев. После краткого анализа было принято решение не проводить никакой работы вообще, а просто перейти на более дорогой тарифный план в облаке. Решение было обосновано тем, что дополнительные расходы на новый тарифный план потянут на 1 чемодан денег в месяц, а два месяца работы дата архитектора потянут на 10 чемоданов денег. Другими словами в данном примере проще добавить больше ресурсов, чем оптимизировать использование существующих.

2. Приходит новый клиент и говорит — хочу мигрировать в облако с целью уменьшения затрат на хостинг, но что-то экономии пока не видно. Анализ показал, что проблема была в том, что клиент перенес все свои виртуалки в облако путем copy and paste. В таком случае достичь видимой экономии практически невозможно и нужно применить голову, чтобы проект был выгоден с экономической точки зрения.

3. Приходит новый клиент и говорит — у меня есть проект он другого вендора и я передаю его вам, а вы должны дожать релиз за 3 месяца. И вроде все понятно, нужно лишь подправить немного тут и там. Проект до нас разрабатывался несколько лет и у меня была чуйка, что там не все так хорошо раз релизов нет и вендора меняют. Был совершен отчаянный шаг — я спросил клиента прямо в лоб: «что вам важнее — сохранить кодовую базу прошлого вендора (читай деньги потраченные на команду на протяжении нескольких лет) или сделать первый релиз для пользователей через 3 месяца?». Клиент выбрал релиз, а мы ответом предложили ему выкинуть все старое и собрать за 3 месяца лайтовую, но самодостаточную, версию продукта. Эту версию он сможет выкатить своим пользователям, которые ждут ее уже год и перестанет кормить их обещаниями.

В чем была суть всех этих историй — я никогда не буду идти в разработке архитектуры от технологий, я всегда буду идти от бизнес задач. Есть такое хорошее слово «enabler», которое я не уверен что смогу полностью корректно перевести на русский или украинский. Технологии являются вот именно этими enabler`ами, но драйвят все именно бизнес задачи.

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

Вот еще небольшой пример с конференциями и моей мотивацией относительно посещения того или иного мероприятия. Большинство инженеров выбирают доклады с темами вида «как заставить entity framework выполнять запросы в два раза быстрее» и это понятно. Человек уже имеет опыт в какой-то сфере и он хочет стать еще более крутым экспертом в этой самой сфере. Это его зона комфорта. Я делаю иначе и часто выбираю доклады из сферы в которой у меня опыта нет. Во-первых я так могу относительно быстро понять — отсутствие опыта в этой сфере это упущение или нет? Признаюсь к своему стыду, что я далеко не сразу уверовал в Docker. В момент пика своего хайпа я не мог понять, и никто мне не мог внятно объяснить, в чем собственно прикол? Если у меня все работает на .NET и вся команда сидит на Windows, то зачем мне еще оборачивать все это в дополнительную абстракцию? Потом я посетил Microsoft Tech Summit в Копенгагене и пошел там на доклад ребят из RedHat, которые рассказывали про OpenShift и его особенности работы в облаке Azure. Только там мне дали понять в чем же суть Docker и какую пользу он может мне принести.

Мораль истории такова — если продолжать развиваться в рамках своей зоны комфорта, то можно стать отличным экспертом в этой сфере, но есть шанс попасть в ситуацию когда у тебя в руках есть только молоток и все задачи кажутся от этого гвоздями. Ценность архитектора в том, что у него всегда должен быть максимально широкий взгляд на вещи. А ширину взглядов можно получить только выбивая себя из зоны комфорта и пробуя что-то новое. Я когда-то начал так смотреть на Node.JS и начал пробовать решать с его помощью задачи, которые я раньше решал на .NET. Для меня это было началом больших откровений. Я не могу сказать что .NET лучше или хуже чем Node.JS, но они довольно разные и позволяют дать хороший старт для «расширения» своих знаний, особенно если крутить Node.JS с TypeScript и без.

Команда без архитектора имеет шанс бежать хорошо, но не в ту сторону.

Ви часто таке бачите на практиці? Маю наувазі команду без архітектора яка якось щось там робить.

Не часто, но все равно такое бывает. Архитектор это не обязательно конкретный человек, разработчик и тестировщик это тоже не обязательно конкретные люди — это все роли.

История из жизни — у меня один раз была инженерная команда из 3 разработчиков и 0.5 архитектора. В этой команде я был как раз разработчиком. С тестированием нам никто не помогал и мы тестировали все сами, зато быстро появилась культура писать авто тесты на все и держать уровень покрытия не ниже 95%. Я понимаю что без хорошего тестировщика мы могли продумать далеко не все возможные сценарии тестирования и это было видно всем, но это все равно не мешало нам делать все возможное чтобы багов было как можно меньше.

И еще одна история из жизни — был проект в котором архитектора на старте решили не брать, вроде как все должно было быть просто и клиент не хотел тратить лишнее деньги. К чему это привело в результате — проект был сделан быстро, но при нагрузке все упало почти в первую неделю после запуска. Проблема оказалась в том, что микросервисы кидали друг другу задачи синхронно используя http запрос-ответ. Как только пошли тяжелые задачи, то решили просто увеличить таймаут http запроса до 10 минут. В результате система получала пачку задач от пользователя и возвращала ему управление на UI с сообщением «задача взята в работу, ожидайте». А на самом деле происходило следующее — загрузка CPU под 100% и не падает, задачи прилетают еще и система перестает отвечать. Архитектор зашедший в проект увидел это сразу и предложил поставить между микорсервисами очередь сообщений с брокером и поменять подход приема задач в работу с push на pull. Это позволило агентам самим решать есть у них еще ресурсы или нет, следовательно могут ли они сейчас брать новую задачу в работу или нет. Появилась также в базе новая таблица со статусами каждой из задач, по которой можно было отслеживать что конкретно происходит с каждой задачей. Также внедрение брокера позволило разделить постановку задачи (задача зашла в очередь) и выполнение задачи (задача взята в работу из очереди), что позволило проще управлять загрузкой каждого ресурса.

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

Але ж це така проблема (тупо типова задача черг з задачами) яку будь який сенйорний чувак міг би розрулити, невже там настільки некваліфікована команда була?

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

Если верить Google, то да. Попробую привести пример — допустим я хочу строить глобальную распределенную систему, которой будут пользоваться люди по всему миру, то облако для меня это enabler. Если у меня стоит задача разграничивать права доступа к ресурсам, то identity server это enabler.

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

Що це за діаграми?
От, припустимо, в мене є апплікейшен, там 4 сервіси, арі гейтвей для них, пара черг, база даних та купка зовнішніх інтеграцій.

І намалював діаграму з 4 блоків, пари стрілочок і додав шо це все буде хоститися в азурі (з посиланням на вендорські інфраструктурні рішення). Я архітект точений, чи просто девелопер який робить свою роботу?

Це вже можна вважати архітектурою?

Для документирования архитектуры я использую подход который называется «4 plus 1 view», вот тут чуть больше деталей en.wikipedia.org/...​_architectural_view_model

Для разработки самой архитектуры использую подход «Attribute Driven Design», вот тут чуть больше деталей en.wikipedia.org/...​i/Attribute-driven_design

Основная идея в том, что схема с набором сервисов, очередей, баз данных и т.д. это часть моей работы, но я не ограничиваюсь только этой схемой. Суть архитектурных документов в том, что они должны покрыть не только технологии, но также дать понять почему бизнес от них получит какое-то преимущество. В данном случае аргумент «технология X работает в два раза быстрее чем технология Y» не факт что является преимуществом. Если на технологии Y уже есть библиотеки для решения наших задач, а на технологии X их нет, то аргумент в пользу скорости работы может быть не такой критичный, как необходимость переписывать свой парсер регулярных выражений или что-то еще в этом роде.

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

Яка частка вашої роботи припадає саме на бізнес-стейкхолдерів проти роботи з технічною командою?

Я правильно розумію що ви ходите на предпродажі та тісно працюєте з продажниками?

Да, все верно. Я работаю с командой которая занимается продажами и это отдельная часть работы. Фаза pre-sale вообще очень сильно отличается от фазы delivery. На фазе pre-sale не всегда есть время разрабатывать архитектуру, это скорее зависит от того, как клиент проводит процесс отбора вендоров. Один раз у нас было такое, что клиент кинул нашим разработчикам тестовое задание и попросил его сделать. И это могло быть хоть как-то обосновано после подписания контракта, но нам такое прилетело еще на этапе выбора одного из N вендоров. Это был новый опыт и новые впечатления для всех.

Относительно работы на фазе delivery — тут я тесно работаю с аналитиками, другими архитекторами, тех лидами, стейкхолдерами, владельцами продукта и т.д. (при условии что все эти люди есть). Сказать сколько именно времени я работаю с кем конкретно тяжело, но я постараюсь описать это на примере. Сперва я трачу около 1 часа вместе с аналитиком чтобы выйти на звонок с владельцем продукта. Получив новые требования мы садимся и решаем что у нас может быть сделано текущими компонентами, а для чего нужно разработать что-то новое. Этот синк может занять от 30 минут, до нескольких часов. Если есть необходимость разрабатывать новый кусок архитектуры, то я сажусь это делать. Времени это может занять от одного часа до нескольких дней. После этого я и аналитик презентуем новые требования и новые компоненты архитектуры команде. Обычно это занимает еще 1 час, максимум 2 часа. После могут быть дополнительные звонки / встречи в рамках инженерной команды с целью уточнить как именно эту архитектуру будем реализовывать.

А було таке шо напродавали одне а по факту зробили інше?

Со мной такого не происходило. Обычно, тот архитектор который участвует в продаже, потом участвует и в создании (поставке) решения. Другими словами — ты пообещал, тебе и делать. Если не можешь сделать что наобещал, или наобещал какой-то фигни, то, как сказал Чарли Харпер в сериале Two and a half men — «нехай твій рот не виписує чеків, які дупа не зможе перевести в готівку».

І намалював діаграму з 4 блоків, пари стрілочок і додав шо це все буде хоститися в азурі (з посиланням на вендорські інфраструктурні рішення). Я архітект точений, чи просто девелопер який робить свою роботу?

Не усложняйте. Если в вакансии написано: «Нужен архитектор», и вас взяли на неё — вы архитектор :) Остальное не считается.

Как только команда инженеров начала работу я продолжаю рисовать архитектуру дальше.

Чи доводиться вам спускатися до технічних проблем, припустимо пацани не тямлять як прискорити обробку черги задач, ви їм щось підказуєте, чи то вже не архітекторська справа?

Да, порой приходилось такое делать. Архитектор всегда воспринимается как самый технически грамотный человек в команде, ну или точно один из них. Помимо этого нужно понимать, что у каждого человека есть свои сильные и слабые стороны. Возьмем меня — я знаю толк в облаках, а в Azure так вообще эксперт. При этом, если мне предложат выбрать в команду одного из двух инженеров, то критерий «знание облаков» для меня явно не будет на первом месте. Я всегда понимаю, что могу помочь человеку освоить облако, но, если у него страдают из-за этого базовые знания и он (гипотетически) не знает чем в .NET абстрактный класс отличается от интерфейса, то я не факт что возьму его работать себе в команду.

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

Бывало такое, что в отсутствии DevOps инженера на проекте его роль я брал на себя. Архитектуры в том проекте еще хватало на пару месяцев вперед и у меня было время помочь команде выполняя другую роль. Бывало такое, что приходилось сесть и писать код, тесты, делать верстку. Главное тут правильно расставить приоритеты и использовать каждый ресурс (талант) по назначению. Другими словами — если архитектор может писать код, то это не значит что он должен писать код. Если у архитектора нет более важных задач для проекта, то пописать код может быть порой даже полезно.

Архитектуры в том проекте еще хватало на пару месяцев вперед и у меня было время помочь команде выполняя другую роль.

Ви займаєтесь тільки «інфраструктурною архітектурою» чи архітектурою бізнес-рішення теж? Наприклад, типовим сценарієм для ентерпрайзу є використання стейт машин або різного роду воркфлоу двіжків. Ви таким теж займаєтеся (це суто прикладне програмування, організація класів методів і тд) чи це вже сильно лоу-левел?

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

Про движки для рабочих процессов могу сказать что бывало разное. Был проект где мы использовали WWF, был проект где аналогичный движок переписывали на PHP. Был проект где использовали BizTalk и я занимался автоматизацией его развертывания лично, как и автоматизацией установки на него компонентов. Были проекты где приходилось писать своими руками код под SharePoint или Dynamics CRM. Был проект с активным использованием Corezoid. Был проект где из ETL тулы пытались сделать движок для бизнес процессов в компании.

В среднем это выглядит так: анализируем требования -> выбираем подход -> смотрим на опции по реализации. Бывало так что решение по реализации принимал сам, а бывало что отдавал его команде.

Бывает что клиент уже приносит свои тулы и приходится выполнять роль адвоката для команды выходя на звонки с архитектором клиента и рассказывая ему что использование SSIS для автоматизации двух-этапного утверждения документа это не самое правильное использование этой технологии.

Send request create payment
Check responce from Kaznache(istvo?)

(докопайся до орфографии mode on) А... кхм... это всегда такие комменты в коде, если работа на внутреннего заказчика?))

Да, таки опечатка есть. Самое веселое что код пролежал в репозиториях около 3х лет и никто не обратил на это внимание до этого самого момента. Если интересно, то этот кусок кода с сайта нашей конференции AzureDay, ибо мы оплату билетов участников принимаем через Kaznachey.

Что самое интересное как минимум три человека смотрели детально этот код и ничего не заметили

Это потому что комментарии никто не читает. Они устаревают и вообще в них смысла мало.

Підписатись на коментарі