🤓💻 Мифы об SLA (часть 2)

Первая часть: https://set.ki/post/bRbQnE3

На предыдущий пост об SLA было много положительных реакций, так что давайте продолжим говорить об этой форме контракта. Но сегодня мы сместим фокус с техники на людей. Разберём 3 мифа, которые продакты встречают в своей практике, и научимся закреплять их в контракте.

Миф 1. Можно гарантировать время решения проблем. Нельзя. Надо уметь строго говорить нет на формулировку "решаем критичные проблемы за 1/2/n часов". И дело не в том, что техподдержка + дежурные разработчики - это всего лишь люди. Как бы ни был совершенен ваш продукт, в нём будут легаси-части, неожиданные сетевые поломки и другие проблемы, которые непонятно как обработать на берегу. И вот вы уже напряглись - а как же мы можем гарантировать клиенту, что наш сервис поднимется..? Тут стоить вспомнить о том, что по другую сторону экранов в клиентском взаимодействии - тоже люди. Им плохо и страшно от того, что у вас что-то упало, а они могут потерять деньги. Их надо в первую очередь успокоить. Ввиду этого в SLA (и реальную жизнь) хорошо ложатся 2 других параметра: • Время первой реакции • Время взятия проблемы в работу Если клиент знает, что его проблемой занимаются - его жизнь уже становится лучше. Это не отменяет ответственности продуктовой, инфровой и остальных команд за решение проблемы, но даёт свободу для манёвра.

Миф 2. Внешние постмортемы по инцидентам не нужно писать, клиент и так всё видит. Вы абсолютно точно можете использовать этот подход - зачем напрягать людей писаниной? Да ещё и время надо писать, как в дневнике. Во столько-то мы легли, во столько-то поднялись, вот столько-то восстанавливались и прочее. Только вы будете удивлены на первом же разборе клеймов клиента, когда к вам придут и скажут: "Вы лежали 20 часов в этом месяце, давайте скидку 90% по контракту". А вы будете открывать и закрывать рот, думая "Как 20... По нашим отчётам 4 часа..." Дело в том, что ваш клиент может быть поступает так даже не со зла. Просто в дни инцидентов он не понимает масштаб проблемы, относит к нему все техничские работы на вашей стороне и даже не пытается пользоваться сервисом. А ещё есть и злые ребята, которые запишут на ваш счёт все дополнительные работы на своей стороне, которые им пришлось делать после восстановления сервиса. Чтобы так не было - пишите постмортемы. Вы потратите меньше времени и нервов вдолгую, делая это упражнение регулярно.

Миф 3. Продакт отвечает только за написание SLA, а не за качество его соблюдения. Если делать так, то вы будете страдать. SLA - это состояние на пути к вашим целям: идеальной техподдержке, 100% аптайму и бесконечному счастью юзеров. Если реальность начинает отличаться от этого состояния в худшую сторону, то нужно идти и наводить суету. Только не стоит быть чаечкой: спокойно разберитесь, почему ваш SLA проседает. Если причин несколько - ранжируйте их. А вы что, думали тут обойдёмся без метрик? Как бы ни так. После обнаружения зон просадок - предпринимайте действия: дообучайте поддержку, ставьте технической команде цели на повышения стабильности и так далее.

Самое главное: не будьте равнодушным к продукту, клиентам и коллегам. SLA - важный документ, но не стоит возводить его значимость в абсолют. Проявляйте здравый смысл и помните, что вас окружает очень динамичная реальность, которую в SLA на 100% не удержать.

📝 А какие мифы об SLA поддержки знаете вы? Пишите в комментариях 👇

P.S. Не забывайте оставлять ❤️😃

Делитесь этим постом, давайте соберём больше мифов и развенчаем их 🤟

Автор: Штейн Александр