О чём на самом деле надо спрашивать девопсов на собеседованиях
У девопсов на интервью обычно спрашивают всякое дерьмо: особо одарённые личности требуют знания алгоритмов. Алгоритмы девопсу нужны раз в году - когда он захочет в очередной раз "пописать код", полуавтоматизирующий очередной недоделанный внутренний процесс.
Помимо собственно умения делать пайплайны, чинить кубер и писать метрики, девопсам (особенно в советской России) чаще всего недостаёт двух умений:
Обычно две эти вещи идут бок о бок - если что-то недоделано, то это и неудобно, а если что-то сделано хорошо, то, как правило, это доделано до конца.
Я долго считал, что это идиотский российский менеджмент не уделяет внимания техдолгу и не закладывает время на сделать хорошо и качественно. Мол, девопсам накидывают тасков, выполнение которых нужно для того, чтобы разработка поехала, а на свой техдолг времени нет. На собеседовании в ДЗО одного очень модного и самого прогрессивного в России банка, у которого ещё бывший хозяин вёл себя как английский лендлорд по отношению к тупым крестьянам, мне так и сказали - "у нас business first, возражения о том, что работать неудобно и инструменты отсталые, не принимаются, инструментами вы будете заниматься в свободное время (никогда)".
Но со временем я пришёл к выводу, что в первую очередь виноваты сами девопсы. Глобальный корень зла здесь вот в чём:
Девопсы не думают об интерфейсе.
Парадокс в том, что при найме во многие корпорации присутствует секция System Design, на которой даётся задание спроектировать какой-нибудь бизнес-сервис. Примеры - навязший в зубах сокращатор ссылок, твиттер, а однажды меня спросили придумать генератор промокодов для покупок в интернет-магазине компании.
Естественно, никто не подпустит девопса к проектированию таких сервисов - если человек это умеет делать и делает хорошо, то он software engineer, а не ops. В некоторых случаях девопс действительно такой пробивной и шарящий, что вырастает из своей позиции в software архитектора - но такие случаи редки и чаще всего объясняются более ранним опытом девопса как разработчика ПО, а не эксплуататора инфраструктуры.
Другое дело инфраструктурные сервисы. Парадокс в том, что девопсу кажется, что нечего тут проектировать - посчитал сайзинг и вперёд деплоить (чаще всего сервис уже написан кем-то, например сервис опенсорсный или это коробочное решение за которое уплочены деньги). Никто при этом не думает о пользовательских сценариях. При этом, как ни странно, может быть реализована некая интуитивная автоматизация в виде API, CLI или UI - которой приходится пользоваться при том, что она реальные сценарии покрывает на 20%.
Почему так получается? Если бы пользовательские сценарии были так галимо реализованы в приложениях, которыми компания зарабатывает непосредственную прибыль, то пользователи просто съебались бы в ахуе к конкурентам. Ну или если это b2b, то заказчики проломили бы голову директору.
Но инфраструктура традиционно считается универсальным доменом. Если кто-то пилит кусок инфры, то его пользователи - это смежные команды опсов и команды разработчиков. Они никуда не денутся: сбежать из компании, где инфраструктура устроена через жопу, в России почему-то считается жутко неприличным.
Поэтому сначала вся автоматизация делается на отъебись, а потом - зачастую в свободное от основной работы время - перепиливается.
И все эти люди, которые по кругу занимаются бесконечным улучшением своей кли-утилиты, они ведь прекрасно знают про 4 золотых сигнала, что такое LA, какие там нюансы у работы куб шедулера и всё такое прочее. Очень хорошо, что у вас есть эти знания, но если вы работаете девопсом в крупняке, то вы обречены на построение сервиса - либо вы сами будете вместо этого сервиса. (Кстати, то, что немыслимо в программировании - не будет же программист сидеть и самостоятельно делать за пользователя работу! - вполне себе работает в девопсе: если нет автоматического фейловера, то девопс будет самостоятельно разгружать ноду БД и переключать нагрузку вручную в 2 часа ночи.)
Если вы на этом этапе подумали, что уметь проектировать - это типичное требование от работодателя в стиле "а ещё нам хотелось бы, чтобы кандидат на позицию девопса умел выполнять все фигуры фигурного катания", то я замечу следующее:
- предметная область, в которой произойдут автоматизации, девопсу уже знакома (ведь он бля девопс, а не грузчик). Сравните с 1С, где программист ОБЯЗАН знать бухгалтерию или складской учёт
- в этой области, как правило, отсутствует хайлоад - вам не придётся придумывать, как поставить кафку шоб обработать 10 триллионов сообщений в наносекунду
- чтобы это уметь, не надо иметь спец знаний - нужно общаться с людьми и владеть техникой мозгового штурма.
Поэтому простой, углубленный опрос кандидата на тему, что он делал и как принимал решения, может дать больше понимания о его ценности, чем ебанутые алгоритмические задачи или проектирование полнотекстового поиска.