PMM ( платформа Merdeka Mengajar ) — это суперприложение для учителей, созданное GovTech Edu. Он имеет множество функций для поддержки учебного процесса учителей и повышения качества. На момент написания у нас было более 2 миллионов загрузок, сотни тысяч DAU, крошечный размер загрузки (4 МБ), рейтинг 4,7+ в Play Store из более чем 60 000 отзывов и 99,97 % ежедневной безотказной работы для пользователей. У нас есть 11 инженеров-андроидов, которые работают удаленно из разных городов по всей стране. Подробнее о ПММ можно прочитать здесь .

Все эти хорошие числа — просто «числа»; настоящий вопрос в том, как мы это делаем? В этом посте мы хотим поделиться некоторыми советами/практиками, которые мы использовали в GovTech Edu, которые позволяют нам поддерживать это приложение на самом высоком уровне, особенно для пользователей без сбоев. Безотказная работа — один из важнейших показателей производительности, показывающий, насколько стабильно работают ваши приложения. Уровень безотказной работы 99,97% впечатляет для супер-приложений с более чем 1,3 миллиона MAU, особенно если учесть, что стандартный эталон для технологической отрасли составляет около 99,00%. Ладно, хватит болтовни☺️ Давайте перейдем к первой практике ниже.

Протестируйте свой код

Что ж, это звучит банально (и не так просто), но это правда. Ну, в любом случае это может косвенно коррелировать. Когда вы тестируете свой код, вы должны переосмыслить логику и не допустить глупой ошибки (которая может вызвать сбой). Наши инженеры в GovTech Edu серьезно обеспокоены этим. Мы согласились строго написать юнит-тест, e2e-тест и UI-тест (тестовая пирамида). У нас есть конвейер, чтобы проверить, когда покрытие упало, и мы также установили определенное количество в качестве минимального покрытия. Команда платформы QA поддерживает эту экосистему при создании инструментов и конвейеров тестирования.

Переключить все

По мере того, как мы растем и разрабатываем все больше и больше функций, иногда это просто ломается на производстве. Независимо от того, сколько тестов вы выполнили для своих кодов, дерьмо случается. Вы называете это, независимо от того, вызвано ли это неисправным сервером или полезной нагрузкой уведомления. Вот почему мы всегда ставим переключатель почти в наши функции. Мобильные приложения имеют проблему со скоростью принятия (в отличие от Интернета). Вы должны сделать больше, чем сделать обновление и надеяться, что все установят последнюю версию. Всякий раз, когда мы обнаруживаем необычную частоту сбоев в определенной функции, мы отключаем ее, пытаясь решить проблему. В большинстве случаев для него не требуется никакого нового выпуска, поскольку он разрешается на внутренней стороне, поэтому мы можем включить его после исправленного развертывания. Удаленная конфигурация Firebase — это хороший бесплатный инструмент переключения.

Приложения по вызову

Помните выражение: «Когда все ответственны, никто не несет ответственности». Это правда, по крайней мере, для нашей команды GovTech Edu. Мы договорились каждую неделю выделять дежурного, который будет заниматься мониторингом, быстрым реагированием и выполнением любых других операций. Сначала мы думали, что в этом нет необходимости, так как приложения не выходят каждый день и даже не через неделю. Мы должны были заметить, что инициирующий фактор исходит не только от самих приложений, но также может быть внешним, таким как развертывание службы, изменения переключения и предоставление обновлений, напрямую влияющие на приложения.

Когда происходит сбой, дежурный по вызову первым откликается, решая стратегию исправления или обращаясь за помощью к другим. Дежурный тоже не робот; им нужны инструменты, чтобы сохранить его. У нас есть визуальное и общедоступное оповещение, размещенное в нашем слабом канале, поэтому оповещение будет быстро уведомлять по вызову. Мы используем простое оповещение Firebase со слабым веб-хуком. Мы знаем, что есть лучший вариант оповещения, например opsgenie, но для нашей команды этого вполне достаточно. Следующая стратегия заключается в настройке оповещения. Вы должны избегать превращения предупреждения в ложную тревогу, которую все в конечном итоге проигнорируют. То, как вы настраиваете оповещение, зависит от ваших приложений и команды: сколько у вас пользователей, какое у вас текущее среднее значение без сбоев, какой-либо недавний резкий сбой, которого вы боитесь. Подумайте об этом, обсудите это со всеми заинтересованными участниками, и вы найдете правильную мелодию.

Будьте разборчивы в выборе библиотеки.

Ошибка в библиотеке иногда неизбежна. Иногда вы думаете, что ваши коды идеальны, вы прошли тест, а потом вдруг происходит сбой в коде библиотеки. Мы сталкивались с этим много раз. Мы должны быть более осторожными в выборе того, какая библиотека лучше, чем другие. Итак, первым делом проверьте количество открытых вопросов. Если число относительно велико, мы должны предотвратить это. Затем используйте библиотеку kotlin вместо java. Мы обнаружили, что стабильность улучшилась после переноса библиотеки Java на версию kotlin. Найдите библиотеку с отличной репутацией, основываясь на количестве участников и последнем обновлении. Мы должны предотвращать библиотеки, которые не работают более 2-3 лет. Он потенциально не синхронизируется с последним обновлением ОС. Вы можете найти эти три критерия отдельно,

Стратегия развертывания

Нам удобно, что в магазине Google Play есть функция поэтапного развертывания. Мы настоятельно рекомендуем выпускать приложения с поэтапным внедрением. Это смертельно простая защитная процедура для предотвращения потенциальных крупных сбоев. Обычно мы начинаем развертывание ниже 10%. Почему этот номер? Потому что это лучшее число, чтобы получить ранний образец, не затрагивая слишком много пользователей. Через один или два дня после релиза мы можем увидеть тенденции сбоя. В этом состоянии вы должны ответить на следующие вопросы: Были ли обнаружены какие-либо новые сбои? Являются ли эти сбои потенциально широко распространенными? Должны ли мы выпустить исправление, чтобы исправить этот недавний сбой? Эти вопросы должны решаться совместно менеджерами, QA и инженерами. Компромисс всегда связан с более длительным временем выпуска, поэтому убедитесь, что ваше исправление того стоит. Вы хотите избежать исправления незначительного сбоя и пропуска целевого запуска,

Тестирование нескольких ОС и производителей устройств

Сталкивались ли вы с некоторыми ошибками или сбоями, которые происходят только на определенных устройствах или ОС? Я уверен, что у всех нас есть. Рекомендуется протестировать свои приложения на разных ОС и устройствах разных производителей. Мы можем провести дымовой тест на всех целевых ОС и выбрать 10 лучших моделей устройств на основе принятия пользователями. Он уделяет больше внимания «проблемной» модели устройства, которая обычно приводит к сбоям. Как только мы это сделали, это предотвратило большой сбой перед релизом продукта. Это станет более управляемым, как только мы сможем позволить себе ферму устройств. В тестовой лаборатории Firebase есть бесплатная, но ограниченная ферма устройств; Вы можете начать оттуда. В настоящее время также существует множество платных облачных ферм устройств с очень разумными ценами.

Добивайтесь этого четко через OKR

Наконец, вся ваша организация должна знать и поддерживать вашу команду для достижения этой цели. Одним из стандартных инструментов согласования командных целей является использование OKR. Подробнее об OKR можно прочитать здесь . Почему это важно? Потому что для достижения 99,9x % безотказной работы вам нужна помощь и поддержка других. Когда это включено в OKR, другие могут подумать, что это довольно серьезно. Они заметят вас, заметят вашу цель и начнут вам помогать. Это ускорит вашу ухабистую дорогу. Ваши OKR также должны развиваться. Сначала установите его на минимум, например, 99 % без сбоев в первом квартале, затем увеличьте его до 99,3 % во втором квартале и так далее, пока не поддержите его до максимально возможного уровня.