Данила Мигалин (@miga) живет в Вильнюсе и работает инженером в Uber.
Давным-давно контора, которая занималась русификацией игр, не взяла его работать переводчиком. На следующий день он устроился админом, потому что в школе увлекался программированием. «Русское IT — это большая деревня, одни и те же люди переходят из компании в компанию. До Uber я успел поработать в Яндексе и Майкрософте», — говорит Данила.
С 2006 года он занимался ip-телефонией и админской работой. В свободное время писал на Перле, затем на Питоне, делал свои пет-проекты. Некоторые из них даже пошли в продакшн и в Яндексе, и в Майкрософте. Писать по-серьезному в продакшн он начал, только когда пришел в Uber. «Место, которое мне предложили в компании, предполагало знание Golang. Меня не смутило то, что я иду админом на позицию разработчика. Я думал: отлично, наконец-то можно будет завязать с админским делом и спокойно писать код».
Мы поговорили с Данилой, и он рассказал, почему в Uber нет разделения на девов и опсов, трудно ли осваивать разработку, если всю жизнь был админом — и почему Golang стал стандартом в сфере Devops.
Трудно ли админу стать разрабом, а разрабу — админом
— Вот ты оказался в мире, где девопсы программируют не меньше разработчиков.
— Сейчас мы все называемся Software Engineer и пишем код каждый день. В Майкрософте мы назывались Service Engineer (уже не Operations, но еще не Software Engineer) и занимались девопской работой. Писали разработчикам разные автоматизации для деплоя.
Сейчас в моем окружении девопсов уже практически не осталось. В Uber у нас нет ни Ops’ов, ни Dev’ов. Все инженеры пишут, деплоят и онколят свой продукт от и до. Команды ответственны за полный жизненный цикл продукта. Больше нет злых дяденек админов или более добрых дяденек девопсов, которые что-то за тебя сделают, задеплоят, замониторят. И мне это нравится.
Такая система хороша тем, что нет размывания ответственности. Есть продукт, его пишет команда. Эта же команда ответственна, чтобы он работал. Если что-то сломалось, ты знаешь, что виноват либо твой коллега, либо ты сам. Сломался продукт, которым ты пользуешься? Ты можешь пойти к ребятам и все прояснить. Они знают, как он написан, они могут его починить. Раньше придешь к админу, который онколит, со своей проблемой — он пожмет плечами, скажет про ошибку в логах, переадресует к ребятам, которые будут только утром.
Для продукта хорошо, когда люди знают, что это они будут ночью вставать, если что-то полетит. Команда начинает серьезнее подходить к разработке: все срезанные углы рано или поздно окажутся у тебя в штанах.
— Я открыл вакансии на бэкенд и понял, что теперь бэкенд — это не просто кодирование и БД. Это кодирование, БД и девопс. Как можно запихнуть столько знаний в одну голову?
— Компьютеры и сервисы становятся сложнее. Требования к разработчикам естественным образом повышаются. Я считаю это нормальным. Когда Яндекс переходил от классической модели «админ и разработчик» к девопсу, и программистов начинали ставить в онкол, многие люди ушли. Им это очень не понравилось! Они нанимались писать код, а все остальное гори синим пламенем.
В Яндексе не было дежурств, у нас было понятие «ответственный за сервис». Этот человек должен был быть доступным 24/7/365. В те времена я реально ходил везде с ноутбуком и повербанком. В любой глуши я был во всеоружии.
Круто, что в Uber дежурства, что называется, follow the sun. Когда у нас ночь — дежурят пацаны по другую сторону океана. Нам остается день. До этого мы дежурили круглосуточно. У нас были проекты, которые мы делали в Вильнюсе, и были проекты из Сан-Франциско. Мы за свои проекты онколили 24/7 и ребята из Сан-Франциско онколили за свои проекты 24/7. Потом провели ряд вебинаров, рассказали что к чему друг другу и начали онколить днем за свое и за американское, а они «своим» днем — за свое и за Вильнюсское.
— Многие хотят работать девопсами, но не все готовы к ночным дежурствам.
— Если дежурство пару раз в неделю для тебя не проблема, то это твое конкурентное преимущество. Не готов? Окей, на рынке много компаний, которые обеспечат тебя другой работой. Но по мне лучше, когда ты несешь ответственность. Это сложнее, ты должен больше знать, но эти знания все еще вмещаются в одну голову. Не такой уж это адский рокет сайнс.
К тому же взрослые продукты не ломаются просто так. С налаженным процессами становится в ротацию онколеров спокойнее. Ты знаешь — все алерты изучены. Вот когда ты пришел в стартап с молодой неотлаженной системой, которая падает каждый час, и все горит, и ты в огне… Мама дорогая, это же я столько денег потрачу на докторов? Пойду поищу что-нибудь попроще.
Либо ты приходишь в дикий стартап огнеборцем, либо в классненький нарядный энтерпрайз, и там гоняешь смузи.
— Программистам кажется, что девопс — это темный лес и совсем другой набор скилл-сета. Захочешь изучить — многое придется начинать с нуля.
— Чтобы нормально функционировать на фулл-стековском уровне, чтобы не зависеть от админа, нужно не так много знаний. На практике это постигается за полгода без особых усилий. Админить — не великая наука. Но это лишь верхушка айсберга. Есть еще очень большая часть непосредственно системных знаний, базовое понимание того, как работают компьютеры. Тайные админские штучки, которым не учат в университетах.
Я всем рекомендую прочитать тоненькую книжку Таненбаума «Современные операционные системы». Книга старая, но до сих пор актуальная. Написана интересно, художественным языком. Прочитал ее, и вот ты уже неплохо знаешь компьютер.
Самое главное, надо приучать себя к ответственности. Твоя программа — это не код, который ты написал и забыл, это код, который где-то бежит надежно и красиво. Понимание этого упростило бы очень многое в индустрии.
— Разрабы — это люди без какой-либо ответственности. В коде баги — виноваты тестировщики, если упал прод — виноват девопс. Все виноваты, а ты нежишься в кровати.
— Так было всегда.
— Тренд на перемены есть, разработчиков начинают потихоньку приучать.
Сейчас вакансию бэкендера без докера уже не найти. Ладно, а в обратную сторону это работает? Ты же не занимался продуктовой разработкой в конвейерном смысле. Сложно было?
— Я не испытывал особых трудностей. Не скажу ничего насчет знания алгоритмов структур данных и прочего computer science, но уметь выразить свои мысли на языке программирования и уметь найти алгоритм — это знание необходимо. И у меня оно было.
Я собеседовал людей, хороших мощных админов из известных компаний. И частенько у них не было навыка решения каких-то проблем с помощью программирования.
Запомнился один собес с админом большой российской технологической компании. Я задал ему простую задачку, скорее всего, сделать рейт-лимитер, и заметил, что у парня ступор. Он просто не знал, с какой стороны подойти. А по системным знаниям отвечал хорошо. Кое-как задачу допинали. Я потом его защищал, предлагал взять его хотя бы мидлом. За 10 лет практики человек каким-то мистическим образом умудрился избежать программирования. Это тренируется легко, с учетом того, что у тебя будут задачи, рядом будут люди, которые смогут тебя менторить. Не такая это великая наука по сравнению с тем огромным пластом знаний, который он получил за время своего админства.
— Вот смотри сразу такой кейс. Тебя зовут делать интересный проект. Все нужно строить на Java, еще и управлять джавистами! Взялся бы, поверил бы в себя, смог бы выучить язык?
— Мне кажется, нет особой проблемы в том, чтобы изучить +1 язык программирования. Я бы не испугался Java.
Почему Golang стал стандартом в сфере Devops
— Есть джуновская болезнь, когда учишь один язык и очень тяжело решаешься на что-то еще. Зрелый разраб работает с любым стеком.
— При переходе с Питона на Golang я не испытал страха. Golang в тысячу, в миллиард раз проще, чем Питон. Ты буквально можешь открыть http://tur.golang.org/, пройти его за день и на утро писать в продакшн. Я не шучу, это действительно так.
Но есть одно «но». Golang очень простой и поэтому не выразительный. Лично меня это раздражает.
— Знаю ребят, которые с Java переходят на Scala, потом на Хаскель, потом на Идрис, и все равно им не хватает выразительности.
— Да, я постоянно страдаю. Пишу код и думаю, блин, занимаюсь ерундой! Будь это Erlang, я бы воспользовался паттерн-матчингом, все было бы изящненько, красивенько. С Golang никакого эстетического удовольствия. Он не про изящность. Это в Питоне ты можешь написать какой-нибудь comprehension и, откинувшись на спинку кресла, любоваться им 5 минут: как ловко получилось. Мало возможностей проявить хоть какую-то творческую жилку. Уверен, что топорность Go была одной из целей создания языка, чтобы гугловские ребята, вся эта армия программистов, не занималась творчеством, а просто писала понятный и надежный код.
— Вы и разработку, и автоматизацию девопс тоже на Golang делаете?
— Да, конкретно в нашей архитектуре нет такого разделения. Это все сервис. Просто один обслуживает юзерский трафик, другой оркеструет контейнеры.
Моя команда занимается автоматизацией баз данных. Мы предоставляем базы данных как сервис внутри Uber. У нас для этого есть свой оркестратор. Как кубернетес, только убернетес! Мы пишем этот оркестратор каждый день. Пишем его на Golang.
В Go есть одна сложность, в которую ты можешь вляпаться реально — это работа с памятью. По этому поводу на страничке документации есть отдельная статья, и там один коротенький абзац, как делать, чтобы все было правильно.
И дальше следует предложение, которое мне очень нравится: «Если вам необходимо читать эту документацию дальше, то вы слишком умный! Вы делаете что-то слишком умное». Так и написано по-английски.
— У меня часто есть проблема: мне надо принять решение, которое на самом деле я принимать не хочу, оно еще не стало проблемой, а мне уже надо действовать. Если решение берет на себя язык — это здорово.
— Ты хорошо заметил, Golang очень opinionated. Он сделан с такой жесткой визией. Ты называешь переменные, выравниваешь текст, организовываешь взаимодействие между потоками и все. Про остальное можно забыть. Это хорошо снижает когнитивную нагрузку.
— Мне кажется, что он поэтому у девопсов и зашел. Программисты любят решать такие проблемы: придумывать, как им форматировать код. А если человеку нужен скрипт, который автоматизирует простую вещь, он не хочет думать о том, как ему собирать, запаковывать, форматировать и так далее. Если тебя человек не из индустрии спросит о твоей профессии, что ты ответишь? Разработчик, девопс или админ?
— Думаю, человек не из индустрии понятия не имеет, кто такой девопс. Я скажу — программист. Я так и говорю. Это же всем понятно.
Присоединяйтесь к нашему сообществу в телеге — там очень крутые инженеры регулярно делятся своим опытом, разбирают различные проблемы и задачи из сферы Devops, а также рассказывают вещи, которые пригодятся и на собеседованиях, и в работе.
