Якщо ви будуєте розподілену систему, то ви це робите, щоб ваша система була більш надійною за централізовану систему, або щоб ваша система була швидшою за централізовану систему.
Для того, щоб аналізувати такі системи існує окреми вокабулярій, який я розгляну.
SLI, SLO, SLA
SLI (Service level indicator) - те, що ми вимірюємо. Це може бути час, коли окремий компонент програми запустився, коли вся програма запускається, час виконання запиту і тд.
SLO (Service level objective) - ціль до якої ми прагнемо у нашому SLI, певний показник часу виконання, відмовостійкості, або високої доступності. Наприклад ми хочемо, щоб у 99% користувач отримував відповідь швидше за 50мс.
Приклад із 99% доступності є найважливішим і я розглядатиму саме його.
SLA (Service level agreement) - SLO + наслідки, це гарантії сервісу, його цілі і дії, які сервіс прийматиме, якщо цілі не будуть досягнуті. SLA потрібний для репрезентації узгодженості клієнту між клієнтом та сервісом. Таким чином клієнт знатиме, що очікувати, якщо цілі сервісу не будуть досягнуті. Наприклад сервіс платитиме штрафи, або даватиме бенефіти клієнту, також SLA повинен передбачати, що робити на технічно-організаційному рівні, щоб більше не допустити провалу SLO.
Ці терміни необхідно розуміти і застосовувати, щоб витрачати ваш час тільки на речі, які важливі для користувача (SLA), таким чином вибудовується прозорість надійності між сервісом та користувачем. Ви надаєте певні обіцянки від яких залежитиме довіра від клієнта.
Як розуміти SLA?
Ви могли часто чути такий вид SLA: “Ми гарантуємо, що сервіс буде доступний (up-time) 99% часу“. Що це означає? Це означає, що сервіс буде досутпний 99% від секунди, від місяця, чи від року? Що взагалі означає “доступність”? Як часто перевіряється доступність сервісу? Зазвичай використовується місячний цикл, тобто 99% часу протягом місяця сервіс буде доступний.
Час недоступності не тільки означає час протягом якого ваш сервіс не можна використовувати, це також означає час необхідний сервісу для відновлення.
Якщо ваш сервіс доступний 99% протягом місяця, то є цілком логічна можливість, що один відсоток від цього часу він не буде доступний. Один відсоток кожен місяць, це 7 годин на місяць, тобто 3.5 дня на рік сервіс буде недоступний. Кожна секунда завдаватиме клієнту збитків. Ось чому ці дев’ятки важливі у ваших SLA.
Для порівняння:
Кількість дев’яток | Доступність | Недоступність/місяць |
|---|---|---|
1 | 90% | 3д |
2 | 99% | 7г |
3 | 99.9% | 43хв |
4 | 99.99% | 4хв |
5 | 99.999% | 25с (5хв/рік) |
Якщо ви використовуєте хмарні сервіси для того, щоб хостити ваші програми, то ви повинні розуміти SLA доступності цих хмарних сервісів. Наприклад Amazon EC2, Google GCE та Microsoft Azure гарантують 99.95% доступності по часу, тобто 22 хвилини недоступності на місяць. Варто зауважити, що ці сервіси також гарантують часову вибірку в одну хвилину. Це значить, якщо ваш сервіс буде недоступний 59с і доступний 1с, то це однаково вважатиметься за повну доступність. Сервіс зможе пропрацювати весь місяць приймаючу запити тільки одну секунду протягом інтервалу в хвилину і ви не зможете виставити жодних претензій цим корпораціям.
Що SLA означає для користувача?
Якщо провайдер каже, що він гарантує вам 99.999% доступності, то йому це дається, або бригадою пожежників, яка приїже, коли згорить черговий ноут і швидко все відновить, або складною і розподіленою системою.
Вам, усвідомлюючи, що є ще 0.001% недоступності, який на вас чекає, необхідно підготуватись також.
Для отримання високо SLA необхідно:
Декілька віртуальних машин, які використовують механізм балансування нагрузки, на випадок, якщо одна з машин відвалиться.
Віртуальні машини повинні знаходитись на різних нодах, щоб бути незалежними.
Автоматичний механізм відновлення, щоб поки інші ноди заберають нагрузку у минулої був час відновитись.
Моніторинг, інструменти як Grafana, ELK, щоб втерти ніс провайдеру, коли щось піде не по плану. Без доказів вони нічого не робитимуть.
Підготовленість до планових відключень. Провайдери попереджають користувача про можливі зміни на сервісі, коли ним не вийде користуватись. Швидше за все, вам доведеться мігрувати, або мати альтернативного провайдера наперед.
Автоматизована підготовка машини (Automated provisioning) - механізм, який дозволяє підтягнути іншу машину, коли виникають проблеми.
Контракт чи маркетинг?
Обоє. Як ви бачите, є певні хитрощі, які ховаються за сміливими словами про 99.95%. Зрештою, якщо ви проведете добре дослідження провайдера перед тим, як його вибирати, то це зробить ваш сон трішки міцнішим.
Встановлення SLO
Інженер повинен встановлювати цілі, він не займається бізнес частиною гарантій та не виплачує штрафи із своєї кишені (зазвичай), тому SLO сепарований від SLA.
Інженери, я теж, часто намагаються створити агресивний SLO, іноді через малий досвід, іноді через неповноцінне бачення картини, тому рекомендується спочатку вибирати менші цілі, а після їнього досягнеяння виважено йти до наступних.
Також важливо розуміти SLA ваших залежностей, інженери часто використовують якісь сервіси для розсилки листів, для генерації тексту, AI інструменти, вони всі також мають свій SLA, який треба враховувати вам, коли ви рахуватимете ваш SLA. Очевидно, ви не можете вибирати SLO вище, за SLA сервісу, який використовуєте.
Не треба враховувати у ваш SLO речі на якій ви не впливаєте, якщо компанія займається доставкою посилок, то ви не повинні враховувати час, який витрачається користувачем, щоб тикнути на кнопку “Замовити“ і не враховувати час, який витрачається, щод доставити посилку це зробить ваше життя спокійнішим.
Складання SLA
Якщо ви будуєте вашу систему використовуючи інші системи, то вам доведеться складати декілка SLA разом.
Ви розумієте, що ваша система не може бути більш надійною за ваші залежності, тому ймовірність падіння вашої системи завжди більша за ймовірність падіння залежностей:
Якщо у вас є репліки вашої системи і навіть механізм відновлення між репліками, то залежність ідеальної реплікованої системи буде наступною:
Для того, щоб це рівняння працювало необхідно, щоб падіння кожної репліки було незалежним і, щоб падіння репліки спричиняєтсья лише падінням залежності.
Ваша система ніколи не буде більш надійною за залежності, але може бути набагато гіршою (баги, проблеми в інфраструктурі, десь кафка відвалиться, десь мережа)
Дивлячись на ці обидва рівняння ви повинні розуміти наскільки важко робити надійні системи і, чому ван необхідно бути скромними у гарантіях SLA.
Матеріали
https://www.youtube.com/watch?v=LKpIirL8f-I
https://static.googleusercontent.com/media/sre.google/uk//static/pdf/SloAdoptionAndUsageInSre.pdf
