Ищу интересную работу

Abstract: Ищу интересную работу в мире open source и linux.

Лирика: Из-за накопившихся разногласий по режиму работы я плавно покидаю Селектел. Там я ещё проработаю примерно три-четыре недели, может чуть больше (на самом деле — до момента, пока не найду подходящую работу). За это время мне хочется найти не просто очередную работу с гэпом по зарплате (ну и всё остальное, что обычно хотят от новой работы), но и место для дальнейшего профессионального роста, место, где мне будет интересно, место, где я смогу много и увлечённо работать над тем, что мне интересно, по возможности спихивая на помощников всё, что не требует раздумий и «и так понятно».

О предыдущем месте работы, то есть о Селектеле

Вероятнее всего, после Селектела найти что-то равное (или даже превосходящее) будет сложно. Не смотря на то, что внутри я весьма недоволен изменениями в рабочих регламентах, в остальном я могу сказать, что для сисадмина Селектел — одно из лучших мест для работы.

Почему? Основное — это коллектив. Редко где можно увидеть столько хорошо понимающих компьютеры, линукс и всё, вокруг них находящееся, людей. Место, где человек за соседним столом вполне может действительно хорошо знать то, с чем ты столкнулся в первый раз. И это место, где любой степени заумности проблемы (при посылке по SAS-интерфейсу команды WRITE SAME (16) c флагом DISCARD устройство не отвечает на запрос, что вызывает задержки с соседними target'ами) будут услышаны и поняты (хотя если сказать глупость — можно огрести должный объём ехидных замечаний, а за криво настроенный нагиос или пропущенную в нём проверку какого-либо сервиса — стать предметом насмешек на ближайшие 5-15 минут). Второй момент — это широчайшая свобода действий. Она не «сверху», она снизу. Подумал, что отсылка dmesg'а по сети в syslog через netconsole — это хорошо, сделал — остальные научатся и будут делать так же, за что будет респект и уважение от коллег.

Вот этот вот peer feeling — самое ценное, что я ощущал в Селектеле. Впрочем, я не про Селектел, а про себя любимого, который из Селектела уходит, и хочет, чтобы на новой работе было если лучше, то хотя бы так же.

Об судьбе облака

Тем, кто переживает за судьбу облака — я его оставляю в надёжных руках, более-менее обклеенное сопроводительной документацией (последние две недели я большую часть времени только и делаю, что пишу «прощальные статьи» о том, что надо доделать, как и в каком порядке и подчищаю мелочи). Так что никаких потрясений в стиле «ну вот, ушёл и всё обвалилось» не будет.

О резюме

Формат резюме обычно не позволяет глубоко раскрыть мотивацию и область знаний. Бесконечные перечисления (да-да, я знаю apache, nginx, nagios, cacti, bind, postfix, etc) утомляют и на самом деле не правда. Потому что я не могу сказать, что я знаю хоть сколько-то много технологий хорошо. Да, я более-менее знаю Xen, но я всё ещё теряюсь при виде описания некоторых патчей из xen-devel и не понимаю как они делают NUMA-aware планировщик. Чем больше я вожусь с Xen, XenServer, xapi, XCP, Linux'ом и т.д. — тем острее я понимаю, как далеко я от понятия «гуру». Так что сказать «да, да, я знаю линукс» будет наглой ложью. Не знаю, но учусь и очень хочу знать больше.

И даже если я напишу у себя в резюме «знаю Linux и Xen», то эти два пункта врят ли будут достаточно весомыми на фоне того, что хотят от резюме пролистывающие их читатели и охотники за головами.

Так что лучше я расскажу не про конкретные технологии, а про новые навыки, с которыми я познакомился в Селектеле.

Что я умею

Когда администраторы-новички в Селектеле первый раз в жизни находят ответ в исходных текстах и рассказывают об этом, их весело приветствуют «о, ты это сделал в первый раз».

Исходный текст

Да, это одно из важных умений для серьёзного администратора. В какой-то момент обнаруживается, что ПО ведёт себя не так, как ожидается. В документации сказано одно (но невнятно) — а ведёт себя по другому. В этой ситуации «посмотреть, что там происходит» — самый короткий (но не самый лёгкий) путь к решению задачи или проблемы. Чтение исходных текстов сдирает с почти любой степени магичности ПО всю ауру элитарности и крутости. Ну как можно быть крутым, когда вся работа по сути — записать пять байт в netlink, или посчитать хэш от заголовка flow и приделать к этому простейшее правило?

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

Читающий исходный текст должен для себя отмечать три вещи:

• Понятия. Терминология, в которой задача описывается внутри программы очень часто не имеет ни малейшего отношения к тому, как это называется снаружи. Поймать смысл понятий и связь их между друг другом — и вы поняли примерно половину программы. Поняли — в том смысле, что увидев код вы тут же поймёте о чём в нём примерно идёт речь.
• Фактическая работа. В большинстве программ всегда есть некоторая «мета-часть», которая обеспечивает диспатчеризацию сообщений, взаимодействие потоков, серверов с клиентами и т.д. Чаще всего этот код (если он не точка поиска) работает отлично, и нужно лишь примерно понять кто к кому зачем ходит. При этом помимо «мета-части» есть и фактическая, которая делает «реальную работу». Выглядит это примерно так: Прочитать флаг, и если он True, а лимит меньше rlimit, то передать дальше, иначе отбросить. Внезапно — а я думал, что если лимит «меньше, либо равен». Так вот, почему часть моих сообщений терялась....
• Отсылки к другому коду. Очень часто оказывается, что большая и сложная программа — всего лишь абстракция над другими программами и библиотеками. Основная задача понять как вызывают чужой код, и что именно вызывают, после чего чтение уходит дальше. Например, для меня в своё время было крайней неожиданностью узнать, что xapi (центральная часть XCP) вообще практически ничего не делает, только командует другими сервисами. И когда нужно понять «что не так», нужно сразу же идти и читать логи и код тех утилит, которым что-то не нравится.

Чем больше я работал в Селектеле, тем больше я использовал эту технику.

Знакомство с DevOps

DevOps — это кооперация системных администраторов и программистов. Когда код написан, работа программиста закончена. Когда программа установлена и работает, работа программиста закончена. Между двумя этими местами простирается гигантская бездна, которая не может быть проигнорирована. Точнее, может, но это будет вести к постоянным конфликтам и проблемам «зачем ты поменял путь к конфигу, оно теперь не обновляется» — «об изменениях было написано в commit'е» — «откуда я знаю что там в коммите, когда у меня бинарник выкатывается?» — и т.д.

Решение этой проблемы состоит из двух простых этапов: признать существование проблемы, решить её. Шутка.
На самом деле это очень сложный процесс взаимного обучения и учитывания интересов сторон. Он включает в себя отлаженные процедуры сборки, причём сам процесс сборки уже выходит за чисто программистские вопросы — потому что если программа линкуется не с той версией libc, то это приводит к неожиданным проблемам, хоть код и не содержит ошибок. Аналогично, правильная настройка конфигурации, миграция с конфигурации на конфигурацию, миграция базы данных и т.д. требует не просто механического применения изменений.

DepOps плавно ведёт к CI, Continuous Integration. Она, в свою очередь, тоже сплав системного администрирования и программирования. Потому что системный администратор не знает, как именно собирается очередная библиотека, а программист может не до конца понимать, как организовать среду для сборки. Потом идут приватные репозитории бинарного кода (чтобы обновлять софт можно было yum update или apt-get upgrade)… Дальше там, собственно, CI — выкатывание кода сразу в продакт, как только его отревьюили программисты. Но сразу в продакт страшно. И тут приходят на очередь такая вещь, как тестирование. Юнит-тесты хорошо, но мало и оно всё равно не покроет съехавших контролов в браузере. И тут им на смену приходит функциональное тестирование, то есть «делает ли оно своё дело, или нет».

Selenium

Одним из моих последних открытий стал selenium. И построенная на его базе система тестирования «всего», которая разворачивает код целиком (включая самые глубокие системные компоненты) и проверяет, что оно «работает как надо». Если находится баг, то надо не только его зарепортить/поправить, но и написать тест, который его ловит (что делается не всегда, увы).

Но чтобы что-то было написано, нужно чтобы программисты это написали.

И тут приходит ещё один важный навык — product owner. Человек, который знает, что должно получиться, и который объясняет это программистам. А заодно и пишет подробную документацию к реализуемой фиче.

Планирование

Последний год я пришёл к крайне удобному формату работы. Выглядит он примерно так: после того, как какая-то фича задумана, она обсуждается в самом грубом виде. Появляется некоторое решение. Это решение обдумывается, выписывается в виде «сопроводительной статьи для эпика» (scrum-терминология). Там выписываются обязательно — мотивировочная часть, описание существующих проблем, и самое простое «бытовое» описание предлагаемого решения. Дальше это решение детализируется — вплоть до полей в базе данных, строится roadmap, задачи из которого постепенно реализуются (иногда в «бэкграунд режиме», то есть по мере появления свободных ресурсов). На каждом этапе у программистов есть право не только обсудить, но и внести изменения. Важно — изменения вносятся в эпик, а не только в код. На выходе мы имеем не только код, но и документацию к нему. (Иного метода иметь актуальную документацию я не вижу).

О том, как я работаю

Я не трудоголик в оригинальном смысле слова. Я не люблю работу. Если я знаю, как что-то сделать, то первый раз это интересно, второй раз — проверка навыков, а на третий раз я ищу того, на кого можно спихнуть этот (уже известный и скучный) процесс. Чаще всего это роботы, но и людям тоже может доставаться.

Зато я люблю зарываться глубоко и серьёзно, а потом, выцепив какую-то крупную и важную деталь (например, найдя причину проблемы, о которой раньше было мнение «шайтан-арба», или обнаружив потрясающую возможность, о которой раньше никто не подозревал — например, что можно биндиться на ipv6-only и при этом слушать на ipv4) несколько дней с ней носиться и всячески собой гордиться. Обычно это выливается в подробное описание проблемы в корпоративную вики (или иную базу документации), ну и личные рассказы тоже.

Процесс глубокого закапывания мне нравится, и мне нравится, когда это даёт моему проекту неожиданные результаты, возможности, что-то, что «по документации не положено». Соответственно, мне крайне не нравится и всячески дискомфортен процесс «прыжков по верхам», когда технологию недовнедряют и бросают, или дёргают между несвязными технологиями (я владею навыком многозадачности — речь именно про ситуацию «да, забей на Х, сделали и забыли, давай пилить Y, а через неделю начнём Z». Более того, мне это очень не нравится в окружающей реальности. Если коллега по цеху (да и начальник тоже) делает фигню, то я буду нудеть над душой, пока либо не получу ответ «почему надо именно так» (причём ответ убедительный), либо я буду продолжать изматывать душу, приводя новые и новые аргументы зачем это нужно. Некоторых это страшно раздражает, да. Но если оно неправильно — то как можно его проигнорировать?

Как выглядит работа моей мечты?

Вероятнее всего, это должна быть команда специалистов, работающих над сложным проектом, в котором значительную роль играют сисадмины (как программист я так себе, да и обсуждать чистые CS-вопросы мне обычно скучно) — то есть что-то, связанное севис-провайдерами, хайлоадом, виртуализацией, etc. Мне бы хотелось, чтобы в команде были как толковые спецы «сисадминской» направленности, так и программисты — ибо без них не работа, а сплошное мучение.

Вероятнее всего, для меня важным будет иметь помощника (спихивать выполнение типовых задач или их автоматизацию). Мне хочется иметь оценку моей работы по результатам, а не по формальным метрикам (число часов, строк кода, etc).

На работе моей мечты, хотелось бы видеть в начальстве человека, который бы не отмахивался от технической части описания и объяснения.

Итог

Если кого-то заинтересовал бывший системный администратор, переросший «просто администрирование» и ушедший в проектирование систем, то я с интересом и благодарностью приму предложения. Наверное, лучше в приват.

Автор: amarao

Источник ^[1]