99,99% надеждност, но достъпността трябва да се преосмисли

Приложението и сервизното софтуер трябва да са винаги достъпни за потребителя. И да работят без проблеми. Това е в идеалния случай. Разбира се, всеки, който по някакъв начин е свързан с IT индустрията, ще каже, че 100% безпроблемна работа е невъзможна. А ако клиентът иска точно това? Разбира ли той колко всъщност струва такава стабилност?

По време на обсъждането на един от новите проекти в Emat EOOD it company за пореден път си спомнихме за статията The Calculus of Service Availability и за „Правилото на четирите деветки“ на Google – математически изчисленото и очакваното средно време за откриване на повреда, престой и възстановяване на услугата.

На пръв поглед нивото на Google е недостижимо за малък ИТ екип или стартъп и всичко това не се отнася за нас. Но същността не е в цифрите, а в подхода: как да мислим за надеждността и какво може да се подобри дори с ограничени сили. Затова днес ще говорим за идеала и за това как можем да се стремим към него.

„Почти винаги“ от Google: 52,56 минути престой годишно
В книгата „Site Reliability Engineering: Надеждност и безотказност като в Google“ се описва принципът на достъпност и работоспособност на конкретна услуга, която трябва да бъде „почти винаги“ в изправно състояние.

SLO (service-level objectives, цели на ниво обслужване) предвижда, че никой потребител няма да може да забележи разликата между 100% и 99,999% достъпност. Между потребителя и услугата има много уязвими звена, върху които разработчиците на услугата не могат да повлияят (лаптоп, домашен Wi-Fi, интернет доставчик, електропреносна мрежа и др.). И няма смисъл да се борим за проценти.

Google:

• Повечето услуги трябва да осигуряват 99,99% достъпност за потребителите.
• Допуска най-лошия сценарий и общ лимит на грешки за година — 0,01% от 525 600 минути в годината или 52,56 минути (365 дни).
• Лимитът, отреден за изключване на критични компоненти, е пет независими критични компонента с лимит 0,001% всеки = 0,005%; 0,005% от 525 600 минути в годината или 26 минути.
• Останалият лимит на грешки на услугата може да бъде 53-26=27 минути.
• Всеки критичен компонент на системата трябва да бъде по-надежден от цялата услуга като цяло.
• Услугата не може да бъде по-стабилна от сумата на най-слабите си звена.

Идеалът срещу реалността
Но трябва ли малките ИТ компании и разработчици да се стремят към нивото на Google, Amazon или Microsoft? Как да използвате техния подход, ако нямате армия от DevOps инженери и денонощна поддръжка? Не всички клиенти имат банков API, не всяко сриване заплашва със загуба на милиони. И все пак дори малките проекти печелят от разбирането на тези принципи.

Цифрите карат да мислим по-точно. Моделът „четири деветки“ помага да погледнем по нов начин на архитектурата на проекта: кои компоненти са критични, кои могат да се репликират и кои трябва да се изолират.

99% достъпност и работа без сривове – това са 3,65 дни престой в годината, 99,9% – 8 часа и 45 минути, 99,99% – същите 53 минути на Google. Просто казано, всяка „деветка“ в договора с клиента струва ресурси и усилия. От друга страна, когато изглежда, че всичко работи „нормално“ и „почти не пада“, трябва да се разбере ясно, колко е „почти“? 3 минути? 3 часа?

MTTR е по-важен от броя на деветките
Нивото на Google не е необходимо за всички, смятат разработчиците от Emat ltd. Да си кажем честно, това е идеал. Но е важно да разберем: принципът е по-важен от процента. Това е инструмент за мислене и зрялост, а не религия. Ето как може да се разгледа това в реални условия.

MTTR (Mean Time To Repair) е нещо, което наистина можете да подобрите дори в малък екип:

• Намаляване на времето за откриване на неизправност — изграждане на система, в която инцидентът се открива, преди клиентът да разбере за него, благодарение на настроени мониторинг, регистриране, сигнализиране и метрики.
• Намаляване на времето за реакция на специалиста, така че отговорното лице да види необходимото уведомление и веднага да разбере какво трябва да направи. Не става въпрос само за графика на дежурствата. Важни са ясните инструкции, автоматичното маршрутизиране на инцидента и подготовката на екипа.
• Намалете времето за възстановяване – с помощта на мониторинг, спасителни действия с „едно натискане на бутон“ (например, връщане към предишното състояние или добавяне на резервна мощност), практики за оперативна готовност и т.н.
• Намалете нивото на средното прекъсване не само чрез технически решения, но и благодарение на архитектурни подходи: сегментиране на инфраструктурата, географско разпределение, възможности за частично влошаване. Дори при отказ един сегмент да остане работен, общото въздействие се намалява. Това означава, че потребителите могат да продължат да работят, макар и с ограничена функционалност, а екипът — да възстанови услугата без паника и суматоха.

От математиката към културата на отговорността
Разговорът за „деветките“ често се превръща в спор за минути, инциденти и време за възстановяване. Още повече, ако става дума не за гигантите на IT пазара, а за малки и средни компании. Сривът винаги е проверка на взаимодействието в екипа. Кой ще разбере пръв? Кой взема решението? Имаме ли сценарий за възстановяване? А клиентът – алтернатива? Доколко вашата услуга е подготвена за реалността?

И колкото по-рано екипът започне да си задава въпроси, толкова по-лесно ще бъде да отговори на тях в бъдеще. Защото надеждността не е цифри. Това е начин на мислене. Това е навик да проверяваш. Това е вътрешна дисциплина, от която с времето се ражда доверие.

Ние в Emat development считаме, че устойчивостта на услугата се характеризира преди всичко не с цифри, а с достъпност на технологиите. Всяка минута престой не е просто минус към SLA. Това е оценка на работата и подхода към инженерството, отношението към потребителите.

Какво може да се направи в малък проект

• Мониторинг: UptimeRobot, BetterStack, Telegram-бот
• Автоматично архивиране на базата данни в облака
• Уведомяване на отговорните лица при проблеми: Slack/месинджър
• Сценарии за реакция: Google Doc с действия (отмяна, рестартиране, добавяне на резервна мощност, превключване на DNS)
• Отказът на един клиент не трябва да засяга другите
• При актуализация (сегментиране, географска изолация, постепенна деградация)