Перейти к содержанию

Как подготовиться и пройти System Design Interview — конспект и анализ выступления Александра Поломодова

У меня есть цель стать в будущем Solution Architect и я ищу пути её достижения.

Поэтому я нашел и послушал доклад Александра Поломодова c ArchDays 2022, в котором он показал путь, который сам когда-то проходил и кажется ему правильным.

Написал конспект с основными мыслями. Привел ссылки на: книги, записи видео, обучающие курсы и прочие ресурсы.

Сделал свои выводы. Помимо прочего, в них я показал альтернативный способ, как можно стать Solutions Architect.

Если у вас такая же цель, как и у меня, читайте, будет полезно!

Конспект

Какие роли проходят интервью по System Design

Интервью по System Design проходят кандидаты на позиции Senior и выше.

Интервью по System Design проходят Senior и выше

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

Структура интервью

⏰ Тайминг — 1 час. Чтобы в него уложиться, будет полезно иметь в голове фреймворк — структуру интервью.

Структура интервью по System Design приведена на рисунке (нажмите для увеличения):

Структура интервью по System Design

1. Формализация задачи

Что стоит уметь:

  1. Задавать правильные вопросы и уточнять, что входит в scope задачи, а что нет.
  2. Собирать функциональные требования в виде желаемых сценариев системы.

Что стоит изучить:

  1. Для функциональных требований:
    1. Use Cases из UML;
    2. User story;
    3. Jobs to be Done.
  2. Для нефункциональных требований:
    1. Architecture Tradeoff Analysis Method от Software Engineering Institute of Carnegie Mellon University. Я не в первый раз уже слышу об этом университете в части архитектуры ПО. Я как-то искал и нашел их курсы, оставлю на память в разделе со ссылками на дополнительные материалы.
    2. Книгу Software Requirements, 3rd Edition, 2013. Книга уже скачана и ждет своего часа.
    3. Книгу Software Architecture for Busy Developers, 2021.

2. Границы системы

Что стоит уметь:

  1. Выбирать правильный способ интеграции со смежными системами: Files, DB, API, Messaging.
  2. Проектировать точки интеграции системы под нужные сценарии.
  3. Если интеграция через API, то выбрать правильно подход, например: REST, RPC, GraphQL, AsyncAPI...

Что стоит изучить:

  1. System Context Diagram из C4 model.
  2. Вспомнить про сети и протоколы: OSI, UDP, TCP/IP, DNS, HTTP 1/2/3, Websockets...
  3. Балансировщики нагрузки: Nginx, HAProxy...
  4. Подходы к интеграции систем между собой: Files, DB, API, Messaging.
  5. ...
  6. Книгу Computer Networks, Andrew S. Tanenbaum, 2003. Книга объемная — 876 страниц. Хорошо, что я уже получил эти знания во время получения сертификаций Cisco (CCNP, CCDP) и Microsoft (MCSE) 🙂.
  7. Книгу Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns (Boston: Addison-Wesley, 2003). Её же рекомендовал Sam Newman в книге Building Microservices (кстати, см. мой обзор не неё).

3. Основные потоки и компоненты системы

Что стоит уметь:

  1. Описать основной поток работы (happy path), проходящий через компоненты системы.
  2. Очертить exceptional flows и как наша система их обработает. Уточнять на интервью, надо ли это обрабатывать, чтобы не тратить лишнее время.
  3. Научиться определять read/write path для системы с учётом архитектурных характеристик. Если ты понимаешь, как будешь читать данные, то можно заранее подумать, в какую удобную структуру данных ты их сложишь.

Что стоит изучить:

  1. Container Diagram из C4 model.
  2. Sequence и Activity Diagrams из UML. Во время интервью обычно их не рисуют, потому что это долго.
  3. IDEF0 и DFD диаграммы. Эти диаграммы мне преподавали ещё во время учебы в университете.
  4. BPMN диаграммы. Этот тип диаграмм я активно использовал, когда работал с Битрикс24.
  5. Как балансировать read/write path для системы. Это хорошо описано в книге Designing Data Intensive Applications — Martin Kleppmann, 2017. Согласен, «Кабанчик» — отличная книга, в ней много ссылок на дополнительные материалы.

4. Концептуальная схема

Что стоит уметь:

  1. Разделять рабочие нагрузки на stateful/stateless. Обычно stateful требует бОльшей проработки.
  2. Связывать между собой компоненты.
  3. Проектировать модели данных: отношения, поля и т.п.
  4. Выбирать классы для stateful компонентов:
  5. RDMBS.
  6. NoSQL по основным типам: K/V, Document-oriented, Column-oriented, Graph.

Что стоит изучить:

  1. Как делить систему на части — Domain Driven Design и конкретно виды subdomains и Bounded Context.
  2. Как моделировать данные ER Diagrams, Class Diagrams.
  3. Принципы для stateless приложений из The Twelve-Factor App.
  4. Какие СУБД бывают и их границы применимости.
  5. Как работают оркестраторы рабочих нагрузок, навроде Kubernetes.
  6. Книгу Software Architecture: The Hard Parts, 2021. Написана консультантами из Thoughtworks. Объём 416 страниц.
  7. Книгу Kubernetes Patterns, 2nd Edition. Объём 478 страниц.

5. Реальная схема и желаемые архитектурные характеристики

Что стоит уметь:

  1. Выбирать конкретных представителей систем из перечисленных в концептуальной схеме.
  2. Думать в концепции failure domains.
  3. Проектировать систему с учетом day-2 operations: эксплуатация и развитие (logs, monitoring, migrations...).

Что стоит изучить:

  1. Потрогать руками основных представителей систем из перечисленных в концептуальной схеме.
  2. Понять гарантии, которые дают эти решения. Понять возможный диапазон рабочих нагрузок, которые они потянут.
  3. Изучить SRE подходы и потрогать руками инструменты для logs, monitoring, migrations...
  4. SRE книги от Google и обязательно Building Secure & Reliable Systems, 2020. Объём последней — 500 страниц. Все эти книги по SRE уже есть в моём плане обучения.

6. Масштабирование под нагрузку

Что стоит уметь:

  1. Масштабировать stateless компоненты.
  2. С использованием оркестраторов и HPA, VPA.
  3. Масштабировать stateful компоненты.
    1. Масштабировать по чтению — Replication. Здесь могут быть ослаблены требования по consistency.
    2. Масштабировать по записи — Partitioning и Sharding. Здесь нужен определённый паттерн доступа к данным, чтобы схема работала.

Что стоит изучить:

  1. Книгу Designing Data Intensive Applications — Martin Kleppmann, 2017.
  2. Книгу Kubernetes Patterns, 2nd Edition.
  3. Книгу Database Internals, 2019. Объём 315 страниц.
  4. Книгу Distributed Systems 4th edition. Объём 683 страницы.
  5. Почитать и погонять нагрузочные тесты с любыми вашими инструментами.

7. Советы для прохождения интервью

  1. Помнить о времени.
  2. Не начинать проектировать сразу. Нужно сначала понять задачу, требования.
  3. Делиться своими размышлениями при проектировании с интервьюером.
  4. Проявлять самостоятельность в проектировании → вести интервью.
  5. Реагировать на наводящие вопрос и уточнения. Возможно, ты что-то забыл и интервьюер мягко подталкивает к размышлениям в правильном русле.
  6. Говорить уверенно о том, что знаешь.
  7. Подготовить вопросы к интервьюеру на случай, если для них останется время.

🔗 Ссылки на дополнительные материалы

  1. Видео доклада на YouTube.
  2. Слайды на Dropbox.
  3. Публичное интервью по System Design, про которое упоминал Александр в своем докладе. Длительность 1,5 часа.
  4. Сайт Конференции по архитектуре IT-решений ArchDays.
  5. Курсы от Software Engineering Institute of Carnegie Mellon University:
    1. Software Architecture: Principles and Practices - eLearning.
    2. Understanding Software Architecture, Quality, and Security Through Code Analysis.
    3. Documenting Software Architectures - eLearning.

Мои выводы

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

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

А ещё, после создания систем, он не должен тут же сбегать с проекта. Он должен поэксплуатировать созданные системы. Это нужно, чтобы понять, где он ошибся в решениях, что получилось удачно и что можно улучшить.

Теперь я понимаю, почему я в своей карьере встречал так мало Solutions Architects. А тех, что встречал, были загружены по уши.

Надо понимать, за что отвечает и чего добивается Александр. Для начала, ему требуется поставлять в компанию архитекторов в требуемых количествах. И при этом желательно, чтобы не сильно задорого.

Как раз для этого и делаются повышенные требования на входе. Чего только стоят алгоритмические секции для архитекторов. Это снижает текучку персонала за счёт создания атмосферы некой элитной группы. Плюс это экономит фонд оплаты труда, т.к. всегда можно оценить человека по матрице компетенций и аргументированно показать, что он не заслуживает прибавки к зарплате. Ну а если и заслуживает, то только по определенной процедуре (1) и в определенные периоды времени (2).

  1. Требуется собирать артефакты и доказывать принесенную компании пользу.
  2. Раз или два раза в год.

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

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

Не раскрыто, какие софт-скиллы ожидаются от архитектора и как их развивать. Что-то мне подсказывает, что навыки коммуникации, лидерства, командной работы и стремления учиться — особенно важные для данной роли 🙂.

Выглядит, как будто миссия невыполнима. Что можно сделать? Как и в случае с полученными мной сертификациями Cisco и Microsoft, пройденным курсом по SRE от МТС, я считаю, что самое эффективное обучение — от игроков из индустрии.

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

Например, можно присмотреться к платной EPAM Solution Architecture Program. Обучение проходит 9 месяцев и стоит $3'000 без скидки. Единственный момент, я не изучал вопрос, можно ли у них поучиться из РФ. Можно попробовать поискать в своей социальной сети её выпускников и узнать детали.

Откуда я о ней узнал

Об этой программе я узнал из выпуска Podlodka #224 — System Design с Элвином Рахманкуловым, главой Mobile Competency Center в EPAM Systems.

Рекомендую дополнительно послушать подкаст Podlodka #212 — Профессия: Solution Architect с Владимиром Ивановым, он как раз был Solution Architect в EPAM Systems.

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

Что дальше?

  1. Нашли эту статью полезной? Поделитесь ею и помогите распространить знания!
  2. Нашли ошибку или есть идеи 💡 о том, что и как я могу улучшить? Напишите мне в Telegram.
  3. Хотите узнать обо мне больше? Читайте здесь.