Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

Миссия Intercom заключается в том, чтобы сделать бизнес в интернете персонализированным. Но персонализировать продукт невозможно, когда он не работает как надо. Работоспособность критична для успеха нашего дела и не только потому что наши клиенты платят нам, но и потому что мы сами пользуемся своим продуктом. Если наш сервис не работает, мы буквально чувствуем боль наших клиентов.

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

Пребывание «всегда на связи» вне рабочего времени действует на вашу жизнь пагубно.

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

История состояния «всегда на связи» в Intercom

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

В любой момент людей «на связи» было слишком много.

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

Мы осознали, что оказались в ситуации, когда у нас есть механика работы технической поддержки, которой нельзя гордиться, и ряд критических проблем, которые мы хотели устранить, таких как:

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

Поиск правильного состояния «всегда на связи»

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

В итоге наша команда поддержки сократилась с 30 человек всего до 6 или 7.

Затем эта команда согласовала и определила, как должны выглядеть оповещения о проблемах и описания в runbook, и описала процесс переадресации оповещений в новую команду поддержки. Они определили все оповещения в коде с помощью модуля Terraform, и начали использовать экспертную оценку для каждого изменения. Мы ввели такой уровень компенсации за недельную смену, который вполне устраивал дежурных. Мы также создали эскалированную команду второго уровня, которая состояла только из менеджеров. Эта команда должна быть единственной точкой эскалации инженеров технической поддержки.

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

Что мы узнали

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

Количество вызовов в нерабочее время сократилось менее, чем до 10 в месяц.

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

Инженеры в нашем офисе в Сан-Франциско присоединись к команде полным составом и вышли за рамки обычной технической поддержки. Перед нами стоял вопрос об определенных накладных расходах, однако распространение членства в команде поддержки на несколько офисов сыграло нам на руку, ведь это оказалось хорошим способом построить отношения, укрепить их и узнать больше о стеке технологий, с которым мы все работаем.

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

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

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