Быть человеком, ответственным за решение проблем, когда они приходят (он же по вызову), вероятно, является одним из самых неприятных аспектов работы, с отзывами, начиная от «это отстой» до «все в порядке», так что вы знаете, что это всегда сложная тема разговора.
Я говорил с несколькими людьми о вызове, и общая обратная связь состоит в том, что это не работает для них. Из отзывов, жалобы варьировались от, рота не правы, не заплачиваемые достаточно за объем вопросов, особенно в нескольких часах, люди не знают, как решать все проблемы, поэтому не хочу втягиваться.
Реальность такова, что вы не сможете решить эти проблемы, когда они не будут компромиссом. Вместо этого лучше принять это и оптимизировать, что будет стимулировать правильное поведение.
Поощрение правильного поведения
Бремя вопросов не должно быть на одном человеке или команде олицетворяемой. Поддержка продуктов, услуг и функций должна принадлежать командам, которые их строят.
Командам нужна как автономия, чтобы выпустить и эксплуатировать новые продукты и функции, так и ответственность за их поддержку. Мы не должны относиться к поддержке иначе, чем конфигурации приложений или инфраструктура. Это требование.
Разработчики должны нести ответственность за реагирование на проблемы, отключения и быть на вызове, а также для разработки и развития систем мониторинга и оповещения, а также показателей, стоящих за ними. Это означает, что разработчики контролируют весь жизненный цикл, включая операционные задачи, такие как резервное копирование, мониторинг и, конечно же, при вращении вызовов.
Таким образом, они становятся более осведомленными о подводных камнях запуска кода в производстве, поскольку они обрабатывают инциденты (пробуждение к оповещениям и т. Д.).
Этот подход означает, что они стимулированы, чтобы принять достаточные меры, чтобы избежать этого. Такие вещи, как мониторинг (метрики и оповещения), ведение журнала, обслуживание (обновление и ремонт) и масштабируемость становятся ключевыми соображениями каждой строки кода, который они пишут.
В случае инцидента, который затрагивает несколько команд, проблема вручную возглавляется управляющему инцидентами, обычно руководителем департамента или назначенным представителем, который будет оставаться вовлеченным до тех пор, пока не будет рассмотрен инцидент. Затем мы используем подход анализа основной причины для безупречной постоткости, чтобы диагностировать и решить проблему.
Я ценю, что этот подход не может быть популярен среди всех, и что люди могут быть скептически настроены, но это проверенный и проверенный вариант, который следует учитывать.
Что не работает
Посмотрим правде в глаза, никому не нравится быть на вызове. В отзывах никто не сказал в этом ничего хорошего, по шкале ОК, отстой, вы можете догадаться, где приземлились большинство людей.
Пытаясь управлять ROTA по вызову на уровне управления, мы настраивались на неудачу, поскольку это не расширяет возможности людей по вызову, это требует постоянного вмешательства и не будет масштабироваться. Звучит великолепно в теории, но может ли он работать на практике? Поощрение правильного поведения было бы теоретическим, если оно невозможно, позвольте мне объяснить …
Одним из вариантов поощрения правильного поведения было бы больше платить за поступку по вызову. Проблема в том, что это предпочитается только одним способом. То есть разработчику платят за проблемы. Это не обнадеживает.
Проблема, не рассматриваемая многими рота, заключается в том, что переключение в полночь не является практичной, хотя вместо этого предлагается восход солнца, он не решает реальную проблему.
Два вопроса, о которых большинство людей обеспокоены тем, что они чувствуют, что не знают достаточно, чтобы решить проблемы, или это не соответствует их образу жизни. Итак, как мы решаем эти проблемы?
Что происходит в другом месте
В Google они нанимают специализированных инженеров по надежности сайта. Как только продукты или услуги становятся стабильными, они передаются им для управления. Это очень практичный вариант, но он, вероятно, дороже и может привести к тому, что разработчики просто бросают работу над стеной на операции, а не несут ответственность. Это также может вызвать культуру типа «нас» и «их», которая не очень хороша для культуры.
В Spotify они попробовали это и обнаружили, что это привело к узкому месту в их команде OPS. Вместо этого они выбрали перераспределение владения. Теперь каждая команда отвечает за поддержку.
В правительственных цифровых службах Великобритании у них тоже была специальная команда технической поддержки, но обнаружила, что на практике это не сработало. Одной из проблем был обмен знаниями. Они очень усердно работали, чтобы попытаться решить эту проблему, но признают, что она все еще работает в процессе.
Netflix, вероятно, наиболее знаменит своим подходом «нока» к этой проблеме. Инженер, как правило, будет иметь Pagerduty 1 из N недель, где n — количество инженеров. Некоторые команды включают инженеров и менеджеров QA в ротации по вызову, а другие нет. Некоторые команды включают только ключевых инженеров в ротацию Pagerduty, в то время как другие будут включать всех инженеров в команде.
В Etsy все их инженеры тоже на вызове. Они создали инструмент с открытым исходным кодом под названием Opsweekly, который позволяет вам организовать свою команду в одно центральное место, но также помогает вам понять и улучшить ротации на вызове благодаря использованию простого обследования на вызове «Обзор» и отчетность в результате этого отслеживания.
Между тем в Facebook, два или три раза в год, инженеры Facebook должны полностью перестраивать свою жизнь в течение двух недель, пока они обслуживают то, что называется «Duty Oncall». По сути, в течение этого времени они несут ответственность за поддержание обслуживания. Обязанность в течение двух недель длится две недели, и он вращается между инженерными командами Facebook. Инженер Facebook по имени Кит Адамс говорит, что это «худшее в работе в Facebook».
В Amazon это менее ясно, они, кажется, вращаются по вызову в команды каждые несколько месяцев в течение недели, и этот подход не очень популярен из того, что я читал.
Как решить проблему
Мы хотим сократить бремя для человека в команде с наибольшим опытом инженера по надежности сайта и поощрять больше инженеров в ROTA.
Все платформы, которые я упомянул, кажутся одной общей чертой, то есть по вызову, является обязательной частью работы.
Вы заметите, что еще одна тема заключается в том, что на уровне команд назначается вызов на уровне команды, и команды берут на себя ответственность за выбор своего рота.
Я считаю, что каждый инженер несет ответственность за поддержку и мониторинг, в том числе по вызову, и что Rotas координируются на командном уровне. Мое предложение было бы повернуть их каждые две недели между командами в соответствии с типичной длиной спринта.
Если не практично привлекать всех на вызов, то вы действительно должны задаться вопросом, почему это не практично. Если вы не решаете основные проблемы, когда любое альтернативное решение является просто компромиссом и будет более дорогим и будет ущерб команде и культуре.
Если не практично привлечь всех к вызову, вам понадобится больше бюджета и ресурсов, чтобы справиться с одинаковыми повторяющимися проблемами.
Смотрите также
- Как Spotify и Gov.uk Ручка на вызове.
- Ответьте на http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html
- Я не хочу DevOps. Я хочу нонс.
Оригинал: «https://dev.to/jpswade/who-s-bug-is-it-anyway-aka-handling-the-on-call-rota-11m6»