Когда наша команда была маленькой, мы собрали единое вращение по вызову. Каждый разработчик находился в ротации и пошел по вызову по одной неделе за раз. Когда мы впервые начали ротацию, у нашей команды было 5 разработчиков. Через год после другого, и, несмотря на рост нашей команды, мы все еще застряли с единственной ротацией. В конце концов, команда была настолько большой, что люди ехали один раз каждые 3-4 месяца. Это может показаться мечтой, но на самом деле это было далеко не так.
Единственное вращение по вызову было несчастным практически для всех по разным причинам.
Большое вращение
Большое вращение означало, что сдвиги по вызову были настолько нечастыми, что разработчики не смогли получить опыт и повторения, которые им нужно было знать, как эффективно решать проблемы с вызовом. Кроме того, наша кодовая база значительно выросла, и сразу развивалось так много вещей, что, когда возникла проблема, была большая вероятность, что разработчик по вызову ничего не знал об этом или о коде, который это вызывал.
Это привело к тому, что паникованные разработчики часто обращались к команде инженерии надежности сайта (SRE) для помощи с проблемами. Постоянно приходится прыгать и помогать с проблемами по вызову, быстро начала истощать много времени и ресурсов команды SRE. По сути, команда начала вести себя так, как будто они были в 24/7. Постоянная бомбардировка вопросов и запросов была очень близка к сжиганию всей команды и забрала ценное время, которое им нужно было работать над своими собственными проектами.
Нет права собственности
Помимо сгоревшей и неэффективно используемой команды SRE, еще один разработчик, обеспокоенный по вызову, заключался в том, что разработчики чувствовали, что они не имеют права собственности на код, который они поддерживали. Один человек напишет код, а другой человек будет отлаживать его, если он сломается. Приложение было настолько большим, что никто не мог иметь чувство владения производственным кодом, так как было слишком много, и они должны были поддержать все это.
3 команды, одно приложение
Из -за размера нашей инженерной организации у нас теперь есть 3 отдельные команды разработчиков. У каждой команды есть 5-7 разработчиков плюс менеджер. Каждой команде также предоставляется собственный набор проектов. Тем не менее, наше основное приложение по -прежнему представляет собой одно монолитное приложение Rails. Все три команды работают одинаково по всей кодовой базе. В отличие от других приложений, которые имеют очень отдельные бэкэнд -компоненты, принадлежащие отдельным командам, нет четких или очевидных линий владения. Решение этой проблемы оказалось бы самой сложной задачей, когда дело дошло до исправления нашей системы по вызову.
3 вращения
Мы знали, что должны были разрушить ротацию, если хотим продолжать расти, но вопрос был в том, как? Несмотря на то, что все разработчики работают в одном приложении без четко определенных линий владения, мы разработали план, который разбил нашу единственную ротацию на 3, по одному для каждой из наших 3 команд разработчиков. Это привело к более коротким поворотам, что означало больше повторений для разработчиков. Как бы это ни звучало отсталый, то, что вызывает больше, является преимуществом, потому что разработчики стали намного более комфортно с этим и могут действительно понять стратегию, которая лучше всего подходит для них.
Разделенное владение приложением
3 Вращения позволили разработчикам получить больше повторений, но это все же оставило самую большую проблему из всех, и это было проблемой собственности. Никто не хочет поддерживать то, что они не чувствуют, что принадлежит. Для этого мы решили разделить владение приложением по вызову среди 3 команд DEV. Этого не произошло в одночасье, но с несколькими встречами и большим количеством командных дискуссий мы смогли разбить все в нашем заявлении между 3 командами.
- Например, мы разбили всех фоновых работников:
- Команда 1: индексация рабочих мест
- Команда 2: Ночь отчетность
- Команда 3: Коммуникация клиента
- Например, мы разбили все отдельные оповещения об услугах:
- Команда 1: предупреждения Redis, предупреждения о резервном копировании очереди
- Команда 2: Elasticsearch оповещения, API -трафик оповещения
- Команда 3: предупреждения MySQL, оповещения о загрузке пользователей
- Например, мы разбили компоненты приложения:
- Команда 1: Пользователи и оповещения моделей и контроллеров
- Команда 2: модели и контроллеры активов и уязвимости
- Команда 3: Модели и контроллеры по электронной почте отчетности и электронной почты
После того, как линии были нарисованы, мы позаботились о том, чтобы подчеркнуть каждую из команд разработчиков, что, несмотря на все возможное, чтобы сбалансировать код одинаково, нам, возможно, все равно придется перемещать вещи. Это показало разработчикам, что мы были полностью инвестированы в то, чтобы это новое вращение по вызову было справедливым и лучше для всех.
После того, как код был разделен, команде SRE потребовалось время, чтобы сесть с каждой командой разработчиков, чтобы тщательно просмотреть компоненты приложения, работников и оповещения, которые они теперь владели. Мы пережили все, от общих проблем до именно того, что делал каждый отдельный кусок кода и как он повлиял на остальную часть приложения. Эти сеансы придают разработчикам гораздо больше уверенности в своей способности справляться с ситуациями по вызову, потому что теперь у них есть четкая картина того, что у них есть и как справиться с этим. Несмотря на то, что они сами не создавали часть кода, у них есть понимание того, как именно он работает и что он делает.
В дополнение к тому, чтобы дать каждой команде образование по сравнению с разделом кода, мы также воспользовались преимуществами Кодоудеры Гитлаба файл. Файл CodeOhlers позволяет вам указать, кто или какие команды в вашей организации владеют файлом. Когда этот файл обновляется кем угодно в PR, владелец файла будет автоматически помещаться для просмотра.
Разумные запасы
Первоначально команда SRE была запасной для Dev. Если бы у Dev для вызова возникла вопросы или нужна помощь, они поговорили бы с членом команды SRE, который был на этой неделе. В настоящее время в нашей команде SRE есть только 3 участника, так что вы можете понять, почему мы сгорели, будучи постоянной запасной. С новой системой 3 Devs 3-й вызыв действуют как запасные друг для друга. Если кто-то из них будет ошеломлен или застрял по вопросу, им рекомендуется обратиться к одному из других разработчиков по вызову за помощью.
Больше фокуса
В дополнение к вышеуказанным изменениям, мы также удалили некоторые обязанности из разработчиков по вызову. До этих изменений вращения по вызову разработчики по вызову отвечали за определение того, нужна ли страница статуса или любые сообщения клиентов во время инцидента. С тех пор мы перенесли эту ответственность в команду поддержки. Команда поддержки является наиболее близкой к клиенту и, следовательно, наиболее подготовлена для передачи любых проблем. Когда происходит инцидент, который затрагивает клиентов, команда поддержки уведомляется и отвечает за определение того, требуется ли страница статуса или какое -либо общение с клиентами. Возвращение этой ответственности команде поддержки позволяет разработчикам сосредоточиться исключительно на диагностике и решении проблемы под рукой.
Улучшенное предупреждение
Первоначально команда SRE создала все инструменты оповещения и мониторинга. Однако, как только мы передали оповещения каждой из команд разработчиков, они взяли их и бежали. Поскольку каждая команда почувствовала обновленное чувство владения своими оповещениями, они начали улучшаться и опираться на них. Мало того, что они делали больше оповещений, но также улучшили точность существующих.
Чувство владения
Несмотря на то, что одна команда может отредактировать код, который поддерживает другая команда, все еще существует острое чувство владения командой поддержки. Поддерживающая команда действует почти как доменные эксперты в своем разделе кода. Использование файла CodeOwners гарантирует, что команда поддержки будет осведомлена и может подписать любые изменения, внесенные другими командами. Поскольку каждый кусок кода, который поддерживает команда, невелика, они могут на самом деле изучать и поддерживать все это, в отличие от того, где все было слишком много, чтобы кто -либо мог справиться.
Более быстрый ответ инцидента
С 3 разработчиками одновременно, и каждый из них сосредоточен на меньшей части приложения, они могут обнаружить проблемы намного быстрее. Каждая команда также хочет убедиться, что когда дела идут не так, они поймали быстро, поэтому многие предпочитают настроить свои оповещения, чтобы предупредить их о проблемах, даже быстрее, чем они были созданы.
Выяснение и выяснение основной причины проблем также намного быстрее. Команды тесно знакомы со своими оповещениями и кусками кода, которые они владеют, что позволяет им решать проблемы быстрее, чем раньше.
Никогда не одинок
Наличие 3 разработчиков одновременно означает, что никто из них никогда не чувствует себя одиноким. Если в одном разделе приложения все начинает разваливаться, разработчик, который владеет этой частью, знает, что есть еще два других, чтобы помочь, если им это нужно. Просто зная, что у вас есть кто-то еще, легко доступный, может творить чудеса, когда вы нахождение на вызове.
Улучшенная связь по перекрестной команде
Как я уже говорил, каждая из 3 команд Dev работает по всему приложению. Это означает, что бывают случаи, когда команда может работать над кодом, который в конечном итоге вызывает предупреждение для другой команды.
Например, допустим, что предупреждение Redis с высокой нагрузкой исчезает. Это не гарантия того, что команда, которая владеет этой оповещением, также владеет частью приложения, вызывающей проблему. Однако из -за того, что команда Redis предупреждает с предупреждением, они знают, как сортировать это быстро и эффективно. Затем триочатая команда может легко передать его команде, которая владеет проблемой проблемой. Это коммуникация в перекрестной команде помогла командам оставаться в курсе работы друг друга, но они никогда не чувствуют, что им приходится исправлять код другой команды.
В связи с вызовом-это то, чего боятся многие люди в этой отрасли, и так не должно быть. Если люди боятся по вызову, то с вашей системой что-то сломано. Конечно, все в какой -то момент получат страницу поздней ночи или выходного дня, это боль, но эта боль не должна быть нормой. Если по вызову заставляет людей все время вытащить волосы, вы должны выяснить проблему и исправить ее.
Оригинал: «https://dev.to/molly/making-on-call-not-suck-490»