Страшная правда о секциях по system design для DevOps или SRE инжинеров

Что такое System design секция на собеседованиях? Это, как правило, задача спроектировать некую систему на коленке за час. Такая секция существовала ранее у архитекторов или старших (senior) разработчиков - т.е. у людей, которые как раз занимались тем, что проектировали такие системы или хотя бы настолько активно участвовали в их реализации, что могли менять изначально спроектированное.

Теперь эту секцию пихают на чисто Ops вакансии.

В чём тут проблема: ни девопсы, ни SRE, как правило, не участвуют в реальном проектировании систем. Для проектирования софта нужно хорошо уметь программировать и минимум три года принимать участие в разработке коммерческого ПО плюс поверхностно знать инфраструктуру. Разработчики умеют программировать и немножко умеют инфраструктурить, а оперейшонс инженеры умеют очень поверхностно программировать и хорошо знают инфраструктуру. Но ПО это не столько построение хорошей инфры, сколько автоматизация бизнес-процесса - а это модели данных, кодинг, хорошее знание особенностей ЯП и платформы. Поэтому software architect'ы это выходцы из разработчиков, а не опсов :)

SRE, которые вроде как должны уметь писать код, всё равно не подходят. Потому что в реальности, а не в книге sre workbook, код пишет примерно 1 человек из 50 с тайтлом "SRE".

Возникает следующий вопрос: тогда а на кой чёрт у девопсов спрашивают систем дизайн - ведь они не умеют и не делают это?

Мода

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

Отсутствие позиции архитектора

Хороший архитектор стоит бесконечное количество денег. Причина - для архитекторства необходимо много-много опыта и сделанные из него правильные выводы. Его знания трудно провалидировать и определить, а не наёбщик ли перед вами, который просто рисовал схемы и отправлял их на имплементацию, а потом клиент отваливался и судьбы решения остались невыясненными. Хороший архитектор способен нагенерировать работы на 10-15 команд. Так что это практически золотой человек. Шанс, что ваши специалисты по спаму в телеграме найдут и наймут именно такого, крайне мал. Поэтому проектированием стали заниматься старшие разработчики. Девопсов, как правило, призывают в такое проектирование как людей, которые подскажут конкретную nosql базу, конкретный cicd движок, конкретный провайдер секретов. О полноценном участии в архитектуре речи не идёт, но я заметил, что очень многие технические лиды верят во внезапное пробуждение архитектурных талантов у администраторов Kubernetes. Блажен кто верует.

Не дёргать разрабов на онколле

Если инженер хорошо разбирается в дизайне систем, то он сможет и самостоятельно решить многие проблемы. Не секрет, что оперейшонс на дежурствах часто говорят: "Блять тут какая-то проблема в коде, но я не могу разобраться, сейчас дёрну разраба в зум". Разработчики, в отличие от девопсов (бывших сисадминов), вовсе не имеют привычку просыпаться в два часа ночи и идти в зум - они больше любят уютно клацать код с чашкой кофия и делать это днём. Поэтому необходимость принимать участие в онколл-дежурствах подобным образом будет поводом, чтобы разраб не стал рассматривать такую вакансию вообще. Словом йоу, программисты пишите свой умный код и смело релизьте всякую парашу, SRE Вася если что придумает воркэраунд и починит сам.

Что с этим делать?

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

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

отсутствие вопросов про сайзинг (т.е. вас даже не просят высчитать трафик и сторадж, что делается элементарно - уже не говоря о тайере виртуальных машин в облаке сколько там будет ЦПУ и РАМ, лол)
отсутствие необходимости нарисовать API и дата-модель

но, по сравнению с систем-дизайн интервью для разработчиков, там будет тонна вопросов про инфраструктуру, например как организовать continious delivery, как организовать secret management и всё такое прочее.

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

Под конец, хочу подбросить несколько идей,

зачем это нужно лично вам:

Очевидное: компании с бОльшим кол-вом этапов собеседования часто более престижны, поэтому прохождение этого этапа повысит ваши шансы на трудоустройство
Знания, необходимые для проектирования систем, в целом очень сильно общи со знаниями, необходимыми для их починки. Т.е. надо знать тот самый computer science, который вы учили в вашем техническом университете. Очень часто люди, которые много и эффективно чинят системы, имеют илитарное, привелигированное положение в коллективе - то есть более быстрый промоушн по зп и отсутствие желания у коллег пререкаться с такими зубрами. Поэтому освежение / приобретение таких знаний только в плюс.
Хоть девопсам и SRE не доверяют проектирования твиттера и гугл поиска, но построение инфраструктурных систем - это тоже проектирование. Так называемый platform engineering представляет собой как раз редкий пример задачи по проектированию, которую разработчик не возьмётся делать - очень много ops-специфики, мало кодинга, всё придётся собирать из готовых компонентов. Как правило, инжиниринг тех.платформы делается через жопу - у людей порой даже нет элементарного понимания, что такое интерфейс и как люди будут пользоваться их замечательными творениями - поэтому если вы будете хотя бы чуть лучше понимать, как строят системы в целом, то вас будут ценить. Другой пример - DevSecOps, там от кандидата ждут как правило большого кругозора, знания одного-двух фреймворков безопасности, поэтому там просят разработать стратегию харденинга инфры, что очень даже проектирование. Кроме того, вы сможете оценивать не системы в целом, а некоторые точечные решения - например, если ваши коллеги захотят сделать скрипт по копированию image pull secrets по неймспейсам в кластере Kubernetes, то вы ударите молотком им по пальцам и найдёте готовое решение.
Субъективно - мне нравится, когда я понимаю, как скорее всего работает очередное супер нужное приложение для заказа еды из перекрёстка. Ну и в целом это соответствует моей концепции "лучше знать, чем не знать" (в противовес "меньше знаешь - меньше ответственности").

Summary

Собеседования на system design становятся де-факто стандартом на *Ops позиции выше миддла с высокой зарплатой. Ссать против ветра и ныть, что требуют знать больше чем раньше, нет смысла.
Сложность таких собеседований значительно ниже, чем если бы вы собеседовались на software architect позицию. Для прохождения достаточно вдумчивого чтения одной книги по подготовке к таким собесам.
Приобретённые в процессе компетенции повысят вашу ценность как специалиста. Вы скоро прочувствуете, как вам больше доверяют, ваше слово имеет больший вес чем у других коллег, и что вас просто так хвалят и дают нормальную ОС. Работать вам будет легче, так как вместо перезапуска подов и заливки железом вы будете решать проблемы системно и эффективно. Короче, только выиграли, да.