Тисячі людей одночасно намагаються купити квитки. В одного сайт відкривається без проблем, у другого виникає затримка, а в третього сторінка перестає завантажуватися. Сервіс залишається тим самим, але один збій призводить до різних наслідків для користувачів. Це показав збій CrowdStrike у липні 2024 року: помилка торкнулася 8,5 млн пристроїв із Windows, тобто менш ніж 1% пристроїв під керуванням цієї операційної системи, але наслідки поширилися на авіакомпанії, банки, ритейл та інші галузі. Зі зростанням аудиторії збільшується кількість поєднань пристроїв, мереж, зовнішніх сервісів і користувацьких сценаріїв, які доводиться враховувати.
Про те, чому один і той самий сервіс може працювати по-різному для різних користувачів і як компанії реагують на подібні проблеми, розповів Федір Плотніков, Principal DevOps & Cloud Infrastructure Leader із понад 20 роками досвіду в IT.
Що змінюється, коли одним сервісом одночасно користуються мільйони людей?
Зі зростанням аудиторії збільшується кількість запитів. Разом із нею зростає кількість пристроїв, мереж, інтеграцій і залежностей між сервісами. Користувачі шукають товари, оформлюють замовлення, оплачують покупки та підключаються до сервісу через різні мережі й пристрої.
Для користувача інтернет-магазин виглядає як один сайт, але на кожному етапі працюють окремі сервіси. Проблема з рекомендаціями може залишитися непомітною, тоді як збій платіжної системи безпосередньо вплине на можливість завершити покупку.
Під час роботи в Globant я стикався з такою складністю в AWS-інфраструктурі для регульованого банківського сектору. Вона була розподілена між більш ніж 10 акаунтами. Зміна в одному середовищі могла вплинути на пов'язані системи, тому її доводилося оцінювати з урахуванням ланцюжка залежностей.
Чому один і той самий збій по-різному впливає на користувачів?
Усе залежить від функції компонента. Для одного користувача це може бути невелика затримка, для іншого - недоступність окремої функції, а в деяких випадках сервіс може повністю перестати відповідати.
Тому під час розбору збою важливо дивитися не лише на технічну причину, а й на те, які користувацькі сценарії зачеплено. Для технічної команди це один інцидент, але для клієнтів наслідки будуть різними.
Чому зі зростанням аудиторії стає складніше заздалегідь передбачити всі варіанти роботи сервісу?
Складність виникає, коли кілька факторів збігаються: система працює під великим навантаженням, зовнішня служба відповідає із затримкою, а користувач підключається через мережу зі збоями.
У проєктах із розподіленою інфраструктурою я стикався із ситуаціями, коли саме поєднання таких умов призводило до збою. Кожен фактор окремо команда вже перевіряла, але проблема проявлялася лише разом.
Описати всі варіанти заздалегідь складно. Тому команда виділяє умови, які впливають на ключові сценарії, і перевіряє їх окремо.
ЧИТАЙТЕ ТАКОЖ: YouTube Premium Lite запустили в Україні: скільки коштує дивитися відео без реклами
Чому 99,99% доступності не завжди означає, що сервіс надійний для клієнта?
Сервіс може бути доступним, але окрема операція при цьому не працювати.
Уявімо банківський застосунок, який відкривається, показує баланс і приймає запит на переказ. Якщо переказ виконується із затримкою, застосунок формально продовжує працювати, але користувач не отримує результат вчасно.
Тому дивитися лише на доступність недостатньо. Важливіше зрозуміти, чи виконує користувач потрібну дію, скільки часу вона займає і де виникає затримка.
Що робити, якщо зберегти роботу всіх функцій під час збою неможливо?
Функції мають різний пріоритет для користувача та бізнесу. Другорядну функцію під час збою можна тимчасово вимкнути, щоб зберегти роботу ключових операцій.
У таких ситуаціях важливо розуміти, які компоненти справді критичні для роботи сервісу, а де допустимі обмеження або оптимізація. Під час роботи над інфраструктурою глобальної платформи для VPN і мобільної безпеки в AdTranquility мені також доводилося оцінювати потребу в ресурсах та їхню доступність і з урахуванням цього розставляти пріоритети між деякими функціями. У результаті нам вдалося оптимізувати інфраструктуру та знизити витрати на 40%.
Такий підхід дозволяє зберігати ресурси для справді критичних операцій і не намагатися підтримувати всі компоненти на одному рівні.
Чи можна заздалегідь перевірити всі сценарії, у яких опиниться користувач?
Перевірити всі поєднання умов надзвичайно складно. Тому частину збоїв і затримок відтворюють спеціально.
Наприклад, команда може штучно створити затримку у зовнішньому сервісі або перевірити роботу системи за нестабільного з'єднання, щоб зрозуміти, як це вплине на інші компоненти.
Коли таких сценаріїв стає надто багато, частину процесів доводиться автоматизувати. Наприклад, можна створити платформу, яка відповідатиме за оновлення інфраструктури. За такого підходу навіть системи з понад 5000 серверів, як це було в нашій роботі із Syniverse, можна оновлювати без значного збільшення обсягу ручної роботи. У цьому випадку це дозволило скоротити час розгортання змін у 8 разів, а кількість інцидентів після розгортання - на 80%.
Як зрозуміти, які відмінності в роботі сервісу вже потребують втручання?
Умови підключення та використання можуть відрізнятися. У таких випадках насамперед варто дивитися на те, що змінюється для користувача. Якщо невелика затримка не впливає на ключовий сценарій, вона може залишатися прийнятною. Якщо через неї частина аудиторії не може завершити оплату або іншу важливу операцію, проблему вже варто розбирати.
У високонавантажених системах я стикався із ситуаціями, які проявлялися лише у частини аудиторії: у конкретному регіоні, на певному типі підключення або за певної послідовності дій. Такі відмінності допомагали локалізувати проблему.
Надійність сервісу не можна оцінювати лише за загальною доступністю. Потрібно дивитися на конкретні операції та на те, як їх виконують різні групи користувачів.
1 
24
Коментарі