Мы еще не видели никаких аналогов Spanner с открытым исходным кодом, но я полагаю, что скоро они появятся.
25. «Ключи безопасности: Практические криптографические дополнительные факторы для современного Интернета» (Security Keys: Practical Cryptographic Second Factors for the Modern Web).
Ключи безопасности, такие как Yubi Key (18), стали самым безопасным вторым фактором аутентификации, и в этой статье от Google объясняются мотивы, которые привели к их созданию, а также проект, благодаря которому они работают.
Выдержка из аннотации:
Ключи безопасности – это устройства для второго шага аутентификации, которые защищают пользователей от фишинга и атак типа «человек посередине»[47]. Пользователи имеют при себе одно устройство и могут самостоятельно зарегистрировать его в любом онлайн-сервисе, поддерживающем протокол. Эти устройства просты в реализации и развертывании, легки в использовании, сохраняют конфиденциальность и защищены от злоумышленников. Мы внедрили поддержку ключей безопасности в веб-браузере Chrome и в онлайн-сервисах Google. Мы показываем, что ключи безопасности повышают как уровень безопасности, так и удовлетворенность пользователей. Анализируем двухлетнее развертывание, которое началось в Google и распространилось на наши веб-приложения, ориентированные на потребителя. Проект ключа безопасности был стандартизирован FIDO Alliance, организацией, в которую входят более 250 компаний, охватывающих всю отрасль. В настоящее время ключи безопасности применяются Google, Dropbox и Git Hub.
Эти ключи также удивительно дешевы! Закажите несколько штук и начните защищать свою жизнь уже через день или два.
26. «Beyond Corp: От разработки до развертывания в Google» (Beyond Corp: Design to Deployment at Google).
Эта публикация более подробная и основана на оригинальной статье о Beyond Corp (19), опубликованной в 2014 году. В ней автор анализирует еще два года мудрости, приобретенных при техническом переходе. Тем не менее, основные идеи остались довольно последовательными, и в самой статье Beyond Corp не так много нового. Если вы еще не читали оригинальную фантастическую статью, это не менее хорошая отправная точка:
Целью инициативы Google Beyond Corp является повышение нашей безопасности в отношении того, как сотрудники и устройства получают доступ к внутренним приложениям. В отличие от обычной модели защиты периметра, Beyond Corp не ограничивает доступ к службам и инструментам на основе физического местоположения пользователя или исходной сети. Вместо этого политика доступа основана на информации об устройстве, его состоянии и связанном с ним пользователе. Beyond Corp считает, что как внутренние, так и внешние сети полностью ненадежны. Он ограничивает доступ к приложениям, динамически утверждая и применяя уровни доступа.
Как это часто бывает, когда я читаю статьи о Google, у меня возникает вопрос, когда мы начнем видеть многоразовые, подключаемые версии с открытым исходным кодом, описанные в подобных публикациях.
27. «Доступность в глобально распределенных системах хранения данных» (Availability in Globally Distributed Storage Systems).
В этой статье исследуется, как думать о доступности в реплицируемых распределенных системах, и она является полезной отправной точкой для тех из нас, кто пытается определить правильный способ измерения времени безотказной работы для уровня хранения или для любой другой достаточно сложной системы.
Выдержка из аннотации:
Мы характеризуем свойства доступности облачных систем хранения данных на основе обширного годичного исследования основной инфраструктуры хранения данных Google и представляем статистические модели, которые позволяют глубже понять влияние различных вариантов проектирования, таких как стратегии размещения данных и репликации. С помощью этих моделей мы сравниваем доступность данных по различным параметрам системы с учетом реальных моделей отказов, наблюдаемых в нашей компании.
Интересен акцент на коррелированных сбоях, основанный на предпосылке, что пользователи распределенных систем сталкиваются с неисправностью только тогда, когда у нескольких компонентов возникают перекрывающиеся сбои. Еще одно ожидаемое, но обнадеживающее наблюдение заключается в том, что в масштабах Google (и с распределением ресурсов по стойкам и регионам) большинство сбоев происходит из-за настройки и проектирования системы, а не из-за базового оборудования.
Я также удивился, насколько простым было их определение доступности в этом случае:
Узел хранения становится недоступным, когда он не отвечает положительно на периодические запросы о проверке работоспособности, отправляемые нашей системой мониторинга. Узел остается недоступным до тех пор, пока он не станет отвечать или система хранения не реконструирует данные с других уцелевших узлов.
Часто обсуждения доступности становятся произвольно сложными («На самом деле должно быть так, что частота ответов превышает X, но с правильными результатами и в пределах нашего времени на обработку одного запроса!»). И обнадеживает то, что самые простые определения все еще применимы.
28. «Все еще все на одном сервере: Необходимость масштабирования» (Still All on One Server: Perforceat Scale).
По мере роста компании эффективность размещения кода становится одним из важнейших факторов общей производительности разработчиков (наряду с производительностью сборки и тестирования), но эта тема обсуждается нечасто. В этой статье от Google рассматривается их опыт масштабирования Perforce:
Google управляет самым загруженным сервером Perforce на планете и одним из крупнейших репозиториев в любой системе управления версиями. С этой точки зрения в статье рассматривается производительность серверов и другие проблемы масштаба, с отступлениями о том, где мы находимся, как мы сюда попали и как продолжаем оставаться на шаг впереди, чтобы обеспечить потребности наших пользователей.
Эта статья особенно впечатляет. Если учесть трудности, с которыми сталкиваются компании при масштабировании монорепозиторий Git (просто поговорите с любым бывшим сотрудником Twitter о военных историях).
29. «Крупномасштабный автоматизированный рефакторинг с использованием Clang MR» (Large-Scale Automated Refactoring Using Clang MR).
Большие кодовые базы, как правило, медленно устаревают, особенно в случае монорепозиториев, на которые полагаются сотни или тысячи различных команд, работающих над разными проектами.
В этой статье рассматривается одна из попыток Google сократить расходы на поддержание своего большого монорепозитория с помощью инструментов, которые позволяют легко переписывать абстрактные синтаксические деревья (англ. Abstract syntaxtrees, AST) по всей кодовой базе.
Выдержка из аннотации:
В статье мы описываем реальную реализацию системы для эффективного рефакторинга больших кодовых баз C++. Clang MR, представляющий собой комбинацию платформы компилятора Clang и параллельного процессора Map Reduce, позволяет разработчикам кода легко и правильно преобразовывать большие наборы кодов. Мы описываем мотивацию для создания такого инструмента, его реализацию, а затем представляем наш опыт его использования в недавнем обновлении API с кодовой базой Google C++.
Аналогичная работа выполняется с Pivot (22).
30. «Обновление исходного кода – это не рефакторинг» (Source Code Rejuvenationis not Refactoring).
В этой статье вводится концепция «обновления исходного кода», – однонаправленного процесса перехода к более чистым абстракциям по мере появления новых языковых функций и библиотек, что особенно применимо к обширным, старым кодовым базам.
Выдержка из аннотации:
В статье мы представляем понятие обновления исходного кода, автоматизированного перехода от устаревшего кода, и очень кратко упоминаем инструменты, которые используем для достижения этой цели. В то время как рефакторинг улучшает структурно неадекватный исходный код, его обновление использует расширенный программный язык и библиотечные возможности путем поиска и замены шаблонов кодирования. Они могут быть выражены с помощью программных абстракций более высокого уровня, с повышением уровня которых растут удобство обслуживания, безопасность и производительность программного обеспечения.
В статье Google о Clang MR есть несколько сильных отголосков этой работы (20).
31. «Поиск задолженности по сборке: Опыт управления технической задолженностью в Google» (Searching for Build Debt: Experiences Managing Technical Debtat Google).
Эта статья представляет собой интересное описание того, как выполнять крупномасштабные переходы в живых кодовых базах. Используя в качестве примера неработающие сборки, они разбивают свою стратегию на три ступени: автоматизация, упрощение выполнения правильных действий и усложнение выполнения неправильных действий.
Выдержка из аннотации:
С большой и быстро меняющейся кодовой базой разработчики программного обеспечения Google постоянно выплачивают проценты по различным формам технического долга. Инженеры Google также прилагают усилия, чтобы погасить этот долг, будь то с помощью специальных дней для исправления или специальных команд, известных как уборщики, культиваторы или эксперты по сносу. Мы описываем несколько связанных с этим усилий по измерению и погашению технического долга, обнаруженного в файлах сборки Google и связанном с ними мертвом коде. Устраняем задолженность, обнаруженную в спецификациях зависимости, недостижимых целях и ненужных флагах командной строки. Эти усилия часто выявляют другие формы технического долга, с которыми необходимо справиться в первую очередь.
32. «Отсутствие верного решения – суть и случайность в разработке программного обеспечения» (No Silver Bullet – Essence and Accident in Software Engineering).
Основополагающая статья автора «Мифического человеко-месяца», «Отсутствие верного решения», расширяет вопрос случайной и существенной сложности. Автор утверждает, что случайной сложности больше недостаточно, чтобы позволить ее индивидуальному снижению значительно повысить производительность инженера.