Традиционното тестване едва-едва „докосва повърхността“ на проблемите в ИТ инфраструктурите, но целенасочените тестови сривове помагат за повече надеждност
(снимка: CC0 Public Domain)
За да предотвратяват сривове и да се възстановят по-добре от тях в днешния сложен, облачен ИТ свят, предприятията трябва проактивно и съвсем целенасочено да „инжектират“ повреди в своите системи чрез практики за т.нар. хаос-инженеринг.
Целенасоченото внедряване на сривове в ИТ системите може да помогне за укрепването и подготовката им за възстановяване при прекъсвания, твърди Саян Мондал, старши софтуерен инженер в платформата за доставка на софтуер Harness. Той отправи това послание по време на конференцията KubeCon + CloudNativeCon China 2025 в Хонконг.
Мондал, който е и мениджър по поддръжката и част от общността на инкубационния проект LitmusChaos на Cloud Native Computing Foundation (CNCF), отбеляза, че разработчиците, инженерите по надеждността на сайтовете и екипите за ИТ операции трябва да се чувстват комфортно в присъствието на хаоса.
Много взаимозависими повреди
„В днешно време навсякъде има облачни и разпределени системи – с много взаимозависими повреди“, каза експертът. „Доставчиците на облачни услуги не са наистина 100% надеждни, защото може да се стигне до повреди на устройства, прекъсвания на захранването и сривове на памет“.
Финансовите и репутационните щети от подобни прекъсвания могат да костват много. Мондал посочи примери, при които финансова компания е загубила над 55 милиона долара поради един-единствен инфраструктурен проблем, който е попречил на обработката на транзакции.
Традиционното тестване едва-едва „докосва повърхността“ на проблемите и обикновено включва само приложния слой, каза Мондал. „Рядко тестваме инфраструктурата или основните платформени услуги“, каза Мондал. „Хаос-инженерингът се фокусира специално върху засягането на долните слоеве.“
„Противопожарно“ учение за приложенията
Мондал описва хаос-инженеринга като „противопожарно учение, което правите в началото на цикъла на доставка, така че когато се случи действителното събитие, да сте много по-подготвени“. Това включва:
- планиране и симулиране на повреди;
- използване на различни видове повреди за идентифициране на уязвимости;
- разбиране как се сриват системите, за да могат организациите да изградят по-устойчиви инфраструктури.
За DevOps и IT екипите, които се чудят откъде да започнат, според Мондал, не е нужно да тръгват с разрушаване на производствените системи. Пътуването може да започне безопасно в локална среда, преминавайки към среда за подготовка и предпроизводство и едва след това към същинските продуктивни системи, когато екипът се почувства комфортно.
Организация за хаоса
Що се отнася до това къде обикновено се намират екипите за хаос-инженеринг в една организация, Мондал посочи, че това често е „споделена отговорност“, водена от тези, които са най-близо до надеждността на системата. Най-често това са оперативните и главните инженери.
Целта обаче е практиката да се разшири и да обхване и разработчиците. Те могат да правят хаос-тестинг в рамките на етапите по доставка на софтуер. Това дава възможност на разработчиците да тестват устойчивостта, докато изготвят и доставят програмен код.
Тестването, ръководено от самите разработчици, се допълва от по-големи, по-структурирани събития. Това може да са периодично разиграващи се събития, които да подготвят екипите да се справят с по-сложни сценарии на сривове.
В крайна сметка комбинирането на непрекъснато хаос-тестване с периодични проигравания на сривове може да помогне за създаване на „култура на надеждността“.