Садржај
- Припрема за неуспех
- Следећи кораци
- Без грешака, без стреса - Ваш корак по корак водич за креирање софтвера за промену живота без да вам уништи живот
- Учење и унапређење кроз вјежбе
Извор: прессуреУА / иСтоцкпхото
Одузети:
Савремени системи морају бити у стању да се носе са хаосом како би се избегли застоји. Зато је најважније него икад важније темељито тестирати системе и осигурати њихову отпорност.
Упркос нашим највећим напорима да их избегнемо, ИТ инциденти су незаобилазни део посла - а покушај да останемо испред застоја који утиче на пословање постаје само отежани. Системи су данас чврсто повезани и све сложенији, а са покретнијим деловима долази и више прилика да ствари пођу по злу.
То је један од разлога зашто се све више организација окреће микросервисима ради веће доступности услуга и веће отпорности на неуспех. Али иако су то сјајне претпоставке за пробијање монолитних апликација, они такође могу потенцијално сложити ризик од неуспеха - осим ако нису изричито дизајнирани с обзиром на отпорност.
Припрема за неуспех
С обзиром на прирођену хаотичну природу дистрибуираних система, услуге би требало да се развијају не само да предвиде квар, већ да се аутоматски обнове у случају квара. То значи да редовно подстичете кварове како бисте осигурали да ваши системи могу поднијети хаос без ометања услуге крајњим купцима. А да бисте то постигли, потребна вам је способност да симулирате промет сличан производњи у тестним окружењима.
Наравно, добра је идеја тестирати отпорност пре него што се промене уведу у производњу. Ако то не учините, нећете моћи да проверите да ли ваше услуге могу да подржавају и просечна и највећа оптерећења. Заправо, најсигурнија опклада је осигурати да ваш производ може да поднесе до двоструко највећег износа без потребе за повећањем.
Када је у питању тестирање отпорности, прави алати не би требали бити превише забринути како се са захтевима поступа, већ само да на крају имају тачан утицај. Имајте на уму да под одређеним условима услуга уноса може да преда захтев остатку система, али да не пријави квар. Не ризикујте да летите испод радара надгледања тако што ћете обезбедити да се валидација све до краја догоди. (За више, погледајте Техничке пропусте: Можемо ли живети с њима?)
Следећи кораци
Након што схватите како се услуге понашају под оптерећењем, време је да почнете са увођењем догађаја квара. Као и код свих тестирања софтвера, најбоље је имати аутоматизоване алате који вам омогућавају да лако и брзо репродукујете сценарије, тако да можете да координирате сложене догађаје који утичу на различите инфраструктурне технологије. А осим могућности верификације исправки и промена услуга, ово вам омогућава покретање случајних сценарија неуспеха у било којем окружењу и на распореду.
Значајни догађаји неуспеха у великој мери зависе од изгледа ваших услуга и можете их формулисати тако да поставите одређена питања која су релевантна за вас. На пример, какав је утицај на људе који користе фронт-енд када база података постане недоступна током одређеног временског периода? Могу ли ти корисници и даље навигирати на веб сучеље? Да ли могу да издају ажурирања својих података и да ли ће та ажурирања бити исправно обрађена када база података поново буде доступна?
Ако покрећете више микро сервиса, можете се запитати да ли ће доћи до глобалног прекида ако се неки појединачни сервис сруши. Или ако имате механизам чекања за усклађивање комуникације између услуга, шта се дешава када потрошачке услуге (или услуге) престану да раде? Да ли ће корисници и даље моћи да раде са вашом апликацијом? А с обзиром на просечно оптерећење, колико времена имате пре него што се редови препуне и почнете губити с?
Без грешака, без стреса - Ваш корак по корак водич за креирање софтвера за промену живота без да вам уништи живот
Не можете побољшати своје вештине програмирања када никога није брига за квалитет софтвера.
Након што дефинишете неколико кључних питања о својој инфраструктури, можете почети са навођењем различитих начина за симулацију тих кварова. Можда ће бити довољно да зауставите одређену услугу или сервер базе података. Можда бисте желели да блокирате главни нит сервиса да симулира мртву браву, док је његов спремник и даље реагован и покренут. Можда ћете одлучити да уведете правила у вашу мрежу како бисте блокирали саобраћај између одређених сервиса. У Линук окружењима можете користити алате попут „тц“ за опонашање мрежних ситуација попут високог кашњења, испуштених, оштећених или дуплираних пакета. (Може бити важно укључити кориснике у тестирање. Прочитајте више у 4 разлога зашто крајњи корисници треба да учествују у тестирању пре УАТ-а.)
Учење и унапређење кроз вјежбе
Један од највреднијих аспеката стварања сценарија неуспеха је тај што они могу разоткрити све потенцијалне начине на које систем може да пропадне, чиме ће урезати пут до логике самоизцељења. Ваш тим ће проћи кораке за ручно враћање услуга - узгред, одлична вежба за потврду да су у стању да то ураде унутар СЛА-ова. Аутоматизација овог поступка опоравка може се радити, али у међувремену се можете одморити знајући да је ваш тим прошао кроз процес враћања услуга на прави пут. Ако случајне и редовне сценарије неуспеха направите и не откријете све детаље трчања, можете да укључите откривање и дијагнозе на вежбу - што је, на крају крајева, и критични део СЛА-а.
У основи, инжењеринг хаоса узима сложеност система као дат, тестира га симулирајући нове и откачене услове и посматра како систем реагује. Ово тимови за инжењеринг података требају да редизајнирају и поново конфигуришу систем да би постигли већу отпорност. Постоји толико много могућности за учење нових и корисних ствари. На примјер, можете пронаћи случајеве у којима услуге не добијају ажурирања када су се услуге на нижој мрежи промијениле или подручја у којима потпуно недостаје надзор. Не недостаје узбудљивих начина да свој производ учините отпорнијим и робуснијим!