Переклад статті підготовлений спеціально для студентів курсу .
Місія Intercom полягає в тому, щоб зробити бізнес в інтернеті персональним. Але персоналізувати продукт неможливо, коли він не працює . Працездатність критична для успіху нашої справи і не лише тому, що наші клієнти платять нам, а й тому, що ми самі користуємося . Якщо наш сервіс не працює, ми буквально відчуваємо біль наших клієнтів.
Безперебійна робота залежить від багатьох факторів, таких як архітектура програмного забезпечення та якість щоденної роботи. Однак досить часто все зводиться до того, що людина, яка завжди на зв'язку, відповідає на виклики від . Така технічна підтримка може бути потужним клієнтоорієнтованим інструментом, який поєднує допомогу інженерів з тим, що клієнти отримують, купуючи продукт. Також тут відкривається чудова можливість для навчання та зростання, адже зрештою виходи з ладу та помилки можуть бути гарним полем для відпрацювання навичок та розуміння складних механізмів роботи.
Перебування "завжди на зв'язку" поза робочим часом діє на ваше життя згубно.
Але в той же час стан «завжди на зв'язку» може чинити на ваше життя згубний вплив. Ви повинні бути готові швидко та грамотно відреагувати на сповіщення про те, що щось зламалося. Навіть якщо вас не викликають по пейджеру в даний момент, стан «завжди на зв'язку» вселяє почуття занепокоєння, я і сам знаю це з особистого досвіду. Особливо через це погіршується якість сну. Регулярне перебування в зоні доступу в будь-який час може призвести до вигоряння, апатії або в цілому до бажання більше ніколи не бачити комп'ютер.
Історія стану "завжди на зв'язку" в Intercom
У перші дні роботи Intercom наш технічний директор Кьяран поодинці був цілою командою цілодобової технічної підтримки, як в офісі, так і поза ним. У міру того, як ріс Intercom було створено оперативну групу для допомоги Кьярану. Незабаром після цього нові команди розробників почали створювати безліч нових функцій та сервісів, і вже вони взяли на себе всі обов'язки щодо технічної підтримки.
Будь-якої миті людей «на зв'язку» було надто багато.
У той час такий підхід здавався найяскравішим, оскільки це був легкий спосіб масштабувати команду технічної підтримки у будь-який момент, він відповідав нашим цінностям і тішив наше . У підсумку, без будь-яких планів у нас вийшло чотири чи п'ять команд, які регулярно виходили на зв'язок із клієнтами у свій неробочий час. Інші команди розробників мали не так багато складних моментів, які могли видати помилку, тому їх викликали рідко, якщо взагалі коли-небудь викликали.
Ми усвідомили, що опинилися в ситуації, коли ми маємо механіку роботи технічної підтримки, якою не можна пишатися, і низку критичних проблем, які ми хотіли усунути, таких як:
- Будь-якої миті часу прийняти виклик були готові занадто багато людей. Наша інфраструктура була не настільки великою, щоб потрібно щонайменше п'ять інженерів-розробників, які працювали б без нормальних вихідних.
- Якість наших сигналів тривоги та процедур виклику була не узгоджена між командами, ми використовували спеціальні процеси огляду нових та наявних сповіщень про проблеми. Вказівки в runbook (яким потрібно слідувати при отриманні оповіщення про проблему) здебільшого впадали у вічі своєю відсутністю.
- Залежно від команди, в яку інженери працювали, у них складалися суперечливі очікування. Наприклад, лише найперша команда технічної підтримки мала якусь компенсацію за чергові зміни та зірвані вихідні.
- Виявилося, що існує загальний рівень толерантності до непотрібних викликів у неурочний час.
- Зрештою, такий тип роботи підходить не всім. Життєві обставини часом показували, що чергові зміни впливають на людей не найкращим чином.
Пошук правильного стану "завжди на зв'язку"
Ми вирішили створити нову віртуальну команду, яка виконуватиме роботу технічної підтримки кожної команди, коли вона матиме неробочий час. Команда складатиметься із добровольців, а не призовників із будь-якої команди організації. Інженери у віртуальній команді змінювалися кожні шість місяців, проводячи тижні «на зв'язку». На щастя, ми не мали проблем зі знаходженням достатньої кількості добровольців для збору віртуальної команди.
У результаті наша команда підтримки скоротилася з 30 осіб лише до 6 або 7.
Потім ця команда узгодила та визначила, як мають виглядати оповіщення про проблеми та описи в runbook, та описала процес переадресації сповіщень у нову команду підтримки. Вони визначили всі оповіщення в коді за допомогою модуля Terraform і почали використовувати експертну оцінку для кожної зміни. Ми запровадили такий рівень компенсації за тижневу зміну, який цілком влаштовував чергових. Ми також створили ескаловану команду другого рівня, яка складалася лише з менеджерів. Ця команда має бути єдиною точкою ескалації інженерів технічної підтримки.
У нас було кілька місяців напруженої роботи, протягом яких ми налагоджували цей процес, у результаті на зв'язку тепер залишалися не 30 інженерів як раніше, а всього 6 або 7. Протягом робочого часу команди самостійно розуміються на проблемах зі своїми функціями чи сервісами, цей час зазвичай припадає найбільша кількість поломок, проте в решту часу технічною підтримкою займаються добровольці.
Що ми довідалися
Після того як ми запустили нашу віртуальну команду технічної підтримки, ми чекали наплив нових завдань, таких як дослідження причин появи проблем або загальний збір для вирішення якоїсь однієї проблеми, що викликала збій. Тим не менш, наші команди розробників взяли на себе всю відповідальність за фактори, що викликають збої, і будь-якою подальшою реакцією, як правило, були негайні заходи. Також нам потрібно було уникнути ситуації, за якої завдання з технічної консультації поверталося б назад команді, від якої вона надійшла, щоб не змушувати інженерів виходити на зв'язок у неробочий час.
Кількість викликів у неробочий час скоротилася менш ніж до 10 на місяць.
Формально наш процес ескалації використовувався рідко. Більш поширеною думкою було, що інженеру неофіційно допомагає команда, яка зараз перебуває в мережі, особливо це стосувалося наших хлопців з офісу в Сан-Франциско. Багато проблем було усунуто або їх кількість була зменшена за допомогою командної роботи та вирішення їх на льоту.
Інженери в нашому офісі в Сан-Франциско приєдналися до команди повним складом та вийшли за рамки звичайної технічної підтримки. Перед нами стояло питання про певні накладні витрати, проте поширення членства в команді підтримки на кілька офісів зіграло нам на руку, адже це виявилося хорошим способом побудувати відносини, зміцнити їх і дізнатися більше про стеки технологій, з якими ми всі працюємо.
У наших командах робота розробників Intercom стала більш послідовною і ми можемо впевнено говорити про переваги посади системного інженера на нашому сайті. , заявляючи, що немає потреби завжди бути на зв'язку, якщо ви цього не хочете самі.
Поряд із фундаментальною роботою зі стабілізації та масштабування наших сховищ даних, постійна увага до вирішення проблем призвела до того, що кількість викликів у неробочий час скоротилася менш ніж до 10 на місяць. Цим числом ми дуже пишаємось.
Ми продовжуємо працювати над змістом та покращенням нашої команди технічної підтримки, і в міру зростання Intercom нам, можливо, доведеться переглянути свої рішення, адже те, що працює сьогодні, не обов'язково буде працювати наступного разу, коли кількість наших співробітників збільшиться вдвічі. Тим не менш, цей досвід був вкрай позитивним для нашої організації, він значно покращив якість життя наших інженерів-розробників, якість наших відповідей на виклики та насамперед досвід наших клієнтів.
Джерело: habr.com