Поиск неизвестных

Экосистемой продуктов Meta ежедневно пользуются миллиарды людей — как для социальных контактов, так и для работы. Эти миллиарды пользователей также рассчитывают, что мы будем постоянно без задержек улучшать наши продукты добавлять в них новые функции. Мы ежедневно вносим в код тысячи изменений, чтобы не разочаровать их.

Постоянный выпуск множества усовершенствований иногда может снижать работоспособность наших приложений и, соответственно, удобство их использования. В компании Meta имеется множество сложных инструментов, цель которых — исключить внесение изменений с ошибками. Они отслеживают различные сигналы от продуктов и выявляют ухудшения до выпуска соответствующих приложений. Такие сигналы относятся к трем областям: производительность, надежность (функциональная и системная) и эффективность. Для их обозначения применяется аббревиатура PRE (от англ. Performance, Reliability и Efficiency). Профилактика неудачных изменений начинается со сбора наблюдаемых и аналитических признаков на этапе написания кода разработчиками. Кроме того, средства наблюдения и мониторинга собирают данные по результатам внутреннего использования продуктов до их выпуска в рабочую среду. Для тестирования продуктов в такой предпроизводственной среде применяются как ручные, так и автоматизированные инструменты обеспечения качества.

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

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

Компания Meta вложила немалые средства в целый ряд программ и систем обеспечения надежности, повышающих оперативность реагирования в масштабе, чтобы как можно скорее, иногда в течение дня, решать возникающие у пользователей проблемы.

Сигналы могут поступать как от широкой публики (частных лиц, компаний, групп и т. д.), так и от внутренних пользователей. Мы внимательно анализируем сигналы от внутренних пользователей, чтобы исключить внедрение нежелательных изменений в рабочую версию продукта. Обратите внимание, что сигналы являются агрегированными, то есть, например, указывают на количество ошибок на миллион пользователей. Сигналы также могут поступать из инструментов и сценариев автоматизированного тестирования, средств разработки (мы предупреждаем разработчиков об изменениях, которые могут вызывать проблемы на этапе выполнения), системных журналов и множества других источников. У нас также есть инструменты, которые используют эти сигналы, чтобы быстро выявлять и устранять причины.

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

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

В следующем разделе мы подробнее обсудим, как с уверенностью обнаружить факт ухудшения и отреагировать на него.

Превращение неизвестных факторов в известные и их квантификация

Говоря о неизвестных факторах, мы имеем в виду ошибки, с которыми сталкивается пользователь или система. Узнать о возможной ошибке можно из разных источников.

• Синтетическое тестирование работоспособности наших приложений и отдельных продуктов в рамках этих приложений.
• Внутренние пользователи, которые проводят тестирование в поиске ошибок. Это могут быть специальные группы тестировщиков или более широкая база пользователей Meta.
• Внешние пользователи, столкнувшиеся с проблемой и сообщившие о ней с помощью соответствующего диалога в нашем приложении.

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

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

Кроме того, ухудшения могут относиться к разным категориям: например, это может быть ошибка в коде, спам или какое-то другое нарушение правил в отношении контента. Наше внимание обращено главным образом на первую категорию, и мы стараемся устранять недоработки кода, связанные с пользовательским опытом взаимодействия. Как этого добиться, если пользователи сообщают о тысячах проблем?

Формирование сигналов и статистики

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

Затем мы собираем дополнительные сигналы, которые могут указывать на тип возникшего ухудшения. Они дают представление о симптомах ухудшения и генерируются алгоритмами машинного обучения, настроенными для конкретных продуктов Meta. Алгоритмы анализируют жалобы пользователей, чтобы определить причину ухудшения и, соответственно, подобрать оптимальную команду специалистов для ее устранения, развертывания исправлений в коде или принятия других мер.

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

Сочетание сигналов позволяет нам выявлять ухудшения и направлять сведения о них командам соответствующих продуктов, которые должны оперативно устранить проблему и привести опыт взаимодействия в соответствие с пользовательскими ожиданиями.

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

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

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

Переход к анализу отдельных аспектов продуктов

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

Для эффективного масштабирования должно выполняться несколько условий:

1. Мы должны полностью охватить и правильно классифицировать все существующие аспекты продуктов.
2. Мы должны уменьшать потенциальную область возникновения ухудшений для существующих продуктов (что означает профилактику).
3. Мы должны распространять свои алгоритмы на новые аспекты наших продуктов.

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

Не только поиск ошибок

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

Профилактика требует ответа на следующие вопросы:

1. Как мы учимся на примере предыдущих ухудшений?
2. Какие меры защиты следует принять, чтобы избежать повторения этих ухудшений?
3. Как добиться того, чтобы потенциальная область возникновения ухудшений со временем уменьшалась?

Как уже говорилось, мы обобщаем информацию о предыдущих ухудшениях, и на ее основании принимаем следующие меры:

1. Добавляем в код маркеры для заблаговременного (до выпуска рабочей версии) оповещения о том, что то или иное изменение является нежелательным.
2. Расширяем охват тестов на различных уровнях в поиске подобных ухудшений.
3. Вносим изменения непосредственно в продукт для устранения возникших проблем.

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

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

В конечном итоге пользовательский опыт взаимодействия должен постоянно улучшаться в плане как функциональности, так и удобства.

Эта статья была написана совместно с Биджаном Марджаном (Bijan Marjan), менеджером по техническим программам Meta.