Инженеринг на надеждността на сайта срещу DevOps: как наистина се съчетават

Начало » Питон » Инженеринг на надеждността на сайта срещу DevOps: как наистина се съчетават

Ако работите някъде близо до съвременната разработка на софтуер, почти сигурно сте чували хора да използват „DevOps“ и „SRE“, сякаш са едно и също нещо. Обявите за работа смесват и двата етикета, инженерите прескачат между ролите, а в много организации ежедневните инструменти изглеждат почти идентични: CI/CD, инфраструктура като код, наблюдаемост, автоматизация навсякъде. Не е чудно, че хората питат дали Site Reliability Engineering и DevOps са просто две марки за една и съща работа.

Реалността е по-нюансирана: SRE и DevOps преследват един и същ резултат – бързо, безопасно и надеждно предоставяне на софтуер – но подхождат към проблема от различни ъгли. DevOps е предимно културно и организационно движение, което променя начина, по който разработката и операциите си сътрудничат, докато SRE е конкретен набор от инженерни практики, роли и механизми за надеждност, които често... прилагане на Принципите на DevOps в производството. Разбирането как те се припокриват, къде се разминават и как се съчетават с нарастващата дисциплина на платформеното инженерство е от решаващо значение, ако проектирате екипи, избирате кариерен път или просто се опитвате да направите системите си по-малко крехки.

DevOps накратко: култура, сътрудничество и непрекъсната доставка

DevOps започна като реакция срещу стария свят на твърди силози между разработката и операциите, безкрайни предавания на задачи и болезнено бавни пускания на пазара. Вместо разработчиците да „хвърлят код през стената“ на оперативния отдел, DevOps се застъпва за унифициран начин на работа, при който всички, отговорни за дадена услуга – разработчици, системни администратори, QA, специалисти по сигурност и работа в мрежа – си сътрудничат през целия жизнен цикъл.

Удобен начин да запомните основната философия на DevOps е акронимът CALMS: Култура, Автоматизация, Lean, Измерване и Споделяне. Културата е в центъра: стимулите, комуникацията и доверието трябва да възнаграждават сътрудничеството, а не локалната оптимизация. Автоматизацията и идеите за „lean“ производство се използват за рационализиране на промените, намаляване на отпадъците и поддържане на малки размери на партидите. Измерването и споделянето гарантират, че подобренията са основани на данни и знанията се движат свободно между екипите.

Една от най-важните DevOps идеи е „край на изолацията“. Традиционните организационни схеми разделяха разработчиците (които оптимизираха за предлагане на функции) от операторите (които бяха оценявани по стабилност и време на работа). Тази структура често създаваше неблагоприятни стимули: разработчиците налагаха рискови промени, операциите се отлагаха с табла за промени и дълги срокове за изпълнение, а бизнесът страдаше. DevOps атакува това, като съгласува целите и прави и двете групи съвместно отговорни за резултатите.

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

Инструментите са от голямо значение в DevOps, но идват след културата. CI/CD конвейерите, автоматизираното тестване, управлението на конфигурациите и инфраструктурата като код са ключови фактори, но лидерите в DevOps настояват, че силната култура може да компенсира посредствените инструменти, докато обратното рядко е вярно. Измерването е в основата на всичко: честотата на внедряване, времето за изпълнение на промените, средното време за възстановяване и процентът на неуспешни промени (DORA показателите) се използват, за да се разбере как се държи конвейерът за доставка и къде да се подобри.

Какво е инженеринг на надеждността на обектите и откъде произлиза?

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

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

Основната предпоставка на SRE е, че операциите трябва да се обработват със същата прецизност и инструменти, както разработването на софтуер. Това означава конфигурация с контролирани версии, възпроизводими среди, автоматизирани внедрявания и връщания към предишни версии, надежден мониторинг и мания за елиминиране на ръчната, повтаряща се работа – това, което SRE специалистите наричат ​​„труден труд“. Ако човек може да изпълни задача, SRE предполага, че машината вероятно би трябвало.

SRE въвежда и мощен език за надеждност под формата на SLI, SLO и бюджети за грешки. Индикаторът за ниво на обслужване (SLI) е внимателно подбран показател, който отразява това, от което потребителите се интересуват – например, делът на заявките за търсене, които връщат валиден резултат под 200 ms. Целта за ниво на обслужване (SLO) е цел за тази SLI, като например 99.9% успех за едно тримесечие. Разликата между перфектната надеждност (100%) и вашата SLO е бюджетът за грешки – количеството допустими грешки, които сте готови да толерирате, за да продължите да се движите бързо.

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

SRE като практическо приложение на DevOps идеите

Полезен ментален модел, широко цитиран в литературата за SRE, е „клас SRE внедрява интерфейс DevOps“. С други думи, ако DevOps е интерфейсът – очакванията на високо ниво за сътрудничество, автоматизация и споделена отговорност – тогава SRE е един конкретен клас, който отговаря на тези очаквания по много своенравен начин.

За разлика от многокомпанийния, нисък произход на DevOps, SRE в Google се развива в рамките на една единствена организация със собствена силна култура и инструменти. В резултат на това, оригиналните трудове по SRE поставят малко по-малко изричен акцент върху мащабната културна промяна и повече върху механиката на управлението на мащабни производствени системи. Това не означава, че културата е маловажна; по-скоро SRE приема някои културни основи и след това се задълбочава в това как да се управляват услугите надеждно.

Има няколко отличителни принципа на SRE, които надхвърлят общите насоки за DevOps:

• Надеждността е характеристика на продукта с цел, а не абсолютна стойност. Преследването на 100% наличност често е разточително и ненужно. Вместо това, екипите по SRE работят с продуктови и бизнес колеги, за да изберат правилния SLO за всяка система.
• Трудът трябва да бъде агресивно ограничен. В Google екипите за SRE имат твърдо ограничение, че не повече от 50% от времето им трябва да се изразходва за ръчна оперативна работа. Това не е формулирано като максимум, а като гаранция, че ще имат време за работа по проекти, която подобрява системите.
• „Мъдростта на производството“ е безценна. Редовният контакт с реални инциденти, страници и заявки дава на експертите по сигурността (SRE) представа как системите действително се държат в сравнение с това как са били нарисувани на бели дъски. Тази обратна връзка води до по-добри решения за проектиране.

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

Едно недооценено предимство на SRE е влиянието му върху скоростта на разработчиците, не само върху суровото време на работа. Чрез намаляване на средното време за отстраняване на често срещани повреди, осигуряване на изпитани в практиката канали за внедряване и по-ранно разрешаване на проблемите в жизнения цикъл, SRE позволяват на продуктовите инженери да се съсредоточат върху функциите, вместо върху гасенето на пожари. Откриването на проблеми в дизайна или ранното тестване винаги е по-евтино от отстраняването им след пускането на пазара.

Основни принципи и най-добри практики за SRE

Въпреки че различните компании прилагат SRE по свой собствен начин, общ набор от принципи се появява отново и отново. Заедно те превръщат мантрата „поддържайте го работещо“ от ad-hoc оперативна мантра в структурирана инженерна практика.

1. Поемете риска, вместо да гоните перфектна работоспособност. SRE изхожда от предпоставката, че никоя система не може да бъде напълно надеждна. Чрез използване на бюджети за грешки, обвързани със SLO, екипите могат да вземат съзнателни решения за това колко риск е приемлив, кога да се изпълняват по-бързо и кога да се въздържат.

2. Дефинирайте и използвайте силни SLO. Неясни цели като „наистина надежден“ се заменят с конкретни цели, като например „99.9% от API извикванията са успешни всяко тримесечие“. Тези SLO ръководят предупрежденията, приоритетите и дизайнерските решения и трябва да отразяват действителните очаквания на потребителите.

3. Безмилостно елиминирайте труда чрез автоматизация. Ръчни, повтарящи се задачи като рестартиране на услуги, изпълнение на едни и същи диагностични задачи или обработка на едни и същи видове заявки са основни цели за скриптове, ботове и системи за оркестрация. Целта е всеки болезнен инцидент да се превърне в кандидат за автоматизация или промяна в дизайна.

4. Инвестирайте сериозно в мониторинг и наблюдаемост. Добрите екипи за SRE знаят, че не можете да управлявате това, което не можете да видите. Те изграждат табла за управление, регистрационни файлове, показатели и трасирания, които открояват правилните сигнали, задействат смислени предупреждения и поддържат бърз анализ на първопричините в сложни разпределени системи. Разпределени системи.

5. Отнасяйте се към инженерството на изданията като към първокласна дисциплина. Безопасни канали за внедряване, прогресивни внедрявания, автоматични връщания към предишни версии и силни схеми за управление на версиите са инструменти, които SRE използват, за да направят промените евтини и обратими. Това пряко подкрепя философията на DevOps за малки, чести промени.

6. Ограничете оперативното натоварване и защитете хората. Здравословните ротации на дежурствата, ограниченията на честотата на обажданията и прозрачните дискусии за прегарянето не са „приятни неща“ – те са необходими за устойчива и надеждна работа. Показателите за обема на пейджърите и натоварването се проследяват също толкова сериозно, колкото латентността и процентите на грешки.

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

Какво всъщност прави инженерът по надеждност на обекта?

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

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

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

Работата след инцидента е друга важна част от работата. След прекъсвания или сериозни повреди, експертите по инженерство и развойна дейност (SRE) провеждат пост-инцидентни прегледи с представители на разработката, експлоатацията и понякога с външни партньори. Те проучват дали въздействията са били сведени до минимум, пречките пред разрешаването на проблемите, забавянията на уведомленията, зависимостите от трети страни и, най-важното, системните коренни причини. Действията от тези прегледи се вливат директно в натрупаните инженерни задачи.

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

Какво е DevOps като практика и какво правят DevOps инженерите?

Докато SRE се фокусира върху надеждността в производството, DevOps възприема по-широк поглед, променяйки начина, по който софтуерът се изгражда, тества, внедрява и изпълнява от първия ден. Често се описва като методология или набор от практики, които обхващат целия жизнен цикъл на разработка на софтуер, от планирането и кодирането до внедряването и текущите операции.

DevOps инженерите работят за рационализиране и автоматизиране на целия този процес, така че малки, висококачествени промени да могат да достигат до потребителите бързо и безопасно. Те проектират и поддържат CI/CD системи, дефинират стратегии за разклоняване и пускане на пазара, интегрират автоматизирано тестване и гарантират, че средите – от разработка до тестване и производство – са последователни и възпроизводими.

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

От гледна точка на инструментариума, DevOps работата обикновено се фокусира върху автоматизация на изграждането и внедряването, управление на конфигурацията и оркестрация на средата. Популярни платформи и рамки – като Jenkins или GitLab CI за пайплайни, Terraform или Ansible за инфраструктура като код и Kubernetes за оркестрация на контейнери – са суровината, която DevOps инженерите вплитат в съгласувани работни процеси.

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

Сравнение на SRE с DevOps: цели, клиенти и ежедневен фокус

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

Тази разлика се проявява в „клиентите“, които всяка дисциплина има предвид. DevOps е склонен да гледа навън към заинтересованите страни по продукта и крайните потребители: доставяме ли ценни функции бързо и безопасно и подобрява ли се потребителското изживяване? SRE, макар че в крайна сметка обслужва потребителите, често гледа на вътрешните екипи за операции и инфраструктура като на свои непосредствени клиенти, като се стреми да намали натоварването им и да им помогне да изпълнят изрични ангажименти за надеждност, като например SLA.

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

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

Разглеждани заедно, DevOps и SRE са по-малко конкуренти и по-скоро допълващи се. DevOps пита: „Как да организираме и стимулираме екипите, така че изграждането и работата с софтуер да е споделен и ефективен процес?“ SRE пита: „Предвид това, как да проектираме надеждността на нашите услуги с дисциплина и данни?“

Метрики и индикатори: DORA срещу SLO и SLI

И двете дисциплини са изключително ориентирани към данни, но разглеждат различни части от тях. DevOps екипите разчитат предимно на показатели за доставка, като например:

• Честота на разполагане – колко често промените достигат до производството.
• Време за изпълнение на промените – колко време отнема от предаването на кода до изпълнението му в производствена среда.
• Средно време за възстановяване (MTTR) – колко бързо системата се възстановява след инцидент.
• Промяна на процента на неуспех – каква част от промените причиняват инциденти или отмяна на промени.

За разлика от тях, екипите по SRE се фокусират върху показатели, пряко свързани с потребителското изживяване и състоянието на услугата. Типичните мерки включват процентили на латентност, проценти на грешки, обеми на заявките, проценти на наличност и спазване на SLA или SLO. Те често се разделят на SLI, които ясно изразяват какво точно представлява „доброто“ от гледна точка на потребителя.

Въпреки разликите, тези метрични семейства са дълбоко допълващи се. Метриките за доставка показват колко ефективно стойността преминава през процеса; показателите за надеждност показват колко често тази стойност пристига в използваема форма. Зрялата организация използва и двата набора, за да избегне двойните капани на „бързо, но нестабилно“ и „стабилно, но заледено“.

Различни нагласи към провала и експериментирането

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

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

На практика двата подхода се сближават повече, отколкото се разминават. И двете ценят ученето от инциденти чрез структурирани прегледи, и двете отхвърлят културата, основана на обвинения, и двете проектират системи, които могат да се провалят безпроблемно. Основната разлика е, че SRE обвързва свободата за експериментиране директно с количествените бюджети за надеждност.

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

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

Екипите по инженерство на платформи изграждат вътрешни продукти – вериги от инструменти, павирани пътища, инфраструктура за самообслужване и работни потоци – които DevOps и продуктовите екипи използват. Те може да притежават споделени CI/CD шаблони, стандартизирани Kubernetes клъстери, регистри на изображения, стекове за наблюдаемост и модели на разрешения.

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

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

Как SRE, DevOps и платформено инженерство си сътрудничат в съвременните екипи

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

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

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

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

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

Погледнато през тази призма, Site Reliability Engineering и DevOps не са съперничещи си лагери, а допълващи се перспективи по едно и също предизвикателство: стартиране на софтуерни продукти, които потребителите харесват, с темпо, изисквано от бизнеса, без да се изтощават хората, които ги поддържат живи. DevOps преобразява културата и предоставянето на услуги, така че промяната да може да протича непрекъснато; SRE превръща хаотичната реалност на производството в инженерна дисциплина с бюджети за грешки, SLO, силна автоматизация и строги ограничения на труда; платформеното инженерство изгражда споделените основи, на които и двете разчитат. Когато тези елементи са внимателно комбинирани, организациите могат да предоставят по-бързо услуги, да се възстановяват по-бързо от неизбежни повреди и да предлагат по-надеждни изживявания – всичко това, като същевременно предоставя на инженерите по-здравословен и по-устойчив начин на работа.