Уебинарът има лошо аудио, затова го преписахме.
Казвам се Медведев Едуард. Днес ще говоря за това какво е SRE, как се появи SRE, какви критерии за работа имат SRE инженерите, малко за критериите за надеждност, малко за неговото наблюдение. Ще се разходим по върховете, защото за час не можете да кажете много, но ще дам материали за допълнителен преглед и всички ви чакаме на . в Москва в края на януари.
Първо, нека поговорим за това какво е SRE - Site Reliability Engineering. И как се появи като отделна позиция, като отделно направление. Всичко започна с факта, че в традиционните развойни кръгове Dev и Ops са два напълно различни екипа, обикновено с две напълно различни цели. Целта на екипа за разработка е да внедри нови функции и да отговори на нуждите на бизнеса. Целта на екипа на Ops е да гарантира, че всичко работи и нищо не се поврежда. Очевидно тези цели директно си противоречат: за да работи всичко и нищо да не се повреди, внедрявайте нови функции възможно най-малко. Поради това има много вътрешни конфликти, които методологията, която сега се нарича DevOps, се опитва да разреши.
Проблемът е, че нямаме ясна дефиниция на DevOps и ясна реализация на DevOps. Говорих на конференция в Екатеринбург преди 2 години и досега секцията DevOps започваше с доклада „Какво е DevOps“. През 2017 г. Devops е почти на 10 години, но все още спорим какво е това. И това е много странна ситуация, която Google се опита да разреши преди няколко години.
През 2016 г. Google пусна книга, наречена Site Reliability Engineering. И всъщност с тази книга започна движението SRE. SRE е специфична реализация на парадигмата DevOps в конкретна компания. Инженерите на SRE се ангажират да гарантират, че системите работят надеждно. Те идват предимно от разработчици, понякога администратори със силен опит в разработката. И те правят това, което системните администратори правеха, но силният опит в разработката и познаването на системата от гледна точка на код води до факта, че тези хора не са склонни към рутинна административна работа, а са склонни към автоматизация.
Оказва се, че парадигмата DevOps в SRE екипите се прилага от факта, че има SRE инженери, които решават структурни проблеми. Ето я същата връзка между Dev и Ops, за която хората говорят от 8 години. Ролята на SRE е подобна на тази на архитекта, тъй като новодошлите не стават SRE. Хората в началото на своята кариера все още нямат никакъв опит, нямат необходимата широта на познанията. Тъй като SRE изисква много фини познания какво точно и кога точно може да се обърка. Следователно тук е необходим известен опит, като правило, както вътре в компанията, така и извън нея.
Те питат дали ще бъде описана разликата между SRE и devops. Току що е описана. Можем да говорим за мястото на СРЕ в организацията. За разлика от този класически подход на DevOps, където Ops все още е отделен отдел, SRE е част от екипа за разработка. Те участват в разработването на продукта. Има дори подход, при който SRE е роля, която преминава от един разработчик на друг. Те участват в прегледите на кода по същия начин, както например UX дизайнерите, самите разработчици, понякога продуктовите мениджъри. SRE работят на същото ниво. Трябва да ги одобрим, трябва да ги прегледаме, така че за всяко внедряване SRE да казва: „Добре, това внедряване, този продукт няма да повлияе отрицателно на надеждността. И ако има, то в някакви приемливи граници. Ще говорим и за това.
Съответно SRE има право на вето за промяна на кода. И като цяло това също води до някакъв малък конфликт, ако SRE е внедрен неправилно. В същата книга за Инженеринг за надеждност на обекта много части, нито дори една, казват как да се избегнат тези конфликти.
Те питат как SRE се свързва с информационната сигурност. SRE не участва пряко в информационната сигурност. По принцип в големите компании това се прави от отделни лица, тестери, анализатори. Но SRE също взаимодейства с тях в смисъл, че някои операции, някои ангажименти, някои внедрявания, които засягат сигурността, също могат да повлияят на наличността на продукта. Следователно SRE като цяло има взаимодействие с всякакви екипи, включително екипи за сигурност, включително анализатори. Следователно SRE са необходими главно, когато се опитват да внедрят DevOps, но в същото време тежестта върху разработчиците става твърде голяма. Тоест, самият екип за разработка вече не може да се справи с факта, че сега трябва да отговаря и за Ops. И има отделна роля. Тази роля е предвидена в бюджета. Понякога тази роля е заложена в размера на екипа, появява се отделен човек, понякога един от разработчиците става него. Така се появява първият SRE в отбора.
Сложността на системата, която е засегната от SRE, сложността, която влияе върху надеждността на операцията, е необходима и случайна. Необходима сложност е, когато сложността на даден продукт нараства до степента, изисквана от новите характеристики на продукта. Случайна сложност е, когато сложността на системата се увеличава, но характеристиките на продукта и бизнес изискванията не влияят пряко на това. Оказва се, че или разработчикът е допуснал грешка някъде, или алгоритъмът не е оптимален, или се въвеждат някакви допълнителни интереси, които увеличават сложността на продукта без особена нужда. Доброто SRE винаги трябва да прекъсва тази ситуация. Тоест всеки ангажимент, всяко внедряване, всяка заявка за изтегляне, при която трудността се увеличава поради произволно добавяне, трябва да бъдат блокирани.
Въпросът е защо просто не наемете инженер, системен администратор с много познания в екипа. Казват ни, че разработчик в ролята на инженер не е най-доброто решение за персонал. Разработчикът в ролята на инженер не винаги е най-доброто решение за персонал, но въпросът тук е, че разработчик, който се занимава с Ops, има малко повече желание за автоматизация, има малко повече знания и набор от умения, за да внедри тази автоматизация. И съответно намаляваме не само времето за някои специфични операции, не само рутинните, но и такива важни бизнес параметри като MTTR (Mean Time To Recovery, време за възстановяване). Така, а за това ще говорим малко по-късно, спестяваме пари за организацията.
Сега нека поговорим за критериите за функциониране на SRE. И преди всичко за надеждността. В малките компании, стартъпи, често се случва хората да предполагат, че ако услугата е написана добре, ако продуктът е написан добре и правилно, той ще работи, няма да се счупи. Това е, пишем добър код, така че няма какво да се счупи. Кодът е много прост, няма какво да се разбива. Това са горе-долу същите хора, които казват, че нямаме нужда от тестове, защото, вижте, това са трите VPI метода, защо да прекъсвате тук.
Всичко това е грешно, разбира се. И тези хора много често биват ухапани от такъв код на практика, защото нещата се чупят. Понякога нещата се развалят по най-непредсказуем начин. Понякога хората казват не, това никога няма да се случи. И това се случва през цялото време. Случва се достатъчно често. И затова никой никога не се стреми към 100% наличност, защото 100% наличност никога не се случва. Това е норма. И затова, когато говорим за наличие на услуга, винаги говорим за деветки. 2 деветки, 3 деветки, 4 деветки, 5 деветки. Ако преведем това в престой, тогава, например, 5 деветки, тогава това е малко повече от 5 минути престой на година, 2 деветки е 3,5 дни престой.
Но е очевидно, че в един момент има намаляване на POI, възвръщаемост на инвестициите. Преминаването от две деветки на три деветки означава по-малко престой с повече от 3 дни. Преминаването от четири деветки на пет намалява времето за престой с 47 минути годишно. И се оказва, че за бизнеса може да не е критично. И като цяло, изискваната надеждност не е технически въпрос, на първо място, това е бизнес въпрос, това е продукт. Какво ниво на престой е приемливо за потребителите на продукта, какво очакват, колко плащат, например колко пари губят, колко пари губи системата.
Важен въпрос тук е каква е надеждността на останалите компоненти. Защото разликата между 4 и 5 деветки няма да се вижда на смартфон с 2 деветки надеждност. Грубо казано, ако нещо се повреди на смартфон във вашия сервиз 10 пъти годишно, най-вероятно 8 пъти повредата е настъпила от страна на операционната система. Потребителят е свикнал с това и няма да обръща внимание още веднъж в годината. Необходимо е да се съпостави цената на увеличаване на надеждността и увеличаване на печалбите.
Просто в книгата за SRE има добър пример за увеличаване на 4 деветки от 3 деветки. Оказва се, че увеличението на наличността е малко под 0,1%. И ако приходите от услугата са $1 милион годишно, тогава увеличението на приходите е $900. Ако ни струва по-малко от 900 долара годишно, за да увеличим достъпността с девет, увеличението има финансов смисъл. Ако струва повече от 900 долара годишно, вече няма смисъл, защото увеличението на приходите просто не компенсира разходите за труд, разходите за ресурси. И 3 деветки ще ни стигнат.
Това разбира се е опростен пример, при който всички заявки са равни. И преминаването от 3 деветки на 4 деветки е достатъчно лесно, но в същото време, например, преминаването от 2 деветки на 3, това вече е спестяване от 9 хиляди долара, може да има финансов смисъл. Естествено, в действителност неуспехът на заявката за регистрация е по-лош от неуспеха да се покаже страницата, заявките имат различна тежест. Те могат да имат съвсем различен критерий от бизнес гледна точка, но така или иначе, като правило, ако не говорим за някои конкретни услуги, това е доста надеждно приближение.
Получихме въпрос дали SRE е един от координаторите при избора на архитектурно решение за услугата. Да кажем по отношение на интегрирането в съществуващата инфраструктура, за да няма загуба на нейната стабилност. Да, SRE, по същия начин, по който заявките за изтегляне, ангажиментите, освобождаванията засягат архитектурата, въвеждането на нови услуги, микроуслуги, внедряването на нови решения. Защо казах преди, че трябва опит, трябват квалификации. Всъщност SRE е един от блокиращите гласове във всяко архитектурно и софтуерно решение. Съответно SRE като инженер трябва преди всичко не само да разбере, но и да разбере как някои специфични решения ще повлияят на надеждността, стабилността и да разбере как това е свързано с бизнес нуждите и от каква гледна точка може да бъде приемливо и което не.
Следователно сега можем да говорим само за критерии за надеждност, които традиционно се определят в SRE като SLA (Service Level Agreement). Най-вероятно познат термин. SLI (Индикатор за ниво на обслужване). SLO (Цел за ниво на обслужване). Споразумението за ниво на обслужване е може би символичен термин, особено ако сте работили с мрежи, с доставчици, с хостинг. Това е общо споразумение, което описва представянето на цялата ви услуга, санкции, някои санкции за грешки, показатели, критерии. А SLI е самият показател за наличност. Тоест какво може да бъде SLI: време за реакция от услугата, брой грешки като процент. Може да е честотна лента, ако е някакъв вид хостинг на файлове. Когато става въпрос за алгоритми за разпознаване, индикаторът може да бъде например дори правилността на отговора. SLO (Service Level Objective) е съответно комбинация от индикатора SLI, неговата стойност и период.
Да кажем, че SLA може да бъде така. Услугата е достъпна 99,95% от времето през цялата година. Или 99 критични заявки за поддръжка ще бъдат затворени в рамките на 3 часа на тримесечие. Или 85% от запитванията ще получат отговор в рамките на 1,5 секунди всеки месец. Тоест, постепенно разбираме, че грешките и неуспехите са нещо съвсем нормално. Това е приемлива ситуация, планираме я, дори донякъде разчитаме. Тоест SRE изгражда системи, които могат да грешат, които трябва да реагират нормално на грешки, които трябва да ги вземат под внимание. И когато е възможно, те трябва да обработват грешките по такъв начин, че потребителят или да не ги забележи, или да забележи, но има някакво решение, благодарение на което всичко няма да падне напълно.
Например, ако качите видеоклип в YouTube и YouTube не може да го конвертира веднага, ако видеоклипът е твърде голям, ако форматът не е оптимален, тогава заявката естествено няма да се провали с изчакване, YouTube няма да даде грешка 502 , YouTube ще каже: „Създадохме всичко, вашето видео се обработва. Ще бъде готово след около 10 минути." Това е принципът на грациозната деградация, който е познат, например, от front-end разработката, ако някога сте правили това.
Следващите термини, за които ще говорим, които са много важни за работа с надеждност, с грешки, с очаквания, са MTBF и MTTR. MTBF е средното време между отказите. MTTR Mean Time To Recovery, средно време за възстановяване. Тоест колко време е минало от момента на откриване на грешката, от момента на появата на грешката до момента на възстановяване на услугата до пълно нормално функциониране. MTBF се коригира главно чрез работа върху качеството на кода. Тоест фактът, че SRE могат да кажат „не“. И трябва разбиране на целия екип, че когато SRE казва "не", той го казва не защото е вреден, не защото е лош, а защото иначе всички ще страдат.
Отново, има много статии, много методи, много начини дори в самата книга, която споменавам толкова често, как да се уверите, че другите разработчици няма да започнат да мразят SRE. MTTR, от друга страна, е за работа върху вашите SLO (цел на нивото на обслужване). И това е предимно автоматизация. Защото, например, нашият SLO е ъптайм от 4 деветки на тримесечие. Това означава, че за 3 месеца можем да позволим 13 минути престой. И се оказва, че MTTR не може да бъде повече от 13 минути. Ако реагираме на поне 13 престой за 1 минути, това означава, че вече сме изчерпали целия бюджет за тримесечието. Ние нарушаваме SLO. 13 минути за реакция и отстраняване на срив са много за машина, но много малко за човек. Защото докато човек получи сигнал, докато реагира, докато разбере грешката, минават вече няколко минути. Докато човек разбере как да го оправи, какво точно да оправи, какво да направи, тогава това са още няколко минути. И всъщност, дори ако просто трябва да рестартирате сървъра, както се оказва, или да създадете нов възел, тогава ръчно MTTR вече е около 7-8 минути. При автоматизиране на процеса MTTR много често достига секунда, понякога милисекунди. Google обикновено говори за милисекунди, но в действителност, разбира се, всичко не е толкова добро.
В идеалния случай SRE трябва да автоматизира работата си почти напълно, защото това пряко засяга MTTR, неговите показатели, SLO на цялата услуга и съответно печалбата на бизнеса. Ако времето е превишено, ще бъдем попитани дали SRE е виновен. За щастие няма виновни. И това е отделна култура, наречена balmeless postmortem, за която няма да говорим днес, но ще я анализираме на Slurm. Това е много интересна тема, по която може да се говори много. Грубо казано, ако определеното време на тримесечие е превишено, тогава всеки е виновен по малко, което означава, че обвиняването на всички не е продуктивно, нека вместо това може би да не обвиняваме никого, но да коригираме ситуацията и да работим с това, което имаме. Според моя опит този подход е малко чужд на повечето отбори, особено в Русия, но има смисъл и работи много добре. Затова ще препоръчам в края на статията и литература, която можете да прочетете по тази тема. Или елате в Slurm SRE.
Нека обясня. Ако SLO времето на тримесечие е превишено, ако времето на престой не е 13 минути, а 15, кой може да бъде виновен за това? Разбира се, SRE може да е виновен, защото той очевидно е направил някакъв лош ангажимент или внедряване. Администраторът на центъра за данни може да е виновен за това, защото може да е извършил някаква непланирана поддръжка. Ако за това е виновен администратора на дата центъра, то за това е виновен човекът от Ops, който не е калкулирал поддръжката, когато е координирал SLO. Виновен за това е мениджърът, техническият директор или някой, който е подписал договора за центъра за данни и не е обърнал внимание на факта, че SLA на центъра за данни не е проектиран за необходимия престой. Съответно всички малко по малко в тази ситуация са виновни. И това означава, че няма смисъл да хвърляме вина върху когото и да било в тази ситуация. Но разбира се трябва да се коригира. Затова има аутопсии. И ако четете, например, GitHub postmortems и това винаги е много интересна, малка и неочаквана история във всеки случай, можете да замените, че никой никога не казва, че този конкретен човек е виновен. Вината винаги е върху конкретни несъвършени процеси.
Да преминем към следващия въпрос. Автоматизация. Когато говоря за автоматизация в друг контекст, често се позовавам на таблица, която ви казва колко дълго можете да работите върху автоматизирането на дадена задача, без да отделяте повече време за автоматизирането й, отколкото всъщност спестявате. Има една спънка. Уловката е, че когато SRE автоматизират задача, те не само спестяват време, но и пари, защото автоматизацията пряко засяга MTTR. Те спестяват, така да се каже, морала на служителите и разработчиците, което също е изчерпаем ресурс. Те намаляват рутината. И всичко това има положителен ефект върху работата и в резултат на това върху бизнеса, дори ако изглежда, че автоматизацията няма смисъл от гледна точка на разходите за време.
Всъщност почти винаги е така и има много малко случаи, когато нещо не трябва да бъде автоматизирано в ролята на SRE. След това ще говорим за това, което се нарича бюджет за грешки, бюджет за грешки. Всъщност се оказва, че ако всичко е много по-добро за вас от SLO, което сте си поставили, това също не е много добро. Това е доста лошо, защото SLO работи не само като долна, но и като приблизителна горна граница. Когато си зададете SLO от 99% наличност, а всъщност имате 99,99%, се оказва, че имате малко пространство за експерименти, които изобщо няма да навредят на бизнеса, защото вие сами сте определили всичко това заедно и сте това пространство не се използва. Имате бюджет за грешки, който във вашия случай не е изразходван.
Какво правим с него. Използваме го буквално за всичко. За тестване в производствени условия, за внедряване на нови функции, които могат да повлияят на производителността, за издания, за поддръжка, за планирани престои. Важи и обратното правило: ако бюджетът е изчерпан, не можем да пуснем нищо ново, защото в противен случай ще надхвърлим SLO. Бюджетът вече е изчерпан, ние пуснахме нещо, ако това се отразява негативно на производителността, тоест ако това не е някаква корекция, която сама по себе си директно увеличава SLO, тогава излизаме извън бюджета и това е лоша ситуация , той трябва да бъде анализиран, следсмъртно и евентуално някои корекции на процеса.
Тоест, оказва се, че ако самата услуга не работи добре и SLO се изразходва и бюджетът се изразходва не за експерименти, не за някои версии, а сам по себе си, тогава вместо някои интересни корекции, вместо интересни функции, вместо интересни издания. Вместо творческа работа, ще трябва да се занимавате с глупави корекции, за да върнете бюджета в ред или да редактирате SLO, а това също е процес, който не трябва да се случва твърде често.
Следователно се оказва, че в ситуация, в която имаме повече бюджет за грешки, всички са заинтересовани: и SRE, и разработчиците. За разработчиците голям бюджет за грешки означава, че можете да се справите с версии, тестове, експерименти. За SRE бюджетът за грешки и въвеждането на този бюджет означава, че те директно вършат работата си добре. И това се отразява на мотивацията за някакъв вид съвместна работа. Ако слушате вашите SRE като разработчици, ще имате повече място за добра работа и много по-малко рутина.
Оказва се, че експериментите в производството са доста важна и почти неразделна част от SRE в големите екипи. И обикновено се нарича хаос инженерство, което идва от екипа на Netflix, който пусна помощна програма, наречена Chaos Monkey.
Chaos Monkey се свързва с CI/CD тръбопровода и произволно срива сървъра в производството. Отново в структурата на SRE говорим за факта, че сваленият сървър не е лош сам по себе си, очаква се. И ако е в рамките на бюджета, това е приемливо и не вреди на бизнеса. Разбира се, Netflix има достатъчно излишни сървъри, достатъчно репликация, така че всичко това да може да бъде коригирано и така че потребителят като цяло дори да не забележи, и още повече, че никой не напуска един сървър за какъвто и да е бюджет.
Известно време Netflix имаше цял набор от такива помощни програми, една от които, Chaos Gorilla, напълно изключва една от зоните за достъпност на Amazon. И такива неща помагат да се разкрият, първо, скрити зависимости, когато не е напълно ясно какво влияе на какво, какво зависи от какво. И това, ако работите с микроуслуга и документацията не е съвсем перфектна, това може да ви е познато. И отново, това помага много за улавяне на грешки в кода, които не можете да хванете при етапиране, защото всяко етапиране не е точно точна симулация, поради факта, че мащабът на натоварване е различен, моделът на натоварване е различен, оборудването е също, най-вероятно, друго. Пиковите натоварвания също могат да бъдат неочаквани и непредвидими. И такова тестване, което отново не надхвърля бюджета, помага много добре да се уловят грешки в инфраструктурата, които етапите, автотестовете, CI / CD тръбопроводът никога няма да уловят. И докато всичко това е включено в бюджета ви, няма значение, че услугата ви падна там, въпреки че би изглеждало много страшно, сървърът падна, какъв кошмар. Не, това е нормално, това е добре, това помага за хващане на грешки. Ако имате бюджет, можете да го похарчите.
Въпрос: Каква литература мога да препоръчам? Списък накрая. Има много литература, ще посъветвам няколко доклада. Как работи и работи ли SRE във фирми без собствен софтуерен продукт или с минимално развитие. Например в предприятие, където основната дейност не е софтуер. В едно предприятие, където основната дейност не е софтуер, SRE работи точно както навсякъде другаде, защото в едно предприятие също трябва да използвате, дори и да не са разработени, софтуерни продукти, трябва да пускате актуализации, трябва да промените инфраструктурата, трябва да растете, трябва да мащабирате. И SRE помагат да се идентифицират и предвидят възможни проблеми в тези процеси и да ги контролират, след като започне известен растеж и нуждите на бизнеса се променят. Защото абсолютно не е необходимо да се занимавате с разработка на софтуер, за да имате SRE, ако имате поне няколко сървъра и се очаква да имате поне някакъв растеж.
Същото важи и за малки проекти, малки организации, защото големите компании имат бюджета и пространството да експериментират. Но в същото време всички тези плодове на експерименти могат да се използват навсякъде, тоест SRE, разбира се, се появи в Google, в Netflix, в Dropbox. Но в същото време малките компании и стартиращи компании вече могат да четат съкратен материал, да четат книги, да гледат репортажи. Започват да чуват за това по-често, разглеждат конкретни примери, мисля, че е добре, наистина може да бъде полезно, имаме нужда и от това, страхотно е.
Тоест цялата основна работа по стандартизирането на тези процеси вече е извършена за вас. Остава да определите ролята на SRE конкретно във вашата компания и да започнете реално да прилагате всички тези практики, които отново вече бяха описани. Тоест, от полезни принципи за малки компании, това винаги е определението за SLA, SLI, SLO. Ако не се занимавате със софтуер, тогава това ще бъдат вътрешни SLA и вътрешни SLO, вътрешен бюджет за грешки. Това почти винаги води до някои интересни дискусии в екипа и в бизнеса, защото може да се окаже, че харчите за инфраструктура, за някаква организация на идеални процеси, идеалният тръбопровод е много повече от необходимото. И тези 4 деветки, които имате в ИТ отдела, всъщност не ви трябват сега. Но в същото време можете да отделите време, да похарчите бюджета за грешки за нещо друго.
Съответно, наблюдението и организирането на наблюдение е полезно за компания от всякакъв размер. И като цяло, този начин на мислене, където грешките са нещо приемливо, където има бюджет, където има Цели, той отново е полезен за компания от всякакъв размер, като се започне от стартъпи за 3 души.
Последният от техническите нюанси, за които трябва да се говори, е мониторингът. Защото, ако говорим за SLA, SLI, SLO, не можем да разберем без да наблюдаваме дали се вписваме в бюджета, дали спазваме целите си и как влияем върху крайния SLA. Виждал съм толкова много пъти, че наблюдението се случва по следния начин: има някаква стойност, например времето на заявка към сървъра, средното време или броя на заявките към базата данни. Той има стандарт, определен от инженер. Ако показателят се отклонява от нормата, тогава пристига имейл. Всичко това е абсолютно безполезно, като правило, защото води до такова пренасищане от сигнали, пренасищане от съобщения от мониторинга, когато човек, първо, трябва да ги интерпретира всеки път, тоест да определи дали стойността на показателя означава необходимостта от някакво действие. И второ, той просто спира да забелязва всички тези сигнали, когато по същество не се изисква никакво действие от него. Това е добро правило за наблюдение и първото правило, когато се прилага SRE, е, че известието трябва да идва само когато е необходимо действие.
В стандартния случай има 3 нива на събития. Има сигнали, има билети, има логове. Сигналите са всичко, което изисква от вас незабавно действие. Тоест всичко е счупено, трябва да го поправите веднага. Билетите са това, което изисква отложено действие. Да, трябва да направите нещо, трябва да направите нещо ръчно, автоматизацията е неуспешна, но не е нужно да го правите през следващите няколко минути. Логовете са всичко, което не изисква действие и като цяло, ако нещата вървят добре, никой никога няма да ги прочете. Ще трябва да прочетете регистрационните файлове само когато в ретроспекция се окаже, че нещо се е счупило за известно време, ние не сме знаели за това. Или трябва да направите някои изследвания. Но като цяло всичко, което не изисква никакви действия, отива в регистрационните файлове.
Като страничен ефект от всичко това, ако сме дефинирали какви събития изискват действия и сме описали добре какви трябва да бъдат тези действия, това означава, че действието може да бъде автоматизирано. Тоест какво се случва. Тръгваме от тревога. Да вървим към действие. Преминаваме към описанието на това действие. И тогава преминаваме към автоматизацията. Тоест всяка автоматизация започва с реакция на събитие.
От мониторинг преминаваме към термин, наречен Наблюдаемост. През последните няколко години около тази дума също имаше малко шум. И малко хора разбират какво означава извън контекста. Но основното е, че наблюдаемостта е показател за прозрачност на системата. Ако нещо се е объркало, колко бързо можете да определите какво точно се е объркало и какво е било състоянието на системата в този момент. По отношение на кода: коя функция е неуспешна, коя услуга е неуспешна. Какво беше състоянието на, например, вътрешни променливи, конфигурация. От гледна точка на инфраструктурата, това е в коя зона на достъпност е възникнала грешката и ако имате Kubernetes, тогава в коя група е възникнала грешката, какво е било състоянието на групата. И съответно Observability има пряка връзка с MTTR. Колкото по-висока е наблюдаемостта на услугата, толкова по-лесно е да се идентифицира грешката, толкова по-лесно е да се коригира грешката, толкова по-лесно е да се автоматизира грешката, толкова по-нисък е MTTR.
Преминавайки отново към малките компании, много често се пита, дори и сега, как да се справим с размера на екипа и дали малък екип трябва да наеме отделен SRE. Вече говорихме за това малко по-рано. На първите етапи от развитието на стартиране или например екип това изобщо не е необходимо, тъй като SRE може да се превърне в преходна роля. И това ще съживи малко отбора, защото има поне някакво разнообразие. Освен това ще подготви хората за факта, че с растежа, като цяло, отговорностите на SRE ще се променят значително. Ако наемете човек, тогава, разбира се, той има някакви очаквания. И тези очаквания няма да се променят с времето, но изискванията ще се променят много. Следователно как да наемете SRE е доста трудно в ранните етапи. Отглеждането на собствено е много по-лесно. Но си струва да се замислим.
Единственото изключение може би е, когато има много строги и добре дефинирани изисквания за растеж. Тоест, в случай на стартиране, това може да е някакъв натиск от страна на инвеститорите, някаква прогноза за растеж няколко пъти наведнъж. Тогава наемането на SRE е основно оправдано, защото може да бъде оправдано. Имаме изисквания за растеж, имаме нужда от човек, който ще отговаря за това, че при такъв растеж нищо няма да се счупи.
Още един въпрос. Какво да направите, когато няколко пъти разработчиците изрязват функция, която преминава тестовете, но нарушава производството, зарежда базата, прекъсва други функции, какъв процес да внедрите. Съответно в този случай се въвежда бюджетът за грешки. И някои от услугите, някои от функциите вече се тестват в производството. Може да бъде канарче, когато само малък брой потребители, но вече в производството, се внедрява функция, но вече с очакването, че ако нещо се счупи, например за половин процент от всички потребители, то пак ще отговаря на бюджет за грешки. Съответно, да, ще има грешка, за някои потребители всичко ще се счупи, но вече казахме, че това е нормално.
Имаше въпрос относно SRE инструментите. Тоест има ли нещо конкретно, което SRE биха използвали, което всички останали не биха използвали. Всъщност има някои високоспециализирани помощни програми, има някакъв софтуер, който например симулира натоварвания или се занимава с канарско A / B тестване. Но основно инструментариумът SRE е това, което вашите разработчици вече използват. Тъй като SRE взаимодейства директно с екипа за разработка. И ако имате различни инструменти, ще се окаже, че трябва време за синхронизиране. Особено ако SRE работят в големи екипи, в големи компании, където може да има няколко екипа, стандартизацията в цялата компания ще помогне много тук, защото ако 50 различни помощни програми се използват в 50 екипа, това означава, че SRE трябва да ги познава всичко. И разбира се това никога няма да се случи. И качеството на работа, качеството на контрол на поне част от екипите ще намалее значително.
Нашият уебинар е към своя край. Успях да кажа някои основни неща. Разбира се, нищо за SRE не може да се каже и разбере за час. Но се надявам, че успях да предам този начин на мислене, основните ключови точки. И тогава ще бъде възможно, ако се интересувате, да се задълбочите в темата, да научите сами, да видите как се прилага от други хора, в други компании. И съответно в началото на февруари елате при нас в Slurm SRE.
Slurm SRE е тридневен интензивен курс, който ще говори за това, за което говоря сега, но с много повече дълбочина, с реални случаи, с практика, целият интензив е насочен към практическа работа. Хората ще бъдат разделени на екипи. Всички ще работите по реални случаи. Съответно имаме инструктори от Booking.com Иван Круглов и Бен Тайлър. Имаме прекрасен Юджийн Барабас от Google, от Сан Франциско. И аз ще ти кажа нещо. Така че не пропускайте да ни посетите.
И така, библиографията. Има препратки към SRE. на една и съща книга, или по-скоро на 2 книги за SRE, написани от Google. Друг , където условията и тяхното приложение са малко по-подробни. Следващите 3 са доклади за SRE в различни компании. първо - , това е основна бележка от Бен Трейнър от Google. второ - . Третият е пак . Четвърти доклад от , която има само 5 ключови служители на SRE в 190 страни. Много е интересно да се разгледа всичко това, защото точно както DevOps означава много различни неща за различните компании и дори различни екипи, SRE има много различни отговорности, дори в компании с подобни размери.
Още 2 връзки за принципите на инженерството на хаоса: , . И накрая има 3 списъка от поредицата Awesome Lists about , относно и за . Списъкът на SRE е невероятно огромен, не е необходимо да го разглеждате целия, има около 200 статии. Горещо препоръчвам статии от там за планиране на капацитета и за безупречен постморт.
Интересна статия:
Благодаря ти, че ме изслуша през цялото това време. Дано си научил нещо. Надяваме се, че имате достатъчно материал, за да научите още повече. И ще се видим. Надяваме се през февруари.
Уебинарът беше воден от Едуард Медведев.
PS: за тези, които обичат да четат, Едуард даде списък с препратки. Който предпочита да разбере на практика, е добре дошъл .
Източник: www.habr.com