Что такое oncall
|По мотивам наболевшего, так сказать. Вопрос на засыпку – после прочтения статьи догадайтесь, чем я занималась сегодня вечером ;).
Google заправляет очень важными сервисами, каждая секунда простоя которых стоит огромных денег. Вот тут пишут, что 44$ в секунду, но что-то мне кажется, что на такое всех инженеров мороженым не прокормить. Google зарабатывает в несколько раз больше за квартал. Кстати, подозреваю что все ниженаписанное в полной мере справедливо и для других компаний с миллиардной аудиторией. Думаю, само представление, что Facebook или Twitter будет недоступен в течение долгого времени довольно немыслимо.
Естественно, что для гугла жизненно необходимо, чтобы сервисы были максимально стабильными. Для этого существует куча разных тестов – от юнит тестов, до canary tests. Еще есть performance tests, regression tests, migration tests, cross canary tests и какие только не :). В общем, шансов, что какой-то баг проползет в продакшн очень мало. Но иногда такое случается.
Для этого в Google (и не только) есть такое понятие как oncall:
Oncall is part of being a SWE at Google whether you work on production services, in SRE or “pure dev” roles. All SWE groups producing user-visible or production code have these oncall rotations but, many have timezone-shifted support so when you are oncall, it doesn’t include overnights (i.e. you will get sleep). SRE’s oncall rotations are generally more organized and consistent than most of SWE teams. (reddit)
Если кратко, то если вы работаете над системой с большим количством пользователей (ads, search и многие другие), то есть вероятность, что ваша команда участвует в поддержке продукта 24/7. Это значит, что кто-то из комманды постоянно на телефоне, например, в течение недели. После недели очередь переходит к следующему сокоманднику. И так по кругу.
Быть на телефоне значит, что если что-то случится с проектом – например, из-за какого-нибудь бага при стечение каких-то определенных обстоятельств сервера начнуть валиться , то тот, кто сидит на телефоне, получит телефонный звонок от робота, который скажет что-то вроде “Ну все, капец!” :). После этого бедный инженер бежит к компьютеру и начинает выяснять, что происходит и насколько все плохо. Если все совсем плохо, то инженер может позвонить своему техлиду, менеджеру, менеджеру менеджера и может даже VP (думаю, именно так и произошло, например, в этом случае). Или может порешать проблему сам, особенно если проблема не очень сложная и не очень много пользователей попало под раздачу.
Позвонить могут в любое время дня и ночи. В моей команде oncall есть, и бывало, что мы сидели ночью*. Правда, мы фанаты тестирования, поэтому баги доползают до финишной прямой крайне редко. Но иногда бывает, да. Еще будучи oncall нужно всегда быть в близкой доступности от своего компьютера, то есть особо далеко никуда не уедешь. Еще нужно постоянно мониторить ситуацию, и при первом намеке на проблемы удостовериться, что ничего серьезного не происходит, даже если пейджер не звонит.
* Почему “мы”? Иногда ситуация требует довольно радикальных решений, хотя бы чтобы перевести проблему из разряда “ничего не работает” в “работает для большинства” (временно отключить часть сервиса, например). И я, как инженер, не могу принимать таких решений самостоятельно. Если решение очень уж радикальное, то может понадобиться разрешение деректора или даже VP.
Впрочем, жить это особо не мешает. Лично я на телефоне раз в пару месяцев, и проблемы у нас случаются крайне редко (за 4 года моего oncall хватит пальцев на одной руке). Если заранее запланирован отпуск или просто поменялись обстоятельства, то всегда можно поменяться очередью с коллегой. Ну и oncall мотивирует держать себя в тонусе и знать всю систему – ведь поломка может случиться где угодно, и желательно, чтобы каждый как минимум был способен сказать, где именно случилась поломка, примерно почему, и кто из команды лучше всего знает эту часть.
Ну и напоследок – если вы получили оффер от гугла, то в вашей команде oncall может быть, а может и не быть, как повезет (ИМХО больше шансов, что не будет). И даже если oncall есть, то это не значит, что это ужас-ужас, бессонные ночи и вообще жуткий геммор. Если команда хорошо тестирует свой код, то все будет хорошо, проблемы будут редки. Если код пишет тяп-ляп, быстрее бы запустить, то тут может быть более проблемно (если что, я не знаю “тяп-ляп” команд в гугле, но это не значит, что они не могут существовать)**.
** Кстати, лично не знаю, но у меня сложилось ощущение, что в Facebook запуск новых фич быстро является более приоритетным, чем хорошо протестировать код перед тем, как его запускать в продакшн. Это может означать, что если вы идете в Facebook, и ваша команда бывает oncall (а она будет в той или иной форме, так как никто не пофиксит код инженера лучше самого инженера, никакой SRE), то ситуация может быть несколько более напряженной. Но я могу ошибаться, это чисто размышления вслух.