Разрабы становятся админами, а админы — разрабами. Интервью с инженером Uber, где разделение исчезло совсем

    Данила Мигалин (@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, а также рассказывают вещи, которые пригодятся и на собеседованиях, и в работе.

    Ребреин
    REBRAIN: Онлайн-практикумы для Инженеров

    Комментарии 23

      0
      Сейчас невозможно админить не программируя, поэтому если уж не программисты, то как минимум мастера-скриптологи уж точно.
        0
        Опытный админ, который не пишет код — это просто продвинутый эникейщик :)
          +6
          Что за категоричность? Помимо компаний, так или иначе занимающихся разработкой ПО, есть и другие. Более того, просто использующих готовое гораздо больше! И там тоже нужны админы. Кто настроит сеть в офисе? Домен? Впн, фалообменник, телефонию, печать, видеонаблюдение, СКУД, мониторинг? Да миллион мест для приложения рук и головы.
          За более чем 10 лет мне не приходилось программировать. Батники, баш скрипты и powershell не в счет.
            +3
            А чем тебе bash/powershell не программирование? Снобизм?
              0
              Тем же что и батники.
              Я говорю исключительно про администрирование. Пишется обычно несколько строк для решения конкретной задачи. В большинстве случаев даже не пишется, а гуглится и правится под себя.
              Максимум что я делал — обход дерева директорий и удаление файлов по маске старше определенного времени. Строчек 15 вышло.
              Я программировал в институте и после сам пытался «войти в айти» с python и php — задачи решаемые программированием в админстве и рядом с этим не стояли.
              И вообще, тут коммутатор новый приехал с портами QSFP+ 40Гбит/сек — пойду погоняю на тестах, раньше ничего больше 10 не приходилось в руках держать.
              Зачем мне ваше программирование?..
                +3
                Я вот тоже работаю не в компании разрабатывающей ПО. И занимаюсь исключительно системным администрированием, без работы с телефонией, печатью, видеонаблюдением и СКУДом. Конечно, я для всего этого выделяю инфраструктурные ресурсы, но непосредственно этим занимаются отдельные, заточенное под оное люди.

                В моём случае много скриптинга на повершелке, потому что:
                1. Собрать нужный отчет с систем виртуализации vmware и hyper-v. много систем банально без vcenter'ов и vmm
                2. Актуализировать учетные записи в AD на основе данных из учетных кадровых систем. Плюс отчеты по учеткам, группам. Не руками же мне править и данные выписывать.
                3. Развернуть виртуальные машины в нужной конфигурации с нужным ПО. собрать с них отчеты о состоянии, ПО, конфигах. разлить специфичную настройку здесь и сейчас.
                4. Собрать информацию по почтовым ящиками в Exchange. Почистить их, отключить, выгрузить.
                И многие другие вещи по мелочи и нет.

                Я скриптовал, даже когда у меня десяток серверов был, видимо по этому я не сильно напрягался когда их стало почти в 50 раз больше.
                  +1
                  Ну я тоже не занимаюсь. В последние годы сосредоточился в основном на виртуализации, докере и прочих линуксах.
                  Но ранее бывало.

                  И в догонку пара вопросов:
                  Как много классов в ваших программах на Powershell? В какой IDE разрабатываете, какую CVS используете? Используете MVC? Регулярно проходите code review?
                    0
                    По классам — свои почти никогда.
                    ISE, VSCode.
                    GIT, GITHub
                    Нет
                    Выстроенного процесса нет, но стараюсь смотреть код моих бойцов прежде чем он начнет работать там где это может нанести вред.

                    Я ж и говорю, не программисты, а мастера-скриптологи. :)
                      +1
                      Ну то есть в целом вы согласны что программирование в системном администрировании несколько отличается от того чем занимаются программисты на полный рабочий день?
                        0
                        Я могу на питоне написать программу, которая будет брать кадровую информацию с разных кадровых систем, класть её в свою БД, потом из БД пушить изменения в AD по набору правил или по запросу из вебинтерфейса. Эдакий IAM.

                        Однако сейчас я делаю тоже самое на повершелке без классов и красивых интерфейсов раз в сутки с автоматическим созданием заявок в сервисдеске, если набору правил что то не нравится.

                        Почему в первом случае я программист, а во втором нет?
                          +2
                          Да программист вы, программист.
                          А вот я таким себя не считаю.
                      0
                      Как много классов в ваших программах на Powershell? В какой IDE разрабатываете, какую CVS используете? Используете MVC? Регулярно проходите code review?

                      MVC в администрировании, ага
                        0
                        А вы дискуссию читали? Я как раз и утверждал что программирование в администрировании сильно отличается.
                          0
                          Я как раз читал, просто вы взяли набор вещей и паттернов из интернетов и начали спрашивать их у админа который говорит, что занимается программированием.
                          Программирование разное бывает, я вполне верю что он что-то программирует, но при чем тут MVC?
                            +1

                            Скриптигн, программинг, тестинг и конфигуринг — разные вещи, со своей спецификой. Как спринт, марафон, физ-ра и споритвное ориентирование. Во всех категориях случается бегать ногами, но подходы отличаются. Причем они крайне хреново совмещаются друг с другом.

            +2

            Сначала у них БД прыгали (mysql -> postgresql -> mysql), теперь вот разработчики с админами. Интересно кто будут следующими? Аналитики с тестировщиками? :)

              +2
              тестировщиков кстати тоже нет, совсем забыл про это упомянуть :)
              +10

              Желание запихнуть внутрь команды разработчиков ещё и саппорт 24/7 понятно. Подходящую риторику и мифологию вместо ITIL для этого тоже придумать не сложно. Не понятно как они на такое ведутся? Вроде ж айтишники умные люди.

              • НЛО прилетело и опубликовало эту надпись здесь
                  0

                  Тоже этот момент очень удивил. Мы добавили бесплатную нагрузку, и почему то люди начали уходить.

                  +5

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

                    +2

                    Обратите внимание, я говорил что есть большой пласт системных знаний, которых невозможно набрать за полгода. Естественно, что всегда будут сложные инфраструктурные задачи, которые будут решаться своими командами. А что до обычного сервиса, так тут ведь каждый может почитать логи, посмотреть графики и понять, что не так — особенно его автор, не так ли? Об этом и речь — об ответственности, это ключевой момент. И, судя по комментариям, люди очень сильно не хотят ее брать на себя :)

                      +1

                      Про ответственность все понятно, и без скрещивания разработчика с админом, у разработчика есть своя сфера ответственности, те кто этого не понимают всю жизнь сидят на попе ровно (день прошел и черт с ним).
                      И ваш посыл я тоже понимаю — отвечать в целом за продукт, а не кивать друг на друга (это твой код кривой, нет это твой кривой контейнер виноват). Вопрос в пределе скрещивания и решать стоит для конкретного проекта. У вас — так, у нас — по-другому. Кто вам нужен на поддержке дев-недоадмин, админ-недодев, недодев-недоадмин и тп комбинации. Сколько он будет стоить и сколько будет стоить решение или нерешение им проблем. Это тоже ответственность руководителя, принявшего решение как и кем закрывать вопрос с поддержкой.
                      Я ваше мнение в статье прочитал, услышал, узнал, что бывает вот так, как вы рассказали. Для себя лишний раз уяснил, что нет универсального решения. Опасения свои привел комментом ранее, потому как сталкивался с печальным опытом — оголтелыми любителями наводнить компанию только универсалами.
                      Хорошо, что у вас ваше решение работает. Успехов.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое