Съдържание
- Подготовка за неуспех
- Следващите стъпки
- Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
- Учене и усъвършенстване чрез тренировки
Източник: pressureUA / iStockphoto
За вкъщи:
Съвременните системи трябва да могат да се справят с хаоса, за да се избегне престой. Ето защо е по-важно от всякога цялостно тестване на системите и гарантиране на тяхната устойчивост.
Въпреки най-големите ни усилия да ги избегнем, ИТ инцидентите са неизбежна част от работата - и да се опитваме да останем пред прекъсването на бизнеса, засягащо бизнеса, става само по-сложно. Системите днес са плътно свързани и все по-сложни и с повече движещи се части идват повече възможности нещата да се объркат.
Това е една от причините все повече организации да се обръщат към микросервизи за по-голяма достъпност на услугите и по-добра устойчивост на отказ. Но макар че това са чудесни предпоставки за разбиване на монолитни приложения, те могат също така потенциално да компенсират риска от отказ - освен ако не са проектирани изрично с издръжливост.
Подготовка за неуспех
Като се има предвид присъщият хаотичен характер на разпределените системи, услугите трябва да се развиват не само за да се предвиди повреда, но и автоматично да се възстанови в случай на отказ. Това означава редовно подстрекаване на грешки, за да се гарантира, че системите ви могат да се справят с хаоса, без да нарушават обслужването на крайните клиенти. И за да постигнете това, се нуждаете от способността да симулирате производствен трафик в тестови среди.
Разбира се, добре е да изпробвате устойчивостта, преди промените да доведат до производство. Ако не направите това, няма да можете да проверите дали услугите ви могат да поддържат средно и максимално натоварване. Всъщност, най-сигурният залог е да гарантирате, че вашият продукт може да се справи с до два пъти максималната сума, без да се налага да увеличавате мащаба си.
Що се отнася до тест за устойчивост, правилните инструменти не трябва да бъдат твърде загрижени за това как се обработват заявките, само че те в крайна сметка имат правилното въздействие. Не забравяйте, че при определени условия услугата за въвеждане може да не предаде заявка на останалата част от системата, но да не съобщи за повредата. Не рискувайте проблеми, които да летят под радара за наблюдение, като се уверите, че валидирането от край до край на практика се случва. (За повече информация вижте Технически провали: Можем ли да живеем с тях?)
Следващите стъпки
След като разберете как услугите се държат под натоварване, е време да започнете да въвеждате събития на грешки. Както при всички тестове на софтуер, най-добре е да имате автоматизирани инструменти, които ви позволяват лесно и бързо възпроизвеждане на сценарии, така че да можете да координирате сложни събития, които влияят на различни инфраструктурни технологии. И освен възможността за проверка на поправки и промени в услугите, това ви позволява да стартирате случайни сценарии за неуспех във всяка среда и по график.
Съществените събития на грешки до голяма степен зависят от оформлението на вашите услуги и можете да ги формулирате, като задавате конкретни въпроси, които са подходящи за вас. Например, какво е въздействието върху хората, използващи предния край, когато базата данни стане недостъпна за определен период от време? Могат ли тези потребители все още да навигират в потребителския интерфейс в мрежата? Могат ли все още да издават актуализации на своята информация и ще бъдат ли обработени правилно тези актуализации, когато базата данни стане отново достъпна?
Ако стартирате множество микросервизи, можете да попитате дали ще има глобално прекъсване, ако някоя отделна услуга се срине. Или ако имате механизъм за опашка за буфер на комуникацията между услугите, какво се случва, когато потребителските услуги (или услуги) престанат да работят? Ще продължат ли потребителите да работят с вашето приложение? И като се има предвид средното натоварване, колко време имате преди опашките да препълнят и да започнете да губите s?
Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.
След като дефинирате няколко ключови въпроса относно вашата инфраструктура, можете да започнете да изброявате различни начини за симулиране на тези грешки. Може да е достатъчно, за да спрете определена услуга или сървър на база данни. Може да искате да блокирате основната нишка на услуга, за да симулирате мъртво заключване, докато нейният контейнер все още реагира и работи. Може да решите да въведете правила във вашата мрежа, за да блокирате трафика между конкретни услуги. В Linux среди можете да използвате инструменти като „tc“, за да подражавате на мрежови ситуации като висока латентност, изпуснати, повредени или дублирани пакети. (Може да е важно да се включат потребители в тестване. Прочетете повече в 4 причини, защо крайните потребители трябва да участват в тестване преди UAT.)
Учене и усъвършенстване чрез тренировки
Един от най-ценните аспекти на създаването на сценарии за неуспех е, че те могат да разкрият всички потенциални начини, по които системата може да се провали, като по този начин издълбаят пътя към логиката на самолечение. Вашият екип ще премине през стъпките за ръчно възстановяване на услуги - страхотна тренировка, между другото, за да потвърди, че са в състояние да направят това в рамките на SLAs. Автоматизирането на този процес на възстановяване може да се работи, но междувременно можете да си починете лесно, знаейки, че вашият екип е преминал през процеса на връщане на услугите на път. Като правите сценарии на грешки случайни и редовни и не разкривате пълните подробности за изпълнението, можете също така да включите откриване и диагнози на тренировката - което в крайна сметка е критична част от SLAs.
В основата си хаос инженерингът приема сложността на системата като даденост, тества я чрез симулиране на нови и чалнати условия и наблюдава как системата реагира. Това е необходимо екипите за инженеринг на данни да препроектират и преконфигурират системата, за да постигнат по-голяма устойчивост. Има толкова много възможности да научите нови и полезни неща. Например, можете да намерите случаи, когато услугите не получават актуализации, когато услугите надолу по веригата са променени, или области, в които мониторингът липсва напълно. Не липсват вълнуващи начини да направите продукта си по-устойчив и здрав!