--- title: SLA технической поддержки сайта — практический шаблон для веб-студии description: Как составить SLA поддержки сайта — критичность, время реакции и восстановления, сервисные часы, исключения, ответственность и готовый шаблон с примерами. source: https://pingvera.ru/blog/sla-tehnicheskoy-podderzhki-sayta.html --- # SLA технической поддержки сайта: практический шаблон для веб-студии SLA технической поддержки сайта — это измеримая договорённость о том, **какие события обслуживает студия, в какие часы, как быстро реагирует, как сообщает о ходе работ и по каким данным стороны проверяют результат**. Хороший SLA не обещает, что любая проблема будет полностью исправлена за пятнадцать минут. Он разделяет время реакции, локализации, восстановления и окончательного решения; учитывает зависимости от клиента и внешних провайдеров; описывает начало и остановку часов. Для небольшой студии особенно важно не копировать корпоративный SLA с круглосуточным дежурством. Обещание должно соответствовать людям, инструментам, бюджету и реальному режиму поддержки. > Этот материал — рабочий редакционный шаблон, а не юридическое заключение. Перед включением SLA в договор проверьте формулировки с юристом с учётом конкретных услуг, ответственности и применимого права. ## Коротко В SLA поддержки сайта нужно зафиксировать: 1. список поддерживаемых сайтов, функций и зависимостей; 2. сервисные часы и часовой пояс; 3. единственные официальные каналы обращений; 4. уровни критичности P1–P4; 5. время первой человеческой реакции; 6. целевое время локализации или восстановления, если его реально можно обещать; 7. правила начала, приостановки и возобновления отсчёта; 8. обязанности клиента; 9. исключения и плановые работы; 10. порядок коммуникации, отчётности и пересмотра соглашения. ## Что SLA решает в реальном бизнесе Без измеримой договорённости клиент думает: > Мы платим за поддержку, значит кто-то в любую минуту обязан полностью починить любую проблему сайта. Студия думает: > Мы отвечаем в рабочее время и не можем гарантировать сроки, если упал хостинг, недоступна 1С или клиент не дал доступ. Обе стороны могут действовать добросовестно и всё равно конфликтовать. SLA делает ожидания явными: - какие бизнес-функции считаются критическими; - кто и как сообщает об инциденте; - что происходит ночью и в праздники; - считается ли автоответ реакцией; - когда студия должна только начать работу, а когда — восстановить функцию; - что меняется, если решение зависит от третьей стороны; - какие доказательства попадут в ежемесячный отчёт. SLA полезен не только клиенту. Он защищает студию от бесконечного «срочно», помогает рассчитать стоимость дежурства и показывает, какие процессы нужно автоматизировать до подписания договора. ## SLA не заменяет состав услуг У договора и приложения к нему обычно есть несколько разных слоёв. Если в составе услуги нет администрирования сервера, SLA не должен незаметно добавлять обязанность чинить операционную систему. Если студия отвечает только за сайт, но не управляет платёжным шлюзом, она может гарантировать обнаружение, диагностику со стороны сайта, эскалацию и коммуникацию — но не срок исправления чужого сервиса. ## SLA, SLO и SLI без лишней теории Эти сокращения полезно различать. **SLI — Service Level Indicator** — фактический показатель. Например, доля успешных контрольных оформлений заказа за месяц. **SLO — Service Level Objective** — внутренняя или согласованная цель. Например, не менее 99,5 % успешных контрольных оформлений. **SLA — Service Level Agreement** — договорённость между сторонами, которая описывает показатели, измерение, обязанности и возможные последствия. Небольшой студии необязательно использовать все термины в клиентском документе. Но внутри команды полезно иметь цель строже, чем внешнее обещание. Если внешняя граница нарушается раньше, чем система успевает предупредить команду, SLA невозможно управлять. ## Четыре разных времени Самая опасная фраза в SLA — «срок решения критической проблемы: 30 минут». Неясно, что считается решением и насколько оно зависит от студии. Разделите показатели. ### Время обнаружения Период от начала наблюдаемого нарушения до регистрации события системой мониторинга или сотрудником. Его можно измерить только для функций, которые действительно проверяются. Если студия проверяет главную страницу раз в пять минут, но не тестирует форму, она не может обещать автоматическое обнаружение потери заявок. ### Время реакции Период от регистрации события в согласованном канале до первого содержательного ответа специалиста. Содержательный ответ подтверждает, что обращение принято человеком, содержит предварительную классификацию или запрос необходимых данных и называет следующий шаг. Автоматическое «заявка №123 создана» само по себе не должно считаться реакцией, если стороны прямо не договорились иначе. ### Время локализации или восстановления Период до восстановления критической пользовательской функции полностью или через согласованный безопасный обходной путь. Пример: проблемный способ оплаты отключён, работающий резервный способ проверен, покупатель снова может завершить заказ. Первопричина ещё не исправлена, но бизнес-функция восстановлена. ### Время окончательного решения Период до постоянного исправления, проверки и документирования результата. Он сильнее зависит от сложности, релизного окна, внешних подрядчиков и согласований. Для многих сайтов разумнее согласовывать срок решения после диагностики, а в SLA гарантировать реакцию, эскалацию и целевое восстановление критической функции. ## Сначала определите сервисное окно Время реакции бессмысленно без часов покрытия. Пример базового режима: Часы поддержки: рабочие дни с 09:00 до 18:00 по московскому времени, кроме официальных нерабочих праздничных дней. Обращения, зарегистрированные вне часов поддержки, считаются принятыми в 09:00 ближайшего рабочего дня, кроме клиентов с отдельной услугой круглосуточного дежурства P1. Пример критического режима: События P1 принимаются круглосуточно по автоматическому мониторингу и аварийному номеру. События P2–P4 обслуживаются в рабочие дни с 09:00 до 18:00 мск. Круглосуточный P1 требует: - графика дежурств; - минимум двух взаимозаменяемых контактов; - оплачиваемой доступности сотрудников; - надёжного аварийного канала; - доступа к системам вне офиса; - регламента полномочий; - регулярных учебных вызовов. Если этого нет, правильнее продать расширенные часы или реакцию на следующий рабочий день, чем обещать фиктивные 24/7. ## Пример матрицы для небольшой студии Это отправная точка для расчёта, а не готовая гарантия для любого договора. Если студия продаёт два уровня обслуживания, разделите их явно. ### Пакет «Рабочее время» - P1–P3 обслуживаются в будни 09:00–18:00 мск; - ночью мониторинг сохраняет события, но не будит специалиста; - отсчёт реакции начинается в начале следующего сервисного окна; - аварийный телефон вне окна не предоставляется. ### Пакет «Критический контур» - P1 принимается 24/7; - только заранее перечисленные функции могут создать P1; - автоматический сигнал дублируется дежурному; - клиент предоставляет круглосуточный контакт для решений; - P2–P4 остаются в стандартном окне; - стоимость включает дежурство, учения и резервный канал. Так клиент понимает, за что платит, а команда не несёт круглосуточную ответственность за каждую правку контента. ## Зафиксируйте уровни критичности Не оставляйте определения «критический», «высокий» и «обычный» без примеров. В приложении перечислите: - критические функции каждого сайта; - примеры P1–P4; - кто имеет право повысить уровень; - как решается спор о классификации; - когда уровень пересматривается после временного решения. Для магазина критическими могут быть каталог, корзина, создание заказа, оплата и обмен с 1С. Для корпоративного сайта — доступность, ключевая форма заявки и публикация обязательной информации. Для B2B-портала — авторизация и оформление заявки партнёра. Готовая матрица: [уровни критичности инцидентов для веб-студии](https://pingvera.ru/blog/shkala-kritichnosti-incidentov-dlya-veb-studii.html). ## Определите официальный канал регистрации Если клиент пишет разработчику в личный Telegram, звонит бухгалтеру и оставляет комментарий в макете, студия не может надёжно измерить SLA. Закрепите: - Helpdesk или служебный email для P2–P4; - автоматический мониторинг и аварийный контакт для P1; - резервный канал, если основной недоступен; - список уполномоченных представителей клиента; - правило переноса решения из мессенджера в карточку обращения. Пример: Официальным временем регистрации обращения считается время его создания в Helpdesk [адрес]. Для P1 допускается аварийный звонок по номеру [номер] с обязательной автоматической или ручной регистрацией карточки. Сообщения в личные аккаунты сотрудников, комментарии в макетах и устные просьбы без регистрации не запускают отсчёт SLA. Формулировка должна быть заметной и удобной. Нельзя спрятать официальный канал в договоре и продолжать приучать клиента писать в личный чат. ## Когда начинается отсчёт Выберите одно проверяемое событие. Варианты: 1. создание заявки клиентом в Helpdesk; 2. создание карточки подтверждённым автоматическим мониторингом; 3. регистрация события дежурным после аварийного звонка; 4. наиболее раннее из согласованных событий. Для автоматического обнаружения полезна формулировка: Для функций, перечисленных в реестре мониторинга, отсчёт реакции начинается с момента создания подтверждённого события в системе [название] и доставки уведомления в согласованный аварийный канал. Единичная неуспешная проверка, не прошедшая правило подтверждения, не считается зарегистрированным инцидентом. Так студия не начинает SLA по каждому сетевому колебанию, но несёт понятную ответственность за настроенные критические проверки. ## Когда часы приостанавливаются Пауза должна быть видима обеим сторонам и сопровождаться конкретным запросом. Допустимые примеры: - студии нужен доступ, который обязан предоставить клиент; - требуется бизнес-решение: отключить оплату или закрыть сайт; - нужно согласовать платную работу вне состава поддержки; - тестирование возможно только в разрешённое клиентом окно; - внешняя сторона должна выполнить действие, а студия не имеет технического контроля. Недостаточно поставить статус «ждём клиента». Напишите: Отсчёт приостановлен в 13:20 мск. Для продолжения нужен временный доступ к панели хостинга с правом просмотра журналов. Запрос направлен [имя]. После получения доступа отсчёт возобновляется автоматически. Для P1 даже во время внешнего ожидания студия может сохранять обязанность регулярно сообщать статус и искать обходной путь. Пауза технического срока не должна означать исчезновение коммуникации. ## Не обещайте доступность без точки измерения Фраза «гарантируем uptime 99,9 %» неполна. Нужно определить: - какой домен, страница или функция измеряется; - из каких точек; - с какой частотой; - сколько повторов подтверждают недоступность; - считаются ли частичные ошибки; - входят ли плановые работы; - какой период используется; - что происходит при сбое внешней зависимости. При расчёте по времени доступность 99,9 % допускает около **43 минут 12 секунд недоступности за условный 30-дневный месяц**, если плановые окна не исключаются. Но эта цифра ничего не говорит о заказах: сайт может отдавать `200 OK`, пока форма и оплата не работают. Поэтому для бизнеса полезнее сочетать несколько показателей: - доступность основного URL; - доля успешных контрольных заявок; - доля успешных оформлений заказа; - доступность авторизации; - свежесть обмена с 1С; - время обнаружения подтверждённого нарушения; - время реакции команды. Выбирайте показатели, соответствующие пользовательскому результату, и не называйте их гарантией продаж. ## Что включить в исключения Исключения не должны превращать SLA в пустой документ. Они описывают границы контроля. Разумно рассмотреть: - заранее согласованные плановые работы; - недоступность из-за действий клиента вне процедуры изменений; - отсутствие или отзыв необходимых доступов; - инфраструктуру и сервисы, не входящие в ответственность студии; - форс-мажор в формулировке, согласованной юристом; - DDoS и атаки — только с точным описанием обязанностей по обнаружению и эскалации; - отказ внешнего API, если студия не управляет им; - блокировку домена или сервиса по решению уполномоченной стороны; - изменения требований после регистрации обращения; - тестовые и архивные системы, не включённые в реестр. Даже если событие исключено из гарантированного срока восстановления, можно сохранить обязательства: - обнаружить; - подтвердить; - уведомить; - открыть обращение внешней стороне; - предложить безопасный обход; - контролировать восстановление; - проверить пользовательскую функцию после возвращения зависимости. Это и есть реальная ценность студии, когда она не может починить чужую инфраструктуру собственными руками. ## Плановые работы Опишите: - разрешённые окна; - минимальный срок предупреждения; - кто согласует; - какие проверки выполняются до и после; - максимальную длительность; - план отката; - когда незавершённая работа становится инцидентом. Пример: Плановые изменения, способные повлиять на доступность, выполняются по средам с 21:00 до 23:00 мск после уведомления не менее чем за два рабочих дня. Исполнитель фиксирует план проверки и отката. Если влияние выходит за согласованное окно или результат контрольной операции не подтверждён, событие классифицируется как инцидент. Обязанности клиента SLA работает только при встречной готовности. Клиент обычно должен: - назначить основного и резервного представителя; - поддерживать актуальные контакты; - предоставить необходимые доступы безопасным способом; - сообщать о рекламных кампаниях и критических датах; - согласовывать изменения через установленный процесс; - не изменять production в обход журнала работ; - своевременно принимать решения по временным мерам; - оплачивать внешние сервисы, домен, хостинг и лицензии, если это его зона; - предоставлять достоверные данные о пользовательском влиянии; - не передавать общие пароли в открытом чате. Укажите, что происходит, если контакт клиента недоступен во время P1. Например, какие заранее разрешённые обратимые меры студия может принять самостоятельно. ## Ответственность внешних поставщиков Для каждой критической зависимости запишите: Если ответственность не определена, во время аварии студия будет искать не причину, а владельца договора и пароль от кабинета. ## Копируемый шаблон SLA Ниже — основа приложения. Замените квадратные скобки и удалите пункты, которые не соответствуют услуге. # Приложение: уровень технической поддержки сайта ## 1. Область действия Соглашение применяется к следующим production-системам: - [домен / система]; - [критическая функция]; - [интеграция]; - [явно включённая инфраструктура]. Не входят: [тестовые системы, контентные изменения, сторонние сервисы, не перечисленные выше, и другие границы]. ## 2. Сервисные часы Стандартная поддержка: [дни и часы, часовой пояс]. P1 вне стандартного окна: [предоставляется / не предоставляется]. Праздничные дни: [правило]. ## 3. Каналы P1: [мониторинг, аварийный телефон, чат]. P2–P4: [Helpdesk / служебный email]. Резервный канал: [канал]. Сообщения в личные аккаунты сотрудников не запускают отсчёт SLA, пока не зарегистрированы в официальной системе. ## 4. Критичность ### P1 — критический [Критерии и примеры для конкретного проекта] ### P2 — высокий [Критерии и примеры] ### P3 — обычный [Критерии и примеры] ### P4 — низкий / изменение [Критерии и примеры] ## 5. Целевые показатели | Уровень | Время реакции | Первое сообщение | Обновления | Цель восстановления | |---|---:|---:|---:|---:| | P1 | [значение] | [значение] | [интервал] | [значение / после оценки] | | P2 | [значение] | [значение] | [правило] | [значение / после оценки] | | P3 | [значение] | [значение] | [правило] | [после оценки] | | P4 | [значение] | [значение] | [правило] | [по плану] | Время реакции означает первый содержательный ответ специалиста, а не автоматическое подтверждение регистрации. Восстановление означает подтверждённое возвращение пользовательской функции полностью или через согласованный безопасный обход. ## 6. Начало отсчёта Отсчёт начинается [событие]. Для автоматического мониторинга инцидент считается зарегистрированным после [правило подтверждения и доставки]. ## 7. Приостановка Отсчёт может быть приостановлен, если требуется: - доступ или информация клиента; - решение уполномоченного представителя; - согласованное окно изменения; - действие внешнего поставщика вне контроля исполнителя. Пауза фиксируется в карточке с временем, причиной и условием возобновления. Коммуникация по активному P1 продолжается по установленному интервалу. ## 8. Плановые работы Окно: [дни и часы]. Предупреждение: не менее [срок]. Согласование: [роль]. Проверка и откат: [правило]. ## 9. Обязанности исполнителя - поддерживать перечисленные проверки; - принимать события по согласованным каналам; - классифицировать и вести карточку инцидента; - сообщать статус по установленному интервалу; - выполнять действия в пределах доступа и состава услуги; - проверять пользовательскую функцию после восстановления; - предоставлять ежемесячный отчёт. ## 10. Обязанности клиента - поддерживать актуальные контакты и доступы; - назначить уполномоченных представителей; - сообщать о критических периодах и изменениях; - своевременно принимать решения; - не изменять production в обход согласованной процедуры; - выполнять обязательства по сторонним договорам и оплатам. ## 11. Исключения [Конкретный список исключений без расплывчатой формулировки «всё, что не зависит от исполнителя».] Для исключённых внешних событий исполнитель сохраняет обязанности: [обнаружение / уведомление / эскалация / контроль / проверка]. ## 12. Измерение и отчётность Источник времени: [Helpdesk / Pingvera / другая система]. Часовой пояс: [значение]. Период отчёта: [месяц]. Отчёт содержит: - количество инцидентов по уровням; - время обнаружения и реакции; - период пользовательского влияния; - соблюдение коммуникационных интервалов; - исключённые события с основанием; - повторяющиеся причины и корректирующие действия. ## 13. Пересмотр Соглашение пересматривается [ежеквартально / при изменении архитектуры, состава услуги или режима работы]. Изменения вступают в силу после [порядок]. Что показывать в ежемесячном отчёте Не ограничивайтесь средним временем реакции. Среднее может скрыть один критический провал. Покажите: - число P1, P2 и P3; - каждый P1 отдельной строкой; - время обнаружения, реакции и восстановления; - соблюдение первого сообщения и обновлений; - подтверждённый период пользовательского влияния; - события, исключённые из SLA, с причиной; - сколько инцидентов обнаружила студия, а сколько — клиент; - повторяющиеся проблемы; - одно–три корректирующих действия; - пробелы в мониторинге и доступах. Удачный отчёт отвечает не только «вписались ли в цифру», но и «стал ли сервис устойчивее». ## Как рассчитать цену SLA Цена зависит не от количества строк в приложении, а от требуемой готовности. Учтите: - часы покрытия; - вероятность ночного вызова; - число и сложность критических функций; - количество сайтов; - необходимость резервного специалиста; - поддерживаемые CMS и интеграции; - доступ студии к инфраструктуре; - требования к коммуникации; - объём учений и отчётности; - стоимость ошибок и срочных переключений; - внешние подрядчики и языки взаимодействия. Практичный подход: 1. базовая абонентская поддержка покрывает рабочее время; 2. расширенные часы оплачиваются отдельным коэффициентом; 3. 24/7 P1 продаётся только для перечисленных критических функций; 4. доработки и постоянные исправления вне состава оцениваются отдельно; 5. первые 30 дней после приёма незнакомого сайта могут иметь переходный SLA. Переходный период полезен, когда студия ещё не проверила бэкапы, доступы и старые дефекты. Нельзя честно гарантировать восстановление системы, которую команда впервые увидела вчера. ## Компенсации и последствия Вопрос скидок, сервисных кредитов, лимита ответственности и расторжения должен согласовываться с юристом и экономикой договора. До юридических формулировок определите операционный смысл: - какое нарушение считается единичным; - как клиент заявляет о несоблюдении; - какие данные считаются источником; - есть ли период проверки; - что происходит при систематических нарушениях; - является ли компенсация единственным последствием; - исключаются ли события, вызванные нарушением обязанностей клиента. Не обещайте штраф, который превышает маржу услуги и делает один внешний сбой финансово опаснее всего договора. ## Как внедрить SLA за семь шагов 1. **Проведите инвентаризацию.** Сайты, владельцы, зависимости, доступы. 2. **Определите критические функции.** Не больше трёх–семи на проект для первого запуска. 3. **Настройте проверяемые сигналы.** Доступность, формы, заказ, SSL, домен, обмены. 4. **Создайте шкалу P1–P4.** С реальными примерами клиента. 5. **Проверьте достижимость сроков.** По истории обращений или учебному инциденту. 6. **Согласуйте контакты и полномочия.** Включая ночные решения и резервных людей. 7. **Запустите пробный месяц.** С отчётом без финансовых последствий, затем скорректируйте показатели. Если во время теста уведомление приходит через сорок минут, не подписывайте реакцию за пятнадцать. Сначала измените мониторинг, маршрутизацию и дежурство. ## Частые ошибки ### Одинаковый SLA для любого клиента Магазин с оплатой, лендинг и внутренний архив имеют разное бизнес-влияние. Общими могут быть процессы, но не обязательно критические функции и сроки. ### Реакция названа решением «Ответим за 15 минут» не означает «полностью исправим за 15 минут». Закрепите определения рядом с таблицей. ### Круглосуточный мониторинг выдан за круглосуточную поддержку Сервис может проверять сайт ночью, но кто-то должен получить, подтвердить и обработать сигнал. Автоматическое наблюдение и человеческое дежурство — разные услуги. ### SLA начинается с сообщения в любом месте Без официального канала невозможно доказать время регистрации и обеспечить резервирование. ### Все внешние сервисы просто исключены Студия не обязана чинить чужой сервис, но может отвечать за обнаружение, эскалацию, обход и клиентскую коммуникацию. ### Измеряется только главная страница Высокий uptime не гарантирует работающую форму, оплату или обмен. Добавьте бизнес-показатели. ### Плановые работы не ограничены Если любое падение можно задним числом назвать техническим окном, показатель теряет доверие. ### Нет обязанностей клиента Без контактов, решений и доступов срок восстановления может зависнуть. Встречные действия должны быть измеримыми так же, как действия студии. ## Как помогает Pingvera Pingvera может стать одним из источников фактов для SLA: - регулярно проверять сайт из нескольких точек; - контролировать формы и доставку тестовой заявки; - следить за SSL, доменом, CMS, сервером и фоновыми сигналами; - фиксировать время начала и окончания нарушения; - отправлять событие в Telegram, email, MAX или webhook; - поддерживать независимую статус-страницу; - сохранять историю для клиентского отчёта. Но система мониторинга не заменяет договор, дежурство, Helpdesk и полномочия команды. Она измеряет согласованные признаки и доставляет событие; студия определяет критичность, принимает решения и отвечает за коммуникацию в своей зоне. > **Сделайте SLA измеримым до подписания:** создайте реестр критических функций, настройте для них проверки и проведите тестовый P1. [Настроить мониторинг в Pingvera](https://app.pingvera.ru/). ## Часто задаваемые вопросы ### Какое время реакции указать для критического сбоя? То, которое команда подтверждает ресурсами и тестом. Для одной студии это 15 минут круглосуточно, для другой — 30 минут только в рабочее время. Скорость без сервисного окна и канала регистрации не является измеримым обещанием. ### Можно ли гарантировать срок полного исправления? Для типовых контролируемых ситуаций — иногда да. Для неизвестных дефектов и внешних зависимостей безопаснее гарантировать реакцию, диагностику, эскалацию, коммуникацию и целевое восстановление функции, а постоянное решение оценивать после диагностики. ### Считается ли автоответ реакцией? Обычно полезнее считать реакцией первый содержательный ответ человека. Автоответ подтверждает доставку, но не показывает, что специалист оценил влияние. Определение нужно прямо записать в SLA. ### Чем SLA отличается от абонентской поддержки? Абонентская поддержка описывает коммерческую услугу и её состав. SLA задаёт измеримый уровень выполнения включённых операций. Абонентка может существовать без формального SLA, но ожидания всё равно стоит зафиксировать. ### Нужно ли обещать uptime сайта? Только если студия контролирует достаточную часть системы и стороны согласовали точку измерения, частоту, подтверждение, исключения и последствия. Часто полезнее добавить показатели критических пользовательских функций. ### Кто определяет критичность — клиент или студия? Первичную классификацию делает назначенная сторона по согласованной матрице. Клиент может предоставить новый бизнес-контекст и запросить пересмотр. Спор решается фактами о масштабе, функции, обходе и срочности, а не должностью участника. ### Что делать с обращением вне рабочего времени? Следовать выбранной модели. В стандартном пакете отсчёт может начаться с ближайшего сервисного окна. В пакете 24/7 только P1 будит дежурного. Правило должно быть известно до инцидента. ### Как часто пересматривать SLA? Не реже чем при изменении архитектуры, критических функций, состава поддержки или режима команды. Для активных проектов полезен квартальный операционный пересмотр даже без изменения договора. ## Главное Сильный SLA — не обещание героизма. Это описание системы, в которой известны критические функции, каналы, часы, роли, измерения и границы контроля. Начните с реального режима команды, разделите реакцию и восстановление, свяжите показатели с бизнес-функциями и проверьте процесс на учебном инциденте. Тогда SLA уменьшит конфликт ожиданий и станет аргументом ценности поддержки, а не источником невыполнимых обязательств. ## Источники и дополнительное чтение - [Google SRE: таблица доступности](https://sre.google/sre-book/availability-table/) - [Google SRE Workbook: Implementing SLOs](https://sre.google/workbook/implementing-slos/) - [Google SRE Workbook: Monitoring](https://sre.google/workbook/monitoring/) - [Atlassian: уровни серьёзности инцидентов](https://www.atlassian.com/ru/incident-management/kpis/severity-levels) - [Atlassian: коммуникация во время инцидента](https://www.atlassian.com/incident-management/incident-communication) - [Cloud.ru: время реагирования и решения обращений](https://cloud.ru/docs/overview/support/topics/concepts__sla) - [ИнфоТеКС: пример соглашения об уровне сервиса](https://infotecs.ru/support/sla/) - [Pingvera: регламент мониторинга сайтов клиентов](https://pingvera.ru/blog/reglament-monitoringa-saytov-klientov.html) - [Pingvera: как принять сайт на техническую поддержку](https://pingvera.ru/blog/priem-sayta-na-tehnicheskuyu-podderzhku.html) Следующий материал курса: **«Карта критических бизнес-путей сайта: что проверять кроме главной страницы»**.