Комментарии 12
Странно выглядит решение предлагать пользователям ставить другой браузер или выполнять инструкции если решение должно быть на вашей стороне и решается установкой платного сертификата.
Платные сертификаты имеют такие-же корневые подписи которые устаревают.
Корневые подписи обновляются вместе со всей системой у пользователя.
Если у пользователя старая система и не обновляются корневые сертификаты то хоть с бубном пляши - проблема остается на стороне пользователя.
Да, верно, протух один из корневых сертификатов в цепочке сертификатов.
Для починки мы отключили его в списке доверенных корневых сертификатов, но осталась проблема, что у клиентов со старыми и необновляемыми ОС этот корневой сертификат остался в списке доверенных. Поэтому купили новый сертификат с другой цепочкой сертификации
Инцидент решается в два этапа:
- Подняться срочно любой ценой и хаками.
- Решить системно.
Решение с другим браузером временное, но помогало пользователям в момент обращения.
Пока мы реализовывали системное решение инцидента с покупкой сертификата.
Например, если недоступен личный кабинет одного ученика — это баг. Если же он недоступен для всех учеников или нескольких их тысяч — это точно инцидент-блокер. То есть нужна массовость проблемы или прерывание основного бизнес-процесса.
А если у одного пользователя приложение вылетает каждый день по 2-3 раза на разных устройствах в течение длительного времени, то это никак не эскалируется? Репорты с ошибкой исправно отправляются каждый раз, но похоже, что в никуда)
Пользователь занимается уже довольно давно и, в принципе, доволен школой и платформой, но технически пользоваться становится невозможно и он уже начинает тестировать альтернативные платформы) эти баги тоже станут потерей.
Пользователь обновил телефон и на телефоне приложение перестало вылетать, но на планшете вылетает, т.е. возможно не хватает памяти для стабильной работы.
Было бы неплохо научить хотя бы бота отвечать таким пользователям что то типа "В вашем устройстве мало памяти - обновите" ;)
Очень приятно слышать, что используете продукт, который делаем:)
Хотим прийти к тому, что любой баг будет заводиться в системе и клиент сможет видет по нему статус решения. Вы отправляли сообщение в чат поддерки пользователей в тех саппорт?
я отправляю каждый раз, когда приложение вылетает, стандартный отчет об ошибке.
Хотим прийти к тому, что любой баг будет заводиться в системе и клиент сможет видет по нему статус решения
Это нужно, но только не стандартной отбивкой из тикетной системы, иначе много спама по каждому движению заявки (уже у вас так было пару лет назад;), а потом тишина)
И еще вам не хватает userecho, там как раз можно пообсуждать конкретные фичи по улучшениям и рейтинговать их, а то некоторые, очевидные, улучшения не делаются совсем)
Для команд разработки есть SLA по инцидентам в 30 дней на решение задач
Спасибо за статью, интересно! А какой реальный на данный момент, укладываетесь ли в 30 дней и кто несёт ответственность за этот показатель?
Ответсвенность несет руководитель направления разработки, команды к который относиться инцидент (Dev Unit Lead). За метрикой в целом по всем направлениям разработки следить проджект-менеджер проекта инцидент-менеджмента, CTO и руководитель QA.
Когда вводили SLA медиана была 44 дня (не укладывались в 30 дней).
На данный момент +/- укладываемся и сразу видим, кто превышает SLA, чтобы повлиять.
Насчёт реп ущербов:
Метрики репутационного ущерба в любом случае нужно определять исходя из понимания, что такое репутация для бизнеса
Тем не менее, можно начать с простых метрик: обращаемость, тональность в сми, соцсети и тп, запросы от регуляторов и другие
Продолжить можно более интересными подходами : исследовать влияние на бизнесовые метрики (например, retention, ltv, отток, виральность, cx и тп). И тут надо смотреть отдельно для багов и для инцидентов. Потому что незначительный бесячий баг может куда больше иметь реп ущерб, чем инцидент, за который мы облизали "попу клиента" извинениями, workaround'ами и плюшками.
Как мы теперь реагируем на аварии на проде (и пара примеров)