Павел Комков

Это второе интервью для нашего портала c инженером компании Гугл.

Это первое интервью, в котором есть такая важная штука, как дисклеймер:

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

 

Как тебя представить нашим читателям?

Так и представить, Комков Павел.

Я Site Reliability Engineer в компании Гугл, то есть отвечаю за надежность работы сайтов. По грэйду — сениор, по факту выполняю обязанности технического лида, и уже не на команде, а в направлении.

 

То есть ты командуешь фронтом работ, а не какими-то специфическими людьми. Ок. В Гугле ты работаешь с 2007 г., а до этого?

Где я только до этого не работал. В лаборатории судебной экспертизы, в ПРЦНИТ СГУ, с 2003 — в МТС.

 

В Гугл — тебя позвали и ты поехал? Или наоборот, ты решил, что пора ехать, и нашел Гугл сам?

Я года с 2003 шутил, что есть ограниченный набор компаний, куда я не думая поеду, если они позовут. В этом шорт-листе были Рэд Хэт и Гугл. И, разумеется, позвали меня не на ровном месте — потому что, ну… как рекрутер Гугла заметит человека, тихо работающего в Саратове?

Во-первых, я бешено контрибьютил в опенсорс — когда другие отдыхали, занимались спортом и какой-то личной жизнью, я сидел и патчил линукс, SQUID и все такое прочее. Также делал специфические вещи, потому что по специфике работы с МТС, например, пришлось работать с kannel и другими специализированными системами. Появилось понимание бытия во всем этом, потом в какой-то момент мне пришла в голову здравая (на самом деле бешеная) идея съездить на конференцию под названием Линукс Симпозиум, которая проходила в Оттаве, и в 2005 г. я собрался и поехал. Это был тот еще цирк, потому что за визой надо было ехать в канадское посольство в Москву, там на тебя смотрят подозрительно — что это за человек из какого-то Саратова на какую-то конференцию? Потом билеты, и все это за свой счет.

 

Вообще все?

Ну а кто, МТС меня, что ли, пошлет? В общем, я поехал и увидел многих людей, которых знал по спискам рассылки и IRC, познакомился с ними. Тогда линукс-симпозиум был очень большой, человек на 700. В частности, и с народом из Гугла познакомился, а в 2006 от их рекрутеров мне пришло приглашение попробоваться. Сейчас-то я лучше знаю, что они именно так и работают — через контрибьютеров в опенсорс, конференции, списки рассылки. И я прошел через все этапы отбора — письма, разговор с рекрутером с вопросами “сколько бит в байте?” — и до конца.

И вот 10 лет ты в Гугле. Доволен? Что там хорошего для глубокого айтишника (как бы смешно ни звучал этот вопрос)?

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

Возможности есть. Даже не меняя команду и должность, можно попробовать очень много всего, и поработать с разными продуктами. Я могу аргументированно говорить только с точки зрения SRE, но это на самом деле общее правило.

 

А оно как-то регулируется? Программа 20%, по которой можно один день в неделю тратить на любой подтвержденный проект?

Эта программа до сих пор есть, и она работает. Во многих командах, например, эти 20%-проекты тратятся как раз на то, что тебе нужно в основной деятельности.  Когда много времени тратишь на что-то, то начинаешь замечать, как можно это изменить, сделать лучше.

Бывает наоборот, эти 20% тратятся на какую-то смежную область, но ты все делаешь там тем способом, которым хорошо владеешь, и это актуально.

 

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

На самом деле в Гугле в 100% случаев никто не настаивает на способе выполнения задачи — всегда требуют только результат.

 

Ну а бывают случаи, когда ты решил задачу неприемлемым способом, что было неочевидно тебе лично?

Ну, (смеется) надо стараться, чтобы таких случаев не было. То есть, например, у тебя локально все работало, а в “большом продакшне” не получилось. Так бывает, когда у команды не хватает экспертизы, или она распределена — к примеру, в одной команде экспертиза продуктовая и умение писать алгоритмы, а другая команда хорошо разбирается в обеспечении надежности и решении проблем. Именно для таких случаев придуманы специальные механизмы: как только ты придумал свою гениальную идею, ты можешь пообщаться с людьми из соседней команды, чтобы они высказали все, что по этому поводу думают.

 

А ситуаций, когда экспертиза распределена между восемью разными командами, и все они очень заняты, у вас не бывает?

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

 

То есть степень зрелости такая, что все это очевидно. Что еще хорошего?

Довольно давно в Гугле идет систематическая работа с целью сделать рабочее место человека более комфортным.

Есть общедоступные материалы на сайте https://rework.withgoogle.com/ — там лежат результаты исследования факторов успешности команды. И основополагающим фактором успешности является Psychological safety (психологическая безопасность). Факторов вообще выделено пять, есть еще Dependability (ответственность), Structure Clarity (ясная структура), Meaning (важность работы лично для тебя), Impact (важность работы для всей компании). Безопасность — главная.

Если тебя в команде чморят, и на вопросы начинают говорить “Ой, как же так, ты не знаешь ничего” — в такой команде трудно ждать эффективности. Если с этим разобраться, наступает пора ответственности. Когда Васе дают задачу, он говорит “да, конечно” и не выполняет — значит, ответственности нет. Разумеется, речь о ситуации, когда у Васи нет аврала.

 

Мне кажется, даже когда у Васи аврал, он должен сказать не “да, конечно”, а “да, когда-нибудь, не сейчас”.

Ну да.  В общем, есть статистика с весом всех этих факторов, можно почитать. И Гугл последовательно улучшает все, что воздействует на продуктивность людей. Наверное, любая работа должна быть такая, по крайней мере, если спросить любого айтишника.

Совершенно не проблема поработать из дома, или поменять профиль работы. Как я говорил на своем юконовском выступлении: если в команде есть техлид и начальник, то работа техлида — это двигать проект вперед, чтобы все работало, а работа начальника — это чтобы люди в команде были счастливы. Гугл это понимает, так что есть много причин, почему там работать хорошо.

 

Ну, учитывая, что ты 10 лет в одной области проработал — логично, что тебе это нравится.

В том и фокус, что систем за это время поменялось много. Я успел и на бэкэнде поработать, и на фронтэнде, с сетью взаимодействовать. Несколько раз пришлось рефакторить распределенные приложения, писать инфраструктурные библиотеки, которые копируют терабайты данных в секунду — но все это считается Site Reliability.

 

Вопрос дурацкий, но задать его надо. Куда Гугл движется, при том, что он находится на острие прогресса в технологическом и организационном смысле?

Хочется верить, что он двигается к светлому будущему. С моей точки зрения, изнутри, кажется, что Гугл двигается вперед. Была у всех на слуху больная тема с закрытием Google Reader — но проекты открывают и закрывают, тут ничего не поделаешь.

 

Наверное, в большей степени общество беспокоит судьба Гугла как Империи Добра в целом — концепция, что он все про всех знает и продает эти знания зловещим корпорациям за деньги.

Не готов обсуждать рептилоидов и военную тайну… хотя почему бы и нет: я знаю людей, которые не ставят себе Гуглмапс на телефон, чтобы про них не знали ничего. Непонятно, правда, что это меняет.

 

Гугл — круто, но давай поговорим про Саратов. Ты уехал 10 лет назад, но контакты поддерживаешь, и потому скажи — что изменилось за это время, и изменилось ли.

Все, кто работает не в центральном американском офисе Гугла в Маунтин Вью, часто ездят туда в командировки, и я в том числе. А в Саратове есть такое мероприятие, как летняя школа информатики, где я с 93 года участвовал, а с 95 был организатором и преподавателем. И в 2009 на корпоративной квартире Мирантиса и Гриддинамикса во Фримонте собрался состав один в один как в этой летней школе. Так что надо уточнить, про что мы говорим — про Саратов там или Саратов тут.

 

Есть еще третья часть, которая выросла уже после того, как ты уехал. И на все эти части хотелось бы каких-то комментариев.

С Саратовом было интересно — для провинциального города тут было много олимпиадников — общий ряд городов был “Москва, Питер, Саратов”, что выглядит странно. И когда команда СГУ выиграла чемпионат по программированию, многие подходили и спрашивали: «А где это — Саратов?». Начинать ответ приходилось с указания полушария Земли.

На олимпиадников пришли бодишопы, часть которых выросла в сервисные компании, и это по-прежнему выделяет город из ряда ему подобных. У многих студентов есть выбор, куда идти, не обязательно уезжать из города, чтобы получить достойную работу. В целом, это самоподдерживающаяся система, которая будет работать, если ее сознательно не начнут разрушать. Компаниям сейчас довольно легко стало цеплять и оставлять молодежь, пока она осматривается, пока не пропала мотивация тут жить. А то ведь я отойду от этого красивого офиса на полквартала, упаду в яму, и меня там никто не найдет. От этого мотивация жить тут пропадает.

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

 

Ок, ответ понятен. Это мне, тут живущему, даже мелкие изменения бросаются в глаза, а в сравнении с Дублином все, значит, грустно.

Дублин — это отдельный разговор на самом деле. Это одноэтажная деревня, где живет 500.000 человек, и во многих домах там до сих пор топят торфом. Как похолоднее становится — в воздухе над городом плотное облако дыма висит. Центрального отопления нет (но зато его и не отключат), с медициной и образованием все еще хуже, чем в России. Мы несколько лет пытались организовать олимпиаду по программированию для школьников, но проблема в том, что в церковно-приходских школах нет предмета “информатика”.

 

Ок, а с детьми-олимпиадниками тут ситуация как-то меняется? Ты же ее мониторишь постоянно.

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

 

То есть те задачи, которые решали вы, уже не решают.

На самом деле, мы решали простые задачи, потом они чуть усложнились, а сейчас тенденция в обратную сторону. Хоть это и упрощенный взгляд на вещи. У олимпиадников сейчас некоторые проблемы с мотивацией — такое впечатление, что часть участников туда просто палками загоняют. Впрочем, в некоторых вузах такая проблема была всегда, например, в СГТУ. Не знаю, что там у них происходит — они всегда записываются на чемпионат и не приходят. Даже если и приходят на основной тур, то решают со скрипом одну задачу и уходят. То ли там религия такая, то ли они решили, что это все детские игры и пользы от олимпиад никакой — непонятно. В то время, как практика показывает, что польза несомненна, и если посмотреть на чемпионов-олимпиадников, можно увидеть, что у них последующая карьера часто обширная и впечатляющая. Кто-то в Гугле, кто-то успел поработать в швейцарском IBM; и я могу уверенно сказать, что при прочих равных бытие олимпиадником никак карьере не вредит.

 

Есть обратное мнение, что олимпиадная практика портит инженеров.

Ну и кто его придерживается? Я знаю олимпиадников, и знаю их начальников, и ни один из них эту точку зрения не разделяет.

 

Давай копнем в это дело. Есть мнение, что на выходе из всей этой олимпиадной активности мы имеем неглупого и довольно самоуверенного человека, который с бешеной скоростью решает ненужные задачи, а когда надо остановиться и заняться реальным делом, то оказывается, что и навыка нужного нет, и самооценка страдает — и что с ним, таким красивым, делать?.. Это мнение на чем-то основано, или те, кто его придерживается, просто не умеют готовить олимпиадников?

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

 

То есть они настолько выше среднего уровня, что даже при  проседающих навыках “реальной” работы быстро нагоняют. Ок.

Что нужно “хорошему олимпиаднику”? И как им стать?

Вообще, надо много над собой работать и научиться решать задачи. Мы говорили с Мишей Мирзаяновым, который тренирует команду СГУ, и он привел аналогию: допустим, ты говоришь на родном языке, и тебе не надо думать, как выразить мысль — ты ее просто говоришь. К этому же уровню спонтанности надо стремиться, когда ты пишешь код. Олимпиадные задачи обладают определенной спецификой — во-первых, у них есть решение, во-вторых, они достаточно короткие. В-третьих, есть определенная классификация этих задач, и ее бы тоже неплохо знать — где-то надо применить известный алгоритим, чуть его модифицировав, где-то надо, чтобы тебя озарило, и ты красиво поделил задачу на две простые части, и т.д. То есть ты должен владеть базой эффективных алгоритмов, и уметь распознавать, где и как их применять.

Инженерные задачи, где это оказывается полезным, чаще лежат в области исследований или машинного обучения (что сейчас очень популярно), обработки языка или изображений.

 

То есть не так много, на самом деле, позиций, где все это оказывается полезным.

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

 

А вот эта активность с олимпиадами — она много времени у тебя занимает?

Наверное, можно сказать, что это дело всей жизни, потому что я беру отпуск, и провожу его не в жарких странах, а в Саратове, рискуя провалиться в яму.

В программирование я пришел в 1992 г., через олимпиады и кружок на станции Юных Техников, которым руководила Наталья Львовна Андреева. Все это было интересно, компьютеров не было, поэтому я пошел на работу к маме и попытался там что-то сообразить. Потом была олимпиада с каким-то смешным местом на ней, летняя школа, другие олимпиады, где я с Наркайтисом познакомился, и мы призовые места занимали. А уже в вузе нас позвали в Питер, где проходил первый в России полуфинал чемпионата ACM, и мы туда съездили и вернулись очень воодушевленные — новизна зашкаливала, компьютеры в начале 90-х были чем-то экзотическим, а тут мы посмотрели на автоматизированную систему проверки решений и учета результатов чемпионата. Я приехал и сделал свою, которой проверял потом школьные олимпиады.

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

 

Надо заметить, что в 90-х было неочевидно, что из этого что-то толковое получится.

Ну, не совсем. Меня с середины 90-х звали, к примеру, в Калифорнию. Так что было очевидно, что программирование — это перспективно. Плюс я довольно рано решил для себя, что я не буду просто решать задачи, а буду учиться писать системы — то есть получать опыт в системном администрировании и прочих смежных областях.

 

Почему? Как у тебя протекал этот процесс?

Неофициальная причина была в том, что я понял, что в олимпиадном программировании переиграть Макса Бабенко не смогу, он готовился по другой системе, которую я бы не потянул. Плюс у меня было время, которое можно было потратить на общественно полезную работу, и так подзаработать очки. Первым в узкой специализации я не стану, значит, доберу широким профилем. И задним числом можно сказать, что это и есть путь вперед. Я смотрел выступление парня из Нетфликс, он был в смешном рогатом шлеме (https://youtu.be/yIPbE7BssOs) и рассуждал о том, что такое сениор в разработке софта — это тот, кому скучно, или кому денег много платят? Сначала он поговорил про опыт — это то, что мы получаем, не получив то, что хотели.

И стоял вопрос, кто получил его больше и у кого он лучше — кто 10 лет занимался одним и тем же, или кто за 1 год делал 10 разных проектов. Если он не для галочки делал, а реально занимался — ответ очевиден, и человек с широким опытом нужнее и полезнее, поскольку проблему видит шире.

Джуниор, получается,  — тот, кому ставят задачу и говорят, как ее проверить, мидл — получает большую задачу и может разделить ее на задачи для джуниоров и собрать потом воедино. А уровень сениора — это когда человек просто смотрит на то, что происходит, и способен из этого сделать вывод, что нужно сделать, чтобы пользу максимальную нанести.

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

О сениорности, кстати, у нас с коллегами интересная дискуссия была. Вот есть проблема, можно взять ее  и решить. А можно сделать шаг назад, и увидеть класс проблем. Можно еще шаг, и в более общей картине увидеть, что именно их порождает. Вот сколько ты таких шагов сделаешь — настолько ты и сениор.

 

Просто отойдя достаточно далеко, можно задачу и не решить, или даже не решать, поняв, что это вовсе даже не проблема, а важный и нужный элемент системы.

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

 

На сколько шагов отступаешь ты?

Не готов назвать цифру, она не имеет смысла. Иногда просто отступаешь на несколько шагов в рамках своей команды, а иногда оказываешься на кухне у какой-нибудь логистики, со своими правилами и специфической базой знаний. Но мы делаем общее дело, и даже если мы все сделаем суперкруто, а они продолжат копипастить старые решения — ничего не улучшится. В итоге приходится решать сразу все. А еще есть очень нелюбимое мной понятие “In scope”, т.е.  “в зоне видимости”, или планирования. И ты приходишь с решением, говоришь, мол,  ребята, надо немного поправить, и всем станет хорошо, а тебе говорят: “извини, нот ин скоуп”. И это значит, что мне надо не решать проблему, а целиком скопировать их систему и как-то криво приспособить к решению моей задачи.

 

Просто если говорить про скоуп работ не в горизонтальном разделении — “вот план работ, тогда-то мы до него дойдем”, а в более широком — часто то, что было оптимальным решением, при этом более широком взгляде оказывается не просто неэффективным, а даже вредным. Появляется более общая проблема, и хорошо, если у тебя есть средства ее решения. А если нет — что делать?

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

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

 

Это не проблема разработки софта, это проблема построения любой сложной системы.

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

Есть смешные картинки “домов, построенных по аджайлу”, когда к двухэтажному дому сверху пристроены еще два и веранда, и сразу понятно, что это нелепо. С программным продуктом это не так наглядно, но по сути эффект такой же.

 

Бывает еще, что тот, кто пишет участок софта,  выполняет задание буквально, вместо того, чтобы пойти и обсудить с кем-то свои сомнения и идеи. Или кто-то начинает решать проблему, например, кривых данных, и на втором шаге мы понимаем, что они в систему приходят кривыми, и тут не надо ничего делать, а надо идти в другую систему и разбираться там — но они не идут, не разбираются, не фиксят, а делают какие-то костыли у себя.

 

Такая ситуация довольно типична для крупных энтерпрайзов.

Типично плохая. Я говорю о том, что не бояться общаться с соседними командами, а еще “делать хорошо поэтапно, мелкими шагами и снизу” — это зачастую единственный способ делать что-то хорошо.

Во-первых, когда ты меняешь что-то большое и развесистое, практически никогда невозможно получить полную картину, что где происходит. Во-вторых, некоторые варианты решений проверяются только в проде на реальных пользователях. И получается, что ты сделал три вещи, которые должны все улучшить, и две из них взлетели, а третья нет — и ее надо переделывать. Плюс бывает заранее видно, что на шаге 10, когда мы придем в эту точку, нам будет счастье. Но случится это не раньше, чем через 9 месяцев, а за это время нагрузка вырастет и свалит всю систему. Поэтому мы делаем какую-то штуку, которая нам позволит просто прожить эти 9 месяцев, зная, что после этого мы ее выкинем.

 

С менеджерской точки зрения, есть два подхода — или мы заранее все хорошо планируем, определяем шаги и делаем их одним куском, понимая, что можем в итоге прийти не туда. Или бьем все на маленькие шажки, на каждом из них оглядываемся, и мало того, что очень неоптимально все делаем, так это еще и не уберегает нас от того, что может оказаться, что мы вообще не туда пошли изначально? Как это все объединить?

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

Я всегда прошу не писать огромные детальные дизайны, потому что он разойдется с реальностью, и придется делать выбор — реализовывать дизайн или реализовывать реальность. И чем больше вы вложили в дизайн, тем больше будет соблазн делать именно его, тем меньше будут на практике пользоваться готовым решением.

 

Это аджайл.

Да. На каждом шаге мы должны помнить, к чему мы идем, уметь быстро корректировать это видение при получении новых данных.

 

А если есть суперспособность ловко угадывать, что на самом деле будет нужно — ну ок, ты король.

Эти суперспособности тоже можно развивать. Нужно как можно больше знаний собрать в самом начале. Посмотреть как устроены аналогичные системы, и на каком этапе они менялись и когда от них стало больше вреда, чем пользы. Посмотрел, повникал — глядишь, что-то и понял.