Публичное интервью по troubleshooting для SRE-инженеров

До начала инцидента участники разбирают систему: веб- и мобильный клиенты получают конфигурацию, затем пользователь входит, видит продукты и может перейти к платежам. Мобильная конфигурация проходит через CDN. По условию серверная телеметрия доступна, а клиентская ещё не внедрена. Такое ограничение определяет ход расследования: нельзя сразу открыть отчёт об ошибках приложения и увидеть причину.

Сигнал — снижение числа платежей примерно на десять процентов. Ошибки и время ответа платёжного сервиса не выросли. Салих разделяет поток по каналам и платформам: веб и iOS работают без заметных изменений, падение приходится на Android и затрагивает разные версии. Проверяются недавние релизы и изменения конфигурации. Уменьшение запросов на сервере здесь оказывается следствием проблемы раньше в пользовательском пути, а не доказательством сбоя самого платёжного сервиса.

В конфигурации продуктов появился новый элемент без поля позиции. На тестовом Android-устройстве воспроизводится пустой список продуктов. В финальном обсуждении уточняется различие клиентов: iOS не блокировал весь список из-за проблемного элемента, а Android реагировал иначе. Платёжная форма оставалась доступной, но пользователи, увидев пустой список, часто до неё не доходили. Поэтому бизнесовая метрика не указывала прямо на повреждённый экран.

Участники возвращают предыдущую конфигурацию и очищают CDN, однако приложение продолжает показывать пустой список: оно хранит конфигурацию до часа. Выход из учётной записи очищает кэш, но принудительно завершать все сеансы — отдельный компромисс с неудобством для незатронутых клиентов. Точно выделить пострадавших без клиентской телеметрии трудно. Обсуждаются ожидание, адресные инструкции и коммуникация с поддержкой; единственное универсальное действие для такой ситуации не объявляется.

Следующий шаг — разбор с хронологией, задержками диагностики, удачными действиями и задачами улучшения. Поиск человека, изменившего конфигурацию, не заменяет этот анализ. Отсутствовали удобная видимость конфигурационных изменений, телеметрия клиента и управляемое обновление его кэша. Наличие инструкции по очистке CDN, напротив, помогло быстрее выполнить часть восстановления и стало положительным наблюдением.

Возможные улучшения включают проверку конфигурации на разных платформах, согласованную обработку неполных данных, уведомления об изменениях и средства управления инцидентом в приложении. Участники связывают это с развитием мобильной надёжности: серверный откат не всегда возвращает работоспособность уже установленному клиенту. Для следующего случая нужны не только исправленный файл, но и понимание потоков данных, доступные диагностические сигналы и заранее предусмотренные действия восстановления.