Спроектируйте Твиттер: полифония наших голосов
YouTube | Подкаст | Слушать

Спроектируйте твиттер.

Любой человек, проходящий или проходивший интервью на системный дизайн, будет делать одно и то же: выяснит предполагаемый масштаб беды — это его рамки; выяснит, чего хотят получить в итоге — это цель. А дальше надо под заданный масштаб так сложить кубики с Kafka, MongoDB, Airflow, чтобы в конце получить ленту с либеральными эмигрантскими срачами. Практически всегда системный дизайн сводится к рисованию прямоугольничков и линий в Excalidraw или прочих сервисах с комментариями, мол, вот тут у нас пойдут 20 тысяч отчаянных криков, которые через 8 нод Кафки сведутся в мощную полифонию наших голосов.

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

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

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

Например, стало трудно и дорого крутить виртуалки в облаке, хочется, чтобы докер, чтобы лямбды — получаем Кубернетес. Хочется единообразно конфигурировать политики — получаем service mesh. Весь этот набор джентельмена имеет свою стоимость не только во внедрении, но и в разработке: а что, если кроме вас никто больше не хочет возится с Istio или писать на YAML? А если вам это все надоест, вы смените команду, компанию, или решите чего-то подправить через пару лет, и с раздражением понимаете, что как-то все недостаточно хорошо документировано, и теперь приходится на это тратить кучу времени, которого нет?

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

А где, кстати, Василий? А у него ребенок на прошлой неделе родился, он уже горой за проект не стоит. Горкой разве что, выгоревшей с прошлого пожара. И в сервисах Василия никто ничего не понимает. Продукт, закованный в сложнейшую технологичную противотанковую броню, влетел в реку из-за пьянства водителя. Забавно, конечно, получается, когда человек, спасающий проект от всевозможных боттлнеков, сам ставит проект в состояние заложника.

Только и остается, что смеяться над публичным ретро горизонтального веган-кафе Фрик. У нас-то и клоуны другие, и сценарий.