Lessons from a Hyperscaler • Casey Rosenthal • GOTO 2024

Интересный доклад от Casey Rosenthal, автора книги "Chaos Engineering", в котором он рассказывает о тех уроках, что были получены от работы в компаниях-гиперскейлерах, где hyperscale это

Hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system. Сам автор работал в компании Netflix и был изначально в traffic team, которая отвечала за то, чтобы Netflix работал для пользователей. А в комплексных системах возникает такой уровень сложности, который не помещается ни в одну голову. Для того, чтобы бороться с этой сложностью в Netflix придумали Chaos Monkey, который рандомно отключает машинки с частями системы. Это помогает инженерам искать системные недостатки и принимать решения для повышения надежности системы. Дальше автор приводит конкретный пример с двумя микросервисами, один из которых stateful и хранит данные в persistent DB, а также у него есть кеш в Redis. А дальше что-то идет не так со stateful сервисом и вся система деградирует:) Суть примера в том, что в комплексных системах возможны пробелмы, несмотря на то, что все компоненты соответствуют спецификациям.

Автор говорит про 4 модели, что помогают гиперскейлерам бороться со сложностью:

• Observability (not metrics) - обеспечение наблюдаемости системы, просто метрик для этого не достаточно
• DevUX (platfoorm engineering) - создание платформенных команд, что делают dev2dev продукты, что снижают когнитивную сложность (можно почитать мой разбор "State of Platform Engineering Report 2023 от Puppet")
• Experimentation over testing - экспериментирование, а не тестирование. Суть в том, что эксперименты помогают узнать что-то новое о системе, а тестирование - это проверка того, что система соответствует нашим ожиданиям
• Low bureaucracy - низкий уровень бюрократии, где у инженеров достаточно полномочий на то, чтобы делать свою работу без кучи согласований

Автор рассказывает про 4 экономических столпа комлексности

• States - ограничение количества состояний системы. Например, Ford Model T, где потребитель мог купить машину любого цвета, если этот цвет черный:) Но сейчас это ушло в прошлое и мы ценим вариативность и персонализацию продуктов под конкретного клиента
• Relationships - здесь у нас тоже все идет по нарастающей - добавляются новые связи, новые уровни абстракции, динамическое поведение систем становится все сложнее
• Environment - окружающая среда тоже не отличается предсказуемостью и мало кто из компаний может на нее как-то значимо повлиять в свою пользу (если вы не Amazon или Google)
• Reversability - а вот тут разработка софта сильно выделяется на общем фоне. Мы можем выбрать для себя фокус на этом и получить возможность откатывать изменения. Тут нам в помощь CI/CD, a/b тестирование гипотез, ... Но для того, чтобы это все работало нам требуется observability.

И автор рассказывает про подходы: observability 1.0 и observability 2.0, где observability 1.0 это • Metrics (метрики) • Unstructured logs (неструктурированные логи) • Structure logs (структурированные логи) Недостатком observability 1.0 является убывающая полезность и нарастающие затраты на создание и хранение логов и метрик. Суть в том, что по мере роста системы, добавления компонентов, инцидентов, логов будет становиться все больше и сложно будет искать в них нужную информацию, а также это все будет занимать все больше места.

В качестве ответа автор говорит про observability 2.0, который обладает следующими возможностями:

• Это подход с high cardinality / high dimenions и в одном месте, который является единым источником истины
• Из этого хранилища можно получать показатели, логи, структурированные и неструктурированные данные
• А кроме того, это не уменьшает эффективность разработчиков, а скорее увеличивает за счет использования одного решения

У нас в Tinkoff таким единым источником истины является Sage, наша obserbility платформа, которая является стандартом де-факто для всех в компании.

#Devops #PlatformEngineering #Management #SoftwareDevelopment #Software #SRE