Сега темата за DevOps е в хайп. Непрекъсната интеграция и тръбопровод за доставка CI / CD всички го изпълняват. Но повечето не винаги обръщат необходимото внимание на осигуряването на надеждността на информационните системи на различни етапи от CI/CD Pipeline. В тази статия бих искал да говоря за моя опит в автоматизирането на проверките на качеството на софтуера и прилагането на възможни сценарии за неговото „самолечение“.

източник

Работя като инженер в отдела за управление на ИТ услуги на компания "ЛАНИТ-Интеграция". Моята основна област на опит е внедряването на различни системи за мониторинг на ефективността и наличността на приложения. Често комуникирам с ИТ клиенти от различни пазарни сегменти по актуални въпроси относно мониторинга на качеството на техните ИТ услуги. Основната цел е да се сведе до минимум времето на цикъла на издаване и да се увеличи честотата на изданията. Всичко това, разбира се, е добре: повече версии - повече нови функции - повече доволни потребители - повече печалба. Но в действителност нещата не винаги се получават добре. При много високи нива на внедряване веднага възниква въпросът за качеството на нашите версии. Дори и с напълно автоматизиран конвейер, едно от най-големите предизвикателства е преместването на услугите от тестване към производство, без да се засяга времето за работа на приложението и потребителското изживяване.

Въз основа на резултатите от многобройни разговори с клиенти мога да кажа, че контролът на качеството на издаването, проблемът с надеждността на приложението и възможността за неговото „самолечение“ (например връщане към стабилна версия) на различни етапи от CI /CD pipeline са сред най-вълнуващите и подходящи теми.

Напоследък самият аз работих от страна на клиента - в услугата за поддръжка на софтуер за приложение за онлайн банкиране. Архитектурата на нашето приложение използва голям брой самостоятелно написани микроуслуги. Най-тъжното е, че не всички разработчици успяха да се справят с високия темп на развитие; качеството на някои микроуслуги пострада, което доведе до смешни прякори за тях и техните създатели. Имаше истории за това от какви материали са направени тези продукти.

"Формулиране на проблема"

Високата честота на издания и голям брой микроуслуги затрудняват разбирането на работата на приложението като цяло, както на етапа на тестване, така и на етапа на работа. Промените се случват постоянно и е много трудно да се контролират без добри инструменти за наблюдение. Често след нощно пускане на сутринта разработчиците седят като на буре с барут и чакат нищо да не се счупи, въпреки че всички проверки бяха успешни на етапа на тестване.

Има още един момент. На етапа на тестване се проверява функционалността на софтуера: изпълнението на основните функции на приложението и липсата на грешки. Качествените оценки на ефективността или липсват, или не вземат предвид всички аспекти на приложението и интеграционния слой. Някои показатели може изобщо да не бъдат проверени. В резултат на това, когато възникне повреда в производствена среда, отделът за техническа поддръжка разбира за това едва когато реалните потребители започнат да се оплакват. Бих искал да сведа до минимум въздействието на софтуер с ниско качество върху крайните потребители.

Едно от решенията е да се внедрят процеси за проверка на качеството на софтуера на различни етапи от CI/CD Pipeline и да се добавят различни сценарии за възстановяване на системата в случай на авария. Също така помним, че имаме DevOps. Бизнесът очаква да получи нов продукт възможно най-бързо. Следователно всички наши проверки и скриптове трябва да бъдат автоматизирани.

Задачата е разделена на два компонента:

• контрол на качеството на сглобките на етапа на тестване (за автоматизиране на процеса на улавяне на сглобки с ниско качество);
• контрол на качеството на софтуера в производствената среда (механизми за автоматично откриване на проблеми и възможни сценарии за тяхното самолечение).

Инструмент за наблюдение и събиране на показатели

За постигане на поставените цели е необходима система за мониторинг, която може да открива проблеми и да ги прехвърля към системите за автоматизация на различни етапи от CI/CD тръбопровода. Също така ще бъде положително, ако тази система предоставя полезни показатели за различни екипи: разработка, тестване, работа. И е абсолютно прекрасно, ако е и за бизнес.

За събиране на показатели можете да използвате набор от различни системи (Prometheus, ELK Stack, Zabbix и т.н.), но според мен решенията от клас APM са най-подходящи за тези задачи (Мониторинг на ефективността на приложението), което може значително да опрости живота ви.

Като част от работата ми в службата за поддръжка, започнах да правя подобен проект, използвайки решение от клас APM от Dynatrace. Сега, като работя за интегратор, познавам доста добре пазара на системи за мониторинг. Моето субективно мнение: Dynatrace е най-подходящ за решаване на такива проблеми.
Dynatrace предоставя хоризонтален изглед на всяка потребителска операция на детайлно ниво до нивото на изпълнение на кода. Можете да проследите цялата верига на взаимодействие между различни информационни услуги: от предните нива на уеб и мобилни приложения, задните сървъри на приложения, интеграционната шина до конкретно повикване към базата данни.

източник. Автоматично изграждане на всички зависимости между компонентите на системата

източник. Автоматично откриване и изграждане на пътя на услугата

Също така помним, че трябва да се интегрираме с различни инструменти за автоматизация. Тук решението има удобен API, който ви позволява да изпращате и получавате различни показатели и събития.

След това нека преминем към по-подробен поглед върху това как да разрешим тези проблеми с помощта на системата Dynatrace.

Задача 1. Автоматизиране на контрола на качеството на възлите на етапа на тестване

Първото предизвикателство е да откриете проблеми възможно най-рано в процеса на доставка на приложения. Само „добри“ компилации на код трябва да достигат до производство. За да направите това, вашият конвейер на етапа на тестване трябва да включва допълнителни монитори за проверка на качеството на вашите услуги.

Нека да разгледаме стъпка по стъпка как да приложим това и да автоматизираме този процес:

източник

Фигурата показва потока от автоматизирани стъпки за тестване на качеството на софтуера:

1. внедряване на система за мониторинг (инсталиране на агенти);
2. идентифициране на събития за оценка на качеството на вашия софтуер (метрики и прагови стойности) и прехвърлянето им към системата за мониторинг;
3. генериране на тестове за натоварване и производителност;
4. събиране на данни за ефективността и наличността в системата за мониторинг;
5. прехвърляне на тестови данни въз основа на събития за оценка на качеството на софтуера от системата за мониторинг към системата CI/CD. Автоматичен анализ на сглобки.

Стъпка 1. Внедряване на системата за мониторинг

Първо трябва да инсталирате агентите във вашата тестова среда. В същото време решението Dynatrace има приятна функция - използва универсалния агент OneAgent, който се инсталира на операционна система (Windows, Linux, AIX), автоматично разпознава вашите услуги и започва да събира данни за наблюдение за тях. Не е необходимо да конфигурирате отделен агент за всеки процес. Ситуацията ще бъде подобна за облачните и контейнерните платформи. В същото време можете също да автоматизирате процеса на инсталиране на агента. Dynatrace се вписва перфектно в концепцията „инфраструктура като код“ (Инфраструктура като код или IaC): Има готови скриптове и инструкции за всички популярни платформи. Вграждате агента в конфигурацията на вашата услуга и когато го внедрите, веднага получавате нова услуга с вече работещ агент.

Стъпка 2: Дефинирайте вашите събития за качество на софтуера

Сега трябва да вземете решение за списъка с услуги и бизнес операции. Важно е да вземете предвид точно тези потребителски операции, които са критични за бизнеса ви за вашата услуга. Тук препоръчвам консултации с бизнес и системни анализатори.

След това трябва да определите кои показатели искате да включите в прегледа за всяко ниво. Например, това може да бъде време за изпълнение (разделено на средна стойност, медиана, процентили и т.н.), грешки (логически, услуги, инфраструктура и т.н.) и различни инфраструктурни показатели (купчина на паметта, събирач на отпадъци, брой нишки и т.н.).

За автоматизация и лесна употреба от екипа на DevOps се появява концепцията за „Мониторинг като код“. Това, което имам предвид с това, е, че разработчик/тестер може да напише прост JSON файл, който определя показателите за осигуряване на качеството на софтуера.

Нека да разгледаме пример за такъв JSON файл. Обектите от Dynatrace API се използват като двойки ключ/стойност (описанието на API може да се намери тук Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

Файлът е масив от дефиниции на времеви редове:

• timeseriesId – проверяваната метрика, например време за реакция, брой грешки, използвана памет и др.;  
• агрегиране - ниво на агрегиране на показателите, в нашия случай ср., но можете да използвате всеки, от който се нуждаете (ср., мин., макс., сума, брой, процентил);
• тагове – таг на обект в системата за мониторинг или можете да посочите идентификатор на конкретен обект;
• тежки и предупредителни – тези индикатори регулират праговите стойности на нашите показатели; ако тестовата стойност надвишава тежкия праг, тогава нашата компилация се маркира като неуспешна.

Следващата фигура показва пример за използване на такива прагове.

източник

Стъпка 3: Генериране на натоварване

След като сме определили нивата на качество на нашата услуга, трябва да генерираме тестово натоварване. Можете да използвате всеки от инструментите за тестване, с които сте удобни, като Jmeter, Selenium, Neotys, Gatling и др.

Системата за мониторинг на Dynatrace ви позволява да улавяте различни метаданни от вашите тестове и да разпознавате кои тестове принадлежат към кой цикъл на издаване и коя услуга. Препоръчително е да добавите допълнителни заглавки към заявките за HTTP тест.

Следващата фигура показва пример, където, използвайки допълнителната заглавка X-Dynatrace-Test, ние показваме, че този тест се отнася до тестване на операцията по добавяне на артикул в количката.

източник

Когато изпълнявате всеки тест за натоварване, вие изпращате допълнителна контекстуална информация към Dynatrace с помощта на API за събития от CI/CD сървъра. По този начин системата може да прави разлика между различните тестове.

източник. Събитие в системата за мониторинг относно началото на тестването на натоварване

Стъпка 4-5. Съберете данни за ефективността и прехвърлете данни към системата CI/CD

Заедно с генерирания тест към системата за мониторинг се предава събитие за необходимостта от събиране на данни за проверка на показателите за качество на услугата. Той също така определя нашия JSON файл, който определя ключовите показатели.

Събитие относно необходимостта от проверка на качеството на софтуера, генериран на CI/CD сървъра за изпращане към системата за мониторинг

В нашия пример се извиква събитието за проверка на качеството perfSigDynatraceReport (Подпис_изпълнение) - това е готово плъгин за интеграция с Jenkins, който е разработен от момчетата от T-Systems Multimedia Solutions. Всяко събитие за стартиране на тест съдържа информация за услугата, номер на компилация и време за тестване. Плъгинът събира стойности на производителността по време на изграждане, оценява ги и сравнява резултата с предишни компилации и нефункционални изисквания.

Събитие в системата за наблюдение относно началото на проверка на качеството на изграждането. източник

След приключване на теста всички показатели за оценка на качеството на софтуера се прехвърлят обратно към система за непрекъсната интеграция, например Jenkins, която генерира отчет за резултатите.

Резултатът от статистиката за сборките на CI/CD сървъра. източник

За всяка отделна компилация виждаме статистика за всеки показател, който задаваме по време на целия тест. Ние също така виждаме дали има нарушения в определени прагови стойности (предупреждение и тежки прагове). Въз основа на обобщени показатели цялата компилация се маркира като стабилна, нестабилна или неуспешна. Също така, за удобство, можете да добавите индикатори към отчета, сравнявайки текущата компилация с предишната.

Преглед на подробна статистика за сборките на CI/CD сървъра. източник

Подробно сравнение на две сглобки

Ако е необходимо, можете да отидете в интерфейса на Dynatrace и там можете да видите по-подробно статистиките за всяка ваша компилация и да ги сравните една с друга.

Сравнение на статистическите данни за изграждането в Dynatrace. източник
 
Данни

В резултат на това получаваме услуга „мониторинг като услуга“, автоматизирана в тръбопровода за непрекъсната интеграция. Разработчикът или тестерът трябва само да дефинира списък с показатели в JSON файл и всичко останало се случва автоматично. Получаваме прозрачен контрол на качеството на версиите: всички известия за производителност, потребление на ресурси или архитектурни регресии.

Задача 2. Автоматизиране на контрола на качеството на софтуера в производствена среда

И така, ние решихме проблема как да автоматизираме процеса на наблюдение на етапа на тестване в Pipeline. По този начин минимизираме процента на некачествени сглобки, които достигат до производствената среда.

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

За да направим това, трябва, по аналогия с предишния раздел, да осигурим автоматични проверки на качеството на софтуера в производствената среда и да ги базираме на сценарии за самовъзстановяване на системата.

Автоматично коригиране като код

Повечето компании вече имат натрупана база от знания за различни типове често срещани проблеми и списък с действия за отстраняването им, например рестартиране на процеси, почистване на ресурси, връщане назад на версии, възстановяване на невалидни промени в конфигурацията, увеличаване или намаляване на броя на компонентите в клъстера, превключване на синия или зеления контур и т.н.

Въпреки че тези случаи на употреба са известни от години на много от екипите, с които говоря, малцина са се замисляли или са инвестирали в автоматизирането им.

Ако се замислите, няма нищо прекалено сложно в прилагането на процеси за самовъзстановяваща се производителност на приложението; трябва да представите вече известните работни сценарии на вашите администратори под формата на кодови скриптове (концепцията „автоматично коригиране като код“) , които сте написали предварително за всеки конкретен случай. Скриптовете за автоматично поправяне трябва да са насочени към премахване на основната причина за проблема. Вие сами определяте правилните действия за реагиране при инцидент.

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

Можете да използвате всяка система или набор от системи: Prometheus, ELK Stack, Zabbix и др. Но ще дам няколко примера, базирани на APM решение (Dynatrace отново ще бъде пример), което също ще ви помогне да улесните живота си.

Първо, има всичко свързано с производителността по отношение на работата на приложението. Решението предоставя стотици показатели на различни нива, които можете да използвате като тригери:

• потребителско ниво (браузъри, мобилни приложения, IoT устройства, потребителско поведение, преобразуване и др.);
• ниво на обслужване и операции (производителност, наличност, грешки и т.н.);
• ниво на инфраструктурата на приложението (метрики на хост ОС, JMX, MQ, уеб сървър и др.);
• ниво платформа (виртуализация, облак, контейнер и др.).

Мониторинг на нивата в Dynatrace. източник

Второ, както казах по-рано, Dynatrace има отворен API, което го прави много лесен за интегриране с различни системи на трети страни. Например, изпращане на известие до системата за автоматизация при превишаване на контролните параметри.

По-долу е даден пример за взаимодействие с Ansible.

източник

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

1. Лошо внедряване – връщане на версията

Дори ако тестваме всичко много добре в тестова среда, все още има шанс нова версия да убие вашето приложение в производствена среда. Същият човешки фактор не е отменен.

На следващата фигура виждаме, че има рязък скок във времето за изпълнение на операциите в услугата. Началото на този скок съвпада с времето на внедряване в приложението. Ние предаваме цялата тази информация като събития към системата за автоматизация. Ако работата на услугата не се нормализира след зададеното от нас време, автоматично се извиква скрипт, който връща версията към старата.

Влошаване на ефективността на операциите след внедряване. източник

2. Зареждане на ресурси на 100% - добавете възел към маршрутизирането

В следващия пример системата за наблюдение определя, че един от компонентите изпитва 100% натоварване на процесора.

натоварване на процесора 100%
 
Възможни са няколко различни сценария за това събитие. Например, системата за мониторинг допълнително проверява дали липсата на ресурси е свързана с увеличаване на натоварването на услугата. Ако е така, тогава се изпълнява скрипт, който автоматично добавя възел към маршрута, като по този начин възстановява функционалността на системата като цяло.

Мащабиране след инцидент

3. Липса на място на твърдия диск - почистване на диска

Мисля, че много хора вече са автоматизирали тези процеси. Използвайки APM, можете също да наблюдавате свободното пространство на дисковата подсистема. Ако няма място или дискът работи бавно, извикваме скрипт за почистване или добавяне на място.

Натоварване на диска 100%
 
4. Ниска потребителска активност или ниска конверсия - превключване между сини и зелени клони

Често виждам клиенти да използват два цикъла (синьо-зелено внедряване) за приложения в производствена среда. Това ви позволява бързо да превключвате между клонове, когато доставяте нови версии. Често след внедряването могат да настъпят драматични промени, които не се забелязват веднага. В този случай може да не се наблюдава влошаване на производителността и наличността. За да реагирате бързо на такива промени, е по-добре да използвате различни показатели, които отразяват поведението на потребителите (брой сесии и потребителски действия, реализация, степен на отпадане). Следващата фигура показва пример, в който, когато процентът на реализация спадне, се извършва превключване между софтуерни клонове.

Процентът на реализация спада след превключване между софтуерни клонове. източник

Механизми за автоматично откриване на проблеми

И накрая, ще ви дам още един пример защо най-много харесвам Dynatrace.

В частта от моята история за автоматизирането на проверките на качеството на сглобките в тестова среда, ние определихме всички прагови стойности ръчно. Това е нормално за тестова среда, самият тестер определя показателите преди всеки тест в зависимост от натоварването. В производствена среда е желателно проблемите да се откриват автоматично, като се вземат предвид различни базови механизми.

Dynatrace има интересни вградени инструменти за изкуствен интелект, които на базата на механизми за определяне на аномални показатели (baselining) и изграждане на карта на взаимодействие между всички компоненти, сравнявайки и корелирайки събития помежду си, определят аномалии в работата на вашата услуга и предоставят подробни информация за всеки проблем и първопричина.

Чрез автоматично анализиране на зависимостите между компонентите Dynatrace определя не само дали проблемната услуга е основната причина, но също така и нейната зависимост от други услуги. В примера по-долу Dynatrace автоматично следи и оценява изправността на всяка услуга в рамките на изпълнението на транзакцията, като идентифицира услугата Golang като основната причина.

Пример за определяне на основната причина за повреда. източник

Следващата фигура показва процеса на наблюдение на проблеми с вашето приложение от началото на инцидента.

Визуализация на възникнал проблем с показване на всички компоненти и събития по тях

Системата за мониторинг събра пълна хронология на събитията, свързани с възникналия проблем. В прозореца под времевата линия виждаме всички ключови събития за всеки от компонентите. Въз основа на тези събития можете да зададете процедури за автоматична корекция под формата на кодови скриптове.

Освен това ви съветвам да интегрирате система за наблюдение със Service Desk или програма за проследяване на грешки. Когато възникне проблем, разработчиците бързо получават пълна информация, за да я анализират на ниво код в производствената среда.

Заключение

В резултат на това получихме CI/CD тръбопровод с вградени автоматизирани проверки на качеството на софтуера в Pipeline. Минимизираме броя на сглобките с ниско качество, повишаваме надеждността на системата като цяло и ако системата ни все още не успее, стартираме механизми за нейното възстановяване.

Определено си струва да инвестирате усилия в автоматизирането на мониторинга на качеството на софтуера; това не винаги е бърз процес, но с времето ще даде плод. Препоръчвам ви след разрешаване на нов инцидент в производствената среда незабавно да помислите кои монитори да добавите за проверки в тестовата среда, за да избегнете попадането на лоша компилация в производствената среда, както и да създадете скрипт за автоматично коригиране на тези проблеми.

Надявам се моите примери да ви помогнат в начинанията ви. Също така ще ми е интересно да видя вашите примери за показатели, използвани за внедряване на системи за самолечение.

източник

Източник: www.habr.com