System Design Interview: оценки и фреймворк интервью

Гость представляется: почти шесть лет в компании, руководит управлением, которое отвечает за онлайн-обслуживание и мобильный банк, и надеется позвать ведущего к себе, когда его группа возьмётся за следующую книгу. Дальше короткие вопросы для знакомства: писал он за карьеру в основном на скриптовых языках, Python и Ruby, а выбирая заново, взял бы что-нибудь более строго типизированное; кумиров нет, но равняется он на тех, кто дорастает до верхних грейдов индивидуального трека в больших компаниях, — недавно смотрел такое интервью с инженером Google. В IT попал через Физтех: думал стать учёным, понял, что в науке платят мало, и лет в двадцать начал совмещать работу с учёбой.

Ведущий вставляет незапланированный рассказ про фреймворки приоритизации: ICE, RICE и матрицу ценности и усилий. В ICE три шкалы — impact, confidence и ease, причём буквы, замечает он, переставлены ради читаемости. У себя на работе он так ведёт приоритизацию задач: impact по шкале от 1 до 10, где единица — некрасивый код, с которым можно жить, а десятка — критичная проблема; confidence — насколько вы уверены в оценке; ease — насколько быстро задачу решить, «как стори-поинты». RICE добавляет reach, охват: новый аргумент в ручке может касаться пяти процентов пользователей, а матрица ценности и усилий показывает, что делать сейчас, но не отвечает, чего делать не стоит. Участники пробуют оценить добавление аргумента в ручку, и один из участников возражает: кандидат, который лезет в оценку вместо вопроса «а зачем это вообще нужно», — плохой звоночек, и ровно про это третья глава.

Свою шпаргалку по второй главе Александр начинает со степеней двойки: из двоичной системы удобно переходить к очередной степени десятки, по три нуля, и подставлять греческую приставку — килобайты, мегабайты и дальше. Главное же в главе — таблица стоимости разных операций; табличка в книге старая, и он советует поискать более свежую версию, выложенную полтора-два года назад, где появились новые строки. Важны не сами числа, а порядки: обращение к кэшу первого уровня — примерно наносекунда, а round trip между континентами — уже пятьдесят миллисекунд. Совет простой: посмотреть на таблицу внимательно, подумать, что делает ваш код, прикинуть, сколько таких операций система должна выполнять в секунду, и сравнить с тем, сколько она выполняет на самом деле. Любимая история Александра — про счётчики, которым не нужна персистентность: он предлагает сложить их в Redis, а в ответ слышит, что миллионы ключей не влезут в память.

Он спрашивает зал, сколько займёт миллиард ключей, и для масштаба напоминает, что население Земли — семь миллиардов, так что миллиард пользователей бывает не у каждого. В чате отвечают, что влезет в оперативную память, — сразу видно опытного человека, комментирует Александр: при коротких ключах и значениях выходят условные двадцать-тридцать гигабайт, не всякий ноутбук, но серверная память держит с запасом, и вместо проектирования шардирования хватает одного дешёвого сервера. Привычку считать он ведёт примерно с 2014 года, с мастер-класса одной социальной сети про устройство их памяти, но предупреждает: считать надо только те параметры, которые нужны для прикидки решения, — нагрузку и объём хранения. Ольга спрашивает, как научиться считать в уме: опыт оценок есть, но обычно это листок и калькулятор. Совет от участников — считать на практике и просить опытного коллегу перепроверить, потому что в цифрах получается одно, а потом вылезают сюрпризы.

Александр вспоминает сайт, которому было уже лет десять: подрядчик перевёл его на новые рельсы, поначалу всё нормально помещалось в память, а через три-четыре месяца после сдачи система начала подвисать — выбранный подрядчиком подход не подошёл, и кэширование переделывали, забирая элементы пачками через multi-get, чтобы уменьшить число запросов. Ведущий добавляет свою историю: таблица на три миллиона записей в сутки казалась пустяком, за полгода разрослась до терабайта на кластере, система стала задыхаться, спасла очередь постепенной очистки. Отсюда главный критерий: искать точки, где одной машины перестаёт хватать. Больше десяти тысяч пишущих операций в секунду — звоночек, что обычный PostgreSQL может не выдержать; сотни тысяч запросов в секунду в отдельные ручки или несколько терабайт данных — тоже. И трафик надо считать в секундах: месячные цифры интересны разве что аналитике, а кандидат, который делит дневной трафик на число секунд, забывает про пики — ночь, день и момент, когда все ломятся разом на старте матча.

Что ждать от кандидата по пиковой нагрузке, зависит от его уровня: сильный сам спросит про профиль нагрузки и максимум, предложит эластичную инфраструктуру или отложить часть нагрузки, — но на интервью обычно договариваются о варианте попроще, отметив сложность «со звёздочкой», чтобы не закопать человека сразу. Хорошие вопросы собирают по кругу: Павел рассказывает про кандидата, который выбирал хранилище по тому, что умеет команда: сам по себе ответ, оговаривается он, не идеален — нельзя всегда выбирать по тому, что знает команда, — но эксплуатировать знакомый инструмент часто важнее теоретической пригодности; Александр вспоминает того, кто начал с ограничений: бюджет, команда, доступные кубики. Обратный сигнал — продавец одного решения в духе «без Kafka ничего не построить, я только что прошёл курс». В финале Александр разбирает четыре шага из книги: понять задачу и не стесняться вопросов, показать high-level design и сверить его с интервьюером, углубиться в важные компоненты и завершить разговором про эксплуатацию и масштабирование. Пять вариантов решения он не любит: это попытка переложить ответственность, лучше выбрать один и объяснить почему. Его любимый дополнительный вопрос — выключилось электричество, как поднимать систему. Заканчивают традиционным фото с книгой.