Як впоратися з простоєм SaaS: Покроковий посібник
Для підготовки до простою SaaS, має бути розроблений письмовий план, що включає кроки, негайне реагування на інциденти та чітку комунікацію.
У цій статті викладено кроки, які варто розглянути щодо впливу простоїв на бізнес та довіру клієнтів, із залученням стратегій та тематичних досліджень.
Огляд концепції
-
Категорія: Управління інцидентами, надійність SaaS
-
Використовується: B2B SaaS, цифрові провайдери, SaaS-платформи
-
Основна мета:
Мінімізувати час простою та захистити довіру клієнтів
-
Пов'язані поняття: Угода про рівень обслуговування (SLA), Резервування, Утримання клієнтів, Аналіз першопричин (RCA)
-
Етап зростання:
Масштабування, після PMF, готовність для підприємств
Розробити комплексний план реагування на інциденти
Що таке план реагування на інциденти є ключовою частиною стратегії управління часом, і його слід ретельно оновлювати та редагувати з урахуванням прогресу системи та будь-яких попередніх інцидентів.
- Визначення ролей та обов'язків: Призначте чіткі ролі членам вашої команди, таким як Командир інциденту (особа, відповідальна за координацію реагування), Технічний керівник (особа, відповідальна за виявлення та усунення несправностей) та Керівник комунікацій (особа, відповідальна за спілкування з клієнтами). Це сприяє встановленню чітких параметрів і може зменшити невизначеність під час виникнення надзвичайної ситуації.
Приклад:
| Роль | Обов'язки |
| Командир інциденту | Координувати реагування, приймати рішення, розподіляти ресурси, спілкуватися із зацікавленими сторонами. |
| Технічний керівник | Виявляти та усувати технічні проблеми, ескалувати за потреби. |
| Керівник з комунікацій | Керувати внутрішніми та зовнішніми комунікаціями, оновлювати сторінку статусу, готувати повідомлення для клієнтів та відповідати на запити. |
| Керівник служби підтримки клієнтів | Обробляти запити та скарги клієнтів, надавати оновлення та ескалувати проблеми відповідним членам команди. |
| Профільний експерт | Надавати спеціалізовані знання та досвід у конкретних сферах програми або інфраструктури. |
Описати процедури ескалації. Створити чіткий маршрут ескалації, щоб забезпечити ефективне та своєчасне вирішення проблем належними фахівцями. Розуміти, коли слід ескалувати інцидент до керівників вищої ланки або зовнішніх команд підтримки.
Створити шаблони комунікації. Розгляньте можливість створення шаблонів для різних ситуацій, пов'язаних з інцидентами (наприклад, погіршення якості послуг, частковий збій, повний збій). Ці шаблони повинні включати відповідні деталі, такі як послуги, яких це стосується, орієнтовний час вирішення проблеми та заходи з її усунення. Обов'язково адаптуйте ці шаблони належним чином для різних аудиторій, таких як клієнти, зацікавлені сторони компанії або компанії-партнери.
План реагування на інциденти від Slack ілюструє процес визначення ролей, налагодження каналів зв'язку та підготовки шаблонів для оновлення статусу.
БЕЗКОШТОВНИЙ Чек-лист реагування на простої SaaS
Швидко реагуйте на збої SaaS за допомогою цього чек-листа реагування на інциденти та відновлення.
-
Перевірки готовності до інцидентів для моніторингу, резервування та відмовостійкості
-
Покрокова послідовність реагування: підтвердження, оновлення, вирішення, компенсація
-
Післяінцидентний аналіз першопричин та список коригувальних дій
-
Заповніть поля для реєстрації критичності, часу простою та постраждалих клієнтів
Налаштуйте моніторинг у реальному часі та систему сповіщень
Перший захист від простоїв — це превентивний моніторинг. Такий моніторинг може сприяти своєчасному виявленню проблем, потенційно впливаючи на їхній перехід у повномасштабні збої.
Коли вибір набору інструментів, необхідно враховувати технічну інфраструктуру, в якій ви працюєте, а також розроблювані додатки. Розгляньте обидві категорії, такі як моніторинг інфраструктури (сервери, бази даних, мережа) та моніторинг продуктивності додатків (APM).
Встановіть порогові значення для важливих показників, таких як час відгуку, частота помилок, використання ЦП та пам'яті. Також створіть сповіщення сповіщати вашу команду щоразу, коли ці пороги перевищуються. Сповіщення краще надсилати електронною поштою, SMS або через Slack, відповідно до уподобань команди.
Така практика популярна серед SaaS-компаній, багато з яких використовують Datadog для швидкого виявлення та вирішення інцидентів.
БЕЗКОШТОВНИЙ Чек-лист реагування на простої SaaS
Швидко реагуйте на збої SaaS за допомогою цього чек-листа реагування на інциденти та відновлення.
-
Перевірки готовності до інцидентів для моніторингу, резервування та відмовостійкості
-
Покрокова послідовність реагування: підтвердження, оновлення, вирішення, компенсація
-
Післяінцидентний аналіз першопричин та список коригувальних дій
-
Заповніть поля для реєстрації критичності, часу простою та постраждалих клієнтів
Запровадити механізми резервування та відмовостійкості
SaaS Резервування означає наявність кількох екземплярів програм, серверів тощо у вашій інфраструктурі на випадок збою одного з них. Цей підхід пов'язаний зі скороченням часу відновлення сервісів.
- Щоб підвищити продуктивність і надійність вашої інфраструктури, ви можете розглянути можливість впровадження деяких ключових надмірностей. Один з таких підходів полягає у використанні двох або більше веб-серверів та розміщенні їх у різних регіонах, застосовуючи географічна надмірність. Система дозволяє розподіляти навантаження, що забезпечує безперервну роботу веб-сайту, попри вихід сервера з ладу.
- Ще одна опція – реплікувати ваші бази даних на кількох серверах або в зонах доступності, використовуючи реплікацію баз даних. Ця функціональність розроблена для підтримки захисту даних та можливостей доступу.
- Якщо ви використовуєте Хмарна інфраструктура, існує кілька вбудованих функцій резервування якими ви можете скористатися, наприклад, кілька зон доступності або регіонів.
Netflix працює з кількома Зонами Доступності в AWS, конфігурація, що відповідає її цілям щодо високої доступності та відновлення після збоїв.
БЕЗКОШТОВНИЙ Чек-лист реагування на простої SaaS
Швидко реагуйте на збої SaaS за допомогою цього чек-листа реагування на інциденти та відновлення.
-
Перевірки готовності до інцидентів для моніторингу, резервування та відмовостійкості
-
Покрокова послідовність реагування: підтвердження, оновлення, вирішення, компенсація
-
Післяінцидентний аналіз першопричин та список коригувальних дій
-
Заповніть поля для реєстрації критичності, часу простою та постраждалих клієнтів
Визнайте простій
Прозорість дуже важлива під час інциденту простою. Швидке публічне повідомлення після виявлення збою пов'язане з визнанням проблеми та ініціюванням процесів її вирішення. Таке спілкування може вплинути на розвиток довіри та коригування очікувань.
Оберіть канали комунікації:
- Включіть у свою сторінку стану інформацію про збій, зачеплені сервіси, орієнтовний час усунення проблеми та будь-які відомі тимчасові рішення.
- Використовуйте платформи соціальних мереж, такі як Twitter та LinkedIn, щоб розширити свою аудиторію та надати короткий огляд ситуації.
- Надішліть електронний лист особам, яких це стосується, щоб надати детальне пояснення та найновішу інформацію.
Будьте чесними та прозорими. Важливо точно оцінити масштаб проблеми та брати на себе зобов'язання, які можна виконати. Повідомте клієнтів про причини простою. Документуйте дії, що вживаються для вирішення питання.
Надайте часову шкалу. Оцініть час, необхідний для вирішення проблеми (ETR), і вкажіть діапазон, хоча б загальний. Потім оновіть ETR з найактуальнішою інформацією. Формування очікувань без достатнього обґрунтування може призвести до негативних емоційних реакцій.
Шаблон:
| “Ми зіткнулися з перебоями в роботі [service/feature]. Наша команда активно працює над усуненням проблеми, і ми надаватимемо оновлення кожні [time interval, e.g., 30 minutes], доки проблему не буде вирішено. Просимо вибачення за можливі незручності та цінуємо ваше терпіння.” |
БЕЗКОШТОВНИЙ Чек-лист реагування на простої SaaS
Швидко реагуйте на збої SaaS за допомогою цього чек-листа реагування на інциденти та відновлення.
-
Перевірки готовності до інцидентів для моніторингу, резервування та відмовостійкості
-
Покрокова послідовність реагування: підтвердження, оновлення, вирішення, компенсація
-
Післяінцидентний аналіз першопричин та список коригувальних дій
-
Заповніть поля для реєстрації критичності, часу простою та постраждалих клієнтів
Регулярно надавайте оновлення
Важливо врахувати одне: тримати своїх клієнтів в курсі про статус вирішення інциденту. Також необхідно надати оцінку часу, потрібного для завершення вирішення, і простою мовою пояснити причину простою.
Збій Facebook у 2021 році показало, чому сторінка статусу має розміщуватися на незалежній від продукту інфраструктурі — їхня відмовила разом із сервісом, змусивши публікувати оновлення на сторонній платформі.
БЕЗКОШТОВНИЙ Чек-лист реагування на простої SaaS
Швидко реагуйте на збої SaaS за допомогою цього чек-листа реагування на інциденти та відновлення.
-
Перевірки готовності до інцидентів для моніторингу, резервування та відмовостійкості
-
Покрокова послідовність реагування: підтвердження, оновлення, вирішення, компенсація
-
Післяінцидентний аналіз першопричин та список коригувальних дій
-
Заповніть поля для реєстрації критичності, часу простою та постраждалих клієнтів
Запропонуйте вибачення та компенсацію
Вибачтесь та повідомити обґрунтування продовження терміну і обставини, які воно спричинило. Практика не передбачає надання виправдань або покладання відповідальності на інші сторони.
Пропозиція сервісні кредити або знижку клієнтам залежно від масштабу збою, його тривалості та серйозності. Розгляньте можливість надання інших переваг, таких як безкоштовні пробні версії або доступ до преміум-функцій зі знижкою. Враховуйте обставини клієнтів та відповідно компенсуйте.
У 2019 році, Salesforce змінила свою кредитну політику, засновану на угоді про рівень обслуговування (SLA), таким чином, щоб надавати клієнтами кредит за час, протягом якого послуга була недоступна.
БЕЗКОШТОВНИЙ Чек-лист реагування на простої SaaS
Швидко реагуйте на збої SaaS за допомогою цього чек-листа реагування на інциденти та відновлення.
-
Перевірки готовності до інцидентів для моніторингу, резервування та відмовостійкості
-
Покрокова послідовність реагування: підтвердження, оновлення, вирішення, компенсація
-
Післяінцидентний аналіз першопричин та список коригувальних дій
-
Заповніть поля для реєстрації критичності, часу простою та постраждалих клієнтів
Аналізуйте, навчайтеся та вдосконалюйтеся
Виникнення проблеми з продуктом або послугою може призвести до огляд пов'язаного процесу та його ефективності. Розбір інциденту та виявлення першопричини, а потім застосування цих знань для запобігання подібним ситуаціям у майбутньому, є ключем до максимально ефективного використання такого аналізу.
Ретельний Аналіз першопричин (RCA) передбачає створення хронології ключових подій, пояснення впливу події, виявлення першопричини та пропозицію коригувальних заходів. Цей процес пов'язаний з виявленням основних проблем та вибором рішень.
Почати збір журналів, метрик та інших відповідних даних з ваших інструментів моніторингу, серверів та застосунків. Поспілкуйтеся з людьми, які брали участь у процесі вирішення інциденту, та отримайте їхні коментарі та інсайти.
Оцінка відгуки клієнтів та заявки в службу підтримки від часу недоступності вебсайту є опцією. Розташуйте надану інформацію відповідно до хронологічної послідовності подій, пов'язаних зі збоєм.
Використайте інформацію для створення хронології подій. Використайте дані для виявлення закономірностей або будь-яких незвичайних дій, які можуть допомогти у пошуку першопричини.
Не робіть висновків одразу. Розгляньте всі можливі причини збою, будь то технічні, людські, механічні чи зовнішні.
Задокументуйте свої висновки. Підготуйте детальний звіт RCA, який включає:
- Хронологія подій
- Оцінка впливу
- Першопричина(-и)
- Супутні фактори
- Рекомендовані коригувальні дії
Шаблон:
| Звіт про аналіз першопричин
Інцидент: [Збій сервісу/функціоналу] Дата: [Дата збою] Хронологія подій:
Оцінка впливу:
Першопричина(-и):
Супутні фактори:
Рекомендовані коригувальні дії:
|
Впровадьте коригувальні заходи. Згідно з результатами вашого RCA, вживіть заходів, щоб уникнути майбутніх простоїв. Це може включати виправлення помилок програмного забезпечення, оновлення конфігурацій, посилення моніторингу та сповіщень, або надання додаткового навчання для вашої команди.
Поділіться вивченими уроками. Включіть висновки вашого RCA у ваші коригувальні дії та дії з вашою командою та клієнтами. Це може бути сприйнято як індикатор відданості розвитку та може вплинути на рівень довіри.
- Всередині компанії: Представте звіт RCA вашій команді та обговоріть ключові висновки. Наявність відкритого спілкування та зворотного зв'язку створює умови, що підтримують ітеративне вдосконалення. Поширюйте інформацію про найкращі практики та висновки з інцидентів для запобігання подібним випадкам.
- Зовні компанії: Додайте розділ на свою сторінку стану або блог, щоб поділитися основними висновками з аналізу першопричин (RCA). Важливо пояснити громадськості причину збою та тримати їх в курсі вирішення проблеми. Здобудьте довіру за терпіння ваших клієнтів, визнавши це.
Для отримання додаткової інформації про простої SaaS та про те, як їх вирішувати, ви можете звернутися до цих ресурсів: Як написати SLA.
Досвід GitHub вказує на важливість навчання на помилках. У відповідь на великий збій у 2018 році GitHub переналаштував свої інструменти відмовостійкості, щоб запобігти міжрегіональному підвищенню, і переробив свою систему звітності про стан, і ці зміни вважаються такими, що впливають на ймовірність подібних подій.
Висновок
Управління простоями протягом часу, коли програма SaaS працює, є постійним процесом, який має бути проактивним, швидким і ніколи не закінчуватися. Впровадження моніторинг, резервне копіювання, плани реагування на інцидентита комунікаційний методи можуть впливати на наслідки простоїв і рівень довіри клієнтів.
Випадки простою SaaS-додатків можуть надати інформації для оцінки та коригування системи, що може вплинути на стабільність та надійність додатка.
Готові розпочати?
Ми були там, де ви зараз. Дозвольте нам поділитися нашим 19-річним досвідом і втілити ваші глобальні мрії в реальність.
Поширені запитання
-
Коли в проєктах виникають проблеми, технічні питання часто виходять на перший план. Такі фактори, як людська помилка або зовнішні впливи, наприклад, кібератаки, також беруться до уваги.
-
Найкращий захист від простоїв — це запобігання, чого можна досягти шляхом впровадження резервування, проведення регулярного технічного обслуговування та ретельного тестування. Крім того, слід використовувати моніторинг у реальному часі для раннього виявлення та вирішення проблем.
-
Перший крок – це визнати наявність проблеми, а потім відкрито спілкуватися зі своїми клієнтами щодо ситуації, вказавши фактичний час її вирішення. Зазвичай приносяться вибачення, а у випадках значних збоїв може бути розглянута компенсація для користувачів.
-
Наявність плану реагування на інциденти є дуже важливою, і цей план повинен включати ролі та обов'язки, процедури ескалації та шаблони комунікації для забезпечення швидкого та впорядкованого реагування.
-
Після інциденту має бути проведений ретельний аналіз першопричини (RCA). Це передбачає виявлення першопричини інциденту, вжиття коригувальних заходів та обмін отриманими уроками з рештою команди, щоб уникнути повторення тих самих помилок.
Українська 
English 
Español 
Português 
Português do Brasil 
Français 
Italiano 
Deutsch 
Nederlands 
Polski 
Română 
简体中文 
日本語 
한국어