Запуск будь-якої масштабованої розподіленої платформи вимагає відданості надійності, щоб клієнти мали те, що їм потрібно, коли їм це потрібно. Залежності можуть бути досить складними, особливо з такою великою платформою, як Roblox. Створення надійних сервісів означає, що, незалежно від складності та статусу залежностей, будь-яка дана послуга не буде перервана (тобто сильно доступний), працюватиме без помилок (тобто high якість) і без помилок (тобто відмовостійкість).
Чому надійність має значення
Наша команда Account Identity прагне досягти більш високої надійності, оскільки створені нами служби відповідності є основними компонентами платформи. Порушення відповідності може мати серйозні наслідки. Вартість блокування природної роботи Roblox дуже висока, з додатковими ресурсами, необхідними для відновлення після збою та ослабленого взаємодії з користувачем.
Типовий підхід до надійності зосереджується насамперед на доступності, але в деяких випадках терміни змішуються і використовуються неправильно. Більшість вимірювань доступності просто оцінюють, чи запущені та запущені служби, в той час як такі аспекти, як толерантність та узгодженість розділів, іноді забуваються або неправильно розуміються.
Відповідно до теореми CAP, будь-яка розподілена система може гарантувати лише два з цих трьох аспектів, тому наші служби відповідності приносять у жертву певну послідовність, щоб бути високодоступною та толерантною до розділів. Тим не менш, наші послуги мало пожертвували і знайшли механізми для досягнення хорошої узгодженості з розумними архітектурними змінами, описаними нижче.
Процес досягнення більш високої надійності є ітеративним, з безперервною роботою точного узгодження вимірювань, щоб запобігти, знайти, виявити та виправити дефекти до того, як виникнуть інциденти. Наша команда визначила цінність таких практик:
- Правильне вимірювання – Побудуйте повну спостережливість щодо того, як якість надається клієнтам і як залежності забезпечують якість для нас.
- Проактивне очікування – Виконуйте такі дії, як архітектурні огляди та оцінки ризику залежності.
- Розставте пріоритети для корекції – Звертайте більше уваги на вирішення звітів про інциденти для служби та залежностей, які пов’язані з нашою службою.
Побудова більш високої надійності вимагає культури якості. Наша команда вже інвестувала в розробку, орієнтовану на продуктивність, і знає, що успіх процесу залежить від його впровадження. Команда повністю застосувала цей процес і застосувала його як стандарт. На наступній схемі висвітлені компоненти процесу:
Сила правильного вимірювання
Перш ніж глибше зануритися в показники, необхідно зробити коротке роз’яснення щодо вимірювань рівня обслуговування.
- SLO (Service Level Objective) — це ціль надійності, до якої прагне наша команда (тобто 99.999%).
- SLI (Service Level Indicator) — це досягнута надійність за певний час (тобто 99.975% у лютому минулого року).
- SLA (Service Level Agreement) – це надійність, яку погодилися забезпечити наші споживачі в певний період часу (тобто 99.99% на тиждень).
SLI має відображати доступність (немає необроблених або відсутніх відповідей), стійкість до збоїв (немає помилок обслуговування) та досягнуту якість (без неочікуваних помилок). Тому ми визначили наш SLI як «коефіцієнт успіху» успішних відповідей у порівнянні з загальною кількістю запитів, надісланих до служби. Успішними відповідями є ті запити, які були відправлені вчасно та у формі, тобто ні підключення, обслуговування або неочікувані помилки.
Цей SLI або коефіцієнт успіху збирається з точки зору споживачів (тобто клієнтів). Намір полягає в тому, щоб виміряти фактичний наскрізний досвід, наданий нашим споживачам, щоб ми були впевнені в дотриманні SLA. Якщо цього не зробити, це створить помилкове відчуття надійності, яке ігнорує всі проблеми з інфраструктурою для зв’язку з нашими клієнтами. Подібно до споживчого SLI, ми збираємо SLI залежностей, щоб відстежувати будь-який потенційний ризик. На практиці всі угоди про рівень обслуговування залежностей мають бути узгоджені з угодою про рівень обслуговування, і з ними існує пряма залежність. Невдача одного означає невдачу всіх. Ми також відстежуємо та повідомляємо показники самої служби (тобто сервера), але це не практичне джерело високої надійності.
На додаток до SLI, кожна збірка збирає показники якості, які повідомляється нашим робочим процесом CI. Ця практика допомагає посилити контроль якості (тобто, охоплення коду) і звітувати про інші важливі показники, такі як відповідність стандартам кодування та статичний аналіз коду. Раніше ця тема розглядалася в іншій статті, Створення мікросервісів на основі продуктивності. Якщо говорити про надійність, то старанне дотримання якості є плюсом, тому що чим більше ми вкладаємо в досягнення відмінних результатів, тим більше ми впевнені, що система не підведе під час несприятливих умов.
Наша команда має дві панелі інструментів. One забезпечує повну видимість як Consumers SLI, так і Dependencies SLI. Другий показує всі показники якості. Ми працюємо над об’єднанням усього в єдину інформаційну панель, щоб усі важливі для нас аспекти були консолідовані та готові до звітів у будь-який певний період часу.
Передбачити невдачу
справи Архітектурні огляди є фундаментальною частиною надійності. По-перше, ми визначаємо, чи є надлишковість і чи є у служби засоби для виживання, коли залежності зникають. Крім типових ідей реплікації, більшість наших служб застосовували вдосконалені методи подвійної гідратації кешу, подвійні стратегії відновлення (наприклад, локальні черги перемикання збоїв) або стратегії втрати даних (наприклад, підтримка транзакцій). Ці теми досить обширні, щоб виправдати ще одну запис у блозі, але в кінцевому підсумку найкраща рекомендація — реалізувати ідеї, які враховують сценарії катастрофи та мінімізують будь-які втрати продуктивності.
Ще один важливий аспект, який слід передбачити, — це все, що може покращити підключення. Це означає агресивне ставлення до низьких затримок для клієнтів і підготовку їх до дуже високого трафіку за допомогою методів контролю кешу, допоміжних колясок і ефективних політик для тайм-аутів, вимикачів і повторних спроб. Ці методи застосовуються до будь-якого клієнта, включаючи кеші, сховища, черги та взаємозалежні клієнти в HTTP і gRPC. Це також означає покращення здорових сигналів від служб і розуміння того, що перевірки стану відіграють важливу роль у всій оркестрації контейнерів. Більшість наших служб краще сигналізують про погіршення якості в рамках зворотного зв’язку з перевіркою стану та перевіряють працездатність усіх критичних компонентів, перш ніж надсилати працездатні сигнали.
Розбивка служб на критичні та некритичні частини виявилася корисною для зосередження на функціональності, яка має найбільше значення. Раніше ми мали кінцеві точки лише адміністратора в тому ж сервісі, і хоча вони не використовувалися часто, вони впливали на загальні показники затримки. Переміщення їх до власної служби вплинуло на кожен показник у позитивному напрямку.
Оцінка ризику залежності є важливим інструментом для виявлення потенційних проблем із залежностями. Це означає, що ми визначаємо залежності з низьким рівнем SLI і просимо вирівняти SLA. Ці залежності потребують особливої уваги під час кроків інтеграції, тому ми приділяємо додатковий час для порівняння та перевірки, чи нові залежності достатньо зрілі для наших планів. Хорошим прикладом є раннє впровадження Roblox Storage-as-a-Service. Інтеграція з цією службою вимагала подання заявок про помилки та періодичних зустрічей із синхронізацією для передачі результатів і зворотного зв’язку. У всій цій роботі використовується тег «надійність», щоб ми могли швидко визначити його джерело та пріоритети. Характеризація відбувалася часто, поки ми не були впевнені, що нова залежність готова для нас. Ця додаткова робота допомогла підтягнути залежність до необхідного рівня надійності, який ми очікуємо, щоб досягти спільної мети.
Доведіть структуру до хаосу
Ніколи не бажано мати інциденти. Але коли вони трапляються, з’являється значуща інформація, яку потрібно збирати та вчитися, щоб бути більш надійним. Наша команда має командний звіт про інцидент, який створюється понад типовий звіт для всієї компанії, тому ми зосереджуємось на всіх інцидентах незалежно від масштабу їх впливу. Ми називаємо першопричину та визначаємо пріоритети всіх робіт, щоб усунути її в майбутньому. У рамках цього звіту ми запрошуємо інші команди, щоб виправити інциденти залежностей з високим пріоритетом, надати відповідне рішення, ретроспективу та шукати закономірності, які можуть стосуватися нас.
Команда виробляє а Щомісячний звіт про надійність за послугу що включає всі SLI, які пояснюються тут, будь-які квитки, які ми відкрили через надійність, і будь-які можливі інциденти, пов’язані з послугою. Ми настільки звикли генерувати ці звіти, що наступним природним кроком є автоматизація їх вилучення. Виконувати цю періодичну діяльність важливо, і це нагадування про те, що надійність постійно відстежується та враховується в нашому розвитку.
Наші інструменти включають спеціальні показники та покращені сповіщення, щоб ми якнайшвидше надсилали сторінку, коли виникають відомі та очікувані проблеми. Усі сповіщення, у тому числі помилкові, переглядаються щотижня. На цьому етапі важливо відшліфувати всю документацію, щоб наші споживачі знали, чого очікувати, коли спрацьовують сповіщення та коли виникають помилки, а потім усі знають, що робити (наприклад, посібники та інструкції з інтеграції узгоджуються та часто оновлюються).
В кінцевому рахунку, Прийняття якості в нашій культурі є найважливішим і вирішальним фактором для досягнення вищої надійності. Ми можемо спостерігати, як ці практики, застосовувані до нашої повсякденної роботи, вже приносять свої плоди. Наша команда одержима надійністю, і це наше найважливіше досягнення. Ми підвищили нашу обізнаність про вплив потенційних дефектів і про те, коли вони можуть бути введені. Служби, які впроваджували ці методи, постійно досягли своїх SLO та SLA. Звіти про надійність, які допомагають нам відстежувати всю роботу, яку ми виконували, є свідченням роботи, яку виконала наша команда, і є безцінним уроком для інформування та впливу на інші команди. Саме так культура надійності торкається всіх компонентів нашої платформи.
Шлях до підвищення надійності нелегкий, але він необхідний, якщо ви хочете побудувати надійну платформу, яка по-новому уявляє, як люди збираються разом.
Альберто — головний інженер-програміст у команді ідентифікації облікового запису в Roblox. Він тривалий час працює в ігровій індустрії, має кредити на багатьох іграх AAA та платформах соціальних мереж з сильним акцентом на високомасштабовані архітектури. Тепер він допомагає Roblox досягти зростання та зрілості, застосовуючи найкращі методи розвитку.
Повідомлення Забезпечення надійності великомасштабної платформи вперше з'явився на Блог Roblox.
- "
- a
- МЕНЮ
- рахунки
- Achieve
- досягнутий
- діяльності
- діяльність
- доповнення
- Додатковий
- Прийняття
- несприятливий
- Угода
- ВСІ
- вже
- аналіз
- Інший
- передбачити
- прикладної
- Застосовувати
- Застосування
- підхід
- архітектурний
- навколо
- стаття
- асоційований
- увагу
- автоматизувати
- наявність
- доступний
- обізнаність
- оскільки
- перед тим
- буття
- нижче
- еталонний тест
- КРАЩЕ
- За
- Блог
- приносити
- Помилка
- будувати
- call
- який
- випадків
- Викликати
- Перевірки
- клієнтів
- код
- Кодування
- збирати
- Приходити
- commit
- зобов'язання
- вчинено
- загальний
- спілкуватися
- порівняний
- дотримання
- Компоненти
- Умови
- довіра
- впевнений
- З'єднуватися
- зв'язок
- Вважати
- постійно
- споживач
- Споживачі
- Контейнер
- Core
- може
- створювати
- створений
- кредити
- критичний
- культура
- виготовлений на замовлення
- Клієнти
- приладова панель
- дані
- глибше
- поставляється
- надання
- постачає
- запити
- залежить
- Визначати
- розробка
- прямий
- катастрофа
- розподілений
- вниз
- керований
- під час
- Рано
- кінець в кінець
- інженер
- особливо
- все
- все
- приклад
- відмінно
- очікувати
- очікуваний
- досвід
- обширний
- Провал
- зворотний зв'язок
- Перший
- виправляти
- Сфокусувати
- фокусується
- фокусування
- стежити
- після
- форма
- знайдений
- від
- Повний
- функціональний
- функціональність
- фундаментальний
- майбутнє
- гра
- Гейтс
- породжує
- мета
- добре
- Зростання
- гарантувати
- керівні вказівки
- траплятися
- сталося
- здоров'я
- допомога
- допомогу
- допомагає
- тут
- Високий
- вище
- основний момент
- дуже
- Як
- HTTPS
- ідеї
- ідентифікувати
- Особистість
- Impact
- здійснювати
- реалізовані
- важливо
- удосконалювати
- поліпшений
- поліпшення
- В інших
- includes
- У тому числі
- збільшений
- промисловість
- вплив
- інформація
- Інфраструктура
- інтеграція
- Намір
- інвестування
- IT
- сам
- Знати
- відомий
- УЧИТЬСЯ
- рівень
- трохи
- місцевий
- Довго
- подивитися
- зробити
- узгодження
- Питання
- зрілий
- зрілість
- сенс
- значущим
- засоби
- вимір
- Медіа
- зустрічі
- Метрика
- змішаний
- більше
- найбільш
- переміщення
- Природний
- необхідно
- проте
- працювати
- операція
- оркестровка
- порядок
- Інше
- загальний
- власний
- частина
- Люди
- продуктивність
- частин
- плани
- платформа
- Платформи
- Play
- точка
- Точка зору
- Політика
- позитивний
- це можливо
- потенціал
- влада
- практика
- представити
- Головний
- пріоритет
- проблеми
- процес
- якість
- Швидко
- швидко
- досягати
- розумний
- Відновлювати
- відновлення
- відображати
- про
- надійний
- звітом
- Звіти
- запитів
- вимагається
- ресурси
- Відгуки
- Risk
- дорога
- Roblox
- Роль
- корінь
- біг
- то ж
- масштабовані
- шкала
- сенс
- обслуговування
- Послуги
- аналогічний
- з
- один
- So
- соціальна
- соціальні медіа
- соціальні медіа-платформи
- Софтвер
- Інженер-програміст
- деякі
- спеціальний
- стояти
- standard
- Статус
- магазинів
- стратегії
- сильний
- успіх
- успішний
- підтримка
- система
- говорити
- команда
- методи
- terms
- тест
- Команда
- отже
- три
- квитки
- час
- терміни
- разом
- терпимість
- інструмент
- тема
- теми
- трек
- трафік
- розуміння
- us
- значення
- перевірити
- вид
- видимість
- week
- Що
- Чи
- в той час як
- без
- Work
- робочий
- б